[#LeanInception]Quando faço uma Lean Inception?
Pode parecer trivial quando falamos de inception e o momento de aplicar em um meio ágil — vamos fazer a inception no início para termos uma visão do produto mínimo viável e traçar um roadmap. Mas na prática não tem sido tão simples assim. No dia-a-dia nos deparamos com dilemas como: o meu produto precisa de uma inception? Já estou preparado para uma inception? Quando faço outra inception? E assim por diante.
Estas respostas envolvem mais que uma dimensão. Qual é o momento da empresa? Qual é o momento do produto? Qual o tipo do produto? Entre outras questões.
Neste caso, quando falo de inception, tenho como modelo a Lean Inception do Paulo Caroli e mantido pela caroli.org. Aqui temos uma separação clara entre o processo de ideação com o levantamento do problema e como abordar através de análise de conhecimento e proposta de soluções da inception, onde já temos a hipótese clara e nosso objetivo é definir o Mínimo Produto Viável (MVP).
Partindo do pressuposto que todos os modelos estão errados, ao mesmo tempo que alguns são úteis, a proposta deste texto é apresentar meu entendimento sobre o assunto e fazer a relação entre a Lean Inception e dois modelos que tem chamado minha atenção por ajudar a construir um modelo mental que tem muita relação com o Business Agility e a capacidade das empresas de adaptarem-se ao mercado e mudar de direção.
TI BIMODAL
Vamos pegar a questão de como a empresa é estruturada, como ela trata produtos que são novos e ou buscam novos mercados e produtos que garantem seu dia-a-dia. Uma abordagem para esta situação é o modelo de TI BIMODAL proposto pelo Gartner. O modelo da TI BIMODAL organiza a empresa em Mode 1 e Mode 2 com o intuito de ampliar as capacidades em duas novas abordagens para atender aos requisitos de negócios concorrentes, sendo que o Mode 1 atende a necessidade de fornecer um desempenho estável e confiável para lidar com o funcionamento diário dos negócios da empresa, enquanto o Mode 2 atende a necessidade de flexibilidade e capacidade de resposta para fornecer resultados digitalmente inovadores que impulsionem novos resultados de negócios. Este modelo não trata somente de uma capacidade de TI, inclusive pode não ter envolvimento de software por um longo período enquanto opções são levantadas. Demandas que se enquadram no Mode 2 são propicias a terem uma inception para definirmos qual a menor quantidade de funcionalidades que precisamos implementar no nosso produto para testá-lo com nosso cliente e obter um feedback o mais rápido possível. Já no Mode 1, boa parte pode não precisar de uma inception pois são aplicações que em boa parte não buscam inovação ou novos mercados. O Gartner utiliza o framework Pace Layering em conjunto com a TI-BIMODAL.
Categorias do Pace Layering
Sistemas de registro (SoR), sujeitos a uma baixa taxa de mudança e projetados para estabilidade e previsibilidade;
Sistemas de diferenciação (SoD), que são investimentos de longo prazo de movimentação rápida, mas totalmente controlados, em que o objetivo é entendido, mas o caminho pode não ser;
Sistemas de inovação (SoI), que são experimentos ou outros esforços efêmeros, rigidamente controlados em termos de tempo e orçamento do calendário para ver se uma ideia tem valor. Se o experimento falhar, ele será morto; se for bem-sucedido e a refatoração for necessária
Da para perceber que os SoD podem também ser suscetíveis a utilizar as capacidades do Mode 2 quando falarmos de melhorias incrementais. Porem os SoR são sistemas que você tem um grande controle sobre os requisitos iniciais e o resultado esperado e pode não fazer muito sentido aplicar uma inception.
Por outro lado, os sistemas da categoria SoI tendem a precisar de uma etapa de experimentação e levantamento de opções e protótipos utilizando Design Thinking antes de estarem preparados para uma inception.
Os três horizontes do crescimento
O Paulo Caroli costuma apresentar os três horizontes do crescimento da Mckinsey que apresenta os produtos e serviços no tempo com seus ciclos de vida.
Segundo Steve Blank, não devemos entender este framework como sendo um mesmo modelo de negócio executado de forma incremental.
O Horizonte 1 tem o foco no negócio core da empresa e busca pela eficiência, Excelência Operacional e Melhoria Contínua, já Horizonte 2 tem foco em Manter a inovação, buscar melhorar os produtos existentes, mover os produtos para mercados adjacentes ou para novos segmentos de clientes enquanto o Horizonte 3 tem foco em Criar novos mercados enquanto novos produtos são criados sob condições de extrema incerteza.
Produtos e serviços do horizonte 3 estão em um momento onde aplica-se usualmente Design Thinking. Aqui a incerteza é muito grande e são levantadas hipóteses e realizadas experimentações por meio de protótipos. No horizonte 2 sim vemos um ambiente bastante propício para inceptions pois estamos explorando oportunidades. Já no horizonte 1, estamos tratando do dia-a-dia onde conhecemos bem o negócio de forma a não estarmos de fato fazendo nenhum tipo de exploração e não precisando de inceptions.
Baseado no modelo Gartner — Combine Design Thinking, Lean Startup and Agile — fazendo uma sobreposição de Desigin Sprint, Lean Inception, Product Backlog Building (PBB) e Scrum temos uma ideia de quando utilizar cada ferramenta no modelo.
Se colocarmos este modelo proposto sobre os três horizontes do crescimento poderíamos ter algo como a imagem abaixo:
No horizonte três, onde estamos explorando modelos de negócio novos, temos maior investimento no levantamento de hipóteses e pelo processo natural, muitas serão descartadas sem chegar na etapa de inception ou construção.
No horizonte dois, onde há uma expansão do modelo de negócio estabelecido em que temos menos incerteza, temos um investimento menor que no horizonte 3 em levantamento de hipóteses para termos um inception e em seguida a contrução em um método ágil.
No horizonte um tendemos a não ter investimento estudo de hipóteses (pelo menos não reconhecido como parte do orçamento) e pouco investimento em inceptions e com execução com modelos ágeis, híbridos ou tradicionais.
Porem uma questão que aparece fortemente nos livros de Eric Ries é que nossos clientes podem ser internos ou externos. Então o pensamento ágil, métodos e ferramentas precisam ser aderentes a ambos. Tendo como exemplo o caso de uma área de operações que queira trabalhar com soluções preditivas para gerar diferencial para seu cliente interno provendo alta disponibilidade, embora em um âmbito empresarial seja uma área de sustentação / operação dia-a-dia. Do ponto de vista da área ela pode prover inovação para seu cliente interno e inclusive por meio de um MVP.
Conclusão
Usei os modelos acima para auxiliar no entendimento, eles têm se mostrado úteis em várias ocasiões, porem os problemas complexos que enfrentamos desafiam abordagens lineares e preditivas e não acredito que haja um modelo perfeito. Acredito que uma inception não é uma etapa necessária para qualquer tipo de demanda ou no mínimo, não deveria ser feito da mesma forma para qualquer situação. Temos que ter claro que o propósito é definir um MVP e este só faz sentido enquanto estamos provando hipóteses que ainda tem um certo nível de ambiguidade. Demandas que temos controle do resultado final dado os requisitos podem não estar neste espectro, assim como iniciar uma inception na etapa em que não temos clareza do problema também pode não ser adequado, sendo mais propício utilizar de frameworks baseados no design thinking (design Sprint por exemplo) para definir entre as opções as oportunidades, para ai sim partir para uma inception.
