Midiendo la Ocupación vs Midiendo los Resultados

 

Lee la transcripción:

Estamos probando transcribir nuestros pódcasts utilizando un programa de software. Por favor, perdona cualquier error tipográfico ya que el bot no es 100% preciso.

Galen Low: Pregunta relámpago: estás a mitad de tu proyecto y todas tus métricas se ven geniales. Tu proveedor ha gastado el número acordado de horas y la velocidad y utilización de tu equipo están exactamente donde lo planeaste.

Pero a pesar de que tu proyecto tiene un excelente informe de salud, el producto sigue sin cumplir las expectativas en los grupos de enfoque y pruebas de usuarios. La tecnología que tanto quería tu patrocinador ejecutivo rápidamente se está quedando obsoleta, dificultando los cambios. Y la moral de tu equipo está baja: cuando les pides soluciones, se encogen de hombros y dicen que hicieron lo que les pidieron dentro del tiempo establecido.

Entonces, ¿cómo puede tu proyecto estar sano si el resultado no produce el valor pretendido?

Si has notado que tus métricas de proyecto miden más la ocupación que el valor, sigue escuchando. Vamos a profundizar en la mecánica práctica de cómo los equipos de proyecto pueden medir el valor y explorar ideas para cambiar el incentivo de horas invertidas a valor creado.

Hola a todos, gracias por sintonizarnos. Mi nombre es Galen Low y soy parte de The Digital Project Manager. Somos una comunidad de profesionales digitales con la misión de ayudarnos a desarrollar habilidades, ganar confianza y conectar, para así amplificar el valor de la gestión de proyectos en el mundo digital. Si quieres saber más, dirígete a thedigitalprojectmanager.com.

Muy bien. Hoy hablaremos sobre la diferencia entre medir la salud y el progreso de un proyecto frente a medir su éxito. ¿Es suficiente rastrear la velocidad del equipo y el desempeño de costos? ¿O también es nuestra responsabilidad como líderes de proyectos medir los resultados e impactos del proyecto?

Hoy me acompaña Fred Fowler, un Scrum Master certificado nivel 3 que ha publicado varios libros sobre la metodología Scrum, es organizador del grupo Silicon Valley Professional Scrum con unos 2000 miembros, lidera una comunidad Scrum similar en Shanghái, China, y organizó la primera conferencia Silicon Valley Scrummit. Así que, en pocas palabras, conoce uno que otro truco sobre Scrum.

¡Bienvenido, Fred!

Fred Fowler: ¡Hola! Gracias por invitarme al programa.

Galen Low: Un placer tenerte aquí.

Fred Fowler: Yo me defino como "tipo scrum". Aunque algunos dirían que soy "scrumcious".

Galen Low: Eso es mejor a que yo dijera Fred "scrum de la tierra".

Fred Fowler: Hay muchas formas de jugar con la palabra scrum. Puedes decir “scrumbag” o lo que sea. En fin, adelante.

Galen Low: De acuerdo. Tienes un historial muy interesante y creo que eso dará a los oyentes buen contexto sobre tu visión en métricas de proyectos. Si entiendo bien, empezaste como programador, luego entraste en política, fuiste alcalde y después CIO antes de usar tu poco usual certificación Scrum Master nivel 3 para ayudar a otros.

Entonces me pregunto, ¿podrías contarnos un poco sobre tu trayecto y cómo esas experiencias han moldeado tu visión actual?

Fred Fowler: Bueno, yo diría que mi carrera pareció estar dentro de una máquina de pinball.

Comencé como programador en 1980. Una época antigua, trabajando en una máquina tan grande y pesada que requería equipo especial para moverla y era menos potente que un teléfono de hoy. Pero gestionábamos una división de una empresa de semiconductores con ella, allí aprendí mis habilidades.

Me moví porque Silicon Valley estaba en sus primeras etapas, eso significaba mucha volatilidad de voluntarios. Así que en los primeros ocho años trabajé en cinco empresas distintas. Mucha, como digo, volatilidad, y al final concluí que necesitaba seguridad laboral, mejor trabajar para mí mismo.

Así que me convertí en consultor y trabajé con 60 empresas en los siguientes 10 años, siempre aplicando tecnología para resolver problemas de negocio, que es de lo que trata todo esto. Y luego una de esas empresas para las que trabajé como consultor me hizo una oferta que no pude rechazar, terminé gestionando su operación de TI, fui CIO e implementé muchas técnicas que en realidad eran scrum, aunque no lo sabía entonces. Empoderar a las personas para que resuelvan problemas, justificar el trabajo basado en el retorno de inversión.

