Ah, o Discovery… faço Discovery nas empresas desde 2008! Já perdi a conta de quantos eu já fiz, de diferentes formas para projetos, produtos e negócios…
Discovery, como o próprio nome já diz é uma “descoberta”, uma “revelação” e usamos esse nome para definir um momento onde paramos um time (com os envolvidos), para apresentarmos um objetivo, que tem muito valor para área de negócio e para a empresa. Também apresentamos os impactos em toda a cadeia de desenvolvimento, desde do “start” até a entrega, ao usuário final.
Esse objetivo que falamos acima pode ser; um novo produto, um novo serviço, uma melhoria ou um novo negócio. Todos esses objetivos nascem de uma necessidade, que pode vir do usuário/cliente, do mercado ou algo que o próprio time enxergou como um valor de negócio a ser desenvolvido e entregue. Gosto de exaltar que, muitas dessas “necessidades” que surgem podem virar grandes oportunidades de negócio para empresa, abrindo novos caminhos para consumo, vendas e até mesmo mudança de comportamento de uma sociedade (como touch screen, 1º Iphone lançado pelo Apple em 2007).
Mas para esse objetivo ser desenvolvido com sucesso precisamos que todos os envolvidos no projeto (áreas de negócio e suporte) saibam o que será necessário fazer. E mais do que saber fazer, precisamos saber quais os impactos teremos em sistemas, produtos, outras áreas da empresa,… E também, se não fizermos, o que deixamos de ganhar! Por esse motivo, para realizarmos um bom Discovery precisamos de TEMPO e de PROFISSIONAIS (time de desenvolvimento, áreas impactadas, área de negócio que representa o usuário/cliente), para conversarmos sobre quais funcionalidades serão desenvolvidas, como serão desenvolvidas e quais os problemas podemos encontrar durante a evolução do trabalho.
Durante o período de Discovery, realizamos algumas atividades que nos ajudam a trazer mais informações sobre o que precisa ser feito e qual caminho devemos seguir :
- Apresentação da necessidade (objetivo do produto, melhoria, inovação) ;
- Pesquisas e levantamentos feitos com usuário/cliente (dados, feedbacks, problemas, sucesso);
- Demonstração de um proposta de solução, baseada em atender a necessidade;
- Prototipação da necessidade (visualização através de fluxos, telas, desenhos);
- Validação do que foi levantado, discutido e definido para o desenvolvimento e entrega com todos os envolvidos;
- Ajustes e alinhamentos caso seja necessário.
Importante lembrar, que esses passos não são engessados e sequenciais. O momento do Discovery é justamente usado para debatermos sobre o que precisamos. Portanto, eu posso levar um objetivo pensando que é super fácil de ser feito e quando expor para os demais, descobrir que é mais complexo do que imaginava, ou que, envolve outras áreas da empresa que não estão presentes. Dessa forma, precisaremos retornar passos anteriores para trazer mais comprometimento e confiança. Logo, podemos retornar o passo toda vez que dúvidas aparecem!
Bom, nesse período de Discovery podemos utilizar várias ferramentas para clarear o desenvolvimento como: Mapa de Empatia, Product Vision, Brainstorming, Learning Canvas, PDCA, É/ Não é/ Faz/ Não faz, Identificação e descrição das Personas (usuários), Votação e Priorização das funcionalidades com mais valor e por ai vai…
Caso queira saber mais sobre técnicas e ferramentas a serem usadas num Discovery, indico o link do
Lean Inception, do meu amigo Paulo Caroli! É um guia completo! Super recomendo 🙂
As funcionalidades propostas devem ser avaliadas como: factíveis, usáveis, viáveis. Avaliamos dessa forma para selecionar as que realmente tem mais valor, ou seja, as que trazem mais benefícios, ganhos e oportunidades para os usuários/clientes ( trabalhamos com conceito de MVP – Minimum Viable Product ou Mínimo do Produto Viável ) . Durante esse período de discussão, pode acontecer de entrar algo que não tenha valor para o usuário/cliente, mas que tenha um impacto enorme para o desenvolvimento, se tornando necessário fazer. Terá que ser feito!
Lembro ainda que, num Discovery podemos ter épicos “camuflados” de funcionalidades ( épicos são várias atividades a serem desenvolvidas pelo time, que ultrapassam o tempo de entrega de uma iteração ou sprint definidos ). Nesse caso, precisamos “fatiar” o desenvolvimento para caber no período de entrega da iteração. Depois de selecionar o que tem mais valor de negócio, avaliamos o que será desenvolvido a curto, médio e longo prazo. Esse momento é complexo porque nos deparamos com várias variantes que podem afetar a entrega no prazo; se temos infra, projetos concorrentes, projetos paralelos, profissionais qualificados, profissionais compartilhados, férias dos profissionais, saída ou entrada de profissionais, etc… Resumindo, toda mudança que possa ocorrer precisa ser prevista nesse momento. Dessa forma teremos um planejamento mais assertivo e mesmo assim podendo sofrer alterações ao longo do trabalho.
Quanto a duração de um Discovery pode levar de 2 dias até 1 semana, pode ter de 5 a 30 pessoas. O que importa é sair com uma proposta de Roadmap ( representação visual contendo as entregas que serão realizadas pelos times de desenvolvimento num determinado tempo acordado. Também traz os impactos e interseções com entregas de outras áreas), para gerar comprometimento e consenso com todos que participaram desse início do processo.
Após ter realizado o Discovery faça uma comunicação e distribua para os envolvidos falando sobre o processo que foi realizado com as áreas, o que ficou definido e os próximos passos, para que não haja ruídos ou mal entendidos.
Bom, terminou o Discovery! Qual a próxima etapa? Tem algum caminho a seguir, Anne?
A resposta é sim! Temos mais tarefas a serem realizadas e o Discovery é apenas o primeiro passo!
Depois do Discovery temos o Release Planning. E depois o Refinamento para finalmente chegarmos ao Planning ( Sprint Planning, PI Planning, Replenishment Meeting, etc). Mas esse já é um outro artigo 😀
Espero ter ajudado 🙂
Até mais!