Los plazos poco realistas son un problema común en el desarrollo de software. Pueden perjudicar la calidad del trabajo, la moral del equipo y, en general, el éxito del proyecto. Este artículo analiza los peligros de los plazos poco realistas, cómo identificarlos y acciones específicas para atenuarlos.
El desarrollo de software es un proceso complejo con muchas partes móviles. Es importante establecer plazos realistas para cada tarea para garantizar que el proyecto se complete a tiempo y dentro del presupuesto. Sin embargo, a menudo se establecen plazos poco realistas debido a varios factores externos e internos que debemos tener en cuenta.
Los peligros de los plazos poco realistas
“Las personas bajo presión de tiempo no trabajan mejor, simplemente trabajan más rápido” - Demarco & Líster, 1987
Los plazos poco realistas pueden tener muchas consecuencias negativas que deberían preocuparle, entre ellas:
- Aumento del estrés y el agotamiento de los miembros del equipo, disminución de la moral y la motivación: cuando los miembros del equipo sienten que trabajan constantemente bajo presión, que su trabajo nunca cumple con las expectativas, lo que les resulta aún más difícil concentrarse, puede llevar a una disminución de la moral y la motivación. Esto también puede dificultar la atracción y retención de los mejores talentos necesarios para mantener la calidad del producto en general.
- Disminución de la calidad del trabajo, mayor riesgo de errores y defectos: los equipos tienen más probabilidades de cometer errores y producir un trabajo de menor calidad. Los trabajadores sometidos a una presión de tiempo extrema tendrán que sacrificar la calidad y es posible que los miembros del equipo no tengan tiempo suficiente para probar adecuadamente su código o corregir errores.
- Desplazamiento del alcance y de las características (cuando se agregan nuevas características o requisitos al proyecto después de que se haya acordado el alcance inicial): es casi imposible mantener el rumbo y cumplir con el plazo si el alcance crece constantemente. Si alguna vez has consegido una prórroga de la fecha límite para acordar un mayor alcance como compensación, ¡has hecho que el problema sea aún mayor!
- Se hace trabajo innecesario, el trabajo no se optimiza: cuando no hay tiempo para detenerse a pensar, los equipos tienden a producir exclusivamente, sin explorar. mejores soluciones o preguntarse si es necesario hacerlo, lo que genera una gran cantidad de desperdicio (funciones que ya no se necesitan, no se usan o se descartan).
- Daños en las relaciones con los clientes y oportunidades perdidas: si el proyecto se retrasa o si el software no cumple con las expectativas, puede dañar la reputación de la empresa y dificultar la atracción y retención de clientes. li>
- Pérdidas financieras: Los plazos poco realistas también pueden provocar pérdidas financieras para la empresa. Es posible que la empresa tenga que pagar horas extras, contratar personal adicional o retrasar el lanzamiento del producto perdiendo oportunidades de mercado.
- Fracaso del proyecto: En el peor de los casos, los plazos poco realistas pueden provocar el fracaso del proyecto. Esto ocurre cuando el proyecto se abandona o cuando el software se lanza en un estado que no está listo para producción.
Cómo identificar plazos poco realistas
Existen varias señales de que su proyecto puede estar sufriendo plazos poco realistas, entre ellos:
- Los miembros del equipo están constantemente trabajando horas extras.
- Los miembros del equipo informan que se sienten estresados y con exceso de trabajo.
- Los miembros del equipo están tomando atajos para cumplir con los plazos.
- La calidad del trabajo está disminuyendo. Los miembros del equipo están cometiendo más errores de lo habitual.
- Incluir nuevas funciones lleva cada vez más tiempo (la deuda técnica está aumentando).
Además de estas señales, también puedes fijarte en las siguientes métricas para detectar que tu proyecto sufre plazos poco realistas:
- Velocidad (medida de cuánto trabajo puede completar un equipo en un período determinado: puntos de historia, puntos u otra unidad de trabajo). Si la velocidad del equipo es consistentemente menor que la cantidad de trabajo que hay que hacer, es una señal de que los plazos pueden no ser realistas.
- Tasa de finalización de tareas (el porcentaje de tareas que se completan a tiempo y dentro del presupuesto): si la tasa de finalización de tareas es baja, es una señal de que los plazos pueden no ser realistas.
- Evaluación de riesgos (el proceso de identificar y evaluar los riesgos asociados con un proyecto): si la evaluación de riesgos muestra que hay una gran cantidad de tareas de alto riesgo, es una señal que los plazos pueden ser poco realistas.
- Moral del equipo (la actitud y perspectiva general de los miembros del equipo) y Burnout (un estado de agotamiento emocional, físico y mental causado por Estrés prolongado o excesivo): si la moral del equipo es baja o los miembros del equipo están agotados, es una señal de que el equipo puede estar teniendo dificultades para cumplir con los plazos.
Acciones para evitar y atenuar plazos no realistas
“El proyecto que debe realizarse en una fecha fija imposible es aquel que no puede permitirse el lujo de no tener frecuentes lluvias de ideas e incluso una cena del proyecto o algo así para ayudar a los participantes individuales a unirse en un todo efectivo” - Demarco & Líster, 1987
Hay varias cosas que puedes hacer para evitar y atenuar los plazos poco realistas, entre ellas:
- Establezca plazos realistas en primer lugar. Esto puede parecer obvio, pero es importante tomarse el tiempo para estimar cuánto tiempo llevará cada tarea y tener en cuenta un margen de tiempo para retrasos inesperados (p. ej. enfermedad, dependencias externas). Recuerde que las estimaciones deben ser proporcionadas por el equipo y no impuestas por los gerentes. Considere también el tiempo adicional necesario para la lluvia de ideas (refinamiento del trabajo pendiente), el análisis y la exploración.
- Divida las tareas grandes en tareas más pequeñas (más manejables). Esto continuó dividiendo tareas grandes en tareas más pequeñas y manejables. Esto hará que sea más fácil estimar el tiempo necesario para cada tarea y realizar un seguimiento del progreso.
- Comuníquese con las partes interesadas periódicamente y manténgalas actualizadas sobre el progreso. Esto ayudará a garantizar que todos estén en sintonía y que no haya sorpresas en el futuro. Una fecha límite es un compromiso compartido en el que tanto las partes interesadas como el equipo de desarrollo deben colaborar. Esté preparado para ajustar los plazos según sea necesario. Las cosas no siempre salen según lo planeado, por lo que es importante estar preparado para ajustar los plazos según sea necesario. Esto puede implicar comunicarse con las partes interesadas y explicar por qué es necesaria una extensión o reducción del alcance.
- Prioriza las tareas y céntrate primero en las más importantes. Esto ayudará a garantizar que las tareas más importantes se completen a tiempo, incluso si es necesario ajustar los plazos para las tareas menos importantes.
- Si no se puede negociar la fecha límite, negociar el alcance que se entregará en esa fecha no negociable. Divida el alcance en múltiples plazos (hitos) cuando sea necesario.
- Di no a nuevas solicitudes si es necesario. Es importante ser realista acerca de lo que su equipo puede lograr. Si le piden que asuma demasiado trabajo, es importante poder decir que no. Tenga un proceso de gestión de cambios claro, tenga en cuenta las horas actuales invertidas (por ejemplo, análisis) y el impacto en el alcance general antes de incluir o intercambiar funciones. Recuerde, si el alcance aumenta, normalmente significa que la fecha límite también debería retrasarse.
Conclusiones
Los plazos poco realistas son un problema común en el desarrollo de software, pero pueden evitarse o atenuarse. Es importante señalar que la calidad del trabajo es más importante que cumplir plazos poco realistas. Si se toma el tiempo para establecer plazos realistas y gestionar el alcance de su proyecto de manera efectiva, puede asegurarse de que su equipo produzca un trabajo de alta calidad y eso tendrá un impacto directo en el éxito del proyecto.
Referencias
- Peopleware: proyectos y equipos productivos por Tom DeMarco y Timothy Lister
- The Mythical Man-Month: ensayos sobre ingeniería de software por Frederick P. Brooks Jr.
- Desarrollo de software ágil: principios, patrones y prácticas por Robert C. Martín
- La falacia de los plazos: por qué los plazos no funcionan y qué hacer en su lugar por Dan Olsen