En esos días, hice muchos proyectos que fundamentaron mi visión sobre la organización de esfuerzos. Hay cosas de las que estoy orgulloso. Por ejemplo, la empresa había construido un sitio web con una gran empresa de computadoras de tres letras que todos conocen. Pagaron un cuarto de millón de dólares por una solución de eCommerce bastante patética. Yo vi la oportunidad de mejora, así que organicé un proyecto, usando scrum.

Había dos tecnologías diferentes. Un legado, un mini ordenador IBM AS/400. Ese era el backend, pero necesitábamos un frontend, así que fui a China, hallé una pequeña empresa ambiciosa para el frontend. Organizamos el equipo de EE.UU. para el backend, el de China para el frontend, solo había que lograr la comunicación entre plataformas.

Resultó ser simple. Así que reemplazamos un trabajo de un cuarto de millón de dólares con un sitio web que en seis meses representaba el 40% del negocio, gastando $14,000. Solo $14,000. La clave era comprender qué era importante medir.

Cuando hablas de equipos offshore, todos se inquietan: “¿cómo sabemos qué hacen?”. Quieren herramientas para medir cuán ocupados están. Queremos que estén ocupados todo el tiempo, ¿verdad? ¿Adivina qué? Eso no importa. No importa si las personas offshore están ocupadas o no. Lo importante es lo que entregan y el valor de eso. ¡Eso es lo que debes medir! Olvídate de medir con cronómetros.

He aquí un ejemplo: un equipo de 200 personas trabajando 8 o 10 horas al día durante dos años frente a un equipo de 10 trabajando horas normales durante un año. ¿Quién crees que aporta más valor? Pues los 200 crearon healthcare.gov, que fue un desastre. Era para implementar el ObamaCare y fracasó, porque medían lo ocupados que estaban. Los 10 que lo rehicieron al año siguiente sí generaron valor.

Galen Low: Profundicemos, tocas una gran cuestión. Mencionas una razón por la que medimos la ocupación, pero en el mundo de agencia y consultoría, todo es horas facturables, utilización, cuántos bugs resolvimos o tareas completamos. ¿Por qué medimos la ocupación?

Fred Fowler: Fácil. Porque es simple de medir. Solo necesitas un reloj para ver la ocupación, un calendario para verificar los plazos. Es fácil. Además, es base de la compensación.

Mencionaste horas facturables, una gran falacia. El tiempo de las personas es valioso para ellas, pero lo que te importa a ti es qué hacen con ese tiempo. Sería mejor medir el resultado. Les digo a las empresas: dividan el valor a crear en partes medibles y midan el progreso según el valor creado. Lean lo llama producto mínimo viable.

Haces lo necesario para poner algo en manos del cliente y que él mismo te diga cuánto vale. Así puedes evaluar si valió la pena la inversión.

Si una app cuesta medio millón crearla, ¿es buena inversión? Si logra 3 millones de descargas a 2 dólares, acabas de ganar 6 millones con una inversión de medio millón. Lo haría siempre. Si solo logra 25,000 descargas, invertiste 500,000 por 50,000 de valor. Mismas horas, pero distinto valor: eso es lo importante.

Galen Low: Mencionaste algo fundamental del producto mínimo viable. Volviendo a lo anterior, a veces medimos la ocupación por confianza. Si les cronometramos, al menos sabemos las horas. Pero eso no mide el valor.

Me preguntan: “necesitamos horas facturables, es el contrato, la compensación, es el trato”. Pero como dijiste: creémoslo, démoselo al cliente y que él decida el valor. A veces quieren conocer su valor antes de gastar, pero no sucede así. Tienes 50,000, construyes y solo después sabes si alcanza el valor esperado.

Pero, ¿sientes que es un mal necesario o debemos superarlo?

Fred Fowler: En cierto modo es un mal necesario. Pero tienes que comparar el costo con el resultado valioso. Scrum dice que siempre hay que entregar algo terminado y listo para el cliente al final de cada sprint, ¿por qué crees?

Galen Low: Supongo que para que sea un valor medible.

Fred Fowler: Exactamente. Eso es valor: cuando está terminado y listo para el cliente.

Así mides el valor: lo que el cliente pagará. Scrum te exige crear algo valioso cada dos semanas para medir ese valor y compararlo con el costo. Así sabes si vas por buen camino. Hay que descomponer el trabajo en partes de valor medible, no suposiciones: valor medible.

Scrum enfatiza decidir basado en datos medibles, no en opiniones. Y lo más importante de medir es el valor.

