El miedo representa un peligro mayor, y aún más común, que cualquier otro para una organización software, mayor que cualquier componente metodológico, que la calidad, un mal ciclo de vida o lo referente a la preparación del equipo técnico, como descubrió un ingeniero informático, al que llamaré “Barry Beck”.
Café de media mañana en el más típico y sucio bar madrileño que te puedas imaginar. Zona, Plaza de Castilla. Día, de esos con esa típica niebla de principios de diciembre. Ruido, ese tan molesto como característico en un bar español, pero que no impide a Barry concentrarse en las notas que tomo el día anterior y que guarda en su Evernotes:
-Los de sistemas no queremos oír que desarrollo haga pasos a producción directamente, ni DevOps u otras historias, porque si antes no comprobamos nosotros las entregas nos jugamos que nos tiren un sistema en producción —dijo uno de los responsables de sistemas—. Seguro que no es lo mejor para que negocio ponga más rápidamente funcionalidad a los clientes, pero peor es vivir con el miedo constantemente de una caída en producción.
-Entre tu y yo, por supuesto que engordamos las estimaciones —dijo uno de los jefes de proyecto—. En esos momentos siempre estás con el miedo de que los comerciales hayan vendido más cosas de las que realmente nos dicen que tenemos que hacer.
-Entiendo que esta conversación es confidencial, y sí, efectivamente te confieso que al sacar los contratos demasiadas veces no tenemos ni idea de lo que queremos, los requisitos representan la mitad de lo que finalmente pediremos que se desarrolle, y sí, además fijamos antes de empezar el proyecto un presupuesto y tiempo inamovible —dijo uno de los clientes—. Añadiendo, y es por miedo Barry, miedo porque es muy típico en este negocio que de lo contrario desarrollo alargue el proyecto indefinidamente.
-Efectivamente, como cualquier comercial de este negocio, prometemos a los clientes menos tiempo y presupuesto del que sería razonable para realizar el proyecto — dijo uno de los comerciales-. Entiende nuestros miedos Barry, por una parte tenemos miedo a que si decimos totalmente la realidad perdamos el proyecto y miedo a que si eso sucede el CEO nos mande a la calle.
Había muchas más anotaciones similares en las notas que Barry había tomado.
Sin tener mucho más que añadir, y con las ideas más claras, finalmente, Barry concluyó la nota añadiendo:
Por mucha metodología, formación, contratación de nuevos perfiles, implantación de testing o similares, antes de todo ello, no reconocer el miedo y desconfianza entre los participantes en un proyecto es la principal e invisible fuente los fracasos software.
Hasta que los miedos no se expliciten cada uno hará batalla por su lado, y la empresa seguirá perdiendo la guerra. Para eliminar el miedo todo perfil debe tener ciertos derechos intocables y claras responsabilidades. Al igual que cualquier sociedad requiere leyes para preservar los derechos de todos.
- Debes crear apps sin saber programar (no hay que saber nada) + Crea Test con IA + Scrum es el nuevo Excel - 12 septiembre, 2024
- Las 6 técnicas prompting + 1ª Ley del Manager Oscuro + Mantenlo sencillo, estúpido - 5 septiembre, 2024
- Guía de Métricas Ágiles (versión agosto 2024) - 22 agosto, 2024
Bravo.
😉
Simplemente Genial…
Brillante!
muy bueno!
¡Más como éste!