
Índice do curso
1. Papel do gerente de produto e estrutura
2. Segmentação de mercado e análise competitiva
3. Personas do usuário
4. Teste de hipóteses
5. Posicionamento do
produto 6. Roteiro do produto <- Você está aqui
7. Elaboração de requisitos para o desenvolvimento
8. Modelo de negócios e negócios- Plano
9. Plano Financeiro e Preços
- Continuação
Ter um roteiro é muito importante para gerenciar o desenvolvimento de produtos. Porém, para traçar corretamente um roteiro, é necessário abordar esta questão de forma sistemática. É muito importante não confundir um roteiro com uma visão, embora ter uma visão seja necessário para construir um roteiro corretamente.

Lema das Nações Unidas: “Pense globalmente, aja localmente . " Curiosamente, também funciona ao criar um roteiro para um bom produto de software. Para fazer isso, você precisa ter uma visão global para que suas aspirações não acabem aqui e agora. Dentro da estrutura da visão, os objetivos são definidos - eles também são bastante globais, e é a esses objetivos que o roteiro deve conduzir. Quando você se move de acordo com o mapa preparado, os lançamentos se tornam marcos e estágios desse movimento - a incorporação de etapas específicas para o desenvolvimento do produto.
Que horizonte você deve balançar com o planejamento? Pode ser diferente, mas para começar é melhor limitar-se a 6 meses. Se você sabe exatamente para onde seu produto será movido, pode levar 3 ou 5 anos. Não há limite. Por exemplo, em seu discurso recenteO fundador da Amazon, Jeff Bezos, anunciou o programa espacial Blue Origin com um horizonte de planejamento de 50-100 anos. Ou seja, uma pessoa cria uma empresa que funcionará na maior parte do tempo depois de sua vida. Como isso é possível?
É que, neste caso, estamos falando de uma visão global - a Blue Origin deve oferecer a possibilidade de voos espaciais intensos. A Amazon conta com uma infraestrutura de correio e correio já existente, disse Bezos. Se eles não existissem, a Amazon não teria sido capaz de trabalhar ou se tornar tão bem-sucedida. Hoje, a Blue Origin planeja criar a infraestrutura para futuras viagens espaciais - foguetes, espaçoportos, satélites, estações orbitais e assim por diante. Os objetivos globais da Blue Origin são construir uma nave espacial até 2025.
Compreender seus objetivos globais ajuda a traçar um roteiro, onde mostramos etapas concretas, construindo um plano realista para atingir os objetivos definidos em um futuro próximo. E a Blue Origin, como uma empresa com planos ambiciosos, está tentando cumprir sua missão - organizar um serviço mundial para o movimento acessível e conveniente de pessoas e mercadorias.
Do céu à terra ...
Considere um exemplo mais realista. Se uma empresa de construção se dedica à construção de alta qualidade, o conceito de seu trabalho pode ser o seguinte:
● Visão - construir a melhor área residencial no norte de Moscou (SAO).
● Objetivos - 5.000 apartamentos, arquitetura moderna, conforto de classe, layouts convenientes, um pátio sem carros.
● Roteiro - filas de desenvolvimento e paisagismo.
● Liberação - edifícios com acabamento em concreto, estradas, parques (a divisão é possível na fase de conclusão).
● Recurso - um componente do lançamento. Por exemplo, um playground, árvores plantadas, estacionamento coberto, uma rampa.
Como criar um roteiro de produto de software?
O roteiro do software inclui versões, cada uma das quais deve conter determinados recursos. É muito importante agendar um roteiro por datas, levando em consideração as capacidades e recursos disponíveis (mais sobre isso mais tarde). Por exemplo, é assim que se parece um roteiro para um dos aplicativos sociais.

Lembre-se de que o roteiro deve ser planejado para todos os departamentos de uma vez. Se a empresa for grande e os gerentes de vendas tiverem seu próprio roteiro, você precisará vinculá-lo ao roteiro do departamento de desenvolvimento. Do contrário, quando chegar a hora, por exemplo, de promover um produto no mercado asiático, pode acontecer que você não tenha uma localização pronta ... e mesmo suporte para o idioma chinês.