Galen Low: ¿Podrías guiarnos en la medición del valor? Si medir la ocupación no es útil, ¿qué métricas debería medir un equipo Scrum? ¿Quién evalúa y cómo se rastrea si algo es valioso en cada sprint?

Fred Fowler: En Scrum, la medición del valor realmente es tarea de una persona. Scrum divide responsabilidades en tres: el Product Owner, los desarrolladores y el Scrum Master.

El Product Owner debe maximizar el valor del trabajo del equipo. No puedes maximizar lo que no puedes medir. Si no puedes medir qué intentas maximizar, no sabes si mejoras o empeoras.

Existen cuatro formas de aumentar valor: la más común es el ingreso. Por ejemplo, una app vendida 3 millones de veces a 2 dólares equivale a 6 millones de valor. Otro es reducir costos, por ejemplo, si haces un millón de unidades y bajas 50 centavos por unidad, generas 500,000 de ahorro. La tercera es reducir riesgos. Cuando fui CIO, nuestra empresa dependía de una conexión de fibra, y cada año un accidente nos dejaba sin conexión y 1 millón de dólares de pérdida. Moví el data center a otro lugar seguro por 50,000 y eliminé ese riesgo de un millón anual.

Galen Low: ¿Solo te costó 50K mover tu data center? ¡Genial!

Fred Fowler: Sí, rentamos espacio en racks. Así que eso es reducir riesgos: fácil de medir. Cuarto: aumentar oportunidades. Si en una licitación ganabas 1 de cada 6 y de pronto 2 de 6, puedes sumar ese valor extra y compararlo con el costo para decidir racionalmente.

Galen Low: Entonces el Product Owner mide todo ese valor, los cuatro aspectos. ¿Cómo lo comunica al equipo?

Fred Fowler: El Product Owner mide y decide racionalmente en qué debe trabajar el equipo. No puedes medir el valor de algo que no existe. Mientras el producto no exista, el Product Owner debe adivinar qué será valioso, hacer una inversión, como comprar acciones. Luego el equipo crea, se entrega a usuarios y se mide realmente el valor generado. Así se toman decisiones de inversión, y es la clave: inversiones. Puedes evaluar la gestión del Owner por el retorno recibido: ¿te dan más de lo que inviertes por sprint?

No es solo tarea del Owner, el equipo también debe interesarse, porque si no generan valor, ¿cómo esperan recibir el pago?

Galen Low: Es una gran frase. Porque a veces asumimos que si hacemos las horas prometidas, nos deben pagar, pero eso no habla de valor.

Fred Fowler: Exactamente. Cuando los desarrolladores comprenden esto, ven que les interesa que sea valioso su trabajo.

Así, es una alianza. El Product Owner no es un rol técnico sino de negocio; debe identificar qué es valioso. Los desarrolladores aportan lo que es posible técnicamente. Negocian para definir qué es lo más práctico y valioso de realizar. De eso se trata Scrum: de negociación entre quienes tienen responsabilidades en esas áreas y llegar al producto más valioso y factible. El Owner entiende el negocio. Los desarrolladores entienden la tecnología, juntos resuelven problemas de negocio aplicando tecnología. ¡Listo!

Galen Low: Me gusta la palabra "alianza", porque no muchos lo ven así. Algunos piensan que solo se hace lo que decide el Product Owner, pero Scrum en realidad es sobre empoderamiento y negociación entre valor de negocio y lo factible técnicamente para obtener el producto más valioso posible, sin disparar los costos.

Fred Fowler: Así es. Y los desarrolladores pueden influir en el costo más de lo que parece. Por ejemplo, para un app con información personal, el Owner pide un login tradicional y toda la funcionalidad relacionada. Pero los desarrolladores podrían sugerir usar "Iniciar sesión con Google" o Facebook, integrando sistemas ya existentes en vez de reinventar la rueda y perdiendo tiempo. Los desarrolladores deben pensar: ¿Cómo resolvemos el problema del Owner? Quizá con reconocimiento facial, lectores de huella, etc. Negocian para elegir la solución más fácil que aporte valor, luego crean una pieza entregable y medible.

Galen Low: Porque he pecado de medir ocupación o velocidad. Seguimos usando velocidad, burndown charts, pero ¿cómo se ven las discusiones sobre valor en tus equipos Scrum? El Product Owner dice: "Queríamos que valiera $65 pero el mercado solo paga $60", ¿o informan y ajustan rumbo cada sprint? ¿Intentan maximizar el valor sobre ese indicador, o solo cambian el enfoque?

