Acabo de releer "The mythical man-month" y estas son algunas de mis conclusiones

"The mythical man-month" es una colección de ensayos escritos por Frederick Brooks. Se basan en su experiencia en IBM durante el desarrollo del OS/360 (como verán, tiene unas cuantas décadas). Sigue siendo un libro vigente sobre project management. Lo que más me gusta es la ilustración del inicio, donde se observa a un grupo de bestias empantanadas en un pozo de brea (una buena analogía para un proyecto de desarrollo de software. Bueno, el caso es que lo releí la última semana y estas son algunas conclusiones que saqué:

• Una mujer puede tener un bebe en nueve meses, pero nueve mujeres no pueden tener un bebe en un mes. Mi frase favorita y la repito a menudo cuando hablo con leads que preguntan por la duración de un proyecto de Odoo. Hay tareas en un proyecto que no se pueden evitar: gap-analysis, prototipado, testeo, documentación, migración. Muchas de ellas no se pueden ejecutar en paralelo (la mayoría tiende a ser secuencial, por más que tengan una carátula de agil). Por eso los proyectos de Odoo duran lo que duran (y por lo general es menos que los proyectos de otros ERPs).

• Agregar más gente a un proyecto de software no acorta el mismo, sino lo alarga. Esto se aplica a los proyectos cuando llega el momento de salir en producción. Cuanto más retrasado se encuentra el proyecto, existe la tentación de agregar gente al mismo con el fin de acelerar su puesta en marcha. Y esto tiene el efecto contrario, debido a las necesidades de comunicación que tiene el nuevo personal.

• Tomar un módulo desarrollado y hacer del mismo un producto, implica el triple del esfuerzo. Esto se aplica por sobre todo a la localización argentina. Por eso a los ingenuos que esperan instalar un módulo, configurar un par de campos y tener andando todo... que esperen sentados.

• En todas las actividades creativas, hay muchas horas de labor ardua. Programar no es la excepción. Y de aca podemos inferir que cualquier proyecto de implementación de Odoo es complicado. Por ende, tengan cuidado con el estar sobre-vendidos y con estar manejando muchos proyectos al mismo tiempo.

• Todos los programadores son optimistas. Todo va a salir bien. No hace falta explicarlo. Ahora este optimismo si tiene su impacto en las estimaciones y por sobre todo, en los presupuestos que se le alcanza al cliente.

• Debido a que desarrollar software es una actividad intelectual, se esperan pocas dificultades en la implementación. Pero de por si nuestras ideas son equivocadas, por ende terminamos teniendo bugs. Va de la mano con el optimismo descripto en el punto anterior. Y nada describe mejor nuestros problemas en las implementaciones. Nunca una primera versión es la que sirve. Debido a que tiene muchos errores (involuntarios, pero errores al fin y al cabo). 

• Agregar gente a un proyecto de software incrementa el esfuerzo en por lo menos tres maneras: el reparticionado de las tareas, el entrenamiento del personal nuevo, y los esfuerzos extras de comunicación.

• Programadores profesionales muy buenos, son diez veces más productivos que los programadores mediocres (teniendo en cuenta el mismo entrenamiento y tiempo de experiencia). Dedicado a los que muchas veces te discuten el valor de la hora.

• El seguimiento de los tiempos de los proyectos es de crítica importancia, y debe hacerselo muy a menudo. Esto es fundamental. Siempre consideré que el trabajo de sistemas es basicamente un trabajo de dar malas noticias (teniendo en cuenta la cantidad de proyectos que fracasan). El estar informado del estado de un proyecto, le permite al cliente tener más opciones para mitigar los efectos de los retrasos.

• No existe "silver-bullet" para salvar un proyecto de software. Ningún cambio en tecnología o herramientas va a reducir la naturaleza compleja de implementar un sistema
  

Que tiene que ver este libro con Odoo? Las conclusiones del libro se aplican a cualquier proyecto de desarrollo de software, y los proyectos de Odoo son proyectos de implementación de software (a menos que lo que se instale sea un producto ya cerrado con poco o nada de desarrollo). Por ende lo que se aprendió durante décadas de esfuerzos programando, sigue vigente. El que sostenga lo contrario, o trabaja en otra industria o lo está engañando.