Primero, las funciones que ha mencionado no cubren realmente todos los aspectos del ciclo de desarrollo.
Segundo, y por muy cliché que parezca, depende. El tamaño del equipo de desarrollo de productos y la estructura dependen en gran medida del producto, la madurez del producto en la industria y la madurez de su propia organización.
Puedo enumerar algunos factores que pueden determinar la estructura ideal (o evolucionada) del equipo
- Al comenzar a desarrollar un producto, ¿cuál es la mejor manera de obtener una base para los aspectos de fijación de precios del producto?
- ¿Cuál es un buen título para distinguir a los gerentes de producto senior que administran personas frente a los gerentes de producto senior que no lo hacen?
- ¿Qué tan efectivo es ágil para el desarrollo de productos?
- Creé un producto para el cuidado del cabello. ¿Cómo puedo llevarlo al mercado?
- ¿Debe un gerente de producto saber codificar? ¿Es un requisito que un PM sea desarrollador o sepa cómo escribir un código?
- Complejidad de la arquitectura del producto: cuanto más complejo sea el producto en términos de su arquitectura, más complicada será la estructura del equipo. La arquitectura no solo significa la naturaleza física, sino también los modos de interacción y transferencia de información entre diferentes subsistemas. La complejidad en términos de requisitos de confiabilidad requiere que tenga equipos y departamentos con habilidades especializadas profundas, estos equipos pueden ser auxiliares y pueden estar activos en un período de tiempo muy específico del ciclo de desarrollo del producto.
- Madurez / mercado del producto: si el producto que se está desarrollando es una variante, incluso con una arquitectura compleja podría ser suficiente una estructura de equipo simple. Frente a una plataforma, el producto tendrá un tamaño y una estructura de equipo totalmente diferentes.
- Madurez de la organización: es una idea generalmente aceptada que la estructura de una organización madura (que ha visto múltiples ciclos de desarrollo de productos) imita estrechamente la arquitectura del producto [Explorando la dualidad entre el producto y las arquitecturas organizacionales: una prueba de la hipótesis de ‘duplicación’]. Es probable que el equipo tenga expertos en cada uno de los subsistemas y en los diversos modos de interacción. Además, debe haber un equipo de integración central que garantice que todos los módulos y las interacciones que se desarrollen sean según las especificaciones, y que las desviaciones se gestionen y comuniquen a las personas adecuadas. Sin embargo, para una startup o para un producto extremadamente novedoso o disruptivo, esta dualidad no se mantendrá bien ya que los elementos del producto en sí están evolucionando y los diferentes miembros podrían trabajar en más de un área del producto. Pero, en general, la dualidad mencionada (en el documento vinculado) surge con el tiempo, ya que ayuda a reducir los costos y permite una mejor utilización de los recursos.
En la práctica, el jefe del producto (o el gerente del proyecto, quien sea el encargado de lanzar el producto) debe decidir sobre la base de estos factores y debe considerar los recursos disponibles y el tiempo esperado de comercialización.
Espero que esto ayude..
