Abner Ballardo

Si no saben que es Crunch Time pueden revisen este post. Crunch Time es una de las malas practicas más generalizadas en la gestión de proyectos informáticos y consiste en exigir a los miembros del equipo a trabajar mas horas y a trabajar fines de semanas o feriados.

¿Por qué llegan la mayoría de proyectos al Crunch Time? Hay diferentes razones y entre ellas podría mencionar:

  • Mala definición del alcance del proyecto: Si al definir el alcance del proyecto solo intervienen los vendedores, el cliente y el jefe de proyecto entonces todo saldrá mal. Los vendedores solo quieren vender y tienen de bajar tiempos, recursos con el fin de vender aun así sepan lo que pasará. Los clientes muchas veces no saben lo que quieren o quieren algo que es imposible realizar con el tiempo y dinero que pueden invertir. Los jefes de proyecto por lo normal tampoco saben de tecnologías y no piden un juicio experto (consultan al arquitecto de software)
  • Mala estimación de tiempos: Tiene que ver mucho con lo anterior. El cliente quiere que todo sea rápido. El vendedor promete un tiempo para convencer al cliente sin consultar si es viable. El jefe de proyecto trata de cumplir con lo imposible porque ya todo esta bajo contrato, etc.
  • Mala estimación de cantidad de recursos: A menos recursos más ganancia (vendedor), menos costo (cliente). El jefe de proyecto tendrá que exigir más y más al equipo.
  • Over-engineering: Hacer más de lo que necesita el cliente, un ejemplo clásico es tratar de hacer un sistema extremadamente flexible. Al final el cliente nunca necesitará aprovechar esa extrema flexibilidad y peor aún esa flexibilidad no funciona correctamente.

¿Que resultado obtendremos con esto?

  • Un equipo desmotivado y por ende un mal producto
  • Un cliente enojado debido a que el tiempo, costo y calidad del producto no es el esperado
  • Los miembros del equipo van renunciando, esto lleva a que en el siguiente proyecto se cometan los mismos errores

Y al parecer nadie aprende de estos errores, nadie trata de cambiar:

  • Enseñar a los vendedores sobre tecnologías y que siempre consulten al arquitecto de software
  • El arquitecto de software debe lo suficientemente fuerte para poder decir las cosas como son y no callar
  • Presentar al cliente opciones factibles/reales para solucionar sus necesidades. Si quiere menos costo o tiempo disminuir las funcionalidades para mantener la calidad del producto. De que le sirve al cliente un producto que se entrego a tiempo y con los costos exactos y no es de buena calidad. Tarde o temprano el producto será más y más costoso para el cliente.
  • El jefe de proyecto debe negociar y no tratar de cumplir por cumplir
  • Documentar las experiencias adquiridas sean buenas o malas para tomarlas en cuenta en los siguientes proyectos

Y mi recomendación final: Digan NO al Crunch Time!!!! o cobren mucho mucho mucho mas!!!!