Hoy en día, donde se habla bastante sobre los beneficios del Management 3.0, la agilidad, peopleware, desarrollo de personas, los procesos y la mejora continua, seguimos encontrando empresas que trabajan como en la época industrial.
Muchas se autodefinen como ágiles, pero lamentablemente no han podido salir del Management 1.0, a lo sumo se encuentran en un Management 2.0, combinando prácticas de gestión tradicional con algo de agilidad.
Desarrollos en cascada que comienzan por los requerimientos, pasan seguidamente a los casos de uso (incompletos e inservibles en casi todos los casos), luego al desarrollo, posteriormente al testing y si aún estamos vivos y no cambiaron los requerimientos, a la etapa de implementación, se acomodan en iteraciones y ..... listo .... ya somos ágiles.
Sigue siendo muy común por ejemplo, encontrar que la unidad de medida para estimar el trabajo que se llevará a cabo, es la hora hombre.
Trabajamos 8 horas diarias, que multiplicadas por 5 días nos dan unas relucientes 40 horas semanales. ¿Ya cargaste tus horas en el sistema de producción?
Luego multiplicamos por la cantidad de personas que conforman el equipo (sí, dije personas) y nos da la cantidad de horas para dedicar por semana al proyecto.
Eso sí, no almuerces ni tomes un café porque lo vas a lamentar.
Pero, ¿necesitamos saber el total de horas?
¿Me sirve de algo?
¿No será mejor conocer cuanto trabajo somos capaces de hacer en un tiempo determinado?
Ahhh ¿Suena mejor no?
Claro que sí.
La hora hombre no es un buen parámetro para dimensionar la cantidad de trabajo a realizar, ya que cada persona realizará las tareas a ritmos distintos. (¿Dije otra vez persona?).
Ed Catmull, cofundador y presidente de Pixar Animation Studios, comenta en su reciente libro Creatividad S.A. que para calcular cuando va a estar listo un largometraje, utilizan como unidad de medida la cantidad de trabajo que realiza una persona en una semana (Ed dijo persona en su libro, no fuí yo).
Por tal motivo en SCRUM utilizamos estimaciones relativas. Para obtener el total de puntos de historia de nuestra pila de producto (Product Backlog).
¿Y que hacemos con eso?
Conociendo cuantos puntos hace un equipo por iteración (velocidad de equipo) podemos determinar una fecha tentativa de entrega.
Finalmente podemos ponernos de acuerdo con el cliente, y en base a sus prioridades, ordenar el Product Backlog y armar un cronograma muy básico que visualice lo que podríamos ir entregando a lo largo de las iteraciones.
Conclusión
Los directivos de las empresas deberán hacer grandes esfuerzos para mejorar la gestión de los proyectos y no quedar atrapados en un paradigma dominante que no les permitirá abrirse al cambio.
La microgestión, gestión por el miedo, gestión del tipo "dirigir y controlar", ausencia de liderazgo y estructuras verticales en las que se organizan la mayoría de las empresas, son el principal camino hacia la mala gestión.
Implementa nuevas metodologías. Los clientes, la empresa y nuestros equipos te lo agradecerán.
