Abordaré la pregunta desde la perspectiva de la ingeniería de software, aunque muchas de las lecciones aprendidas también se aplican a otros proyectos. Producir estimaciones precisas de proyectos es una de las tareas más difíciles de hacer en ingeniería de software y una habilidad a menudo pasada por alto que la mayoría de los ingenieros (incluido yo mismo) no saben cómo hacer bien. También es el caso que las personas que no han necesitado estimar los tiempos de finalización de los proyectos antes tienden a subestimar la dificultad y, a menudo, hacen que sus estimaciones sean erróneas al menos por un factor de dos. Como cualquier habilidad, uno solo mejora con la práctica.
Mi memoria más vívida de las estimaciones de proyectos que salieron mal ocurrió algunos meses después de unirme como ingeniero en Ooyala, una empresa que proporcionó una plataforma de video en línea de extremo a extremo. En agosto de 2008, apenas un poco más de un año después de la fundación de la empresa, el equipo de ingeniería comenzó a reescribir el reproductor de video basado en Flash del producto. Nuestros objetivos fueron hacer que el jugador sea más modular y de mayor rendimiento y también tener un código base más limpio y mejor probado. Un equipo inicial de 3 personas diseñó y escribió una infraestructura central antes de incorporarme a mí y al resto del equipo de ingeniería de ~ 10 personas. Estimaron 4 meses para que se completara el proyecto, y el CTO y el gerente de producto produjeron los diagramas de Gantt [1] que resumen el desglose y las dependencias del trabajo. El nuevo jugador terminó de lanzar completamente 9 meses después, en mayo de 2009 [2].
Nos perdimos el objetivo no por falta de trabajo duro o ingenieros talentosos; hubo una serie de meses en los que la mayoría de las personas del equipo sacaron de 70 a 80 horas por semana (no recomendado). En la mitad del proyecto, incluso realizamos minuciosamente ejercicios de unos días en los que asignamos estimaciones por hora a tareas bastante detalladas. Los mayores retrasos casi siempre se debieron a factores, muchos externos, que no hemos considerado en las estimaciones iniciales:
- se están firmando acuerdos con clientes de alta prioridad que requieren que los ingenieros cambien de contexto a un trabajo personalizado,
- errores en el código del reproductor flash de Adobe que dificultaban la determinación precisa de cuándo el video estaba realmente pausado, almacenado en búfer y reproduciéndose,
- Errores de corrupción de video difíciles de reproducir que podrían bloquear el reproductor al buscar ciertos marcos de video en IE,
- el desarrollo del producto debe reanudar 4 meses en el proyecto para mantener a la base de clientes actual feliz,
- problemas de escalabilidad que debían abordarse a medida que crecía la cantidad de datos analíticos,
- un ingeniero temprano que abandona el equipo a mitad de proyecto, que requiere una gran cantidad de transferencia de conocimiento de las partes principales del código base,
- etc.
Si bien la reescritura del jugador era definitivamente necesaria para la compañía, la manera imprevista en la que se prolongó tuvo un gran costo en la puesta en marcha temprana. Otros proyectos en los que he trabajado, visto de segunda mano o sobre los que he hablado con otros ingenieros han seguido patrones similares en los que el tiempo de finalización real a menudo duplica las estimaciones originales.
Aquí están algunas de mis lecciones para llevar lejos de estas experiencias:
En la medida de lo posible, haga que las personas que producen las estimaciones para una tarea sean las personas reales que trabajarán en ello. Esto es similar al punto de Ian McAllister de usar la estimación del jugador B: ya es increíblemente difícil para una persona predecir con precisión cuánto tardará en realizar una lista de tareas, incluso si las tareas son bastante granulares; es aún más difícil predecir cuánto tiempo le tomaría a otra persona tener un grado diferente de familiaridad y un grado diferente de habilidad. Se hizo evidente durante la reescritura del jugador de Ooyala que muchas de las estimaciones iniciales eran extremadamente agresivas e ignoraron el tiempo de rampa de un ingeniero en partes de la base de código con las que estaba menos familiarizado.
Cuidado con el efecto del segundo sistema. En The Mythical Man-Month , Frederick Brooks describe a partir de sus experiencias de proyectos en IBM cómo una tendencia humana de sobre diseño del segundo sistema lleva a una complejidad sustancialmente mayor, lo que hace que los calendarios de proyectos de rediseño se deslicen [3]:
El primer trabajo de un arquitecto puede ser sobrio y limpio. Sabe que no sabe lo que está haciendo, así que lo hace con cuidado y con gran moderación.
Cuando diseña el primer trabajo, se le ocurren adornos y adornos después de adornos. Estos se almacenan lejos para ser utilizados “la próxima vez”.
Tarde o temprano, el primer sistema está terminado, y el arquitecto, con una confianza firme y un dominio demostrado de esa clase de sistemas, está listo para construir un segundo sistema.
Este segundo es el sistema más peligroso que un hombre diseña … La tendencia general es sobre-diseñar el segundo sistema, usando todas las ideas y adornos que se desviaron cautelosamente del primero.
Especialmente para un proyecto que involucra la reescritura de software existente, es tentador agrupar una serie de nuevas características en lo que de otro modo podría haber sido un puerto sencillo, usando el argumento de que el equipo también podría hacerlo si van a reescribir el código base. . El aumento de la complejidad puede llevar a que la reescritura y las nuevas funciones no se ejecuten hasta mucho más tarde.
Tenga cuidado al combinar cuánto tiempo tomarán las tareas de un proyecto con qué tan pronto antes de que termine un proyecto. Cuanto más tiempo toma un proyecto, mayor es la probabilidad de que las variables ambientales externas entren en juego y amplíen el cronograma general del proyecto. El arrastre recurrente que menciona Ian contribuye a la línea de tiempo de un proyecto, pero también lo hacen los eventos inesperados. Para los proyectos en los que he trabajado a principios de este año en Quora, algunos de ellos tardaron más en iniciarse de lo esperado debido a los costos de tiempo acumulados de:
- responder y recuperarse de una interrupción inesperada de varios días de AWS,
- manejo de alertas de servicio de buscapersonas perioídicas para mantener el sitio arriba,
- vacaciones programadas que una vez parecían estar muy lejos de un proyecto, pero que terminaron superponiéndose con él,
- Preparación y asistencia a eventos de reclutamiento.
- cambio de contexto entre múltiples proyectos que resultó ser más complicado de lo que se esperaba inicialmente.
Para cualquier proyecto, probablemente se podría enumerar cualquier cantidad de eventos y distracciones que individualmente podrían ser poco probables o poco convincentes, pero que colectivamente están obligados a suceder y sumar en un período de tiempo suficientemente largo. Cuanto más largo sea el proyecto, más distracciones habrá, y es importante presupuestar el tiempo de búfer para factores externos desconocidos.
Presupuesto suficiente tiempo para cualquier tarea relacionada con la integración. Especialmente para proyectos con muchos componentes interrelacionados, muchos ingenieros tienden a 1) posponer las tareas de integración de extremo a extremo hasta el final, y 2) subestimar significativamente la cantidad de tiempo requerido para integrar todas las piezas en un sistema operativo. Debido a que la integración tiende a estar muy lejos y debido a que los riesgos son típicamente desconocidos, el supuesto por el tiempo de integración es que todos los componentes funcionan de manera aislada, subestimando el tiempo de integración tiende a ser bastante común. Los proyectos a menudo se asignan solo a una fracción minúscula del tiempo total del proyecto para las pruebas de extremo a extremo, aunque es uno de los aspectos más riesgosos de un proyecto y, en comparación con los hitos anteriores, requiere una mayor sobrecarga de comunicación entre los miembros del equipo.
El corolario de esto es comenzar las pruebas de principio a fin tan pronto como sea posible para identificar los riesgos y problemas de integración antes, de modo que haya tiempo suficiente para abordarlos.
La estimación se basa en el tiempo que durarán las tareas, no en el tiempo que usted o alguien más quiera que tomen. Siempre habrá presión para completar los proyectos más rápido, ya sea de usted mismo, de los miembros de su equipo, de la administración o de los clientes, y muchas veces la respuesta emocional a esa presión nos une a líneas de tiempo exigidas externamente y nos lleva a subestimar sistemáticamente las tareas. Psicológicamente, nadie quiere decepcionar a otras personas, y es fácil decirse que si trabaja más duro o más eficientemente, puede cumplir con un determinado plazo. Especialmente para proyectos largos, sin embargo, este tipo de ilusiones es en última instancia insostenible.
Revisar periódicamente y revisar las estimaciones del proyecto a medida que avanza el proyecto. Así como la mayoría de los buenos programas de software se construyen y mejoran de forma incremental, también lo son las estimaciones de proyectos. Revisar las estimaciones del proyecto y comparar las estimaciones de las tareas en la última semana con el tiempo real que se necesita para sacar a la luz los errores de estimación y revisar los cronogramas en función de los riesgos imprevistos que anteriormente se habían producido.
Las estimaciones de proyectos casi siempre tienden a ser subestimaciones en lugar de sobreestimaciones; rara vez se oye hablar de proyectos largos que terminan antes de lo previsto. Saber que la estimación de un proyecto es difícil y reflexionar sobre por qué las estimaciones resultaron incorrectas en un proyecto en particular lo guiará hacia errores de estimación más pequeños en proyectos posteriores.
Hay mucho más que ejecutar en un proyecto que solo producir estimaciones precisas. Si usted es ingeniero y desea dominar las técnicas utilizadas por los mejores ingenieros de software para convertir sus proyectos en éxitos, descargue un capítulo de muestra gratuito de mi libro, The Effective Engineer. Está lleno de cientos de historias, ideas y estrategias viables de líderes en todo Silicon Valley.
———-
[1] http://en.wikipedia.org/wiki/Gan …
[2] http://go.ooyala.com/Swift.html
[3] http://www.the-wabe.com/notebook …