Tabla de contenido del curso
1. Rol de product manager y framework
2. Segmentación del mercado y análisis competitivo
3. Personas de usuario
4. Prueba de hipótesis
5. Posicionamiento del
producto 6. Hoja de ruta del producto <- Usted está aquí
7. Redacción de requisitos para el desarrollo
8. Modelo de negocio y negocio- Plan
9. Plan financiero y fijación de precios
: continuará
Tener una hoja de ruta es muy importante para administrar el desarrollo de productos. Sin embargo, para poder elaborar correctamente una hoja de ruta, es necesario abordar este tema de forma sistemática. Es muy importante no confundir una hoja de ruta con una visión, aunque es necesario tener una visión para construir correctamente una hoja de ruta.
Lema de las Naciones Unidas: “Piense globalmente, actúe localmente ". Curiosamente, también funciona cuando se crea una hoja de ruta para un buen producto de software. Para ello, necesitas tener una visión global para que tus aspiraciones no terminen aquí y ahora. Dentro del marco de la visión, se establecen objetivos; también son bastante globales, y es a estos objetivos a los que debe conducir la hoja de ruta. Cuando se mueve de acuerdo con el mapa preparado, los lanzamientos se convierten en hitos y etapas de este movimiento, la encarnación de pasos específicos para el desarrollo de productos.
¿Qué horizonte debería oscilar con la planificación? Puede ser diferente, pero para empezar es mejor limitarse a 6 meses. Si sabe exactamente dónde se moverá su producto, podría ser de 3 años o 5 años. No hay límite. Por ejemplo, en su reciente discursoEl fundador de Amazon, Jeff Bezos, anunció el programa espacial Blue Origin con un horizonte de planificación de 50 a 100 años. Es decir, una persona crea una empresa que funcionará la mayor parte del tiempo después de su vida. Como es esto posible?
Es solo que en este caso estamos hablando de una visión global: Blue Origin debe brindar la posibilidad de vuelos espaciales intensos. Amazon se basó en una infraestructura de mensajería y correo ya existente, dijo Bezos. Si no existieran, Amazon no habría podido funcionar ni tener tanto éxito. Hoy, Blue Origin planea crear infraestructura para futuros viajes espaciales: cohetes, puertos espaciales, satélites, estaciones orbitales, etc. Los objetivos globales de Blue Origin son construir una nave espacial para 2025.
Comprender sus objetivos globales ayuda a trazar una hoja de ruta donde mostramos pasos concretos, construyendo un plan realista para lograr los objetivos establecidos en el futuro cercano. Y Blue Origin, como empresa con planes ambiciosos, está tratando de cumplir con su misión: organizar un servicio mundial para el movimiento accesible y conveniente de personas y mercancías.
Del cielo a la tierra ...
Considere un ejemplo más realista. Si una empresa constructora se dedica a la construcción de alta calidad, el concepto de su trabajo puede verse así:
● Visión : construir la mejor zona residencial en el norte de Moscú (SAO).
● Objetivos : 5000 apartamentos, arquitectura moderna, comodidad de clase, diseños convenientes, un patio sin automóviles.
● Hoja de ruta : colas de desarrollo y paisajismo.
● Liberación : edificios con acabado de hormigón, carreteras, parques (la división es posible en la etapa de finalización).
● Característica : un componente de la versión. Por ejemplo, un patio de juegos, árboles plantados, estacionamiento cubierto, una rampa.
¿Cómo crear una hoja de ruta de un producto de software?
La hoja de ruta del software incluye versiones, cada una de las cuales debe contener determinadas características. Es muy importante programar una hoja de ruta por fechas, teniendo en cuenta las capacidades y recursos disponibles (más sobre esto más adelante). Por ejemplo, así es como se ve una hoja de ruta para una de las aplicaciones sociales.
Tenga en cuenta que la hoja de ruta debe planificarse para todos los departamentos a la vez. Si la empresa es grande y los gerentes de ventas tienen su propia hoja de ruta, debe vincularla a la hoja de ruta del departamento de desarrollo. De lo contrario, cuando llegue el momento, por ejemplo, de promocionar un producto en el mercado asiático, puede resultar que no tenga una localización preparada ... y de hecho soporte para el idioma chino.
Las solicitudes de lo que debería estar en un producto provienen de muchos sectores diferentes. Ya hablamos de esto en uno de los posts anteriores .... Deben organizarse y planificarse cuidadosamente. Es importante entender que no será posible preparar y lanzar todas las funcionalidades en la versión 1.0, porque en realidad nunca hay suficientes recursos para implementar todas las ideas (si este no es el caso, entonces tienes pocas ideas y necesitas pensar más).
Con el enfoque correcto, Roadmap es una oportunidad para dividir el proceso de desarrollo de productos en etapas y desplegar la funcionalidad con una prioridad e importancia decrecientes en las iteraciones.
Echemos un vistazo a otro marco de desarrollo de productos de software ( marco de gestión de productos de software) que controla el desarrollo de software:
La matriz de madurez de una empresa que vive bajo un marco dado está determinada por la siguiente tabla. Y con la adhesión formal al proceso de preparación de la hoja de ruta, la empresa pasa inmediatamente al segundo nivel de madurez:
en general, este marco es una rama separada para cualquier curso sobre desarrollo de productos. No nos detendremos en eso ahora. Si alguien está interesado en leer una publicación adicional sobre este tema, deje un comentario sobre esta publicación.
Aquí, por nosotros mismos, solo aceptaremos que al observar algunos procedimientos formales en el desarrollo de software, mientras se construyen estos procesos, la propia empresa mejora la cultura de entregar mejor software. La hoja de ruta es parte de esta cultura.
¿Cómo recopilar y procesar los requisitos del producto?
Cuando recibimos requisitos de diferentes lados, deben ingresarse en algún tipo de sistema. Por ejemplo, Acronis usa Jira, que es una herramienta bastante poderosa, pero para las startups puede usar las más simples, incluidas las gratuitas, por ejemplo, Redmine o Asana.
Lo principal es que se registran todas las ideas, porque no hay malos pensamientos. Si la idea aún no merece ser implementada, su prioridad seguirá siendo baja. Por lo tanto, es muy importante ingresar cada oración en el sistema, incluso sin una descripción detallada de "cómo debería funcionar". Solo con este enfoque puede planificar la implementación de las funciones demandadas, es decir, crear una hoja de ruta real.
Todas las ideas llegan al llamado "Incoming backlog", pueden ser formalizadas o "crudas", sin evaluaciones y sin entender quién necesita estas características. Después de resolver las solicitudes y agregar detalles, algunos de ellos pueden pasar a la próxima versión. El resto se envía al Backlog y puedo quedarme allí mucho tiempo.
Épico
La metodología Agile o Scrum implica un término como "Epic". Para explicar su esencia de la manera más simple posible, estamos hablando de una gran característica, cuya implementación requiere la participación de todos los participantes: desarrolladores, evaluadores, diseñadores de interfaces, redactores técnicos, etc.
Por lo general, al crear una epopeya, se evalúa su importancia desde el punto de vista comercial, se calculan los costos laborales y se toma la decisión de incluirla en la versión actual o enviarla a la cartera de pedidos.
Para las epopeyas que ya han sido calificadas, puede asignar una prioridad en el sistema. Por ejemplo, en el mismo Jira, puede establecer "alto", "medio" o "bajo". Pero, por ejemplo, en nuestra acumulación de Acronis hay cientos e incluso miles de funciones. En este caso, las prioridades simples son indispensables.
Calcular la puntuación de características
Una metodología de puntuación más compleja se llama Feature Score. La idea es reunir todos los factores que influyen en el desarrollo en una sola calificación. Luego, según la calificación normalizada, tome decisiones sobre la inclusión de la función en el lanzamiento o el abandono del desarrollo en este momento. Por lo tanto, las métricas positivas agregan puntos a una característica, mientras que las negativas actúan con una proporción inversa (más valor - menos puntos). Algunas de las métricas positivas incluyen:
1. Urgencia.
2. El tamaño del cliente que lo necesita.
3. Incremento de la cuota de mercado por la aparición de nuevos clientes.
4. Posibles ganancias o pérdidas por la salida de clientes actuales.
5. Logros estratégicos (metas que nos llevan a la personificación de la Visión).
Métricas negativas:
1. El monto de los costos laborales.
2. Riesgos potenciales.
La puntuación de características debe ser un número. No se trata de una evaluación cualitativa, sino de algún tipo de calificación, y el método para su cálculo debe ser unificado y aprobado en el marco del desarrollo de un producto específico.
Los puntos se determinan en función de valores normalizados, objetivos de mercado de la empresa y otros parámetros. El primer parámetro que se tiene en cuenta en el Feature Score es el factor cliente. El llamado Factor Cliente se define como el producto de la urgencia y el tamaño del cliente. Puede ver un ejemplo de cálculo en la imagen a continuación.
Penetración de mercadose define como la probabilidad de atraer nuevos clientes y depende de sus planes para ampliar su base de clientes. Por ejemplo, para las funciones que no atraerán nuevos clientes, este parámetro puede ser igual a 0, y para aquellas que pueden traerle, digamos, 500 clientes, la puntuación será 20.
La siguiente pregunta es el cumplimiento de la estrategia. Para evaluar la estrategia, debe verificar si la función lo ayuda a avanzar en las direcciones de desarrollo estratégico. Y cuantas más direcciones cubra, mayor será la puntuación.
Los ingresos son las ganancias potenciales que puede dar la implementación de una función. La estimación de este parámetro depende del tamaño de la empresa, las características del producto y los ingresos que espera recibir. La tabla muestra un ejemplo de puntuación para este indicador.
Pero ahora hablemos de los factores opuestos, que dan menos puntos a una característica, más se manifiestan. Por ejemplo, los costos de desarrollo también se pueden fijar para su empresa al nivel de ciertas estimaciones, dependiendo de cuánto esté dispuesto a gastar en el desarrollo de ciertas características.
Los riesgos es el segundo aspecto. Cuanto menor sea su confianza en las evaluaciones, mayores serán los riesgos, lo que significa que menor será el valor del criterio en la fórmula de Puntuación de características.
Después de tener en cuenta todos los factores mencionados, la fórmula Feature Score puede verse así:
Es bueno si las puntuaciones son objetivas, basadas en factores específicos. Pero si recién está ingresando al mercado, aún obtenga un Puntaje de Característica. Es mejor ser subjetivo que nada en absoluto.
Hoja de ruta sobre el ejemplo de la aplicación "Taxi"
En uno de los posts anteriores ya hemos hablado de crear una aplicación para llamar a un taxi. Suponga que necesitamos clasificar las siguientes características para este producto:
Una tabla con prioridades podría verse así:
Considere la característica "Ordenar en el momento adecuado". Resumiendo todos los parámetros, obtenemos 56. ¿Qué significa este número? ¡Nada! Esta es una calificación relativa, y debemos calcular las 9 características, siguiendo los mismos criterios y calificaciones. El resultado es una lista de prioridades. En nuestra aplicación, obviamente necesitamos hacer una aplicación móvil en Android. El segundo paso es la tarifa "Niños".
Un enfoque sistemático permite no hacer lo que no es tan importante para el negocio y no elegir una “característica aleatoria” para su implementación. El rendimiento del trabajo gradual y por fases será mayor. Y esto es muy importante, porque siempre existen factores limitantes para el desarrollo de cada proyecto: tiempo, costo, volumen. La combinación de los cuales te da calidad.
No solo prioridades
La planificación del lanzamiento tiene en cuenta la capacidad del equipo de desarrollo. Algunos productos tienen más de uno de estos comandos. Por ejemplo, para crear un servicio de pedidos de taxis, al menos debe haber comandos backend, QA, Android, iOS.
Pero además de priorizar, también debemos estimar cuántas horas los desarrolladores pueden dedicar a trabajar en cada característica siguiente. Para ello, es necesario multiplicar el número de personas del equipo por el número de días asignados para su preparación. Comprender lo que se puede incluir en la capacidad disponible para la próxima versión (alcance) ayuda a evitar el desperdicio de recursos.
La capacidad de diferentes equipos para un ciclo de lanzamiento:
Si observa la tabla a continuación, queda claro que se necesitan muchos recursos para una aplicación móvil para iOS, no solo el equipo de desarrollo de iOS, sino también especialistas en backend y control de calidad. Por eso es lógico que la dirección tome la decisión de no incluir una aplicación móvil para iOS en el primer lanzamiento, ya que el equipo aún no tendrá tiempo para hacerlo, pero por otro lado, terminarán “Pedido de taxi en el momento adecuado”.
Por lo tanto, si vamos en el orden de prioridad de todas las características ordenadas, entonces la hoja de ruta para el desarrollo de la aplicación solicitando un taxi se verá así:
cada versión posterior incluirá las siguientes características prioritarias que se colocan en la capacidad del equipo de desarrollo.
Hoja de ruta: como filosofía de desarrollo de productos
Recuerde que Roadmap no es un compromiso, sino una predicción. Aconsejaría tratar la hoja de ruta como un plan actual. Es posible que en un mes venga un nuevo cliente y pida una nueva función. Y cuando la agreguemos a la lista de trabajos pendientes, su prioridad probablemente será más alta que cualquier cosa planificada previamente. Como regla general, a la hora de trabajar en un producto, es importante tener un Roadmap para cada momento, pero no debes dejarlo estático, porque hoy necesitas adaptarte a las condiciones cambiantes del mercado.
El trabajo propuesto con la hoja de ruta (priorizando características según reglas generales) requiere una cultura interna. Todas las partes interesadas deben seguir los mismos principios de puntuación, por lo que el primer paso es discutir la fórmula de cálculo y luego seguir esta regla. Por supuesto, todo se puede cambiar si se comprende cómo mejorar la priorización, pero luego será necesario volver a calcular las prioridades para todo el trabajo pendiente.
Para productos grandes, también es recomendable asignar una capacidad diferente de los equipos de desarrollo a cosas que no están directamente relacionadas con el desarrollo de funciones personalizadas. Por ejemplo, un líder del equipo de desarrollo puede decirle: "Necesitamos cambiar a una nueva versión de Python, de lo contrario tendremos más tiempo ( dinero) gastar en mantener el ecosistema existente en la versión anterior ”. Para resolver estos problemas, puede asignar, por ejemplo, el 25% de la capacidad del equipo para funciones relacionadas con la captación de nuevos clientes, el 45% para retención de clientes actuales, el 20% para deuda técnica y refactorización, y el 10% dejar como búfer para que haya espacio para funciones. que vinieron de repente o de forma generalizada para dar cuenta de actividades que no estaban directamente relacionadas con el desarrollo de productos (implementación de un nuevo sistema de compilación, implementación de CI \ CD, etc.).
Conclusión
Para planificar con éxito el desarrollo y ajustar la hoja de ruta, debe revisar periódicamente su trabajo pendiente y volver a calcular la puntuación de funciones para aquellas funciones que planea desarrollar y las desea en el alcance del lanzamiento. Pero si ya nos hemos decidido por el próximo lanzamiento, se hace necesario establecer interacción entre gestores y desarrolladores.
Para hacer esto, en la próxima publicación veremos el mecanismo para crear requisitos para una característica que debe presentarse al departamento de desarrollo. Esto es necesario para que se desarrolle la función, preferiblemente en la forma en la que desea verla. Hablaremos sobre por qué los requisitos deben ser claros, cómo deben formalizarse y qué prácticas existen para trabajar con requisitos para desarrolladores.
→ La grabación de video de todas las conferencias del curso está disponible en YouTube
Conferencia sobre la hoja de ruta y los requisitos para el desarrollo: