El Mítico Hombre-Mes Mítico

Como líder de producto en una empresa de tecnología, soy un pozo sin fondo de necesidad. Mi trabajo como director de productos en Mailchimp es llevar al mercado el producto que ganará en un espacio muy competitivo. Las aspiraciones de Mailchimp son altas y, para realizarlas, debemos entregar una cantidad sustancial de productos al mercado. A menudo, para muchos en la empresa, parece que estamos haciendo demasiado. Siempre estamos al borde de que las ruedas se salgan.

Y cuando estás haciendo demasiado y decides hacer más que eso, inevitablemente comenzarás a escuchar referencias a The Mythical Man-Month . Es como una de esas bolas para aliviar el estrés en las que, si aprietas un extremo, aparece el Mythical Man-Month en el otro extremo.

Publicado por Frederick Brooks en 1975 (¿recuerdas 1975, verdad? ¿Cuando el desarrollo de software se parecía al 100 % al desarrollo de software en 2020?), este libro es bastante famoso entre los ingenieros de software. Específicamente, hay un punto en todo el libro que es famoso (no estoy convencido de que la gente lea nada más que este punto, si es que han leído el libro):

“...agregar más hombres alarga, no acorta, el cronograma”.

Solución fácil. A partir de ahora, solo incluiré mujeres en los proyectos (ver el Retorno del Rey y la lucha contra el Rey Brujo de Angmar).

Pero supongamos que el punto de Brooks se mantiene independientemente de la identificación de género de los ingenieros de software en cuestión. Aquí está el punto: el software es difícil de construir con muchas interdependencias complejas. Y todos deben trabajar juntos para lograrlo.

A medida que agrego personas a un equipo, es necesario que se incorporen e injerten en el proyecto. Alguien tiene que hacer el trabajo adecuado para ellos. El equipo tiene que comunicarse para asegurarse de que todo funcione en conjunto, y cada persona adicional aumenta geométricamente la complejidad de la comunicación. Y en algún momento, agregar personas se convierte en una carga para el proyecto, no en un beneficio.

Aquí está el gráfico del libro que ilustra ese punto:

Este es absolutamente un punto justo. Por eso lo escucho tanto en el trabajo. Tanto los contribuyentes individuales exhaustos como los líderes exhaustos lo tirarán: ¡no podemos ir más rápido, no podemos hacer más, detener la contratación, leer The Mythical Man-Month y desesperarse! Aparentemente, la única solución es dejar de crecer y matar algunos proyectos.

Cuando yo, como CPO, digo: "¡vamos a hacer esto!" la respuesta entonces es a menudo: "Está bien, entonces, ¿qué vamos a matar?" The Mythical Man-Month convierte el desarrollo de productos en un juego de suma cero. Si queremos una cosa, debemos detener otra. Ahora, eso es un mito real, y yo lo llamo tontería.

Y llevado a su conclusión patológicamente malinterpretada (llegaremos a esta), el libro aparentemente dice que la compañía de tecnología más rápida es aquella que emplea a cuatro personas, aparentemente cuatro hombres . Cualquier cosa más solo lo ralentiza todo. Alguien debería enviar copias del libro a Amazon, Apple y Google, para que puedan arreglar sus organizaciones obviamente infladas.

El único problema con este enfoque es que en un espacio donde la competencia está creciendo, iterando y ejecutando, simplemente controlando el crecimiento organizacional, editar y enfocar la carga de trabajo para que coincida puede ser una receta para la extinción. Estarás más cuerdo y menos estresado, justo hasta que te quedes sin trabajo.

Y como propietario de la gestión de productos de mi empresa, no soy indiferente a esta necesidad de reducir la velocidad y concentrarme. ¡ Debemos priorizar despiadadamente! Sin duda. Pero ejecutar un producto es un ejercicio de contradicción. Debo priorizar lo que tengo y al mismo tiempo planear para hacer más. Pero, ¿qué debo hacer frente al Mes del Hombre Mítico ?

Sorprendentemente, la respuesta a esta pregunta proviene del mismo libro de Brooks. Aquí hay otro gráfico en el mismo capítulo:

Hay una batalla en la escala del desarrollo de productos. Si el trabajo que está tratando de realizar es puramente particionable, ¡adelante y agregue personas! Si todo su trabajo está conectado, en algún momento agregar personas es simplemente incorrecto.

Si alguien dice que absolutamente tengo que terminar un proyecto para comenzar otro, ese no es el caso. Si los dos proyectos requieren muy poca comunicación y coordinación, entonces podemos escalar.

Es por eso que agregar núcleos a una CPU puede aumentar la velocidad experimentada de su computadora o teléfono hasta cierto punto, algo que los ingenieros deben conocer. Claro, agregar núcleos no me ayudará a completar un cálculo complejo de un solo subproceso. Pero puede ayudarme a ejecutar un montón de tareas independientes .

Entonces, el conflicto para un ejecutivo de producto entre el escalado y la priorización despiadada se puede manejar.

