"El lado humano del software"

Proyectos imposibles en plazo, así se gestan

(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.

Clásico pensamiento de todo programador: “¿por qué no me dediqué al cultivo de la patata?”

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

 

Si en una reunión al comenzar un proyecto avisas en un acto de buena voluntad de las previsiones reales que percibes, los estarás dejando en ridículo y desbaratando sus planes ¡DESPEDIDO INMEDIATAMENTE!

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.

 

No hay programador más estúpido que aquel que trabaja con orejeras de burro haciendo sólo lo que le indican sin mirar a los lados, dejando fuera de su responsabilidad todo aquello que no sea estrictamente lo suyo. Este es un género de lo peor ¡Puaggg! Odio este tipo de programadores

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.

“Soy un profesional WuaUP”

Las incidencias o bugs son una de las mayores causas de asfixia para el programador. La realidad de los proyectos supera lo imaginable y los usuarios torpes o habilidosos van a sacar incidencias de tú software por los 4 costados. El tiempo para las mismas es minimizado intencionadamente en el diagrama de Gantt. ¿Te suena la frase “¡esa incidencia era más que evidente!” como si fueras tonto por no haberla previsto? Claro, es evidente ahora, cuando la aplicación está casi terminada, no un año antes, con lo que la culpa es tuya, y si es tuya ¿para qué van a meter ese tiempo en el diagrama?

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.

  1. Comunican el tiempo que corresponde a un tercio del proyecto y lo presentan en un formato creíble.
  2. Ellos saben que se tardará muchísimo más, pero lo mantienen en absoluto secreto.
  3. 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.

Deja un comentario

Compartir
Twittear
Compartir
+1
Pin