Oi Meu nome é Anatoly Savchenko, sou desenvolvedor e, simultaneamente, um scrum master na equipe do serviço AutoTech . Como você deve ter adivinhado, trabalhamos no Scrum. A cada duas semanas, realizamos uma revisão de sprint - uma reunião em que a equipe e as partes interessadas discutem o que foi feito. Com base nessas informações, a equipe pode tirar conclusões sobre se o desenvolvimento está caminhando na direção certa, quais melhorias ainda são necessárias etc. Recentemente, adquirimos uma nova e valiosa experiência ao realizar esta importante reunião. Eu quero falar sobre ele.

Ferramentas de feedback

Obviamente, uma revisão de sprint não é o único canal de feedback: temos um laboratório de UX, processamos análises em lojas de aplicativos móveis, suportamos chamadas, análises em vários recursos da Internet, realizamos pesquisas com usuários no site e muito mais.
Isso é para usuários particulares.

Além deles, trabalhamos com parceiros de negócios aos quais fornecemos funcionalidades e ferramentas de trabalho adicionais. Temos uma interação mais próxima com eles. Nossos gerentes estão sempre em contato com eles (correio, telefone), há bate-papos em mensagens instantâneas, que são membros da equipe de desenvolvimento. Assim, nos aproximamos de nossos usuários de negócios: os conhecemos melhor, entendemos suas necessidades, ouvimos e sentimos sua dor ou alegria.

E esses são todos os canais de comunicação maravilhosos e necessários. Mas eles dão informações após o lançamento. Além disso, nesse caso, a equipe de desenvolvimento ainda está muito longe dos usuários. É por isso que as revisões do sprint podem ser mais benéficas para uma equipe, produto e, finalmente, para os usuários.

Revisão da Sprint - como era antes

Nossas reuniões geralmente eram realizadas em um bom nível: recebemos comentários rápidos e de alta qualidade de nossos stakeholders (ou seja, clientes internos - gerentes) e de outros colegas da Avito. Uma situação bastante câmara foi criada, mas em algum momento começamos a perder a plenitude do feedback. Queríamos mudar alguma coisa. E nosso treinador ágil, Levon Goncharov, da AgileVerse, nos levou à idéia de convidar usuários externos - nossos parceiros de negócios - diretamente para a reunião.

Levon Goncharov, co-fundador da AgileVerse: “Conheci os caras quando eles decidiram melhorar seus processos. Eles entenderam que algo estava errado e procuravam uma resposta. Durante o diagnóstico, cada membro da equipe de alguma forma falou da necessidade de entender "como o usuário vive". Isso influenciou alguém do ponto de vista da motivação, alguém precisava entender como desenvolver o projeto arquitetonicamente. Este, em princípio, é um problema bastante comum das equipes de scrum - transformando uma revisão de sprint em uma reunião, na qual elas contam o que foi feito e pensam não como criadores, mas como artistas. Para evitar isso, você precisa pensar sobre isso.

No. 1 Ao desenvolver um produto, você pensa mais em recursos ou problemas do usuário?
№2 Você sabe como o usuário vive e por que ele deveria usar o seu produto?
Não. 3 Você costuma se comunicar com quem usa seu produto?
Aconselhei a equipe a discutir essas questões e alterar o formato da revisão do sprint.

O caso de conversar com os usuários apareceu rapidamente. No final do sprint, planejamos lançar uma nova ferramenta para parceiros da linha de montagem que ninguém havia visto antes. E decidimos "quente" para coletar feedback sobre um produto que ainda não foi lançado.

Preparação

Para começar, Levon e meus colegas reuniram expectativas em uma nova reunião, após a qual planejamos a agenda e preparamos todo o material necessário.
Posso dizer que apenas sobre a preparação, pode-se escrever um post inteiro. Isso nos permitiu criar uma imagem integral da reunião e levar absolutamente tudo em consideração (é claro, não levamos em conta tudo, porque é impossível, mas levamos isso em conta também).

Primeiro, pintamos a meta e a imagem do resultado em um flipchart. Registramos pontos para o plano geral da reunião. Detalhando o preenchimento de cada etapa.
Registramos os tempos de todas as etapas (e os reescrevemos várias vezes). Determinamos o material necessário para cada etapa e anotamos o que você deve se lembrar de levar para a reunião.

Em suma, é isso que conseguimos.

Finalidade

1. Fale o foco da equipe no trimestre
2. Entenda como a conta de usuário atualizada (LKP) atende às necessidades
3. Mostre teasers e formule um plano para 1-2 sprints

Planejar

1. Abertura (5 minutos)
   a. Agenda
   b. Nós dizemos como dar feedback
   c. Conhecendo a equipe
2. Parte comum (15 minutos)
   a. O que você fez?
   b. Planos futuros (foco no trimestre)
   c. Perguntas e Respostas
3. Demonstração (15 minutos)
   a. Discutir
   b. Teasers
4. Diálogo LCP (10 minutos)
   a. O que você achou? (o que é assim, o que não é)
   b. Quando terminamos (sprint aproximado)
   c. O que substituir? (falando sobre a vida do usuário)
