IA e Agilidade: começando pelo skate para construir um carro
Artigo
É 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”.
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.
(Por Israel Dias (foto), agilista na FINCH /Foto⁚ Divulgação)
