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
- ¿Cómo debe administrar un desarrollador para no corregir errores que no son cruciales para llegar al mercado de productos?
- ¿Alguien prueba Craft.io? Necesito tu opinión!
- Cómo cambiar mi carrera de ser desarrollador a gerente de producto
- ¿Cuál es el consejo de Mark Fisher para entrar en el desarrollo de productos?
- ¿Quién me costaría más: un buen programador para escribir mi idea de la aplicación asesina, o un buen escritor para escribir la idea de mi libro asesino?
- 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..
