(Al final del artículo te regalo la fórmula matemática para saber cuánto te van a exprimir)
Por desgracia, la realidad endémica y uno de los principales motivos de la chapuza clásica lo verás si participas en la elaboración de un presupuesto para licitar un proyecto: si eres previsor y presupuestas todos los hitos sencillamente perderás el contrato por precio o por sobreexcederte en los tiempos de ejecución.
De tal modo que al final, los proveedores mienten y el cliente final espera la mentira, con lo que el proceso se retroalimenta para ver quién gana la partida…
El proveedor espera ir engordando el presupuesto con la marcha del proyecto, en sucesivas ampliaciones, aunque al principio le pierda dinero. El cliente final espera ajustar y racanear el importe al máximo.
He visto proyectos que requerían de un año de programación que luego han sido planteados para que fueran terminados ¡en un mes! 😲 Lo más increíble es que todos los peces gordos de uno y otro lado decían “sí, sí” con el clásico tono de sapiencia de “grandes ejecutivos”. ¡Qué ridículo! Al final, lo dicho, se tiraron el año porque “todos los programadores son unos frikis inútiles”.
Una vez aprobado, para empezar a preparar tú carne para ser picada, los clientes finales y consultoras, suelen emplear a modo de herramienta, un diseño dibujado (diagrama de Gantt) que haga más creíble los tiempos imposibles que han lucubrado en sus fantasías empresariales.
Si trabajas en la típica subcontrata, si avisas de todas las dificultades que acabarán disparando los plazos pensarán que eres un mal programador porque engordas el proyecto y lo sacas fuera de presupuesto.
Que los tiempos se disparen suele ser considerado como habitual en la construcción del software; si tú llegas subiéndoles las previsiones, ellos tomaran como real tu 33% ampliado, más ese 100% propio que pensaban y callaban, por consiguiente, o eres un inútil o muy caro. Por avisar no van a considerar que eres mejor profesional, todo lo contrario.
Encima, advertir de los problemas venideros sólo va a servir para que te endosen más trabajo o molestar a tu jefe (olvida las películas americanas, el último mono es el último mono).
¿Cómo crees que tu responsable pensaba arreglar ese tiempo extra necesario?
¿Acaso aplicando una solución distinta a la de matarte a trabajar?
Así que mejor ser inteligente y sólo advertir lo previsible e inmediato, por ejemplo, antes de subir algo a producción haremos de “ángel de la guarda” avisando de los desastres que acontecerán si se avanza/cambia una/s determinada/s característica/s
En resumen, avisar de los desastres generales de un proyecto que arranca redunda en tu contra, pero advertir de los desastres que van a acontecer a muy corto plazo si suele ser positivo.
Ojo, quede claro que no hablo sobre nuestro propio código de programación. Debemos tener una especie de radar, previniendo las fallas por adelantado y considerando la lógica de negocio.
Por regla general, los informáticos son para los responsables simples informáticos sin distinción: piensa en un médico, ¿a que no tiene nada que ver un forense con un pediatra? pero para el profano ante la pregunta ¿a qué te dedicas? “Médico”. Pues lo mismo.
Los informáticos somos informáticos, gente rarita, punto, sin más, esta es nuestra realidad social lo queramos o no.
Los hitos del diagrama de Gantt no deben ser sólo los hitos de lo que se va a codificar… ¿le añadimos todo lo que omiten?:
- Tiempo de cohesión o selección del equipo.
- Preparación e instalación de los ordenadores y su software. Revisión del funcionamiento correcto.
- Contraseñas y accesos a los repositorios de código, etc. Esto parece una tontería, pero no lo es.
- Formación del personal.
- Diseño funcional del Software.
- Diseño técnico.
- Selección final de herramientas tecnológicas y sus pruebas. Revisión y formación de que el personal realmente conocen estas herramientas (si hablo de formación por segunda vez)
- Pruebas funcionales
- Reuniones, reuniones y más reuniones, las podemos hacer todo lo prácticas que queramos, con toda la agilidad del mundo, pero reuniones, al fin y al cabo.
- Arreglos funcionales
- Descubrimiento de nuevos requisitos funcionales y técnicos (mínimo esperar un 25%) y su desarrollo.
- Arreglo de bugs
- Arreglos de nuevos bugs provocado por el arreglo de todo lo anterior (se produce un 10% de bugs arreglando los bugs anteriores).
- El 1% más del punto anterior retroalimentado (el 10% de ese 10%).
- Fallos al subirse a preproducción.
- Fallos al subirse a producción.
- Despido de algún analista/programador y tener que explicar a un novato todo desde el principio.
- Enfermedades.
- Festivos, vacaciones.
- Manuales de instrucciones.
- Pérdidas de tiempo en miles de estúpidos emails para que todo el mundo escurra el bulto (mientras no cambie el planteamiento es lo que hay)
- 10% de imprevistos y de margen de seguridad pues la programación es una ciencia inexacta.
FORMULA PARA SABER CUANTO TE VAN A EXPRIMIR.
¿Quieres ahorrarte calcular tantos hitos en el diagrama? Es muy sencillo, se llama aplicar la Multiplier law (ley del multiplicador). Por ejemplo, si calculan que sólo en programación vas a tardar 4 meses en realizar un proyecto, el tiempo real es 4 X 3 = 12 meses. Así de sencillo.
¿Quieres saber cuánto vas a ser exprimido? muy fácil también. ¿Recuerdas que hace un momento arriba en el artículo te contaba que ellos esperan un 100% de más? Entonces sobre la estimación de sólo programación del diagrama de Gantt debes multiplicar X 2. Ellos esperan 8 meses.
¿Y los 4 meses que faltan? Pues simple, 2 meses serán fuera de plazo, con lo que todos los programadores son malos de verdad. Vas a sentir la clásica sensación de culpa para que así te exprimas al máximo tú mismo, y luego los otros 2 meses se subsanaran mediante sobreexplotación del personal, mediante tú sobreexplotación.
Las matemáticas no mienten, ya sabes cómo va el cálculo.
Conclusiones.
- Comunican el tiempo que corresponde a un tercio del proyecto y lo presentan en un formato creíble.
- Ellos saben que se tardará muchísimo más, pero lo mantienen en absoluto secreto.
- Finalmente se tarda el triple, lo que hace que te sientas fatal, te hartes de trabajar y que pese a ello seas un inútil para que de este modo no pidas aumentos salariales.
Lo has clavado. Yo calculo que es entre x3 y x4 el tiempo total necesario, si la cosa va a ir bien sin problemas es x3 y si aparece algún problema es x4. El primero que lo reconoce y al que se lo escucho decir, creía que yo era un marciano ;-).