As solicitações do que deveria estar em um produto vêm de diversos setores. Já falamos sobre isso em um dos posts anteriores .... Eles precisam ser cuidadosamente organizados e planejados. É importante entender que não será possível preparar e lançar todos os recursos na versão 1.0, pois na realidade nunca há recursos suficientes para implementar todas as ideias (se não for o caso, você tem poucas ideias e precisa pensar mais).
Com a abordagem certa, o Roadmap é uma oportunidade de dividir o processo de desenvolvimento do produto em estágios e implementar a funcionalidade com prioridade e importância decrescentes nas iterações.
Vamos dar uma olhada em outra estrutura de desenvolvimento de produto de software (Software Product Management Framework) que controla o desenvolvimento de software:

A matriz de maturidade de uma empresa que vive sob uma determinada estrutura é determinada pela tabela a seguir. E com a adesão formal ao processo de preparação do roadmap, a empresa chega imediatamente ao segundo nível de maturidade:

Em geral, este framework é um ramo separado para qualquer curso de desenvolvimento de produto. Não vamos insistir nisso agora. Se alguém estiver interessado em ler uma postagem adicional sobre este tópico, por favor, deixe um comentário sobre esta postagem.
Aqui para nós mesmos, aceitaremos apenas que, ao observar alguns procedimentos formais no desenvolvimento de software, ao construir esses processos, a própria empresa aprimore a cultura de entrega de software melhor. O roadmap faz parte dessa cultura.
Como coletar e processar os requisitos do produto?
Quando recebemos requisitos de diferentes lados, eles precisam ser inseridos em algum tipo de sistema. Por exemplo, o Acronis usa Jira, que é uma ferramenta bastante poderosa, mas para inicializações você pode usar ferramentas mais simples, incluindo as gratuitas, por exemplo, Redmine ou Asana.
O principal é que todas as ideias sejam registradas, pois não existem maus pensamentos. Se a ideia ainda não merece implementação, sua prioridade permanecerá baixa. Portanto, é muito importante inserir todas as frases no sistema - mesmo sem uma descrição detalhada de "como deve funcionar". Somente com essa abordagem você pode planejar a implementação dos recursos exigidos - ou seja, criar um Roadmap real.

Todas as ideias chegam ao chamado "backlog de entrada", podem ser formalizadas ou "brutas", sem avaliações e entendimento de quem precisa dessas funcionalidades. Depois de trabalhar as solicitações e adicionar detalhes, alguns deles podem ir para a próxima versão. O restante vai para o Backlog e posso ficar lá por muito tempo.
Épico
A metodologia Agile ou Scrum implica em um termo como "Épico". Para explicar sua essência da forma mais simples possível, estamos falando sobre algum grande recurso, cuja implementação requer o envolvimento de todos os participantes - desenvolvedores, testadores, designers de interface, redatores técnicos e assim por diante.
Normalmente, ao criar uma epopeia, sua importância do ponto de vista do negócio é avaliada, os custos de mão de obra são calculados e uma decisão é tomada se deve ser incluído no release atual ou enviado para o backlog.