1. Priorizas despiadadamente en lugares que son de un solo subproceso (digamos, el trabajo pendiente para un equipo de producto).
2. Puede escalar agregando más núcleos para manejar el trabajo independiente.

Muy raramente, sin embargo, hay algo totalmente independiente de todo lo demás en una empresa. Como mínimo, su empresa centralizará las funciones de soporte (TI global, legal, recursos humanos, etc.) lo que generará cuellos de botella.

Se trata de la gestión de dependencias

El trabajo de un ejecutivo de producto se convierte no solo en crear una estrategia, sino también en ejecutarla de una manera que maximice el valor para el cliente y el negocio al garantizar el rendimiento y reducir el riesgo de interdependencia tanto como sea posible. “Tanto como sea posible” siendo clave aquí. De esa manera, puede hacer que la empresa se parezca tanto al último gráfico como al primero. La interdependencia es una enfermedad que no tiene cura , pero sus síntomas se pueden controlar con muchos tratamientos.

Una solución es armar una dirección estratégica para la empresa que minimice o limite la dependencia a través de una cartera de iniciativas cuidadosamente seleccionada. Lo gracioso aquí es que muchas personas rechazarán esto. Digamos que tengo dos opciones, una en la que puedo ejecutar los proyectos A, B y C que tienen muy poca coordinación (digamos que impactan en diferentes productos), y otra opción con los proyectos D1, D2 y D3 que tienen toneladas de interdependencias ( digamos que todos impactan en el mismo producto). Suele ocurrir que el Mes del Hombre Mítico se invocará contra el primer plan en lugar del segundo. Porque sobre el papel parece más .

De hecho, está menos "enfocado". Pero, en realidad, es menos difícil desde la perspectiva de la dependencia y, por lo tanto, funciona mejor con personal adicional.

Tenga en cuenta que no estoy diciendo que elija un montón de trabajo para la empresa que no esté relacionado. Mailchimp no construirá un horno de microondas en el corto plazo. Todo el trabajo debe conducir en la misma dirección a largo plazo. Este enfoque puede aumentar el riesgo de la experiencia del cliente (que analizaremos más adelante), así como la carga de las funciones globales, como la investigación de clientes. Mantente pendiente de eso.

Otro tratamiento es crear un proceso de gestión de productos y programas que facilite la coordinación y la comunicación de las dependencias cuando sea necesario sin sobrecargar a los equipos con coordinación si no se requiere . A veces, al intentar administrar la coordinación para que podamos hacer más , terminamos creando procesos tan onerosos que terminamos haciendo menos. Es un equilibrio entre hacer muy poca coordinación, lo que hace que las piezas no interoperen, y hacer demasiada coordinación, lo que hace que las piezas nunca se construyan porque todos estaremos en stand-ups por la eternidad.

El argumento en Mythical Man-Month es que a medida que agrega personas a un proyecto de software, la comunicación debe aumentar geométricamente. Por ejemplo, si tiene 3 personas en el proyecto, son 3 líneas de comunicación. Pero si tienes 4, son 6 líneas de comunicación. ¡Una persona extra, en este caso, conduce al doble de la comunicación! Divertido. (Esto es, por supuesto, una simplificación excesiva de la comunicación en proyectos de desarrollo de software).

Diferentes personas tienen diferentes roles y, por lo tanto, reciben diferentes cantidades de autonomía. Quizás el director del proyecto necesite comunicarse con todos los miembros del equipo. Pero, ¿un ingeniero que trabaja en la API necesita comunicarse con el comercializador del producto? ¿O el vendedor puede simplemente pasar por el gerente de producto? Un buen proceso y cadencia de reuniones puede eliminar comunicaciones y reuniones innecesarias. El punto es que la fórmula de intercomunicación de Brooks es un límite superior en la coordinación , no una sentencia de muerte.

Finalmente, use herramientas, principios y marcos combinados con el trabajo independiente sobre la colaboración real para combatir los síntomas de interdependencia. Por ejemplo, si puedo coordinar los indicadores clave de desempeño de dos equipos (KPI, es decir, medidas de éxito) para incentivar el movimiento en más o menos la misma dirección, entonces es más probable que su trabajo independiente termine "más cerca" que si sus KPI incentivan el movimiento ortogonal. Esto no garantizará que las cosas encajen perfectamente, solo que el trabajo que debo hacer para que encajen en el futuro es menor de lo que podría ser de otra manera. Otros ejemplos pueden incluir el uso de declaraciones "iguales", sistemas de diseño y pruebas automatizadas.

Así que hay un comienzo. Pero las interdependencias toman muchas formas más allá del código. Permítanme dar un ejemplo de Mailchimp.

Riesgo de la experiencia del cliente: el costo oculto (¿pero aceptable?) del trabajo de firewall

Dado que el cliente de Mailchimp suele ser el propietario de una pequeña empresa que es un novato en marketing (y hay millones de propietarios de pequeñas empresas que se han convertido en especialistas en marketing en todo el mundo), debemos ofrecer una experiencia que sea fluida y comprensible de inmediato de principio a fin . No podemos permitirnos el lujo de ensamblar un monstruo de nubes de Frankenstein a través de la adquisición de la forma en que los jugadores empresariales pueden hacerlo. No podemos disimular el software mal integrado con consultores y gerentes de cuentas.