Fred Fowler: Todo se resume en la compensación, como mencionaste. Si pagan por hora, todos tienen el incentivo de hacerlo todo de la manera difícil. Eso es una enfermedad en muchos proyectos. Recuerdo una compañía Fortune 50 con un proyecto de dos años y $500 millones para replataformar todos sus procesos. Un ejército de gente, todos muy ocupados, muchas reuniones y código creado, incluso "código desechable", que escribieron y luego no sirvió. Por dos años generaron solo actividad, pero ningún valor. Solo gastaron y nada valioso resultó.

Ahora, sobre compensación, lo he pensado mucho. Hay dos partes: la base para atraer talento, que es el pago según mercado. Por ejemplo, un junior cobra menos que un especialista. Pero para recompensar el valor generado, hay que darles parte de ese valor como premio. Si el equipo crea 100,000 en valor, la empresa paga infraestructura y les da tal vez el 20%. Ellos, como equipo, deciden cómo repartirlo, considerando quién realmente aportó más. Así todos tienen incentivo de crear mucho valor.

Galen Low: Es similar a un sistema de reparto de utilidades. El salario base atrae al talento y el extra depende del valor generado y medido consistentemente por el Product Owner.

Interesante.

Fred Fowler: Tiene sentido porque alinea los incentivos. Es lo bueno de Scrum: incentivos y toma de decisiones en las manos correctas. El Product Owner es como un inversor y decide en qué invertir el tiempo del equipo, pero se le mide por los resultados. Así toma las decisiones y rinde cuentas. Igual el equipo: tienen autoridad para decidir el cómo, nadie más se los dice. Así no hay a quién culpar y sirven de referencia si fallan; solo pueden señalarse a sí mismos. Eso fomenta la responsabilidad.

Galen Low: Nuestra industria no ha fomentado bien la responsabilidad porque las conductas son de "hazlo así porque yo lo mando".

Fred Fowler: Totalmente. Así, las lecciones aprendidas no afectan a quienes toman las decisiones; por eso Scrum dice que los equipos deben ser autogestionados y multifuncionales. Si no pueden crear el producto por sí mismos, habrá culpables externos. Deben poder hacerlo todo entre ellos para no poder culpar fuera. Igualmente, deben autogestionarse: si no, culparán a quienes sí deciden. Y esos externos que deciden no aprenderán de los errores. Como dice el dicho: "Nada es imposible si tú no lo tienes que hacer".

Si te dicen que hagas algo, para ellos no es imposible porque tú lo haces. ¿A cuántos no nos han solicitado lo imposible?

Galen Low: Es gracioso.

Es el equilibrio entre empoderamiento y responsabilidad: te empoderan, pero eres responsable, y ese aprendizaje lleva tiempo.

Fred Fowler: Son tres cosas: empoderamiento, responsabilidad y capacidad. Quienes son empoderados deben ser capaces. El Product Owner debe tener capacidad para invertir cientos de miles, si no millones, para crear productos valiosos. Los desarrolladores deben ser capaces de crearlos en equipo para poder responder por ello. El Scrum Master debe lograr que todos trabajen como equipo y entiendan su responsabilidad. Usualmente, el Scrum Master debe convencer a los desarrolladores para que no solo esperen instrucciones, sino que se involucren.

Una forma es vinculando la compensación al valor real creado: si no hacen buen trabajo, no hay bonificación. La bonificación depende del valor medible generado, así que mejorarán su desempeño.

Galen Low: Me gusta: medir valor y recompensar el valor.

Fred Fowler: Una cosa más: el producto sobre el que trabaja el Product Owner debe tener valor medible. Si trabajas en algo sin poder medir su valor, no es un producto y no puedes tomar decisiones racionales.

Por ejemplo, trabajé con una empresa cuya app financiera tenía tres grandes componentes: frontend web y motores de aplicaciones, una capa de APIs y un backend de procesamiento. Había tres Product Owners, uno por nivel, y constantes conflictos porque el frontend requería algo, pero debía pelear con el Owner del API y el del backend por prioridades. Un cambio esencial en el frontend estuvo parado dos años porque no convenía al Owner del backend según sus incentivos.

Nadie podía medir el valor de sus decisiones parcializadas, solo era posible hacerlo considerando toda la cadena de valor. Debía existir un solo Product Owner responsable por todo. Así desaparecerían los conflictos y tendrías un desarrollo racional.

Galen Low: Lo curioso es que el inhibidor del valor a veces es la política interna, ¿no?

Fred Fowler: Sí, y clave fue que nadie podía medir el verdadero valor de lo que hacían. No podían tomar decisiones racionales basadas en valor.

