Esta es una buena pregunta. Contestaré desde la perspectiva de alguien con 30 años de experiencia con una década como gerente de proyectos dedicado en todas las áreas, excepto el desarrollo de software, pero recientemente tropecé con el desarrollo de software del área sin querer. Independientemente de la metodología utilizada en su equipo y de cómo se llama, al final del día, los proyectos de desarrollo son los mismos que cualquier otro en el sentido comercial de que los objetivos deben cumplirse dentro de las limitaciones de tiempo, presupuesto y calidad: - y mientras los proyectos se ejecutan, el negocio continúa moviéndose y evolucionando y tiene una buena posibilidad de inyectar cambios en su proyecto. Por lo tanto, es necesario establecer y comprometerse con objetivos y plazos, y poder proporcionar actualizaciones con frecuencia y cuando se le solicite. Yo no'
Dicho esto, en mi experiencia, lo que hace que las estimaciones de tiempo en el desarrollo de software sean particularmente desafiantes es que los proyectos de desarrollo implican muchos territorios desconocidos. La definición técnica de un "proyecto", según el Cuerpo de Conocimientos de Gestión de Proyectos del Project Management Institute, es que un proyecto debe ser único. Sin embargo, la gran mayoría de los "proyectos" en TI son meras re-ejecuciones de planos y diseños previamente diseñados y libros de ejecución. En el desarrollo de software, tenemos marcos y varios patrones de diseño genérico que hacen que gran parte del desarrollo sea reutilizable, pero aún así, el núcleo de cada proyecto es completamente único.
Además, la mayoría de los proyectos de desarrollo implican la integración con otros sistemas y la rapidez con que se puede hacer es una gran suposición. Estoy trabajando en un proyecto en este momento en que mis estimaciones de tiempo originales se basaron en el supuesto de que los 4 sistemas con los que necesito interactuar programáticamente tendrían API, y resulta que ninguno lo hace. Además, uno de los sistemas está alojado en la nube, y mi organización tiene políticas que prohíben el trabajo realizado. ¿Quién podría haber predicho eso?
A medida que se hacen descubrimientos que ponen en peligro los plazos, es importante comunicar bien por qué se produjo el retraso, por qué no se pudo prever, etc.
También me han pasado que me dijeron que el plazo dado no funcionaría y que sucedería mucho más "rápido". A otra variación se le está dando una gran cantidad de cambios para inyectar en el desarrollo sin que también se le otorgue el tiempo adicional. Hay una ley en física que dice que la materia no puede ser creada o destruida, y esto viene a mi mente porque me parece que el tiempo tampoco puede ser creado de la nada. Acelerar el desarrollo probablemente tendrá un impacto negativo en la calidad del lanzamiento, la capacidad de soporte del producto y / o la evolución futura del producto.
Las solicitudes sobre el cronograma deben responderse en términos comerciales generales. "Sí, estamos en camino de cumplir con los plazos previamente comprometidos, y no hay problemas que lo pongan en peligro". Las solicitudes para agregar un alcance significativo sin más tiempo, o simplemente para acelerar la entrega, deberían ser una forma de "podemos hacer eso, pero para que todos sepan que conlleva un riesgo inherente de errores porque gran parte del tiempo de desarrollo se hace para ser proactivo. para no introducir errores y también para realizar pruebas exhaustivas ". Cuando responden con "así que solo prueben más rápido", eso obtiene una respuesta que explica que las pruebas de desarrollo no implican tiempo de inactividad y pueden acelerarse sin introducir algún riesgo de defectos faltantes.
En resumen, simplemente sugiero que todos los desarrolladores, no solo los leads, scrum master o gerente de proyecto, estén preparados para discutir sus tareas en un contexto comercial y para tener discusiones sobre los parámetros cambiantes del proyecto al tomar en cuenta las compensaciones que puede resultar.