Inteligência Artificial e Agilidade: aprendendo a fazer um skate

É 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 (Para saber mais sobre isso, leia “Inteligência artificial: entenda como seu negócio pode se beneficiar com ela“).

Com tantos benefícios que esses projetos trazem, como a praticidade, o aumento de produtividade e rapidez na informação, surgem também novos desafios, tais como dificuldades em lidar com prazos e contratos, constantes alterações de escopo, novas burocracias processuais, complexidades e incertezas. 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, representado por um documento elaborado por um grupo de especialistas em desenvolvimento de software. Nele estão contidos 4 valores:

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;

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. Nisso temos uma quebra de paradigma, pois estávamos, tradicionalmente, um pouco mais acostumados a pensar projetos de uma maneira “cascateada”, ou seja, divididos em etapas subsequentes, sendo que seu progresso só ocorre com a finalização da etapa anterior e o resultado final somente é alcançado com o término de todas elas.

Para ilustrar melhor esse pensamento, vamos pensar na confecção de um bolo: primeiro, pensa-se no sabor, depois na receita, na massa, no recheio, na montagem, nos confeitos e, por último, na cereja! Essa maneira de pensar não está errada e em muitos casos ela será a melhor forma. Apesar disso, a aplicação de uma metodologia ágil lidará melhor com contextos caracterizados pela incerteza e pela complexidade. Voltando ao exemplo do bolo, uma entrega rápida e de valor seria um cupcake, que, embora mais simples, também é um bolo completamente pronto e abre a oportunidade para colher feedback e melhorar o produto.

 

Como fazer um MVP – (Most Valuable Player? Não nesse caso!)

 

Embora o título deste texto mencione o skate, a sigla MVP aqui não se refere ao que, no universo do esporte, chamamos de “Most Valuable Player”. O significado desta sigla, neste contexto é “Minimum Viable Product” (Produto Mínimo Viável), conceito que pode ser muito bem ilustrado pelo exemplo do bolo/cupcake acima descrito. Trata-se de uma versão mínima do produto, que, embora não seja a versão final, supre funcionalidades básicas e necessárias ao propósito para o qual foi destinado.

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). 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.

 

Mas o que o skate tem a ver?

 

Henrik Kniberg em seu artigo “Making sense of MVP (Minimum Viable Product) — and why I prefer Earliest Testable/Usable/Lovable” 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)

3. Earliest Lovable Product (Produto amável mais cedo)

O autor defende que a maioria dos clientes não querem o mínimo, mas aceitam receber algo antecipado. Seu ponto é que o MVP não é ruim, contudo, se for mal compreendido (e mal aplicado) pode gerar insatisfação do cliente que entender que está recebendo um produto “incompleto”.

Voltando às metáforas, 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, como mostra a figura abaixo.

 

Fazendo uso da abordagem de produto “testável o mais cedo”, inicialmente, não alcançamos totalmente 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.

 

 

Qual a relação entre a IA e o Skate?

 

O time de inteligência artificial da Finch desenvolve diversas soluções para vários clientes. Sendo composto por analistas e cientistas de dados, o time possui 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 final alcance seu objetivo. Nesse processo, o time 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?”.

Caso 1 – Uma loja de autopeças

Em um dado projeto que consiste no desenvolvimento de uma plataforma de análises estatísticas de processos jurídicos, o time precisa realizar exames prévios de uma série de documentos que o cliente envia para que, com base nisso, desenvolva modelos matemáticos preditivos que fornecem informações e insights para o cliente tomar decisões mais assertivas e fundamentadas em dados. Este é um projeto complexo, que lida com constantes incertezas (devido a descobertas diárias) e ao mesmo tempo com prazos contratuais. Aqui adotamos o framework ágil Scrum, de maneira que, Sprint após Sprint, temos pequenas entregas a fim de caminharmos para a solução desejada.

Ao longo do processo de desenvolvimento, embora com excelentes resultados de nossos modelos, começamos a perceber que tínhamos muitos “pneus”, “volantes”, “bancos”... praticamente uma “loja de autopeças!” O problema é que, apesar de essas partes serem componentes de um carro e serem indispensáveis para o seu funcionamento, elas por si próprias não fazem o nosso cliente “se deslocar de um ponto A para o B”. Essa foi uma das primeiras provocações que começamos a nos fazer (não somente em relação a esse projeto em específico): a maneira como estávamos conduzindo nossos projetos estava perdendo oportunidades de aprender com feedback ao entregar produtos testáveis e usáveis. Isso mudou a nossa forma de olhar para todos os outros projetos!

Caso 2 – Uma Ferrari ou uma bicicleta?

Em outro cenário, de outro projeto que consiste basicamente na leitura e preenchimento de documentos de maneira automatizada, o time estava com uma missão: “Entregar a solução com maior assertividade possível para o nosso cliente!”. Para isso, foi necessário empenho para descobrir quais os índices máximos e mínimos de assertividade que nossos modelos deveriam performar. Isso começou a nos custar muito tempo. Neste caminho, nos deparamos com a pergunta: “Qual é a assertividade mínima que nosso cliente precisa?”. Em outras palavras, “queremos entregar uma Ferrari para o nosso cliente! Mas será que – para testarmos hipóteses e cenários – uma bicicleta já não seria o suficiente num primeiro momento?”.

Desta vez, com o conceito de “usável/testável/amável” em mente, tivemos sucesso em desenvolver uma solução testável obtendo positivos (e valiosos) feedbacks! Esse tempo pôde ser investido para gerar ainda mais valor para nossos clientes. Como disse Peter Drucker: “Não há nada tão inútil quanto fazer eficientemente o que não deveria ser feito”. Estamos no caminho certo para a solução amável.

 

Qual é a melhor forma?

 

Em contextos incertos e complexos, vale sempre o questionamento: “Estamos começando pelo skate ou pelo pneu?”. A nossa entrega está “testável” ou já é “usável”? Como podemos chegar na solução “amável” de forma a resolver o problema de 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” está nos levando para mais perto de entregas mais rápidas e de maior valor para nossos clientes. O nosso time de IA está aprendendo a começar pelos skates.

 

Sobre o autor

 

Israel Dias Felipe, músico e Engenheiro de Produção pela UFSCar - São Carlos, atua na gestão de times ágeis, com certificações PSM I e KIKF. Atualmente cursando MBA USP/Esalq em Gestão de Projetos e é Agilista na Finch.