Administrar un proyecto con el jefe/propietario como miembro del equipo de desarrollo

A un amigo mío se le ocurrió una gran idea para un producto.

Ha reunido a un grupo de amigos, que piensan que la idea es genial, y está en camino de convencerlos (/nosotros) de donar 16 horas a la semana de nuestro tiempo para hacer realidad este sueño. Si bien no hay dinero involucrado (todavía), le gustaría manejar esto como un proyecto comercial adecuado.

Se acercó a mí y, sabiendo que tengo un poco de experiencia en gestión de proyectos, me preguntó si podía ser el PM.

Él no quiere manejar la gestión. Si bien inicialmente su sueño y su carisma eran formar un equipo, una vez que está en marcha, solo quiere hacer trabajo de desarrollo.

Sin embargo, al final del día, Él sigue siendo el 'Propietario', sigue siendo el tipo que firma el producto terminado, etc.

  • ¿Cómo se va a desarrollar esto?

    • En toda mi experiencia, el propietario/patrocinador del producto ha estado muy por encima de los desarrolladores y, en general, es extremadamente discreto. A menudo solo recibe actualizaciones mensuales
  • ¿Qué conflictos son probables

  • ¿Debo crear un contacto social escrito semiformal que describa las responsabilidades y los derechos de varias personas para el desarrollo del producto?

Respuestas (3)

Apoyo firmemente la sugerencia de J: usted tiene una situación delicada y escribir las cosas podría ayudar mucho en el futuro. Lo que podría estar buscando es una Matriz RACI donde necesita especificar dos roles muy distintos que cubrirá su compañero: cliente / propietario del producto y desarrollador.

Además, este diagrama facilitará la comprensión de quién debe realizar las llamadas. La función principal de un PM en un proyecto es informar y asegurarse de que el proyecto va por buen camino . Como el 'propietario del producto' será parte del equipo, estará actualizado sobre el progreso general... así que no es un gran problema. Lo que dejaría claro en el RACI es quién se supone que debe tomar las decisiones sobre la toba. La función principal de un PM NO es tomar decisiones .

Se espera que los PM propongan escenarios, el cliente/propietario del producto/tu amigo/un pequeño grupo dentro del equipo toma la decisión. Ese es el tipo de cosas en las que vale la pena dedicar algo de tiempo y redactar algunas filas. No necesita hacer un ejercicio extenso, redactar algunos roles y, a medida que pasa el tiempo, volver al tablero y agregar algunos roles más.

¡Éxito!

Los roles son inherentemente un conflicto de intereses. Por ejemplo, en Scrum, el rol de propietario del producto es distinto del de miembro del equipo de desarrollo. Sin embargo, muchas startups tienen fundadores que también son desarrolladores, ya sea por deseo o por necesidad.

El resto de su pregunta es simplemente demasiado amplia y demasiado similar a una encuesta de opinión para abordarla en el caso general. Deberá guiarse por su experiencia de las personas involucradas en la estructuración del equipo; nadie fuera de su grupo realmente podrá aconsejarle sobre lo que funcionará mejor para las personas involucradas.

Los gerentes de proyecto a menudo se usan en organizaciones de estilo más plano o matricial. Es muy posible que asuma el lado de la gestión de proyectos, como la gestión de cronogramas, costos, comunicación, etc., mientras descarga la gestión funcional al "propietario".

El gerente funcional, en este caso, trabajaría directamente con el equipo que construye el proyecto, mientras que como PM no estás directamente involucrado en nada de eso. Ser un PM no significa necesariamente ejecutar el proyecto.

Un ejemplo de un gerente funcional sería el líder del equipo de desarrollo, un gerente de marketing o un director de ventas, personas que poseen un conjunto de habilidades y que lideran a otros con esas mismas habilidades. Por ejemplo, un gerente de ventas lideraría un equipo de vendedores. Un gerente de proyecto, por otro lado, trabaja con esos diferentes equipos para ayudar a coordinar todo. En muchos casos, no hay una autoridad formal. Su amigo, siendo un desarrollador, probablemente cumpliría algo similar a un papel principal de desarrollador.

Ahora, definitivamente querrá crear un contrato por escrito, uno que defina claramente sus roles, cuál es su nivel de autoridad y cómo resolverá las disputas. Es imposible hacer su trabajo de manera efectiva si está siendo microgestionado, pero esto se puede hacer. Hay ejecutivos que están acostumbrados a delegar responsabilidades en otros. De hecho, una organización no puede tener éxito a menos que los ejecutivos puedan soltar el volante en algunas áreas y dejar que otras manejen.

Cuando se trata de conflictos, el que veo que es más probable que ocurra es un desacuerdo entre el propietario y otros desarrolladores, o desacuerdos entre usted y el propietario con respecto a algún proceso de PM. Idealmente, cualquier cosa relacionada con PM debería ser su responsabilidad y su decisión, por lo que esto debería incluirse en el contrato.

En lo que respecta a las disputas entre otros desarrolladores, su amigo simplemente no puede ser un desarrollador común y felizmente ignorante. No es un desarrollador ordinario; él es el fundador y líder del proyecto, le guste o no. Es su visión de producto; por lo tanto, lo más probable es que se ocupe de todo lo que implique decisiones técnicas.

Esto es realmente útil. ¿Puede ampliar más sobre qué tipo de cosas podría hacer un "gerente funcional"?
Un ejemplo de un gerente funcional sería el líder del equipo de desarrollo, un gerente de marketing o un director de ventas, personas que poseen un conjunto de habilidades y que lideran a otros con esas mismas habilidades. Por ejemplo, un gerente de ventas lideraría un equipo de vendedores. Un gerente de proyecto, por otro lado, trabaja con esos diferentes equipos para ayudar a coordinar todo. En muchos casos, no hay una autoridad formal. Su amigo, siendo un desarrollador, probablemente cumpliría algo similar a un papel principal de desarrollador. Espero que esto ayude.
Eso ayuda mucho. Podrías editarlo en la respuesta.