Cliente presente é algo que todos entendemos que é obrigatório para entregar um projeto com sucesso. Será que é suficiente?

Tenho visto alguma frequência que desenvolvedores se esforçam para construir uma aplicação corretamente, buscam um modelo rico, OO, fugindo do modelo anêmico. Usam tecnologias de ponta, ORMs, bancos NOSQL. Tem cliente presente. Entregam em iterações curtas, e chegam até a buscar o release contínuo. Buscam evitar o Scrum flácido, praticam XP, programam pareados. E falham. Quero analisar aqui um dos motivos que tenho visto para essa falha.

É comum que o cliente, apesar de presente, não tenha todo o entendimento de como o software deve se comportar. Um Product Owner pode saber o que deve ser feito, mas frequentemente não sabe como a aplicação deve funcionar em detalhes. Mas tudo bem, ele sabe quem sabe. E quem sabe é o especialista de negócio, ou business expert. Essa é a pessoa que realmente realiza as ações de negócio hoje, provavelmente de forma manual no Excel, como boa parte do planeta. É ele que sabe como as coisas devem funcionar, em detalhes.

Só que entender o negócio é algo complicado, e hoje em dia, mais do que nunca, precisamos de especialistas. E quem faz o trabalho super especializado de entender o negócio? O analista de negócio, é claro; vou chamá-lo de André. Ok, temos times multidisciplinares, pessoas multidisciplinares. Isso significa que provavelmente temos mais de uma pessoa no time que sabe fazer análise, mas ninguém o faz tão bem quanto o André. O André se especializou, ele leu o BABOK todo, fez cursos e mais cursos de análise, entende bem de usabilidade, conhece diversas técnicas para entender o que o especialista de negócio precisa, e sabe como documentar isso, como passar esse conhecimento pra frente.

Mas ele não programa.

Quer dizer, ele está num time multidisciplinar, mas ele prefere não programar. Quando está na hora de ele ser multidisciplinar ele escreve uns casos de testes, e está aprendendo a especificar com testes de aceitação com os Test Cases do Visual Studio, ou Fitnesse, ou Cucumber. Já faz uns 5 anos ou mais que o André prefere não programar. E ele é feliz assim, ele gosta de investir seu tempo no desenvolvimento de suas soft skills, é o que ele mais gosta de fazer. Isso é normal, todo mundo tem suas preferências, e estas habilidades são úteis ao projeto.

Então ele vai lá, analisa o negócio. Prepara o conhecimento e o transfere da melhor forma possível para o codificador – vou chamá-lo de Carlos – que vai implementar com código o que André analisou. O Carlos não fala com o especialista de negócio, ele fala com o André.

O André fala com o especialista de negócio sobre o negócio. Se o domínio é um caixa eletrônico, ele fala em saques, depósitos, saldos.

O André também fala com o Carlos. Ele fala de regras de negócio, fluxos principais, fluxos alternativos, wireframes, critérios de aceitação e até de tabelas de banco de dados de vez em quando. E no meio desse monte de outras coisas, ele também fala de saques, depósitos e saldos.

O Carlos, quando tem uma dúvida, pergunta pro André, que pergunta pro especialista de negócio. O especialista responde pro André, o André responde pro Carlos. O Carlos daí conta pros outros codificadores, analistas de banco de dados, etc. Ou o André conta.

Não preciso dizer que isso é um telefone sem fio, não é? Quem já brincou de telefone sem fio sabe que o que sai de um lado dificilmente é igual ao que chega do outro lado. E é assim que tantos consultores, cursos, etc, recomendam que façamos análise de negócio. Com telefone sem fio. Esse é um dos grandes motivos para a falha na entrega: entendemos errado porque o processo de comunicação é falho.

O Carlos, ao contrário do André, não se aprofundou em análise de negócio. Pode ser que ele odeie analisar o negócio, pode ser que não, mas de qualquer forma ele não desenvolveu tanto suas soft skills. Ele prefere codificar, ele se aprofundou em padrões de projeto, em OO, em assuntos diferentes do que o André se aprofundou.

Como resolver isso? Eliminando o analista de negócio do projeto? Claro que não! Quem fará a análise, o Carlos, que não é tão especializado? Não, é o próprio analista que fará a análise do negócio, mas ele o fará de uma maneira um pouco diferente. Em vez de fazer a ponta entre especialista de negócio e codificador, ele vai trabalhar como um facilitador da comunicação dos dois. Ele vai trazer o codificador ao especialista de negócio, ou vice-versa, e usar suas técnicas e soft skills para levantar as informações mais relevantes, na maior quantidade possível. Os três, juntos, vão desenhar a aplicação.

E na hora de parear, porque não o André, sentado ao lado do Carlos, enquanto ele codifica? Isso sim, é trabalhar num time verdadeiramente multidisciplinar.

Ingrediente pro sucesso.

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.