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.