Galen Low: Hablamos de la experiencia viable mínima. Hay equipos que dicen: "No podemos hacer Scrum porque no producimos incrementos" o "No se puede aplicar el producto mínimo viable". Pero quizá solo no tienen mentalidad de producto y si se organizaran de otra manera podrían medir y entregar valor de forma incremental, no por componentes aislados.

Fred Fowler: De hecho, consulté esto con Jeff Sutherland, uno de los creadores de Scrum. Confirmó que un producto es algo que se puede producir y cuyo valor puede medirse objetivamente, sin opiniones subjetivas.

¿Cómo mides el valor? Mediante la venta, con alguien pagando por ello o ahorrando al consumirlo; si no lo puedes vender, probablemente tienes solo parte de un producto mayor, que es lo que debería guiar las decisiones de desarrollo.

Galen Low: Última pregunta: Has hablado mucho de Scrum, pero en cuanto a medir valor e impacto más que ocupación, ¿esto funciona en otras metodologías? ¿Qué consejo darías?

Fred Fowler:¿Otras metodologías? Sí. Scrum es una capa sobre algo más profundo, como Agile lo es sobre Scrum. Scrum busca resultados sin seguir una receta exacta. El modelo Waterfall de PMI se basa en planificar y crear una receta a seguir paso a paso, pero eso falla porque las cosas cambian. Roman Pichler, en Agile Product Management with Scrum, relata que tras un gran proyecto Waterfall bien planificado y entregado a tiempo, el producto resultó obsoleto antes de lanzarse.

El Scrum Guide, irónicamente, es solo una receta. Pero el trasfondo válido de todas las metodologías es tener personas calificadas tomando decisiones responsables en negocio y desarrollo, autogestores, multifuncionales, y alguna forma de medir el progreso incremental. Eso es Scrum, Kanban y la base de todo. Recomiendo a todos, sea cual sea el marco, que midan el valor y los resultados, no solo la actividad. Haz, mide resultados y aprende. Ese es el camino al éxito.

Galen Low: Ahí lo tienes. Muy bien.

Fred, hablamos de tu meetup y de tus libros. ¿Dónde pueden encontrarlos nuestros oyentes?

Fred Fowler: Desde 2015 dirijo un meetup sobre Scrum, llamado Advanced Scrum Case Studies. Cada dos semanas nos reunimos online, presento un caso que suele plantear un problema de gestión de proyectos o Scrum, como equipos offshore o medición del valor. El grupo es Silicon Valley Professional Scrum en Meetup, allí verás nuestro meetup de Advanced Scrum Case Studies. Serías bienvenido/a.

Ese meetup ha generado mucho material interesante. Tengo notas de unos 60 casos, algunos redactados por miembros, otros por mí, compilados en el libro Advanced Scrum Case Studies, disponible en Amazon y en mi web www.siliconvalleyscrum.com. Incluye 15 de los casos más interesantes y ya estoy trabajando en el segundo volumen con otros 15. Tengo más de 60 recopilados y sigo sumando cada semana.

Galen Low: Muy bien, no sabía que el libro se basaba en los debates del meetup.

Eso es genial. Me encanta.

Fred, muchas gracias por venir al programa hoy. Disfruté mucho tus historias, tu visión y la discusión sobre la compensación. Creo que ese tema daría para otro episodio entero.

Espero que nuestros oyentes hayan sacado mucho valor de esto. ¡Gracias!

Fred Fowler: Gracias, fue un placer conversar contigo. Gracias por invitarme.

Galen Low: Dime, ¿qué opinas?

¿Es factible que los equipos de proyectos se orienten a la creación de valor en vez de las horas o historias de usuario completadas? ¿O estamos demasiado atados al modelo trabajo-por-hora?

Cuéntanos tu experiencia: ¿cuáles han sido las métricas más relevantes en tus proyectos? ¿Qué cambios o resultados has visto al analizar los datos de tu proyecto?

¡Déjanos tus comentarios abajo!

Y si quieres perfeccionar tus habilidades como líder de proyectos estratégicos, ¡únete a nuestra comunidad colectiva!

Ingresa a thedigitalprojectmanager.com/membership para acceder a una comunidad de apoyo que comparte conocimiento, resuelve retos complejos y forja el futuro de nuestra disciplina, juntos.

Desde plantillas robustas y entrenamientos mensuales que te ahorran tiempo y energía, hasta peer-support a través de nuestro Slack, eventos en vivo y grupos mastermind, ser miembro significa tener a más de mil personas de tu lado en tu carrera de gestión de proyectos digitales.

Y si te gustó el episodio de hoy, suscríbete y mantente al día en thedigitalprojectmanager.com.

Hasta la próxima, gracias por escuchar.