Una pequeña diatriba: ¿quién/cómo van a reponer ese tiempo?

De las cosas que más me disgustan del modelo anterior (y que aún sigue sucediendo en algunos contextos ágiles) es cuando el PMO / Gerente de Producción / un mal Gerente de Proyecto / un mal Cliente / un mal Product Owner / un mal Scrum Master le hacen la dichosa y molesta pregunta al equipo o al encargado de turno:

¿Cómo van a reponer ese tiempo?

¿Quién va a pagar ese tiempo?

Lo peor es que lo dicen señalando el cronograma, como si este tuviera la respuesta a todas las preguntas y dentro de el estuvieran embebidos todos los posibles escenarios en un proyecto de software, el cual posee elementos cantidad de elementos cambiantes e incontrolables.


y yo me pregunto

• ¿es que acaso creen que el equipo estuvo desocupado todo este tiempo?
• ¿es que se la pasaron silvando mal hombre -como decimos en Colombia  - ( ver video de la canción http://www.youtube.com/watch?v=hS5iEP8SUKw )?

Hombre.. claro entraron de vez en cuando a facebook, pero "la madre", esta gente estuvo trabajando fuerte por el proyecto....y el atraso no se corrige poniendo a facebook en el firewall, les aseguro que el problema no se encuentra allí.

Lo simpático es que la respuesta que ellos esperan es:

Si, vamos a trabajar más duro estas próximas X semanas para reponer esas horas, para reponer lo que perdimos, o lo que se perdió. (que para ser sinceros no fue culpa del equipo)

Y para acabar de ajustar (en ese contexto) un "buen gerente de proyecto"  es el que logra comprometer a su equipo bajo presión por largas, largar jornadas hasta lograr reponer algo que pronto se volverá a perder y es el estar al día en el cronograma (el cpi y el spi cercanos a 1)  (Sugiero ver este post Recomendaciones sobre el sobre-esfuerzo - clic aquí)

Lo cierto es que un equipo de desarrollo honesto durante un mes, dos meses o el periodo que sea se la pasa enfocado en producir el resultado que se le encomendó, y ¿si no se cumple lo prometido donde esta la falla?

• ¿en el equipo?
• ¿en las personas?
• ¿en el gerente de proyecto?
• ¿en el cliente?
• ¿en el scrum master?
• ¿en el product owner?
• ¿en el coach?
• ¿en el comercial?
• ¿la documentación?
• ¿los casos de uso?
• ¿la arquitectura?
• ¿el involucramiento del cliente?
• ¿en el modelo de contratación?
• ¿en la metodología?
• ¿en la falsa concepción de que los errores de planeación debe pagarlos el equipo?

o ¿quien en sus cabales va a querer hacer mal su trabajo?

Pienso y siento que la forma de trabajo actual (proyectos a valor cerrado y ejecución en cascada y/o RUP ) es un esquema deshonesto con los equipos de desarrollo, con las empresas de software, somos trabajadores del conocimiento, que volvemos información en innovación , que queremos hacer las cosas mejor, si algún tiempo no se cumple la falla no esta en el equipo (estoy bajo el supuesto que el equipo es el equipo adecuado para el proyecto), ni es el equipo el responsable de remontar esos retrasos inalcanzables, tengan la seguridad que los más felices de ver el proyecto funcionando son los que lo están construyendo.

El esquema tradicional de contratación de software ya demostró con creces durante bastantes años que falló, aunque hay rezagos en las mentes de muchos en su transformación hacia el agilismo, debemos soltar todos las antiguas concepciones y permitir que en un marco de trabajo como Scrum, con límites definidos y la capacidad de fallar de forma temprana permitan corregir el camino, hacer de esta profesión algo atractivo y creativo, algo motivador y que no sean los de sistemas los destinados a trabajar y trabajar a cambio de frustraciones.

Yo quisiera dejar de encontrarme con amigos, colegas, alumnos, exalumnos, que trabajan sin descanso en favor de los software sin ninguna recompensa, desgastándose y perdiendo tiempo valioso con ellos mismos, sus novi@s, sus familias. Hacer software debe ser algo chévere, motivador, creativo, que den ganas de ir a trabajar los lunes, que el jefe/líder/gerente de proyecto/novato scrum master sea alguien que no considere que el éxito del proyecto esta dado por la ejecución del plan (PLAN-DRIVEN) - lo cual no garantiza el éxito de lo construido-, sino alguien orientado al valor (VALUE-DRIVEN), en liberar las funcionalidades que más beneficio traigan al negocio lo antes posible con la calidad inmersa en cada iteración.

Esta esclavitud de proyectos de software gerenciados/liderados con MS PROJECT debe de cambiar/ tiene que cambiar / tiene que acabar, tenemos una oportunidad de oro para transformar de nuevo nuestra industria local y latinoamericana y ponernos a la par de los líderes mundiales.

Ojalá el agilismo, el buen agilismo, el que tiene excelentes prácticas técnicas y metodológicas juntas, el que cumple la DEFINITION OF DONE, llegue pronto a todas las universidades, a las entidades públicas, a las gerencias de TI de las diferentes industrias y a las empresas de software y volvamos a ver entre todos una industria donde se matriculan gran cantidad de estudiantes (en Colombia actualmente las universidades sufren una escasez de matrícula de estudiantes en ingeniería de sistemas y afines, y una deserción de la misma), a una industria que mueve masas, felicidad y ¿por qué no? millones de dólares para beneficio de todos los roles involucrados en esta profesión.

Hasta acá mi reflexión y diatriba, bienvenida la discusión

Saludos ágiles

Jorge Abad.