A segunda parte com meus erros, a primeira
aqui .
Deixe-me lembrá-lo de que sou o proprietário do produto em uma equipe composta apenas por desenvolvedores e estamos criando uma plataforma de TI para gerenciar redes afiliadas de postos de gasolina.
Erro quatro.
Fator de ônibus: o que a princípio parecia muitos erros, mas na verdade acabou sendo um grande prêmio para a equipe
Recrutar 8 pessoas que não podem se substituir, sem um testador e primeiro sem um analista? Parece que fiquei louco e decidi afundar o produto.
Na verdade , preciso fazer 6 grupos diferentes de serviços, para cada um deles já existe “a melhor prática”, que é rápida e facilmente implantada, o mercado de desenvolvedores experientes é grande.
O que essa
equipe significa para mim ? A capacidade de encontrar rapidamente uma equipe com as competências certas, implantar rapidamente o MVP e começar a validar hipóteses de negócios, além de ocupar esse nicho muito livre no mercado.
O que é isso
para a equipe ? No nível inicial, existem muitas competências diferentes que eles podem compartilhar entre si, a capacidade de cada recurso usar a solução mais rápida possível e, o mais importante, eles aprendem algo novo constantemente, e isso, você vê, é interessante até para os mais velhos. (Pelo menos minha equipe de desenvolvimento compartilha esses princípios).
Durante o teste de hipóteses de negócios, a equipe de desenvolvimento se reúne e, com o tempo, começa a testar hipóteses técnicas entre si; assim, nas disputas, surge a arquitetura de destino da plataforma que a EQUIPE criou, e não apenas um arquiteto. "Todo arquiteto" é uma pessoa, na minha opinião, inútil, caro e eles não existem :) Quando uma equipe tem a mesma responsabilidade, o produto se torna uma ideia comum, todos aplaudem, não quero mais mudar a responsabilidade. De maneira tão espinhosa, a equipe cresce, toma decisões, COMO tornar o produto ainda mais, as competências se expandem, a intercambiabilidade e a auto-organização aparecem. Ainda não passamos por esse caminho, mas mais cedo ou mais tarde passaremos. Obviamente, agora estamos expandindo a equipe para um testador dedicado, mas no início, a equipe é capaz de lidar com essa função.
Sim, é mais fácil pegar 6 desenvolvedores de Java e agora eles são imediatamente intercambiáveis, mas rapidamente do zero eles não produzirão um produto funcional e serão muito limitados por suas competências.
A propósito, é extremamente difícil ser o proprietário de um produto de TI sem experiência nessa área de TI, por exemplo, um desenvolvedor, analista de sistema ou consultor (qualquer pessoa, exceto os gerentes de projeto) e, mesmo se você tiver um guru de arquiteto, será o produto dele, não o seu. . Aqui você pode argumentar, mas a prática e as estatísticas são as seguintes.
Erro cinco.
É inconveniente para mim, para que outros não gostem
Nossa equipe sempre perguntava "Quem precisa disso?", "O cliente quer assim", "É definitivamente inconveniente porque eu não gosto" e assim por diante. No início, é claro, você pode pensar no cliente, oferecer algo a ele e, com base no feedback, preencher o backlog. O principal aqui é realizar um estudo qualitativo e ouvir dores, não soluções prontas, caso contrário, eles pedirão um "cavalo mais rápido" e não uma máquina que funcione perfeitamente.
É necessário mergulhar a equipe na dor do
cliente , ligar para os
clientes e a equipe para cuidar, dar contatos à equipe daqueles clientes a quem eles sempre podem pedir uma opinião ou verificar rapidamente a funcionalidade.
Comecei a dizer com mais frequência para mim mesmo: "Nunca tente o papel de um cliente se você não estiver no lugar dele e não deixe a equipe fazer isso". Por que discutir em vão se você pode perguntar à pessoa por quem está fazendo isso?
Erro seis.
Ninguém precisa de protótipos
Um grande erro para um RO iniciante não é fazer protótipos ou testar hipóteses. Eu gostaria de criar rapidamente o belo e imediatamente o produtivo.
Se a dor do cliente: ele não vê as estrelas à noite devido ao mau tempo, e você cria uma espaçonave para ele imediatamente, tentando exceder suas expectativas e fazer 100 vezes melhor do que ele poderia imaginar, então este é um erro claro. Ele tinha uma tarefa diferente, dor e desejos.
Você pode passar três dias ou uma semana, desenhar à mão a aparência do produto e também mostrá-lo ao cliente. Peça a ele para descobrir como ele o usará e não se esqueça de fazê-lo sempre que as idéias forem transferidas para o backlog do produto.
Bem, quando você criou um recurso brilhante, criou um protótipo, o usuário bate palmas e realmente quer - não, você ainda não pode levá-lo ao trabalho :) Não se esqueça das métricas dos recursos, tanto de mercado quanto de negócios. As métricas são geralmente uma história especial com erros - mais sobre elas mais tarde e com mais detalhes na próxima edição. Enquanto o anúncio ...
Erro sete.
Métrica de onipotência
Deixe-me lembrá-lo de que nossa equipe faz parte de uma startup muito grande em uma grande empresa. Lidar com métricas de produtos com as partes interessadas foi difícil. Colocar uma métrica comercial em uma solução de TI que ainda está no estágio de design é uma má ideia. Mas os investidores precisam mostrar seu trabalho, mesmo que ainda não haja incrementos para o usuário.
Quaisquer métricas de dinheiro desmotivam você e a equipe, mas é exatamente nelas que as partes interessadas vão querer assistir. E agora você já está na pista escorregadia do PI, esforçando-se com confiança, não pode influenciar essa métrica em um sentido positivo. E em todos os sentidos, a partir de agora, o produto parece ineficiente e não rentável.
Se você não cometeu o erro número 6, terá todas as chances de convencer as partes interessadas, usar e mostrar o protótipo aos usuários, coletar feedback e desligar as métricas de atração. Torne o desenvolvimento o mais transparente possível, mostre o que você está fazendo neste protótipo, qual botão ou formulário funcionará, o que ele permitirá que você faça e como usar uma agenda bonita que será exibida em breve. O principal aqui não é
prometer demais e manter todas as suas
promessas.Resumo das conclusões:
- Primeira tentativa, se a sua - vá para a escola de RO
- Você não é imortal, não agarra tudo de uma só vez, recrute uma equipe na qual esteja pronto para confiar
- Você definitivamente precisa de um scrum master. Em tempo integral.
- Dê uma chance. A equipe de scrum se tornará intercambiável mais cedo ou mais tarde, e as hipóteses de negócios não caem no chão, é melhor tomar uma vaga no mercado com seu MVP, embora com os riscos do fator de baixo no início, do que não ter tempo para isso.
- Comunique-se mais com o cliente, lembre-se da dor dele, tente resolvê-la.
- Questione todas as suas idéias, crie protótipos e teste hipóteses, observe a reação do cliente, estamos aqui para nos reunir :)
- Escolha você mesmo as métricas, pois elas devem ajudá-lo a criar um produto de qualidade e iterativamente bom. Lembre-se de que existem muitos produtos que permaneceram no "vale da morte" devido à falta de qualidade.