¿Qué tan constante debe ser el equipo de software?

Creo que cada producto de software debe tener su equipo constante a lo largo de su ciclo de vida.

¿Qué pasa con la situación, cuando uno de los desarrolladores principales, que ha estado involucrado en el proyecto al 100%, cambia a otro proyecto? Aquí, asignar un nuevo desarrollador parece la única forma razonable de mantener el proyecto en marcha. Sin embargo, el tiempo dedicado a la comunicación y la plena participación y comprensión del código escrito por otros plantea muchos problemas. Además, muchos desarrolladores son reacios a participar en este tipo de proyectos. Otra cosa importante es que el equipo se fragmenta y el espíritu de equipo comienza a desaparecer, si los miembros del equipo cambian constantemente.

¿Cómo debería PM mantener su equipo de software o al menos los miembros principales sin cambios hasta la entrega del proyecto?

Respuestas (2)

¿Cómo debería PM mantener su equipo de software o al menos los miembros principales sin cambios hasta la entrega del proyecto?

No deberías... ni podrías. La gente deja. Ellos mueren. se enferman Lo único cierto acerca de tu gente es que no están seguros. Y su proyecto debe planificarse con eso en mente. En otras palabras, crear una capacidad de proyecto que no dependa de un individuo. Nunca jamás te vuelvas dependiente de una persona.

La capacidad de su proyecto debe establecerse de tal manera que, si una persona se va, puede conectar a otra con un conjunto promedio de conocimientos, habilidades y capacidades que se requieren y mantener la máquina del proyecto funcionando con poca o ninguna degradación del rendimiento. Y si tiene degradación, la planeó y puede hacerle frente sin secuelas notables en otras áreas del proyecto o negocio. Ese es el trabajo del PM.

Este es un escenario común que ocurre en muchas organizaciones. Si necesita mover un recurso central de un proyecto a otro en el medio del proyecto, debe tener cuidado con las siguientes cosas... (Supongo que el desarrollador principal fue el líder del equipo)

  1. Cuando el desarrollador central mueve el conocimiento, la transferencia al nuevo desarrollador es más importante. Intente dedicar algo de tiempo y hacer que el nuevo desarrollador comprenda el pasado, el presente y el futuro del proyecto.
  2. El antiguo desarrollador, incluso después de pasar al nuevo proyecto, debe pasar tiempo con el proyecto y el equipo hasta que el nuevo desarrollador se sienta cómodo manejando el proyecto.
  3. Una vez que el nuevo desarrollador se sienta cómodo con el equipo y el proyecto, el antiguo desarrollador puede pasar permanentemente al nuevo proyecto.