5. Reunindo feedback sobre o formato da revisão (5 minutos)

Imagem do resultado

1. Feedback trimestral
2. Lista de melhorias na pintura
3. Discuta as dores mais graves do usuário, escreva o resto
4. Discutir um entendimento comum de teasers, planos para 1-2 sprints
5. Feedback sobre o formato da revisão dos participantes

Levon Goncharov, co-fundador da AgileVerse: “Quando preenchemos uma agenda de reuniões de exemplo , escrevemos tudo o que pode acontecer e de que maneira podemos gerenciá-la. Assumimos que os usuários começariam a falar sobre dores completamente comuns e incorporamos isso ao design da revisão do sprint. Mas, no processo de preparação, ficou claro que não havia espaço suficiente para isso. Portanto, obtivemos informações úteis antes da reunião que não poderemos abordar tópicos comuns. "

Como foi

A idéia principal era oferecer aos usuários uma experiência ao vivo de contato com o produto e obter o máximo de feedback. A seguir, apresentamos o seguinte: colocamos cada hóspede atrás de um laptop com um produto, ao lado do qual sempre havia dois membros da equipe. O papel de um é falar sobre o produto e responder a perguntas, e o segundo é registrar o máximo possível tudo o que acontece e, em seguida, processá-lo em conjunto com o proprietário do produto.

Bem, resultou um pouco mais de dois membros da equipe para cada convidado

A discussão acabou saturada e até estendemos o tempo para a exibição do produto. Como resultado, não apenas recebemos muitos comentários úteis, mas também aprendemos como o trabalho do nosso parceiro foi construído por dentro. Isso nos ajudará a planejar mais trabalho no produto.

Parecia a primeira versão do produto

Queríamos colocar o máximo de informações úteis em uma página, mas para os usuários a interface acabou sobrecarregada. Além disso, algumas informações eram simplesmente incompreensíveis.
Registramos os comentários e desejos de nossos convidados, notamos o mais importante e a prioridade e discutimos imediatamente com os parceiros o que e quando vamos implementá-lo.
O feedback nos ajudou a repensar como podemos apresentar informações de forma conveniente e clara ao usuário. No momento da redação deste artigo, as edições de maior prioridade já haviam sido feitas, o que transformou significativamente a versão original.

Versão do produto após as edições

Graças ao feedback inicial, fomos capazes de evitar uma situação em que demos aos nossos usuários um produto bruto que precisava ser editado em qualquer lugar.

Como equipe, adquirimos uma experiência muito valiosa. É o que dizem meus colegas.

Vadim Ivanov, CEO da Autoteks: “Considero esse tipo de coleta de feedback uma prática muito útil e necessária, que, de uma maneira boa, teve que ser implementada muito antes: uma coisa é assistir / ouvir as críticas de velocidade na atmosfera acolhedora dos colegas de espírito positivo; outra é ver imediatamente. uma resposta animada do usuário ao trabalho realizado. A opinião dos usuários corporativos é duplamente útil, pois eles costumam conhecer com mais precisão suas necessidades e problemas. Mesmo a primeira tentativa acabou sendo bem-sucedida, toda a equipe estava muito entusiasmada e envolvida no processo, conseguiu coletar comentários valiosos que eles imediatamente levaram ao trabalho antes do primeiro lançamento da nova funcionalidade e, como resultado, tornaram um produto muito mais preparado para os parceiros. E custos trabalhistas extras para a preparação do evento mais do que valeram a pena. Eu recomendo a todos que implementem esses métodos em casa e não tenham medo de experimentar. ”

Mansur Ahmadi, QA Autotech: “Na cabeça do engenheiro, a imagem do usuário final e do seu UX frequentemente diverge da imagem real do mundo, o que, por sua vez, pode levar a soluções não mais adequadas. Na última reunião, isso ficou bem claro quando nosso convidado descreveu sua visão do produto. Essa visão, que lhe daria mais felicidade. Essa visão em que devemos nos concentrar. Na minha opinião, são precisamente essas reuniões que ajudam a chegar até ele mais rapidamente. ”

Andrey Tumkin, proprietário do produto Autoteks: “A primeira coisa que pode surgir antes de convidar usuários reais para uma demonstração é por quê? Nos estágios iniciais, revelamos suas dores e, após o lançamento, coletamos feedback e fazemos correções. Mas não é tão simples.
Em primeiro lugar, você perderá tempo e dinheiro, em vez de resolver imediatamente os problemas do usuário. Em segundo lugar, mesmo o CusDev realizado antes do desenvolvimento não será capaz de identificar todos os problemas que serão revelados em um produto real. Em terceiro lugar, nenhum outro processo envolverá essa equipe no produto ".

Conclusão

O encontro com os usuários não é apenas uma ferramenta para melhorar e obter feedback, é uma construção real de relacionamentos com aqueles para quem você está produzindo um produto e conscientização sobre a importância desse trabalho.
Nossa equipe ficou muito inspirada pela experiência adquirida, por isso planejamos introduzir essa prática regularmente - uma vez por mês ou dois. Desejo que você realize uma reunião semelhante e veja o que vem dela. Boa sorte