Esta es la segunda parte, y última, de la serie de dos post que empezó ayer. Te dejo el enlace a la primera parte.
¿Por qué hay directivos, jefes de proyecto, etc., que eligen fechas imposibles o demasiado apretadas?
Quienes gestionan proyectos del tipo a los anteriores, suelen hacer uso de frases como… “¿ves como dando caña y apretando se llega?”. Y efectivamente… se llega. Y como se llega (otra cosa es las condiciones en las que se llega)… hacer uso de cualquier buena práctica (Scrum, Gestión de Versiones, etc.) para ellos parece no tener sentido. Incluso parece justificarse el uso de fechas extremadamente apretadas.
Además, incrementa el problema que quién toma decisiones como las de antes… normalmente no entiende cómo se hace la tecnología, no conoce esas buenas prácticas de nombres raros, todo eso se sale de sus esquemas mentales.
O si conoce los mínimos del desarrollo… no le importa, porque se impone la visión de salir al paso… «y luego, ya veremos».
Y por ello, todo razonamiento de por qué es necesario unos mínimos a la hora de desarrollar les suena a chino y excusa, les suena a querer hacer cosas que consumen tiempo que no se justifica… “¿para que hay que hacer todas esas cosas raras si nunca las hicimos y salieron los proyectos?”
Los efectos de trabajar mal para llegar
Resumidamente… estás hipotecando tu futuro. Y para ponérnoslo aún peor, los efectos de esas fechas apretadas, que se llevan por delante cualquier buena práctica de trabajo… se notan a medio – largo plazo.
Lo que pasará a medio – largo plazo, tiene que ver con la deuda técnica (te recomiendo aquí aquel post de yo que tú vigilaría la deuda técnica (y sus intereses) que puedes estar pagando durante mucho tiempo), la acumulación de cosas mal hechas se lleva por delante la productividad, se disparan los errores, funcionalidades incorrectas, caídas, tiempos imposibles de cumplir, quejas de clientes, clientes que ahora tampoco ellos entienden por qué antes se iba tan rápido y ahora tan lento… y rotación de gente que se quema y se va.
Pero todo ello se ve a medio – largo plazo e, incluso, será difícil de ver (o querer mirar) toda esa acumulación de trabajo mal hecho.
Pero, créeme, llegará, tardará pero pasará, aunque quizá tu ya no estés allí, o nunca entiendas por qué pasó, llegará el momento en el que se acumulen tantas malas prácticas que todo se vea frenado. Y si te lo digo es porque lo estoy viendo día sí y día no en un montón de sitios.
Cosas que debes interiorizar si eres desarrollador y estás en un proyecto de fechas extremadamente apretadas
Es duro, lo sé, pero mejor saber que no saber. En este tipo de proyectos, bajo ese tipo de decisiones, saber (más allá de saber escribir líneas de código en un lenguaje), ser un buen profesional, no aporta valor a quienes dirigen ese tipo de proyectos.
Es decir, ser muy bueno programando, diseñando, testeando, no sirve, resta, tiempo, además, probablemente, si eres muy bueno, cobraras más y, además, estorbará que digas, por ejemplo… “es que hay que Testear” o “necesitamos hacer retrospectivas”.
Todo ello, y perdona la sinceridad, te convierte en un lastre para ese tipo de proyectos y, normalmente, todo ello termina en alguna de las siguiente 3 situaciones: (1) te frustras y te vas de la empresa, (2) o te echan o (3) te conviertes y te haces un mal profesional que vive en proyectos pena (intenta no convertirte, evita la 3)
Terminando
Aunque todo lo anterior te pareciera obvio, sigue ocurriendo una y otra vez, día tras día.
Dejo fuera de este post cuestiones sobre cómo puedes saber cuál es una fecha realista frente a una fecha imposible o extremadamente apretada. Hay bastantes post sobre ello en el blog (si no los encuentras dímelo en los comentarios y te dejo los enlaces).
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
Estoy convirtiéndome en un 3…
Hola Javier,
te sigo leyendo desde hace tiempo y eres genial Sigue así!
Yo también he estado (y sigo estando) en proyectos así y cuando ves que se toman este tipo de decisiones, la pregunta que me salta a la cabeza es…¿Porqué nadie lo impide o pone de manifiesto que es imposible llegar?
Al cliente le importa un pimiento y a la empresa que va a desarrollar el sw no dice ni mu para no perder el cliente. Y si a los técnicos se les ocurre abrir la boca….las caras que reciben son de ordago. Y así se empieza un bonito de planificación inversa. Y los técnicos pensando qué será peor, el proyecto en si o el mantenimiento que vendrá después.
Yo me he visto en los dos casos y todavía no sabría decirte cual es mejor.
Espero que este tipo de posts los lea quien toma estas decisiones y empiecen a meter algo de sentido común a este sector.
Un saludo,
Manuel
Muy interesante tu post.
Estoy de acuerdo, el problema es que la presión del «cliente» para que se le plantee una fecha razonable perpetua este problema. Dicho esto, hay ocasiones en que no hay mas remedio que ceñirse a una fecha pues por ejemplo, una ley entra en vigencia en una fecha y te cambia todo, las elecciones no se pueden postergar, un evento importante como un campeonato internacional no se puede postergar porque el software no esta listo, y claro.. en algunos casos si se puede llegar a la fecha con un producto minimo, pero en otros si que hay que llegar con todo…
Perdona, pero los clientes no somos siempre los que perpetuamos este problema. Habrá algunos que sí, no te digo que no, pero es que últimamente veo que mucha gente le echa la culpa de todo al cliente. Y esto me parece que es una dinámica peligrosa que evita la autocrítica en el sector.
Yo quiero que el software que encargo se haga bien y pronto, pero no antes del tiempo que necesita. Cuando vamos a un restaurante, no queremos que, por comer lo antes posible, la comida venga cruda. Y sobre todo, no queremos tener después indigestiones por una comida mal cocinada.
Si un comercial nos quiere vender que el desarrollo tarda X tiempo, entendemos que sabe de lo que se habla. Si se pilla los dedos (o mejor dicho, se los pilla a los desarrolladores), supongo que lo hace por que la competencia no le pise el proyecto, o por tener contento al cliente, o porque quiere hacer creer que la empresa es la leche, o porque no tiene ni idea. Yo que sé, el sabrá por qué lo hace. Pero lo que no queremos los clientes es sufrir las consecuencias.
Me parecen muy acertados tus post, es fin de año y estoy leyendo bastantes de los que has publicado este año. de ante mano muchas gracias, y por cierto, a mi si me gustaria molestarte con saber como en realidad estimar una fecha realista para entregar un proyecto.