Mi nombre es Maxim y durante los últimos ocho años he trabajado en grandes empresas como analista de negocios y propietario de producto. Hoy me gustaría compartir con ustedes mis pensamientos sobre el desarrollo de productos, organizado con el uso de una gran cantidad de equipos de desarrollo.
Aquellos que estén interesados y dispuestos a hablar sobre este tema, bienvenidos bajo cat.
Empecemos por las grandes empresas. Por grandes empresas, me refiero a empresas con miles de desarrolladores, probadores, analistas, ingenieros de devops, propietarios de productos y otros gerentes de personas. Se trata de decenas de divisiones, cientos de equipos, jerarquías complejas, interminables dependencias y áreas de responsabilidad.
Entrar en una empresa de este tipo, al principio es difícil de navegar. Pero el tiempo pasa y ahora puedes imaginar tu "isla". Como regla, estos son:
- Algún sistema o componente comprensible que esté involucrado en un proceso comercial muy grande y complejo;
- El Product Owner es una persona que sin duda sabe dónde desarrollar este sistema;
- Un conjunto de documentación en diversos grados de relevancia;
- Un conjunto de pruebas, automatizadas y no muy.
¿Suena familiar?
Así es como se ve un sistema de desarrollo de software típico y no el peor. Por lo general, los departamentos de desarrollo de las empresas con productos exitosos llegan a esta forma en 10-15 años. Los productos exitosos generan dinero, el dinero se invierte en desarrollo. El desarrollo está creciendo a pasos agigantados, se escala linealmente y llega a una situación en la que los gerentes de proyecto ya no pueden mantener todas las dependencias en sus cabezas, muchos equipos comienzan a tirar de la "manta" sobre sí mismos y, a veces, dañan el producto en lugar de desarrollarlo. En tal situación, es bastante normal que un equipo se esfuerce por su propio éxito, sin preocuparse más de que sus colegas estén experimentando algunos problemas, y su característica común no se cumplirá debido a esto. Está en la naturaleza de las cosas desarrollar la funcionalidad que un sinfín de partes interesadas piden más fuerte, y no la que los usuarios necesitan.El desarrollo "sobre la mesa" no es infrecuente. El proceso continúa: los requisitos llegan, se implementan, se prueban y se entregan. Es fácil ocultar lo principal detrás de una pantalla de ajetreo y bullicio: el desarrollo de productos no es tan efectivo como solía ser.
Para comprender esta pérdida de eficiencia, pasemos a los clásicos de la gestión de productos. Ahora hay suficientes escuelas o universidades en línea que pueden enseñarte esta ciencia por algo de dinero.
Mi pequeña lista si no los conocías
Entonces, según los "clásicos", un producto es lo que la gente compra. Las tareas de un gerente de producto son encontrar el público objetivo, determinar el mensaje de valor, seleccionar los canales de venta adecuados, reducir la economía, encontrar puntos de crecimiento, resolver todas las hipótesis adecuadas. Si es necesario, cambie la idea, público objetivo, canales, mensaje, modelo de negocio, mercado. O incluso matar el producto si está claro que no tiene perspectivas previsibles.
No suena como la historia anterior, ¿verdad?
El punto es que, cuando eres una pequeña empresa, todos los procesos de desarrollo de productos son bastante transparentes y sencillos. Es muy fácil detectar el problema y solucionarlo. Es fácil comprender la idea del producto. Es fácil de comprender y desarrollar la funcionalidad requerida. Usuarios: aquí están, a mano. Prod: aquí está, con todas las métricas.
Sin embargo, el tiempo pasa, el producto gana cuota de mercado con éxito, se convierte en una línea de productos, se contratan más y más desarrolladores y, antes de que te des cuenta, tu empresa se convierte en una enorme confusión de estructuras, intereses y responsabilidades.
- ¿Usuarios de productos personalizados? Ahora los propietarios de sus productos no los recuerdan, se apresuran de una parte interesada a otra, tratando de comprender qué requisitos tomar al principio;
- ¿La unidad económica fue clara y transparente? Ahora los propietarios del producto ni siquiera consideran PnL (Profit and Loss), cargando a todo el equipo en el piso del sprint con lados con dudosos beneficios;
- ¿Había una historia de trabajo, un mapa de viaje del cliente y otras personas? Ahora escriben en la tienda “Como product owner, quiero que esto se haga porque el departamento de Operación y Mantenimiento lo necesita”;
- ¿Se entendió la responsabilidad por el resultado y los términos? Ahora que cada equipo es para sí mismo, sus funciones se entregarán a producción para una versión o dos más adelante.
La complejidad de la gestión del desarrollo de productos a gran escala está creciendo exponencialmente. ¿Qué hacer?
Lo primero que le viene a la mente a la alta dirección es que necesitamos un marco mágico que haga que todo este complejo sistema funcione como un reloj suizo. Hay demanda, hay oferta. Conozco varios marcos de este tipo que, en teoría, pueden hacer frente a la tarea en cuestión.
¿Son una "bala de plata"?
He pasado por varias transformaciones empresariales en las que se contrataron coaches de oro, se introdujeron los procesos de gestión y comunicación más modernos. Miles de personas cambiaron de puesto de la noche a la mañana y se mudaron a una nueva estructura, un nuevo equipo, nuevos procesos, nuevos proyectos.
Y puedo decir lo siguiente:
- es caro;
- no es rápido;
- es muy arriesgado;
- el éxito final depende en gran medida de la cultura de la empresa. Si la gente comprende y cree, es probable que tenga éxito.
¿Es este enfoque el único correcto? Veamos qué más puedes hacer.
Creo que hay otras formas de escalar el desarrollo de productos. Desafortunadamente, no tengo instrucciones paso a paso para usted, pero aquí están mis ideas que podrían ayudarlo con esto:
Producto . El producto debe agregar valor. Considere el zoológico de sus sistemas y componentes en términos de valor. Resalte todas las corrientes de valor para clientes finales, contrapartes o terceros y divida el mapa del sistema por dichas corrientes. Cada propietario de producto debe tener bajo control una cadena completa de sistemas de valor. Déle un par de analistas si el alcance de la responsabilidad es demasiado grande.
Métrica... Para administrar, primero debe aprender a medir. Cada propietario de producto debe identificar métricas para su producto, sobre la base de las cuales conducirá el desarrollo de este producto.
Usuarios . Dejemos de lado a las partes interesadas. Solo los usuarios pueden dar una idea real del valor de un producto. El propietario del producto debe guiarse por los resultados de las entrevistas y el análisis de los tickets de soporte en sus hipótesis.
Hipótesis . No más implementaciones ciegas de la funcionalidad. Cada epopeya o característica debe tener expectativas sobre el impacto en las métricas. Al implementar funciones y probarlas con pruebas A / B, los propietarios de productos deben comprender si la hipótesis fue exitosa o no.
Coordinación... Por supuesto, el trabajo de múltiples productos debe coordinarse de acuerdo con el marco que elija. Sin embargo, no debe convertir esta coordinación en una junta de responsabilidad colectiva de gerentes de producto.
Creo que solo manteniendo las condiciones descritas anteriormente se puede escalar con éxito la gestión de productos y, en general, no importa qué marco elijas para este escalado.