¿Como reaccionamos ante la incertidumbre en un proyecto software?
Como he dicho en otras ocasiones nuestro nivel de control sobre un proyecto es limitado:
Especificaciones en cambio constante
Incertidumbre sobre las distintas alternativas
Gestión del cambio
Cambios en las personas
Identificación de responsables
La solución habitual para estos problemas ha sido:
Documentos de especificaciones
Documentos de gestión de cambios
Reuniones de seguimiento
Actas de reunión
etc.
Parece todo muy razonable. Pero la realidad es que estos documentos, en la gran mayoría de los proyectos, acaban convirtiendose en armas arrojadizas ante los problemas entere el cliente y el desarrollador (ya sean estos internos o externos), en una carga de trabajo para todo el equipo (tanto para los que los escriben como para los que los leen), y además no suelen reflejar bien la realidad del proyecto (por ejemplo la documentación nunca o casi nunca coincide con el producto).
En general la respuesta a estos problemas suele ser todavía mas control, todavía mas reuniones, todavía mas documentos, todavía mas trabajo, y además los mismos resultados. Te invito a consultar la documentación que te han entregado de un proyecto software, o la última que hayas escrito, casi siempre la documentación y el código no están sincronizadas.
Hay otra manera de ver las cosas. ¿Que tal si trabajamos todos en la misma dirección? ¿que tal si cambiamos algunas cosas?. Yo empezaría por cambiar la relación entre usuario y desarrollador, empecemos haciendo un esfuerzo real de confianza mutua.
Ahora aderecemos la confianza con:
Trasparencia en la evolución del proyecto, toda la información la tiene todo el mundo, o al menos la tiene accesible.
Trabajamos a corto plazo, no hace falta memoría escrita, las decisiones son mas fáciles.
Todos nos equivocamos, el miedo al error paraliza, y en la mayoría de los casos el equipo acierta a la primera. Es mejor aceptar los errores, tiene menos coste que evitarlos, sobre todo si vamos avanzando poco a poco.
Decidamos lo mas tarde posible, cuanto mas tarde tomemos una decisión mas información tendremos sobre ella.
Incertidumbre y control: “too many mind”
¿Como reaccionamos ante la incertidumbre en un proyecto software?
Como he dicho en otras ocasiones nuestro nivel de control sobre un proyecto es limitado:
La solución habitual para estos problemas ha sido:
Parece todo muy razonable. Pero la realidad es que estos documentos, en la gran mayoría de los proyectos, acaban convirtiendose en armas arrojadizas ante los problemas entere el cliente y el desarrollador (ya sean estos internos o externos), en una carga de trabajo para todo el equipo (tanto para los que los escriben como para los que los leen), y además no suelen reflejar bien la realidad del proyecto (por ejemplo la documentación nunca o casi nunca coincide con el producto).
En general la respuesta a estos problemas suele ser todavía mas control, todavía mas reuniones, todavía mas documentos, todavía mas trabajo, y además los mismos resultados. Te invito a consultar la documentación que te han entregado de un proyecto software, o la última que hayas escrito, casi siempre la documentación y el código no están sincronizadas.
Hay otra manera de ver las cosas. ¿Que tal si trabajamos todos en la misma dirección? ¿que tal si cambiamos algunas cosas?. Yo empezaría por cambiar la relación entre usuario y desarrollador, empecemos haciendo un esfuerzo real de confianza mutua.
Ahora aderecemos la confianza con:
Siempre me ha gustado mucho la escena de “El último emperador” cuando Nobutada le explica a Algren que se deje llevar, que no piense demasiado:
Cuando el control se relaja, las cosas fluyen. Las personas producen al máximo y el proyecto avanza con velocidad porque:
En definitiva en nuestra experiencia la incertidumbre se reduce con iteración con la realidad y colaboración.