Como producto de consumo (piense en Instagram, Nintendo Switch o Roomba), tenemos que ser utilizables desde el primer momento. Para una plataforma de marketing todo en uno destinada a potenciar su negocio, ¡eso es difícil! Y eso significa que cada cosa que construye Mailchimp debe estar perfectamente conectada desde una perspectiva de experiencia.

Pero, la partición perfecta de los proyectos introduce el riesgo de la experiencia . No es que el código no se pueda escribir de forma independiente. Eso se puede lograr, pero aún existe el riesgo de que los productos se vean como si hubieran sido creados por diferentes equipos, y esa experiencia puede ser muy confusa para el usuario. Nos topamos con la ley de Conway: nuestros clientes pueden saber dónde termina el trabajo de un equipo y comienza el trabajo del otro equipo.

Por lo tanto, intenta conectar el trabajo de todos juntos, no solo en el back-end sino también en el front-end. En la era del ecosistema, dominada por la excelencia de CX de jugadores como Apple, esto se ha convertido casi en apuestas en el espacio del consumidor. Pero esta es una pesadilla del Mes del Hombre Mítico , aunque esta vez no desde una perspectiva de ingeniería. Es desde una perspectiva de diseño de servicios. A medida que agregamos más personas a todo este trabajo conectado de "extremo a extremo", todo se ralentiza hasta convertirse en un rastreo colaborativo.

Aparte de la tercera solución que mencioné anteriormente, usar herramientas y marcos en lugar de supervisores y puertas de escenario, hay otra válvula de escape: haga algunas compensaciones deliberadas en la experiencia del cliente . Específicamente, ¿dónde nos sentimos cómodos lanzando una experiencia que está desconectada del resto (es decir, que está por debajo de la media)? Aceptar el riesgo y seguir adelante es el trabajo del líder de producto. Entonces, usa algunos criterios para resolverlo (tal vez no está manteniendo las áreas nuevas y de poco tráfico de la aplicación con los mismos estándares de experiencia que sus "vacas de efectivo"), y toma una decisión (por ejemplo, iteración y aprendizaje sobre pulido en adyacentes innovaciones). Esto, por supuesto, se extiende más allá del diseño.

Siempre puede hacer un cortocircuito en la ley de Brooks eligiendo los esfuerzos de firewall, incluidos los esfuerzos que, en un mundo perfecto, ¡no deberían ser bloqueados!

“

Voy a advertir esto diciendo que el software que construyo no mata a nadie. No recomendaría este enfoque si estuviera construyendo un dispositivo médico. Pero en una empresa de software de marketing, puedo aislar deliberadamente a los equipos sabiendo que he aumentado las probabilidades de incompatibilidad como compensación por ampliar el personal y avanzar más rápido.

Me entristece admitir que el Hombre-Mes Mítico es una realidad en mi empresa, y sospecho que también en la tuya. Pero es manejable , ese es el resultado final. La paralelización y la mitigación de la dependencia nos ofrecen una salida que limita el estado casi mítico del Mes del Hombre Mítico . Así que la próxima vez que se plantee la cruda dicotomía en su empresa (escala para ir más lento o renunciar a sus aspiraciones) recuerde que si es inteligente acerca de cómo alinea el trabajo, aún puede crecer.

No se olvide del lado más suave del escalado

Tenga en cuenta que administrar el Mes del Hombre Mítico no impedirá que los ingenieros lo invoquen como magia oscura. Están invocando el principio no solo porque hay algo de verdad en él, sino porque escalar simplemente apesta (siempre) desde una perspectiva emocional y cognitiva. Si creo que me pagan por escribir código y resolver los problemas de los clientes, lo último que quiero hacer es cambiar mi rutina y averiguar cómo trabajar con gente nueva y un equipo más grande.

A medida que escala su empresa, recuerde empatizar con el dolor de escalar y cambiar. Un equipo que agrega incluso un solo miembro se convierte en un equipo completamente nuevo desde una perspectiva cultural y de confianza. La gente está cansada de este cambio. Eso significa que mientras maneja y mitiga el Mes del Hombre Mítico , necesitará manejar las emociones que rodean el crecimiento. Esa es quizás la tarea más crítica de todas.

La fuerte creencia en el Hombre-Mes Mítico por parte de un equipo en sí mismo puede hacer realidad sus conclusiones. Es básicamente el equivalente a la creencia de volar en Peter Pan. Si el equipo cree que escalar los ralentizará y no aceptan el cambio, de hecho se ralentizarán.

Entonces, mientras trabaja para administrar las dependencias e introducir herramientas para ayudar a escalar, asegúrese de comunicar claramente el por qué detrás de las prácticas. Involucre a la gente en la selección del trabajo y los procesos que mitigan los problemas de mes-hombre, porque cuando son parte del cambio y su perspectiva cambia, la escalabilidad repentina se vuelve al menos culturalmente posible.