Eric Ries está brilhantemente nos ensinando a lidar com a incerteza no mundo dos negócios. Já está na hora de aproveitarmos essas técnicas de Lean Startups e aprendermos a aplicá-las em todo o processo de desenvolvimento de software, não mais somente para o mundo das Startups.
Product Backlog não mais!
"You gotta start with the customer experience and works backward to the technology. You can’t start with the technology and try to figure out where you are going to sell it." (Steve Jobs, WWDC 1997)
A realidade hoje, infelizmente, ainda é a de que 80% do software desenvolvido não está sendo utilizado (CHAOS Report Standish Group 2009). O que significa um enorme desperdício de dinheiro. Deveríamos desenvolver software somente depois de termos a certeza de que será utilizado.
É muito comum em projetos de software nem se saber quem são os usuários finais. O Product Owner do seu time de desenvolvimento é um usuário real? Ou é apenas um intermediário? Somente os usuários finais podem esclarecer de alguma forma para a equipe de desenvolvimento o que querem utilizar e como querem utilizar. Somente em uma relação muito próxima com os usuários finais é que as funcionalidades certas são reveladas.
O loop "Build, Measure, Learn", definido para as Lean Startups, deve ser aplicado também no processo de desenvolvimento de software desde o seu início. Na prática isso significa:
Ter sempre uma quantidade mínima de tarefas no Task Board, apenas o suficiente para amparar uma próxima conversa com os usuários finais. (Build)
Medir bem de perto os resultados do ambiente de produção. Como os usuários finais de fato estão utilizando as funcionalidades que já foram desenvolvidas. (Measure)
Estar completamente aberto para os novos direcionamentos que os usuários finais vão revelando ao longo do uso do software, ou seja, não ter um Product Backlog já pré-determinado, impedindo o fluxo das necessidades naturais do software. (Learn)
Figura 1: O loop Build-Measure-Learn das Lean Startups.
Mesmo em aplicações muito grandes e complexas, esse é o caso onde é ainda mais importante evitar o desperdício. O primeiro a fazer é dividir a aplicação muito grande e complexa em um monte de pequenos projetos independentes, que podem ser focados e geridos de uma forma mais precisa e realista. Depois definir com clareza quem são os usuários finais e aproximá-los ao máximo da equipe de desenvolvimento. Quando os projetos de softwares são pequenos e simples, é muito mais fácil para o usuário absorver os conceitos de negócio, entender as necessidades técnicas e prover um feedback preciso. Bem como muito mais rápido e barato para a equipe de desenvolvimento produzir os resultados certos. (Leitura complementar: Conceito de Mini Aplicações)
"(...) And some mistakes we made by the way. Some mistakes will be made along the way. That’s good because at least some decisions are being made along the way. And we’ll find the mistakes and we’ll fix them." (Steve Jobs, WWDC 1997) R.I.P :_-(
Um Método para Desenvolver Software Incerto
Figura 2: O poster do Desenvolvimento Ágil adaptado para o Software Incerto
O Desenvolvimento Ágil é sem dúvida um grande avanço para a humanidade. Mas mesmo com as metodologias e ferramentas de desenvolvimento Ágeis ainda existe muito desperdício, muito backlog, muita repetição de documentação e muito planejamento no processo de desenvolvimento de um software.
O Desenvolvimento Ágil inicia seu processo com a construção do Product Backlog. Já o Método Incerto inicia o seu processo de desenvolvimento com a identificação dos Minimum Viable Products da aplicação.
Para se identificar um MVP, é necessário ter muito conhecimento sobre os usuários (e clientes) da aplicação, caso contrário, o software nunca será viável (Leia também: Definindo o seu MVP). É muito comum Product Owners terem difículdade para minimizar e priorizar requisitos. Eles normalmente querem que tudo seja feito e com urgência. Não raramente um Product Backlog tem vários itens com a prioridade máxima. Mesmo que eles ainda pensem que tudo pode ser feito, a inicialização do desenvolvimento pode ser facilitada identificando-se qual será a primeira funcionalidade a ser entregue de imediato, ou seja, basta colocar as prioridades máximas em uma ordem e selecionar somente a primeira. O objetivo é que a equipe de desenvolvimento tenha um ponto por onde começar. A partir daí, as próximas prioridades deverão ser definidas de acordo com os resultados das entrevistas com os usuários finais (ver em breve: User Driven Development, post em construção).
Na Figura 2 acima encontra-se um resumo das adaptações sugeridas para o processo de desenvolvimento Ágil. São elas:
- Distribuir um MVP para cada time de desenvolvimento. (One MVP)
- Entrevistar constantemente os usuários finais e medir o grau de utilização de cada funcionalidade que está sendo adicionada no ambiente de produção. (Acceptance)
- Substituir as inúmeras reuniões de estimativas e planejamento por uma rápida priorização de tarefas baseada em dados empíricos extraídos das medições do ambiente de produção. (Mini Iteration Plan)
- Engajar diretamente a equipe de desenvolvimento com os usuários finais para que os próprios desenvolvedores possam criar as soluções mais adequadas para o software que está sendo construído. (Improvements Meeting)
- Criar tarefas dinamicamente baseando-se nos dados de uso do software. (User Driven Development - UDD, post em construção)
Abordagens não sistêmicas são muito úteis, como low fidelity prototypes ou qualquer outra prática de UX (User eXperience). Mas tenha em mente que entrevistar um usuário final pessoalmente, em frente ao software em funcionamento, tem valor inestimável para um desenvolvedor. A atmosfera psicológica que é formada em um momento como este, fornece uma percepção única com tanta informação preciosa para o desenvolvedor que nenhum documento e possívelmente nenhum intermediário podem descrever.
One MVP
Entendo que praticamente qualquer funcionalidade tem dependências externas. É difícil isolá-las e desenvolvê-las de forma independente. Mas se a equipe de desenvolvimento puder simular (mock-up) as dependências externas e focar em cada MVP separadamente, as perspectivas se tornam muito mais claras, e facilmente surgem diferentes possibilidades de implementação para esse MVP. O vantagens são enormes. O que normalmente acontece é que várias dessas dependências nem precisarão mais ser implementadas, porque o planejamento começa a sofrer drásticas alterações depois que se começa a dialogar com os usuários finais.
"É preciso entender profundamente a essência de um produto para podermos nos livrar das partes não essênciais." (Jonathan Ive, Designer chefe da Apple)
Cada equipe de desenvolvimento deve focar-se em seu próprio MVP e começar a trabalhar com as tarefas determinadas para a primeira funcionalidade priorizada. Um Task Board pode ser utilizado, Improvements Meeting, Retrospectivas, etc, mas o mais importante é entregar algo o mais rápido possível no ambiente de produção, para que os usuários finais possam manipular o software pessoalmente e o loop Build, Measure, Learn possa girar o mais eficiente possível.
Depois que os usuários já estiverem satisfeitos com o atual MVP, é a hora de começar o próximo. A interação com os usuários neste momento já estará bem mais fluente. Será mais fácil identificar o que eles querem a seguir. E comumente eles não se importam muito que o software seja super flexível e adaptável, ás vezes nem mesmo que tenha alguns errinhos minoritários. Normalmente o que eles preferem é um software que tenha personalidade, algo que eles possam dizer "Que legal!".
No comments:
Post a Comment