Trabajo como desarrollador en una pequeña empresa de TI con 4 desarrolladores y 2 gerentes de proyecto. Actualmente implementamos algún tipo de gestión de proyectos tradicional, en la que el flujo de trabajo para un proyecto determinado es el siguiente:
Cada proyecto que realizamos está hecho a la medida de las necesidades específicas de nuestro cliente. Esto significa que las estimaciones de tareas a veces están mal (es difícil estimar una tarea que nunca has hecho antes) o que ciertos problemas técnicos solo surgen cuando estamos en medio del desarrollo. Esto frustra enormemente a nuestros gerentes de proyecto, ya que generalmente significa que superamos nuestro costo estimado de desarrollo y nuestro margen de beneficio para los enlaces del proyecto.
Sin embargo, la mayor frustración se origina por el incumplimiento de los plazos prometidos a los clientes. Esto se debe a que tenemos, en un momento dado, siempre 3 o más proyectos en desarrollo activo. Además de eso, los desarrolladores a menudo son llamados directamente por los clientes para preguntas, problemas técnicos o emergencias. También existe la sobrecarga adicional cuando las tareas se transfieren de un desarrollador a otro, que luego deben explicarse al desarrollador que recibe la tarea.
Cada semana, uno de los gerentes de proyecto asigna tareas a los desarrolladores que deben terminar esa semana para cumplir con los plazos. De las 38 horas de trabajo asignables por desarrollador, 4 horas se dejan sin asignar para dar cuenta de imprevistos. También hay un nuevo desarrollador que acaba de unirse a nosotros hace tres semanas y necesita ayuda técnica de vez en cuando, lo que también, en promedio, requiere de 2 a 3 horas de mi tiempo cada semana.
En conclusión, estas 4 horas hasta ahora nunca han sido suficientes. La comunicación con la administración, los errores de alta prioridad,... lleva más de 4 horas cada semana. La gerencia culpa a los desarrolladores por no poder priorizar y dice que deberíamos esforzarnos más para hacer estimaciones precisas y cumplir con nuestros plazos.
Mi pregunta es esta: ¿cuál es el enfoque correcto aquí? ¿Cómo podemos estimar mejor el alcance y la duración de un proyecto y establecer y cumplir con eficacia sus plazos? ¿Qué necesita cambiar?
Gracias de antemano.
Hay tantas cuestiones clásicas contenidas en este enfoque que es difícil saber por dónde empezar. En primer lugar, diré esto, un enfoque Agile puede ser más adecuado para usted debido a la forma en que maneja los requisitos funcionales y la deuda técnica (errores y problemas), sin embargo, personalmente no tengo experiencia directa con ese modelo. Estoy seguro de que alguien vendrá y discutirá eso como un enfoque. Sin embargo, mientras tanto, suponiendo que desee seguir con un modelo en cascada:
Gerentes de proyecto que recopilan requisitos funcionales: esta no es una tarea tradicional de PM y es más adecuada para analistas de negocios y sistemas. Los BA están capacitados para descifrar los requisitos funcionales exactos y presentarlos de una manera que el cliente pueda aprobar y (con suerte) el equipo de desarrollo pueda utilizar en sus procesos de estimación y desarrollo.
Planificación: Claramente, los PM no están planificando los proyectos con suficiente contingencia para permitir problemas imprevistos, impactos de otros proyectos que se sobrepasan y errores y problemas críticos. No me parece que se trate de un problema de estimación (depende de cuán descabelladas sean las estimaciones de los desarrolladores y cuánto difieran de la realidad). Suena más como una planificación irremediablemente optimista y una mala gestión de las expectativas. Estas son todas las áreas en las que quizás los PM podrían beneficiarse de una formación adicional.
Planificación de la capacidad: las personas responsables de planificar cómo se distribuye y asigna el grupo de recursos (no dice si también son los PM) deben ser más inteligentes con su comprensión de las diferentes tasas de producción del equipo. Algunos siempre lo harán. ser más rápido/más prolífico que los demás y al formar el equipo para un proyecto determinado, este conocimiento debe incorporarse a la planificación; pretender que todos trabajan tan rápido como el miembro más rápido del equipo es algo delirante y siempre dará como resultado un exceso de planificación optimista. También es importante tener en cuenta el impacto en los miembros existentes del equipo de agregar nuevos miembros que necesitan ser capacitados/asesorados o incluso simplemente asimilados al equipo; el efecto nunca es solo en la productividad de la nueva persona, sino que afecta la productividad de todos alrededor de esa persona. La otra cara de la moneda de la planificación de la capacidad es que, en un entorno de consultoría/casa de software pura, la utilización es el rey. Ninguna empresa puede darse el lujo de tener personas en el banco, por lo que un entorno impulsado por las ventas siempre sobrecargará al personal ("sudando los activos"). Esto nunca desaparecerá y va con el territorio, sin embargo, mediante una mejor planificación y comprensión de la productividad. de la gente podría ser mejor. La gerencia también debe desempeñar un papel en esto y ser guiada a comprender que si presiona demasiado a las personas, se reducirán las esquinas, la calidad disminuirá y se dedicará más tiempo a solucionar los problemas de calidad. Además, por lo general habrá daño a la relación oa la reputación. Equilibrar esto con un "banco" sin carga de personas infrautilizadas siempre es una tarea complicada.
La gerencia culpa a los desarrolladores por no poder priorizar: esto tiene una respuesta simple: los desarrolladores NO priorizan los problemas. Los PM, tal vez. Los BA, tal vez. El cliente, siempre (una vez llegas a la UAT). Alguien en algún lugar debería estar discutiendo y equilibrando los problemas pendientes e informando al equipo de desarrollo del orden de prioridad de los errores. Tan simple como eso: los desarrolladores son probablemente el peor grupo de personas a las que se les puede pedir que prioricen los errores y los problemas, ya que (por lo general) no tienen una visión del proyecto de nivel superior/orientada al negocio. En mi experiencia personal, yo, como PM, suelo facilitar la priorización de los problemas. Durante la etapa SIT lo hacemos usando un enfoque basado en riesgo (para simplificarlo demasiado,
Una última cosa, no menciona las pruebas en su proceso de cascada. ¿Es porque no lo haces o simplemente porque es "tan obvio" que no es necesario mencionarlo? Si pasa directamente de Desarrollador/Pruebas unitarias al cliente/puesta en marcha, entonces se está buscando problemas. El equipo debe realizar pruebas de integración y sistemas (SIT) antes de que el cliente las vea y eso debe planificarse adecuadamente por alguien que comprenda las pruebas; no un PM y definitivamente NO un desarrollador. Aquí es donde las tareas llevadas a cabo por los BA adecuados cobran importancia, ya que los profesionales de pruebas utilizan sus especificaciones para construir casos de prueba y luego para probar que el producto funciona en esos casos de prueba. Para cuando el cliente vea el código, ya debería pasar todas las pruebas que el cliente ejecutará en su contra.ser una cosa simple (¡aunque de alguna manera nunca lo es!)
Espero que ayude. ¡Buena suerte!
EDITAR después de volver a leer la pregunta: dado que es una empresa pequeña, probablemente no tenga el alcance para agregar BA y probar recursos. Sin embargo, me preguntaría seriamente por qué se necesitan dos PM para cuatro desarrolladores. Para tantas personas, no puedo ver cómo se necesita más de un PM para ejecutar múltiples proyectos. Si eliminó un PM y lo reemplazó con un BA que tiene experiencia en pruebas, en mi opinión, sería una combinación mucho mejor.
Seguramente es una tarea difícil administrar proyectos simultáneos con recursos limitados. He estado enfrentando estos problemas últimamente y encontré una salida implementando ágil y algunos fragmentos de KANBAN.
Me aseguré de que haya una herramienta de gestión de tareas PM +, que me apoye en todos los procesos a lo largo del ciclo de vida del proyecto. Implementé Redmine para gestionar proyectos y tareas. Enlazó a todos los miembros del equipo al portal, sprints definidos después de realizar scrum de scrum y luego realizar scrums diarios para garantizar que se cumplan los plazos del proyecto/tarea. Desafortunadamente, yo, como PM, también era responsable de recopilar y documentar los requisitos y luego probarlos en la puesta en escena.
Para resumir, te sugiero que sigas unos pasos rápidos:
Estos pasos prácticamente controlarían el caos con la gestión de múltiples proyectos.
Tiago Cardoso