En mi equipo, hay dos desarrolladores de pila completa, un tipo de DevOps , un gerente comercial y una persona de marketing. Pronto estaremos contratando a más personas.
¿Es demasiado pronto para crear e implementar un proceso de gestión de proyectos, o debería esperar hasta que el equipo sea más grande?
Si bien no puedo darle una idea específica sobre si es demasiado pronto, le sugiero que se asegure de que su equipo aprecie completamente los conceptos de desarrollo ágil y también quiera tener un proceso útil en marcha.
En este momento estoy trabajando en un equipo de 4.5 (3 desarrolladores full stack, un interno y yo, el PM/BA). Quería que comenzáramos con el concepto ágil desde el principio, porque el objetivo principal es reducir el ciclo de retroalimentación.
Ya sea que use scrum o algún otro tipo de ágil, tener un proceso establecido ayuda cuando se incorporan nuevas personas, para que sepan lo que se espera de ellos. Es un concepto explorado con bastante facilidad en este libro: http://www.amazon.com/Team-Geek-Software-Developers-ebook/dp/B008EKF87S/ref=sr_1_1?ie=UTF8&qid=1382398521&sr=8-1&keywords=team+ adicto
Básicamente, cuanto más rápido pueda establecer una cultura de equipo, más fuerte será su equipo a largo plazo.
Una forma de pensar en la gestión de proyectos es que no se trata necesariamente de adoptar un proceso, marco o conjunto de prácticas específico. Más bien, suele ser una herramienta para gestionar las expectativas y asegurarse de que las comunicaciones relacionadas con el proyecto sean efectivas .
Nunca es demasiado pronto para manejar las expectativas o para comenzar a comunicarse de manera efectiva. La única pregunta real es qué nivel de formalidad es necesario para lograr esos objetivos dentro de una organización determinada.
La fórmula para determinar el número de canales de comunicación es:
n * (n - 1) / 2
La complejidad de la gestión de las comunicaciones del proyecto es, por lo tanto, una función del número de personas involucradas. Por ejemplo:
Es posible que necesite o no un proceso formal de gestión de proyectos en este punto, pero ciertamente necesita comenzar a pensar en un plan de comunicación efectivo para sus proyectos.
Los equipos pequeños generalmente no requieren el mismo nivel de rigor en su proceso que los equipos más grandes. Eso no significa que los controles no estén presentes en el proceso; simplemente significa que a menudo se aplican de manera menos estricta para que requieran menos tiempo.
El rigor de un proceso generalmente se correlaciona con la cantidad de sobrecarga del proceso. Por ejemplo, un proceso Scrum formal que utiliza un sprint de dos semanas generalmente consume alrededor del 30 % de las horas-hombre disponibles en los gastos generales del marco . Por el contrario, un plan de comunicaciones simple en el que todos los miembros del equipo simplemente publican un informe de estado en el wiki una vez por semana consume menos del 3 % de los gastos generales.
La compensación es esencialmente entre la mejora de las comunicaciones dentro de la organización y el tiempo dedicado al desarrollo activo. La mayoría de los proyectos llegan a un punto de inflexión en el que el costo de una comunicación deficiente o de crear algo incorrecto es mayor que el costo de los gastos generales de cualquier proceso.
El punto de inflexión será diferente para cada organización y cada proyecto, pero mi experiencia personal es que es hora de pensar en agregar algo de rigor cuando:
Su organización puede tener un cálculo diferente para determinar cuándo es el momento de formalizar los controles de un proyecto, pero cada organización tiene que hacer las mismas concesiones esenciales. Probablemente no sea demasiado pronto para comenzar a calcular esos números para su organización y determinar dónde se debe trazar esa línea.
Uno de los principios de una buena gestión de proyectos es adaptar su enfoque a las necesidades de su proyecto. Mirándolo desde esta perspectiva, siempre debe tener un proceso de PM, la pregunta está más en la línea de qué tan formal debe ser para el proyecto actual .
Por todos los medios, desarrolle una cultura que abrace PM, pero tratar de implementar y hacer cumplir algún proceso basado en el tamaño de su equipo volverá a morderlo. O su proceso será demasiado caótico para manejar proyectos muy complejos o será demasiado oneroso para manejar proyectos simples de manera eficiente.
Para llegar al punto B, vas a tener un proceso. La pregunta realmente es si desea pensarlo detenidamente y diseñarlo formalmente, con puntos de control, reglas, asignaciones y expectativas, o simplemente improvisar. Hay beneficios y costos/riesgos para ambas alternativas.
Lo que probablemente encontrará es que su rendimiento será inferior al deseado. Eso desencadenará su deseo de mayores controles, entonces tendrá su respuesta.
EDITAR: Recuerde que su capacidad de rendimiento está impulsada por cuatro habilitadores: personas, procesos, herramientas y gobierno. Al ignorar cualquiera de estos, estás confiando en el excelente rendimiento de los demás para compensarlo. Por ejemplo, si elige usar una pala en lugar de una retroexcavadora para mover 10 toneladas de tierra, entonces está confiando en el excelente rendimiento del lado humano de la ecuación para hacerlo. Necesitarás más gente y gente en buena forma física. Use una retroexcavadora y podrá hacerlo con una o dos personas con obesidad mórbida.
La misma regla se aplica al proceso. Existirá el proceso, pero sería ad hoc, no estándar, rebelde, impredecible, irrepetible.
"¿Debería ponerse en marcha un proceso?" Sí. Incluso con un equipo de dos he descubierto que es útil poner en marcha un proceso. A decir verdad, establezco un proceso cuando el tamaño del equipo es 1 (solo yo). Cometo errores y el proceso es una de las herramientas que utilizo para compensar mi falibilidad.
¿Debería ajustarse el proceso en función del tamaño del equipo? Si, absolutamente. El proceso debe ajustarse en función de todos los factores pertinentes.
Tomando la pregunta de otra manera, cuando agregue a la siguiente persona al equipo, ¿será más fácil ponerlos al día si tiene un proceso documentado? Si alguien de su equipo se va repentinamente y el trabajo debe ser cubierto por otros hasta que se encuentre un nuevo empleado, ¿querrá un proceso? Si quiere hacer algo mejor la próxima vez que esta vez, necesita un proceso.
También reconoce que este es otro caso de “el plan no tiene valor, pero la planificación no tiene precio”. Si usted y su equipo se reúnen para diseñar un proceso, incluso si ese proceso nunca se consulta, el ejercicio de diseñar el proceso colectivamente dará como resultado mejoras tanto en el equipo como en el proceso.
Todd A. Jacobs
cristian