En este artículo quiero compartir un poco de experiencia con respecto a la creación de equipos en proyectos de TI. Quiero hablar de algo no siempre obvio como la "Pirámide de madurez del equipo".
Este indicador no es un término científico estricto y no tiene fórmulas de cálculo exactas, pero su principio está bien formulado en el nombre mismo.
Un equipo típico en proyectos medianos y grandes consta de varios participantes: gerente de proyecto, analistas de negocios, desarrolladores, probadores e ingenieros de operaciones. En cada dirección, generalmente hay clientes potenciales: empleados líderes en la dirección, por ejemplo, un ingeniero de desarrollo líder, un ingeniero de pruebas líder, etc.
Si representamos la estructura de dicho equipo en forma de una pirámide con un reflejo de la experiencia de los empleados y su influencia en la toma de decisiones, entonces obtenemos esa pirámide:
Tenemos una especie de "pirámide de Maslow para el equipo". Pero no olvide que los proyectos de TI no solo tienen ingenieros. Por ejemplo, los desarrolladores se pueden dividir en Junior / Middle / Senior y Dios sabe cómo, dependiendo de la experiencia laboral y el conocimiento (o de la imaginación del empleador).
Sucede que una persona tiene un título bajo, pero por experiencia y conocimiento, esta persona puede cumplir el rol de Arquitecto de soluciones (pero debido a circunstancias no cumple este rol). Obviamente, esas personas influyen en la toma de decisiones dentro del equipo, incluso sin tomar posiciones formales dentro del proyecto. Y esas personas necesitan ser elevadas al segundo paso en nuestra pirámide. Es importante que no haya más personas en el segundo nivel que en el tercero.
Puede asignar una cierta cantidad de "maná" a cada miembro del equipo, dependiendo de la experiencia y la influencia en la toma de decisiones. Por ejemplo, los miembros del equipo de rango y archivo recibirán 1 punto, los líderes y los gerentes 2 puntos.
Imagine que tenemos un equipo de 15 personas, luego una pirámide típica se considerará de alguna manera como esta:
1 :
Project Manager + Technical Lead = 4 pts
2 :
2x Stream Leads + 2x Senior Engineer = 8 pts
3 :
9x Middle and Junuor Engineers = 9 ptsY obtenemos tal pirámide:
Bueno, usted dice, este es exactamente el camino o no en nuestro proyecto y todo está bien para nosotros. ¿Y cuál es el resultado práctico de esto?
Evaluar a un equipo utilizando este método le permite comprender dos cosas: cuán manejable (estable) es un equipo existente y cuán extraño es lo cómodo que se sienten todos para trabajar en dicho equipo.
De hecho, lo que es más importante, lo que sucede cuando la pirámide de madurez del equipo se pone patas arriba. O cuando se vuelve plano, paralelepípedo o algo más. Y este es un escenario muy malo.
La pirámide correcta es muy estable, pero la invertida no lo es. Puede recordar el experimento insidioso con la colonia "White Swan" donde estaban sentadas algunas autoridades criminales y cómo terminó para ellos.
Y si no se desvía del sector de TI, puede imaginar dos situaciones reales:
- proponen que un gerente de proyecto efectivo sea barato y alegre: contrate a 30 "indios" y presente el proyecto en un mes en lugar de seis meses;
- Un cliente muy importante corta en las entrevistas a todos los ingenieros, excepto aquellos con títulos Senior o Lead.
En el primer caso, obtenemos un "ladrillo" en lugar de una pirámide y un proyecto claramente incontrolable con un final triste.
En el segundo caso, tenemos la misma colonia "White Swan" en el proyecto. Esto es cuando las personas respetadas y experimentadas se reúnen en una habitación y en dos horas no pueden llegar a una solución simple. Solo porque son experimentados y geniales, cada uno de ellos quiere hablar y cree que su idea es buena. El sentido de tales conversaciones suele ser muy pequeño. Además, no está claro quién debería "levantar el jabón", es decir, ¿quién debería ver esta característica?
En mi carrera ha habido proyectos con tal grupo de personas en equipos y, sinceramente, digo que trabajar en la primera y segunda versión no es muy cómodo. Tanto el gerente como el empleado ordinario. Cuando un equipo tiene demasiadas personas inteligentes, se vuelve tonto. La pirámide se vuelve inestable y a menudo "cae" aplastando descuidadamente.
De hecho, todo es simple, un proyecto de TI debe tener suficientes ingenieros que hagan el trabajo, se beneficien y no hagan preguntas. Sin un número suficiente de tales personas, el proyecto simplemente no tiene suficientes "caballos de fuerza" y no grava en un futuro feliz.
La situación inversa es cuando tienes demasiada "potencia" y poco control, entonces tu auto de carrera simplemente se estrellará en la primera cerca.
El número ideal de personas en un equipo de TI es de 5 a 15 personas. Bezos de Amazon compiló esto como el principio del "equipo de dos pizzas". Un aumento adicional en el número de personas complica la comunicación dentro del equipo y ya no tiene un efecto multiplicador.
La distribución ideal de los miembros del equipo por madurez es por líder de 2 a 5 ingenieros de nivel medio. Si hablamos de ingenieros junior o de
Vasiliev , entonces no debería haber más de 1-2 por líder (o la persona responsable de ellos). Solo porque es físicamente incapaz de prestar atención a más personas. La Revisión del Código Elemental para 5 personas ya puede tomar la mitad del tiempo de trabajo. Además, los líderes todavía tienen todo tipo de reuniones con otros equipos y el cliente, por lo que no puede hacer el trabajo el 100% del tiempo como ingeniero habitual.
Es decir Podemos decir que dentro de la pirámide de madurez del equipo, debemos construir pequeñas pirámides de sub-equipos separados para mayor estabilidad.
En cuanto al nivel superior de la pirámide, no es tan importante cuántas personas tiene en la parte superior, si tiene 2 niveles inferiores adecuados, eliminarán todo el proyecto. La pirámide en la mayoría de los casos no será perfecta, pero no da miedo. Lo principal es tener suficientes personas desde abajo.
No tener en cuenta en la pirámide de supervisores, es decir personas que lideran una dirección completa y simplemente controlan el proceso en varios proyectos sin interferir en la gestión.
El propietario del producto de Agile es parte del equipo, pero no debe interferir con el proceso de gestión. Si él comienza a involucrarse en la microgestión o inmediatamente tiene 5 propietarios de productos, entonces tiene grandes problemas. Pero estos ya son problemas de gestión competente de proyectos y relaciones con los clientes. Si caes en esta trampa, entonces la pirámide invertida ya es tu problema más pequeño.
Otro punto es cuando demasiadas personas quieren liderar el proyecto, y usted, como la única persona que trabaja, recuerda el trabajo de Saltykov-Shchedrin, "Cómo un hombre alimentó a dos generales". O esta
historia . Pero tal situación es fácil de predecir usando la "pirámide de madurez del equipo" y no continuar con un proyecto de este tipo.
En una empresa competente, cosas como la composición del equipo deben planificarse desde la etapa de venta del proyecto. Luego seleccionan un gerente de proyecto que formará la columna vertebral del equipo de clientes potenciales y con su ayuda construirá pirámides, verá proyectos y capturará galaxias.