En el mundo de la planificación y gestión de proyectos software este tema es un clásico. Asunto tan clásico y repetido como desconocido, aun siendo de una obviedad insultante: un deseo de negocio (por ejemplo, “-Queremos la versión 2.7 en mayo-”) no es necesariamente una estimación software.
Estoy seguro, y nadie puede discutirlo, que la gente que rige y decide los objetivos de negocio tienen grandes e importantes razones para establecer objetivos de negocio independientemente de las estimaciones software. Pero un objetivo, un deseo, una obligación, no implica necesariamente que sea algo alcanzable, realista y realizable.
Entre los muchos errores a la hora de gestionar proyectos este debe estar (y de hecho lo está, véase aquello de errores clásicos en el desarrollo software) entre los primeros y entre los más peligrosos.
Y el problema viene cuando un objetivo de negocio “deseable” se convierte en un compromiso, en la promesa de entregar cierta funcionalidad definida, además con un determinado nivel de calidad, unos recursos económicos limitados, y en una fecha determinada… que es imposible.
Todo el mundo con potestad para convertir objetivos e negocio en estimaciones debería saber que en un proyecto se pueden fijar sólo dos de tres dimensiones: presupuesto, alcance y tiempo (el llamado triangulo de hierro).
Si se fija el presupuesto y el alcance, debe dejar que sea el equipo de desarrollo quien diga cuánto tiempo. Si se fija tiempo y alcance, se debe ser flexible en presupuesto. Y si se fija tiempo y presupuesto, debe ser flexible en el alcance.
Si cierras compromisos de entrega de funcionalidad en fechas imposibles y con recursos económicos invariables la cosa explotará por algún lado, siempre pasa, es inevitable.
Normalmente se entregará un desarrollo con menos funcionalidad de la esperada, desarrollado por gente quemada, que por las prisas y de más habrá creado software con mínima calidad. Que normalmente costará mucho más dinero que si se hubiese hecho en el tiempo que razonablemente se necesitaba para ello.
Sucederá que, como hablamos en déjate de probar (o de diseñar, refactorizar, etc.) y ponte a programar, que no tenemos tiempo, al ver que el proyecto se va a retrasar n meses, comenzarán a saltarse y dejarse de hacer las tareas típicas y básicas de, llamemos, calidad software. Se saltarán las pruebas, las buenas prácticas de control de versiones, los mínimos en calidad a la hora de programar, aparecerán los pasos a producción “en caliente”, etc., cosas que al final habrá que volver a hacer, y que el sobre coste de hacerlas en el momento no adecuado está estimado que subre entre un por 10 y un por 100.
Y serán estas, y algunas otras, las razones por las que, como hablamos en ¿Qué es mejor? ¿Sobrestimar (decir tiempo de más) un proyecto o subestimarlo (decir tiempo de menos)?, los sobrecostes de un proyecto que se subestima crecen exponencialmente en función de lo grande que sea el recorte de tiempo que se le haya dado.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Hola todos,
Yo creo con total convencimiento que estimar es bueno. El acto de estimar implica un proceso de reflexión que nos permitirá entender bien las necesidades que tenemos que resolver.
Otro tema es cuándo se estima, quién lo hace y para qué lo hace. En mi compañía los proyectos se ganan a partir de las ofertas que el área de negocio presenta, es cierto que los técnicos participamos pero solo como apoyo, la oferta final la dirige el Negocio. La de veces que nos habrán pedido que bajemos nuestras estimaciones iniciales. Incluso en alguna ocasión les he visto meter un porcentaje de bajada.
Es muy complejo, para estimar bien hay que tener una buena estructura montada, un método único y conocido, datos históricos y un equipo de expertos con gran capacidad analítica y con altos conocimientos técnicos. Y tiempo para estimar. Para todo esto en la estructura montada hay que medir los resultados obtenidos.
Vamos, que estimar sí pero estimar bien.
Un saludo muy cordial
Considero que la estimación de proyectos es una herramienta útil de caracter obligatorio, pero:
Debe exisitir un trabajo en conjunto, donde los negociantes no se desentiendan de los desarrolladores; se comprende que: si se quiere ganar un proyecto con un cliente no se tiene tiempo para hacer pepeles y documentos, y mucho de lo que pueden llamarle burocracia. Pero sin medios para estimar costos los directivos dueños del capital «no ven» como se reditua su inversión.
En mi opinión, buscando una simpleza en la idea «se debe trabajar en equipo y con conciencia colectiva».
Si bien no hay tiempo, entonces ¿como esperan estimar costos sin tomar en cuenta la experiencia de quien desarrolla?.