Para epopeias que já foram avaliadas, você pode atribuir uma prioridade no sistema. Por exemplo, no mesmo Jira, você pode definir "alto", "médio" ou "baixo". Mas, por exemplo, em nossa lista de pendências Acronis existem centenas e até milhares de recursos. Nesse caso, prioridades simples são indispensáveis.
Calculando a pontuação do recurso
Uma metodologia de pontuação mais complexa é chamada de Feature Score. A ideia é reunir todos os fatores que influenciam o desenvolvimento em uma única classificação. Em seguida, com base na classificação normalizada, tome decisões sobre como incluir o recurso na versão ou abandonar o desenvolvimento no momento. Assim, métricas positivas adicionam pontos a uma característica, enquanto as negativas agem com uma proporção inversa (mais valor - menos pontos). Algumas das métricas positivas incluem:
1. Urgência.
2. O tamanho do cliente que precisa.
3. Aumento da participação de mercado devido ao surgimento de novos clientes.
4. Lucro ou perda potencial com a saída de clientes atuais.
5. Realizações estratégicas (metas que nos levam à incorporação da Visão).
Métricas negativas:
1. A quantidade de custos de mão de obra.
2. Riscos potenciais.
A pontuação do recurso deve ser um número. Esta não é uma avaliação qualitativa, mas sim uma espécie de avaliação, e o método para seu cálculo deve ser unificado e aprovado no âmbito do desenvolvimento de um produto específico.
Os pontos são determinados com base em valores normalizados, objetivos de mercado da empresa e outros parâmetros. O primeiro parâmetro que é levado em consideração na Pontuação do recurso é o fator do cliente. O chamado Fator do Cliente é definido como o produto da urgência e do tamanho do cliente. Você pode ver um exemplo de cálculo na imagem abaixo.

Penetração de mercadoé definido como a probabilidade de atrair novos clientes e depende de seus planos para expandir sua base de clientes. Por exemplo, para recursos que não atrairão novos clientes, esse parâmetro pode ser igual a 0, e para aqueles que podem trazer, digamos, 500 clientes, a pontuação será 20.
A próxima questão é conformidade com a estratégia. Para avaliar a Estratégia, você precisa verificar se o recurso o ajuda a seguir as direções de desenvolvimento estratégico. E quanto mais direções ele cobrir, maior será a pontuação.

A receita é o lucro potencial que a implementação de um recurso pode gerar. A estimativa desse parâmetro depende do tamanho da empresa, das características do produto e da receita que você espera receber. A tabela mostra um exemplo de pontuação para este indicador.

Mas agora vamos falar sobre os fatores opostos, que dão quanto menos pontos a uma característica, mais eles se manifestam. Por exemplo, os custos de desenvolvimento também podem ser fixados para sua empresa no nível de certas estimativas, dependendo de quanto você está disposto a gastar no desenvolvimento de certos recursos.

Os riscos são o segundo aspecto. Quanto menor for a sua confiança nas avaliações, maiores serão os riscos, o que significa que menor será o valor do critério na fórmula de Pontuação do Recurso.

Depois de levar em consideração todos os fatores mencionados, a fórmula de pontuação de recurso pode ter a seguinte aparência:

É bom se as pontuações forem objetivas, com base em fatores específicos. Mas se você está apenas entrando no mercado, ainda faça uma Pontuação de Característica. Melhor ser subjetivo do que nada.
Roteiro no exemplo do aplicativo Taxi
Em um dos posts anteriores , já falamos sobre a criação de um aplicativo para chamar um táxi. Suponha que precisemos classificar os seguintes recursos para este produto:

Uma tabela com prioridades pode ter a seguinte aparência:

Considere o recurso "Solicitar no momento certo". Somando todos os parâmetros, obtemos 56. O que significa esse número? Nada! Esta é uma classificação relativa e precisamos calcular todos os 9 recursos, aderindo aos mesmos critérios e classificações. O resultado é uma lista de prioridades. Em nosso aplicativo, obviamente precisamos fazer um aplicativo móvel no Android. O segundo movimento é a tarifa “infantil”.
Uma abordagem sistemática permite não fazer o que não é tão importante para o negócio e não escolher um “recurso aleatório” para implementação. O retorno do trabalho gradual e em fases será maior. E isso é muito importante, pois sempre existem fatores condicionantes para o desenvolvimento de cada projeto: tempo, custo, volume. A combinação disso oferece qualidade.

