¿Cómo puedo hacer que un jefe (o colega) sea más cuidadoso al estimar la complejidad de una tarea / proyecto?

Soy desarrollador de software y trabajo en una pequeña empresa de desarrollo web. Parece ser un tema recurrente que un gerente intermedio me preguntará cuánto tiempo tomará algo, y cuando les doy mi estimación, piensan que es demasiado alto. Si se trata de un gerente más técnico u otro desarrollador, por lo general ya tendrán en mente una estimación propia y comenzarán a tratar de implementarla a su manera porque creen que pueden hacerlo más rápido.

Sin embargo, existe una tendencia en la que los otros desarrolladores han terminado usando mucho más tiempo del que citaron. Llegarán a la mitad de su presupuesto, luego se darán cuenta de que existe una necesidad comercial que su plan de implementación no puede abordar adecuadamente. Más de las veces, mi plan habría abordado esta necesidad, pero se descartó como una característica de " No la vas a necesitar ".

Peor aún, cuando golpean esta pared, generalmente vienen a mí para ayudarlos a salir de la esquina en la que se han pintado, pero solo hay tantas horas en mi día.

El mejor de los casos : estas interrupciones reducen el tiempo que he asignado para mi propio trabajo de desarrollo, lo que resulta en retrasos en otros proyectos o en que tengo que trabajar horas extras porque soy "el único que puede hacer X".

El peor de los casos : termino teniendo que asumir la tarea / proyecto como propio, y para ese punto no me queda tiempo en el presupuesto para que lo haga "a mi" manera. Tengo que tratar de terminar lo que comenzaron de la manera en que lo comenzaron, para que "la empresa no pierda más dinero". Esto siempre vuelve a morderme porque luego se convierte en "mi" código malicioso, y cuando se rompe, la gente me pregunta por qué se creó de la manera que fue (después de todo, no tienen idea de quién lo creó realmente).

Entonces, mi pregunta es : ¿cómo puedo ayudar a estos colegas a comprender cuando las cosas no son tan simples como están imaginando y necesitan reevaluar su comprensión de las necesidades del cliente?

A diferencia de esta pregunta similar sobre cómo convencer a la gerencia para que se ocupe de la deuda técnica [existente] , mi pregunta busca estrategias para ayudar al equipo a darse cuenta [de manera proactiva] antes de que estén a punto de incurrir en deuda técnica, en un intento de evitar que ocurra. Estas dos cosas van de la mano, pero son claramente diferentes en mi mente. Las respuestas de la otra pregunta sugieren agregar tiempo de refactorización a las estimaciones para futuras características. Esto nunca puede funcionar si otros desarrolladores (y, por lo tanto, gerentes) siempre piensan que dicha función futura tomará menos tiempo de lo que realmente lo hará, y no puedo convencerlos de que mi estimación es más realista.

Me encanta esta pregunta porque todos los días me enfrento a una nueva estimación o sufro una estimación anterior.

La respuesta depende de qué tan grande de un proyecto / tarea esté hablando. Existen libros y métodos para tratar las estimaciones. La estimación del proyecto para un equipo de desarrollo de 50 personas con un presupuesto de 1 millón adopta un enfoque diferente al de trabajar en pequeños proyectos de '80 horas ': aquí hay algunos puntos de' vida real 'para lo siguiente:

• Estimación "de abajo hacia arriba": cuanto más pequeño puede dividir las tareas, mejor será su estimación. Puede estimar las partes más pequeñas de forma independiente, lo que tiene el beneficio adicional de identificar las funciones que faltan. Digamos que le entregan maquetas de un sitio web y le piden que le pida un presupuesto. No vaya por la cantidad de páginas, vaya por la cantidad de características. Por ejemplo, un carrito de compras puede ser '1 página', pero puede estar compuesto por 10 características diferentes.

• Las estimaciones de "tres puntos" significan hacer tres estimaciones como un rango. Luego puede responder con "40-80 horas, dependiendo de cuán complicadas deben ser las funciones xxx". Esta es una buena manera de introducir riesgos en su estimación. También es una buena idea obtener estimaciones de otros miembros de su equipo, por lo que si alguien dice 50 horas y otra persona dice 100 horas, puede discutir la diferencia.

• Cumplir con el presupuesto / alias establecer expectativas: si sabe que el presupuesto es para 100 horas y cree que es un proyecto de 200 horas, puede ayudar a establecer expectativas antes de comprometerse. "Todo lo que solicitó es un proyecto de 200 horas; si limitamos la función-x, podemos hacerlo en 100 horas".

• Tiempo de desarrollo frente a tiempo de prueba frente a tiempo de proyecto frente a tiempo de calendario: todos estos son diferentes y si eres un equipo, es fácil mezclarlo todo. Si necesita pasar 8 horas resolviendo los requisitos, luego 72 horas de tiempo de desarrollo, le llevará mucho más tiempo que 2 semanas calendario para completar el proyecto. Especialmente si necesita equilibrar otras tareas, interactuar con un equipo, esperar a los clientes o pasar horas escribiendo por correo electrónico. En este caso, dígale a su jefe "100 horas, que son x horas de tiempo de desarrollo, horas y tratando con el cliente y horas z de soporte inicial". Esto ayudará a mostrar que está incluyendo tiempo además de su código.

IMPORTANTE: no creo que la estimación sea su problema principal, creo que la comunicación externa e interna lo es. Si la característica X era tan importante, entonces el cliente debería haberla comunicado al principio. Cuando llegó la solicitud de la función X, su gerente de proyecto debería haber dicho "está fuera de alcance, pero podemos reasignar las horas actuales o ampliar el presupuesto".

Internamente, necesita comunicarse para que sus superiores sepan que está por encima del presupuesto / horario mucho antes de que sea "demasiado tarde". Cuando se le entrega una tarea, debe saber el tiempo (como en horas) y el tiempo (como en un calendario) que tiene que trabajar en esa tarea. Si la tarea no se ajusta a esas restricciones, debe informarlas: "La función A y B requerirá que haga C. Esto no dejará tiempo para X o Y".

Sin sorpresas: también debe asegurarse de comunicarse a lo largo del proyecto. Asegúrese de informar las cosas buenas, pero si algo tarda más de lo esperado, asegúrese de decirlo de inmediato. El cincuenta por ciento del camino a través del proyecto es responsable de decir:

"La función X me está tardando más de lo esperado, es posible que no llegue a la función Y".

En la fecha de vencimiento, no es responsable decir:

"No hice la función Y porque se me acabó el tiempo"

MOMENTO PERSONAL: todo esto puede ser realmente difícil cuando los gerentes todavía quieren seguir siendo codificadores y cuando todos quieren complacer al cliente.

Haz el bien y hazlo saber.

Si tienes que arreglar los problemas de otras personas porque no escucharon lo que dijiste antes o porque no tienen mucha experiencia para entender lo que les estabas diciendo, asegúrate de que esas personas y tus jefes sepan cuál fue la razón cuando se esperaba se perdió el plazo y qué tipo de falla de planificación se hizo. Y sea paciente, si sus colegas no son completamente resistentes a aprender de los errores, la situación probablemente mejorará con el tiempo.