Por Israel Dias*
É sabido que o avanço da tecnologia tem moldado nossas vidas de diversas maneiras, desde como consumimos até como nos relacionamos. Na área jurídica, além de se utilizar a inteligência artificial para a automatização de processos – que aumenta a qualidade da entrega e reduz o custo operacional (ex: chatbots, assistentes virtuais, gerenciadores de tarefas etc.) –, há a possibilidade de empregá-la para coletar, extrair, estruturar e utilizar dados de forma estratégica, rápida e funcional.
Da mesma forma que esses projetos trazem praticidade, aumento de produtividade e rapidez na informação, surgem também novos desafios, tais como dificuldades em lidar com prazos e contratos, necessidade de constantes alterações de escopo, novas burocracias processuais, complexidades e incertezas.
Neste contexto, percebeu-se que não era mais viável gerenciar projetos de desenvolvimento de software da mesma maneira que se gerenciava um projeto convencional.
Em resposta a isso é que surgiu o Manifesto Ágil, um documento elaborado por um grupo de especialistas em desenvolvimento de software, onde estão contidos 4 valores fundamentais:
1) Indivíduos e interações mais que processos e ferramentas;
2) software em funcionamento mais que documentação abrangente;
3) colaboração com o cliente mais que negociação de contratos e
4) responder a mudanças mais que seguir um plano.
O objetivo desse manifesto é propor uma nova maneira de desenvolver softwares, entregando valor ao cliente o mais rápido possível.
Em um processo de desenvolvimento de um produto/serviço gerenciado da maneira tradicional (ou “cascata”) o cliente só recebe no final, sem chances para feedback no curso do processo e com alto risco de retrabalho (caso ele não fique satisfeito com a entrega).
A maneira ágil de gerenciar projetos permite que as entregas sejam feitas de forma iterativa e incremental, ou seja, a cada iteração (progresso a cada ciclo constante) há a entrega de um incremento (“pedaço” de software).
Trata-se de uma versão mínima do produto (MVP – Minimum Viable Product) que, embora não seja a versão final, supre funcionalidades básicas e necessárias ao propósito para o qual foi destinado.
No entanto, precisamos nos atentar ao fato de que o incremento deve entregar valor para o cliente; caso contrário será somente uma entrega não finalizada.
Logo, a cada entrega há oportunidades para colher feedback e implementar melhorias no incremento seguinte.
Essa abordagem do MVP é extremamente útil para testes, validações de ideias e cenários a partir da coleta de feedbacks que o cliente fornece a partir dessa experiência com o produto mínimo viável, propiciando a realização de um trabalho assertivo, correspondente ao desejado, adequado ao propósito e reduzindo a chance de perdas e retrabalhos.
Entretanto, se for mal compreendida (e mal aplicada), a metodologia MVP pode gerar insatisfação do cliente que entender que está recebendo um produto “incompleto”.
Notícias Relacionadas
Em seu artigo “Making sense of MVP (Minimum Viable Product) — and why I prefer Earliest Testable/Usable/Lovable”, Henrik Kniberg propõe a ideia de que devemos quebrar o termo “Minimum” (mínimo) em três partes:
1. Earliest Testable Product (produto testável mais cedo);
2. Earliest Usable Product (produto usável mais cedo) e
3. Earliest Lovable Product (produto amável mais cedo).
O autor defende ainda que a maioria dos clientes não querem o mínimo, mas aceitam receber algo antecipado, desde que satisfaça sua necessidade, ou pelo menos parte dela.
Através do feedback, o cliente então passa a contribuir ativamente para o desenvolvimento mais assertivo e customizado dos produtos/serviços. Para ilustrar melhor esse pensamento, imaginemos o seguinte cenário: o cliente deseja se deslocar do ponto A para o ponto B da maneira mais rápida possível.
Entregar um pneu de um carro de maneira rápida não entrega valor para o cliente. É algo antecipado? Sim! Mas é um “mínimo” que não supre em nada o seu problema de deslocamento.
O mesmo ocorre se pensarmos na entrega de 2 pneus ou até mesmo um carro sem direção. Fazendo uso da abordagem de produto “testável o mais cedo” não alcançamos a satisfação do cliente, mas conseguimos suprimir minimamente o seu problema de deslocamento, com um skate (por exemplo).
É a melhor maneira possível? Ainda não! Mas conseguimos aprender com base no feedback do cliente de forma a implementar melhorias a fim de levá-lo ao estágio de produto “usável o mais cedo”, como, por exemplo, uma bicicleta ou uma moto.
O objetivo é seguir colhendo feedbacks de modo a se aproximar cada vez mais do estágio de produto “amável”, ou seja, de como de fato será o produto final. Esse processo favorece a aprendizagem e lida melhor com mudanças ao longo do caminho, tendo por base a colaboração do cliente.
Num time de inteligência artificial de uma empresa de tecnologia, por exemplo, contamos com diversos talentos, habilidades e competências para desenvolver diversas soluções para nossos clientes.
Composto por analistas e cientistas de dados, temos uma característica de “time de pesquisa”, pois é necessária muita exploração de dados, desenvolvimento de modelos matemáticos e validações de ordem jurídica para que o resultado alcance seu objetivo final.
Nesse processo, a equipe conta com diversas ferramentas, linguagens e habilidades, mas enfrenta também desafios como “até onde devemos seguir pesquisando soluções ótimas?” ou “qual é o índice de assertividade que esse modelo matemático deve atingir para ser considerado bom?”.
Em contextos incertos e complexos, vale sempre o questionamento se estamos começando pelo skate ou pelo pneu.
A nossa entrega está “testável”? Já é “usável”? Como podemos chegar a uma solução “amável”, de forma a resolver o problema dos nossos clientes?
Não há uma fórmula pronta ou parâmetros objetivos universalmente aplicáveis, mas estamos certos de que essa compreensão de “testável/usável/amável” pode nos aproximar de realizar entregas mais rápidas e de maior valor para nossos clientes. Começar pelos skates sempre pode ser uma boa estratégia.
*Israel Dias, agilista na FINCH.