Não apenas prioridades
O planejamento da liberação leva em consideração a capacidade da equipe de desenvolvimento. Alguns produtos possuem mais de um desses comandos. Por exemplo, para criar um serviço de pedido de táxi, pelo menos deve haver back-end, QA, Android, comandos iOS.
Mas, além de priorizar, também devemos estimar quantas horas os desenvolvedores podem alocar para trabalhar em cada recurso seguinte. Para fazer isso, você precisa multiplicar o número de pessoas na equipe pelo número de dias alocados para sua preparação. Entender o que pode haver na capacidade disponível para a próxima versão (escopo) ajuda a evitar o desperdício de recursos.
A capacidade de diferentes equipes para um ciclo de lançamento:

Se você olhar a tabela abaixo, ficará claro que muitos recursos são necessários para um aplicativo móvel para iOS, não apenas a equipe de desenvolvimento do iOS, mas também especialistas em back-end e QA. Por isso, é lógico que a administração tome a decisão de não incluir um aplicativo móvel para iOS no primeiro lançamento, já que a equipe não terá tempo para fazê-lo de qualquer maneira, mas por outro lado, terminará o “Pedido de táxi na hora certa”.

Assim, se formos na ordem de prioridade de todos os recursos classificados, o roteiro para o desenvolvimento do aplicativo pedindo um táxi será parecido com este:

Cada versão subsequente incluirá os próximos recursos prioritários que são colocados na capacidade da equipe de desenvolvimento.
Roteiro - como uma filosofia de desenvolvimento de produto
Lembre-se de que o Roadmap não é um compromisso, mas sim uma previsão. Aconselho tratar o roteiro como um plano atual. É possível que em um mês um novo cliente chegue e peça um novo recurso. E quando a adicionarmos ao backlog, sua prioridade provavelmente será maior do que qualquer coisa planejada anteriormente. Como regra geral, ao trabalhar em um produto, é importante ter um Roteiro para cada momento do tempo, mas você não deve torná-lo estático, porque hoje você precisa se adaptar às mudanças nas condições do mercado.
O trabalho proposto com o roadmap (priorizando recursos de acordo com regras gerais) requer uma cultura interna. Todas as partes interessadas devem seguir os mesmos princípios de pontuação, portanto, o primeiro passo é discutir a fórmula de cálculo e depois seguir esta regra. Claro, tudo pode ser mudado se houver um entendimento de como melhorar a priorização, mas então será necessário recalcular as prioridades para todo o backlog.
Para produtos grandes, também é aconselhável alocar uma capacidade diferente das equipes de desenvolvimento para coisas que não estão diretamente relacionadas ao desenvolvimento de recursos personalizados. Por exemplo, um líder da equipe de desenvolvimento pode dizer a você: “Precisamos mudar para uma nova versão do Python, caso contrário, teremos mais tempo ( dinheiro) gastar na manutenção do ecossistema existente na versão antiga ”. Para resolver esses problemas, você pode alocar, por exemplo, 25% da capacidade da equipe para recursos relacionados à conquista de novos clientes, 45% para retenção de clientes atuais, 20% para débito técnico e refatoração e 10% para deixar como buffer para que haja espaço para recursos. que veio repentinamente ou sobrecarregou as atividades não diretamente relacionadas ao desenvolvimento do produto (implantação de um novo sistema de compilação, implementação de CI \ CD e assim por diante).

Conclusão
Para planejar o desenvolvimento e ajustar o roadmap com sucesso, você precisa revisar periodicamente sua lista de pendências e recalcular a pontuação dos recursos que planeja desenvolver e deseja que eles estejam no escopo da liberação. Mas se já decidimos sobre o próximo lançamento, torna-se necessário estabelecer uma interação entre gestores e desenvolvedores.
Para fazer isso, na próxima postagem, veremos o mecanismo de criação de requisitos para um recurso que precisa ser apresentado ao departamento de desenvolvimento. Isso é necessário para que o recurso seja desenvolvido, de preferência na forma em que você deseja vê-lo. Falaremos sobre por que os requisitos devem ser claros, como devem ser formalizados e quais práticas existem para trabalhar com requisitos para desenvolvedores.
→ A gravação em vídeo de todas as palestras do curso está disponível no YouTube
Palestra sobre o roteiro e requisitos para o desenvolvimento: