¿Cómo asignas personas a proyectos muy pequeños?

He visto muchas organizaciones donde los gerentes de proyecto razonan así:

Nos especializamos en proyectos muy pequeños. Dado que un proyecto muy pequeño necesita un equipo muy pequeño, debo asignar una o dos personas a cada proyecto. Sin embargo, esto significa que solo un par de personas en la organización conocen el proyecto; si se van o los atropella un autobús, el proyecto está condenado. Por lo tanto, asignaré cuatro o cinco personas al proyecto por si acaso, a pesar de la sobrecarga innecesaria.

Puedo entender que a un gerente de proyecto le preocupe que un empleado renuncie y deje el proyecto sin personal; eso sería desastroso. Sin embargo, compensar haciendo trabajar a cuatro o cinco personas en un proyecto muy pequeño que solo necesita una o dos no parece una buena idea.

¿Qué otras estrategias se te ocurren para minimizar el riesgo y preservar los recursos?

Respuestas (3)

Documentación buena y clara como los objetivos del proyecto, las tareas involucradas, los riesgos, el cronograma y el registro de comunicaciones con el cliente.

+1 Gracias, Marcos. El enfoque de la documentación es bueno, pero, de nuevo, se puede argumentar que los proyectos muy pequeños deben ser livianos en cuanto a la documentación. De lo contrario, necesitará tanto esfuerzo para documentar lo que hace como para hacerlo realmente. ¿Es esta la única forma de avanzar?
Si minimizar el riesgo es primordial, DEBE tener más personas o documentar... no puede tener su pastel y comérselo también.
@CesarGon: no necesita exagerar con la documentación, solo lo suficiente para garantizar la continuidad. @Kwang Mark Eleven, correcto. Es cuestión de encontrar el equilibrio.
@Kwang: tienes razón; Acepto esta respuesta porque creo que un buen equilibrio entre la documentación y las personas es la clave. Gracias.

Cambiar los recursos no debería arruinar un proyecto siempre que esté bien documentado y tenga personas inteligentes trabajando en su organización. También es útil si las personas que trabajaron anteriormente en el proyecto fueron inteligentes y organizadas para que el código sea legible y mantenible. Aunque siempre habrá una curva de aprendizaje, otros desarrolladores deberían poder intervenir y desempeñar el papel.

He trabajado con desarrolladores que intervinieron y desempeñaron un papel en un proyecto, y después de unas pocas semanas se involucraron productivamente en el proyecto. Nunca he visto morir un proyecto porque alguien dejó la organización.

Gracias, pero esto está demasiado orientado al software. ¿Algo más general?
Mientras las cosas estén bien documentadas y sigan los estándares de la industria, no debería importar tanto. En el ejército, por ejemplo, tuve muchos comandantes y suboficiales de alto rango que iban y venían, y nuestra unidad seguía funcionando sin problemas. También trabajé con personas que ocuparon más un rol de gestión de proyectos en servicio al cliente, comunicándose con un cliente grande, y ese cambio tampoco afectó negativamente al proyecto.

Una cosa es que el miedo a adelantar un proyecto a una persona “atropellada por el autobús” está sobrevalorado. De hecho, he visto muchos casos en los que, por las razones que sean, los equipos tuvieron que hacer esto y no fue tan difícil.

Dicho esto, todos prefieren estar preparados. No estoy seguro de que poner a más personas en proyectos pequeños sea la solución. Creo que se trata más de organizar el trabajo de una manera que ayude a compartir el conocimiento entre los miembros del equipo que simplemente asignarlos al proyecto.

Algunas ideas que se me ocurren.

  • Programación en pareja (si hablamos de proyecto de software). No es algo fácil ya que la gente a menudo se resiste a esta técnica, pero esto no es algo completamente nuevo o desconocido. Las personas se emparejan durante mucho tiempo y en entornos específicos parece funcionar muy bien. Y puedes tener al menos el doble de personas que conozcan el proyecto.

  • Propiedad colectiva del código (nuevamente para proyectos de software). Funciona especialmente bien para proyectos en fase de mantenimiento. Si tiene un error que corregir o un cambio que aplicar, puede hacer que cualquier persona libre lo haga, incluso si no está familiarizado con el código. Si se pierden, pueden pedir ayuda a quienes trabajaron en una aplicación anteriormente. Después de un tiempo, tienes conocimiento sobre los proyectos repartidos por todo el equipo. La misma técnica que puede usar contra proyectos en su fase de construcción, pero necesita algún tipo de líder técnico o líder de proyecto de todos modos para coordinar el esfuerzo de todos.

  • Equipo de mantenimiento que asume la responsabilidad del proyecto después de alguna fase. Hace que la transición del proyecto a la fase de mantenimiento sea explícita, por lo que obliga a compartir conocimientos, alguna documentación mínima razonable, etc.

¿Cómo asignas personas a proyectos muy pequeños?
RespuestasAquíPolítica de privacidad1y, 0v