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 hacer bien. También es el caso de 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, sus estimaciones se equivocan por al menos un factor de dos. Como cualquier habilidad, uno solo mejora con la práctica.
Mi recuerdo más vívido de las estimaciones de proyectos fallidas ocurrió unos meses después de unirme como ingeniero en Ooyala, una startup que proporcionó una plataforma de video en línea de extremo a extremo. En agosto de 2008, poco más de un año después de la fundación de la empresa, el equipo de ingeniería comenzó a trabajar en una reescritura del reproductor de vídeo basado en Flash del producto. Nuestros objetivos eran hacer que el reproductor fuera más modular y de mayor rendimiento, y también tener una base de código más limpia y mejor probada. Un equipo inicial de 3 personas diseñó y escribió una infraestructura básica antes de incorporarme a mí y al resto del equipo de ingeniería de ~10 personas. Estimaron 4 meses para que el proyecto se completara, y el director de tecnología y el gerente de producto produjeron gráficos de Gantt que resumían el desglose del trabajo y las dependencias. El nuevo jugador terminó lanzándose por completo 9 meses más tarde, en mayo de 2009 .
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 en el equipo tiraron de 70 a 80 horas por semana (no se recomienda). A mitad del proyecto, incluso realizamos minuciosamente ejercicios de unos días en los que asignamos estimaciones horarias a tareas bastante granulares. Los mayores retrasos casi siempre se debieron a factores, muchos de ellos externos, que no se tuvieron en cuenta en las estimaciones iniciales:
- se firmaban ofertas de clientes de alta prioridad que requerían que los ingenieros cambiaran el contexto a un trabajo personalizado,
- errores en el código de Adobe flash player que dificultaban determinar con precisión cuándo el vídeo estaba en pausa, se almacenaba en búfer y se reproducía,
- errores de corrupción de vídeo difíciles de reproducir que bloqueaban el reproductor al buscar ciertos fotogramas de vídeo en IE,
- 4 meses en el proyecto para mantener feliz a la base de clientes actual,
- problemas de escalabilidad que debían abordarse como la cantidad de los datos de análisis crecieron,
- un ingeniero temprano abandonó el equipo a mitad del proyecto, lo que requirió una gran cantidad de transferencia de conocimientos de partes importantes de la base de código,
- , etc.
Mientras que la reescritura del reproductor era definitivamente necesaria para la compañía, la manera imprevista en la que dragged out tuvo un gran costo en la primera puesta en marcha. Otros proyectos en los que he trabajado, visto de segunda mano o hablado con otros ingenieros, han seguido patrones similares donde el tiempo real de finalización a menudo duplica las estimaciones originales.
Aquí están algunas de mis lecciones para llevar hasta ahora 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 ella. 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 tiempo le llevaría hacer una lista de tareas, incluso si las tareas son bastante granulares; es aún más difícil predecir cuánto tiempo le llevaría a otra persona con 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 ignoraban el tiempo de rampa de un ingeniero en partes del código base con las que estaba menos familiarizado.
Cuidado con el efecto de segundo sistema. En El Mítico Mes del Hombre, Frederick Brooks describe a partir de sus experiencias de proyecto en IBM cómo una tendencia humana a sobre-diseñar el segundo sistema conduce a un aumento sustancial de la complejidad, lo que hace que los horarios de los proyectos de rediseño se resbalen :
La primera obra de un arquitecto es apta para ser sobria y limpia. Sabe que no sabe lo que está haciendo, así que lo hace con cuidado y con gran moderación.
A medida que diseña la primera obra, se le ocurren adornos tras adornos y adornos tras adornos. Estos se almacenan para ser utilizados » la próxima vez.»Tarde o temprano, el primer sistema está terminado, y el arquitecto, con una firme confianza 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 haya diseñado… La tendencia general es sobre diseñar el segundo sistema, utilizando todas las ideas y adornos que se desviaron cautelosamente en el primero.
Especialmente para un proyecto que implica reescribir el software existente, es tentador agrupar una serie de características nuevas en lo que de otra manera podría haber sido un puerto sencillo, utilizando el argumento de que el equipo también podría hacerlo si va a reescribir la base de código de todos modos. El aumento de la complejidad puede llevar a que ni la reescritura ni las nuevas características se lancen hasta mucho más tarde.
Tenga cuidado al combinar cuánto tiempo tardarán las tareas de un proyecto con qué tan pronto terminará un proyecto. Cuanto más tiempo tome un proyecto, mayor será la probabilidad de que las variables ambientales externas entren en juego y extiendan 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, varios de ellos tardaron más en lanzarse de lo esperado debido a los costos de tiempo acumulados de:
- responder y recuperarse de una interrupción inesperada de AWS de varios días,
- manejar alertas de servicio de buscapersonas periídicas para mantener el sitio activo,
- vacaciones programadas que antes parecían lejanas de un proyecto pero que terminaron superponiéndose con él,
- prepararse para eventos de reclutamiento y asistir a ellos,
- eso resultó ser más complicado de lo que se esperaba inicialmente.
Para cualquier proyecto, probablemente se podría enumerar cualquier número de eventos y distracciones que individualmente podrían ser improbables o no, pero que colectivamente están obligados a suceder y sumarse 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 reserva para factores externos desconocidos.
Presupueste tiempo suficiente 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 juntas en un sistema de trabajo. Debido a que la integración tiende a estar tan lejos y debido a que los riesgos generalmente se desconocen, la suposición por parte del tiempo de integración es que todos los componentes funcionan con éxito de forma aislada, subestimar el tiempo de integración tiende a ser bastante común. A los proyectos a menudo se les asigna solo una fracción minúscula del tiempo total del proyecto para las pruebas de extremo a extremo, a pesar de que generalmente es uno de los aspectos más riesgosos de un proyecto y, en comparación con hitos anteriores, requiere una mayor sobrecarga de comunicación entre los miembros del equipo.
El corolario de esto es comenzar las pruebas de extremo a extremo lo antes posible para identificar los riesgos y problemas de integración antes para que haya tiempo suficiente para abordarlos.
Estimación basada en cuánto tiempo tardarán realmente las tareas, no en base a cuánto tiempo tú o alguien más quieren que tarden. 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 a menudo la respuesta emocional a esa presión nos ancla a los plazos exigidos externamente y nos lleva a subestimar sistemáticamente las tareas. Psicológicamente, nadie quiere decepcionar a otras personas, y es fácil decirse a sí mismo que si solo trabajas un poco más duro o de manera más eficiente, puedes cumplir con un cierto plazo. Sin embargo, especialmente para proyectos largos, este tipo de ilusiones es, en última instancia, insostenible.
Revisar y revisar periódicamente las estimaciones del proyecto a medida que avanza el proyecto. Así como se construye y mejora la mayoría de los buenos programas informáticos de forma incremental, también lo son las estimaciones de proyectos. Revisar las estimaciones de los proyectos y comparar las estimaciones de las tareas de la semana pasada con el tiempo real empleado ayuda a detectar errores de estimación y revisar los horarios en función de riesgos previamente imprevistos.
Las estimaciones de proyectos casi siempre tienden a ser subestimadas en lugar de sobreestimadas; rara vez se oye hablar de proyectos largos que terminan antes de lo previsto. Ser consciente de que la estimación de proyectos es difícil y reflexionar sobre por qué las estimaciones fallaron en un proyecto en particular lo guiará hacia errores de estimación más pequeños en proyectos posteriores.
Ejecutar un proyecto es mucho más que solo producir estimaciones precisas. Si eres ingeniero y quieres dominar las técnicas utilizadas por los mejores ingenieros de software para convertir sus proyectos en éxitos, descarga un capítulo de muestra gratuito de mi libro, The Effective Engineer. Está repleto de cientos de historias, ideas y estrategias prácticas de líderes de todo Silicon Valley.
———-
http://en.wikipedia.org/wiki/Gantt_chart
http://go.ooyala.com/Swift.html
http://www.the-wabe.com/notebook/second-system.html