"Uno de mis clientes cuenta con una larga historia en el desarrollo de software, ahora llegando más de 30 años. A través de gran parte de este periodo, han mantenido trabajando a 100 o más desarrolladores de software. Por lo que ellos pueden alardear, sin exagerar, que tienen más de 30.000 persona/años de experiencia en desarrollo de software. Yo estaba muy impresionado: Imagine todo ese aprendizaje siendo depositado en cada nuevo proyecto. De tal manera que le pregunte a un grupo de ellos, ‘Cuando envian un nuevo manager a un proyecto nuevo de software, ¿cuáles sabias palabras le susurran al oído? Ellos pensaron sólo por un momento y contestaron, casi al unísono: 'Buena suerte'"
Podemos pasar años sin sacar provecho de nuestras experiencias, sin aprender de los errores. Esta es una idea que me preocupa y me esfuerzo porque no me suceda. Por eso observo con detalle lo que hago y lo que hacen otros. Analizo que es lo que he hecho mal, que es lo que otros han hecho mal. Siempre existe una lente algo crítica entre mis ojos y la realidad. Me resulta muy positivo este tipo de análisis porque es de allí que nace el aprendizaje que le da valor a la experiencia.
No importa si has gestionado varios proyectos de desarrollo si una vez tras otra culpas a la inmadurez e indecisión del cliente como origen de todos los fracasos.
Raymond Chen indica en su sitio que la NASA tiene un newsletter donde los aviadores pueden enviar reportes anonimos sobre "cosas estupidas que he hecho" para transmitir a otros pilotos la idea "No hagas lo que yo hice". Es una buena idea para compartir experiencias. Quien las lee puede sacar algo de provecho para no cometerlas, quien las escribe seguramente ha aprendido a no repetirlas.
Mi experiencia en el desarrollo de software es limitada pero tengo cosas para contar en la categoría "cosas estupidas", por eso posiblemente este sea el primero de una serie de artículos sobre esta temática. Hoy comenzaré con una frase clásica:
"En la proxima iteración recuperaremos el tiempo perdido."
Trabajar en una empresa pequeña y tener iniciativa da grandes oportunidades, como planificar un proyecto mucho antes de tener cierta experiencia para no caer en trampas clásicas. Pero se aprende mucho en el camino.
Una vez se presentó un proyecto pequeño que no parecía tener mayores complicaciones. El esfuerzo estimado para terminarlo era de 10 personas/meses. En mi rol de planificador decidí definir 5 iteraciones de 1 mes de duración. No podía dedicarme completamente a este proyecto pero existían otras dos personas que si lo hacían y eran quienes hacían la mayor parte del trabajo. Ocasionalmente yo observaba el avance, hacía alguna sugerencia pero mi tiempo estaba dedicado mayormente a otros proyectos (¡Ay, multitasking! Un buen tema para escribir en el futuro). La planificación era simple. Teniamos una iteración de un mes, con un conjunto de casos de uso para terminar y responsables para hacerlo.
Terminado el primer mes, nuestro avance no era el esperado. Los casos de uso planificados no estaban terminados y teníamos algunos días de retraso.
"No importa, vamos a recuperar el tiempo en la proxima iteración." pensaba yo. "Comenzaremos a trabajar de manera paralela en más de una iteración. Además empezamos por lo más dificil y no conociamos mucho el contexto del proyecto. Ahora todo ira más rápido".
Adivinen que pasó... No, no recuperamos el tiempo. En realidad eso nunca pasa.
Los planes deben alimentarse y mejorarse con lo que ocurre realmente, no se puede eliminar toda esta información de retroalimentación que dice a gritos: "las cosas no son como las planificaste. Los tiempos son otros." Lo peor que se puede hacer es desechar esta información y seguir con el plan. Porque un plan escrito en piedra no sirve.
Errores clásicos
Es muy cómun caer en este tipo de errores porque parece existir algo en nuestra naturaleza que nos lleva hacia ellos una y otra vez..
Yendo más allá del desarrollo de software, es muy interesante los disfraces que puede tomar este error en distintos ámbitos. Hace unos días vi un especial de un canal de televisión francés que hablaba sobre la organización de los Juegos Olimpicos de Atenas del 2004. En este especial se podía ver a miembros del COI justificando los retrasos dramáticos en la organización de los Juegos hablando del sertaki.
El sertaki es el baile griego que inicia a ritmo lento y a medida que pasan los compases el tempo comienza a acelerarse hasta que no pueden verse los pies de bailarines. Era su forma de decir que los griegos comienzan a trabajar lento pero que al final iran tan rápido que recuperaran el tiempo perdido. Hoy nadie puede asegurar si se podrá terminar el techo vidriado del estadio olímpico para la ceremonia inaugural. Algunas frases de la voz en off del programa me resultaron tragicómicas: "El retraso llego a un punto tal que no existió mas remedio que modificar el plan original y replantear los tiempos."
En resumen, la enseñanza que queda de todo esto es simple: nunca pienses que recuperaras el tiempo perdido en tu proyecto. Actualiza los planes para que sigan siendo útiles.
