Em projetos de tecnologia, uma pergunta costuma aparecer cedo: qual time vai construir cada parte?
Um time fica com o aplicativo, outro com as APIs e outro com o sistema legado. Cada equipe recebe seu escopo e começa a trabalhar.
O problema aparece quando essas partes precisam funcionar juntas. A tela está pronta, a API responde e o legado processa. Mesmo assim, o cliente não consegue concluir o que precisava fazer.
Podemos inverter esse raciocínio:
Primeiro desenhamos a jornada que precisa funcionar. Depois perguntamos: que coordenação, responsabilidades e compromissos essa jornada exige?
Essa é a manobra reversa: partir do resultado esperado para descobrir quais condições técnicas e organizacionais tornam esse resultado possível.
Imagine uma jornada de investimento. O cliente escolhe um produto, informa o valor, confirma a aplicação e acompanha o resultado.
Descrever essas etapas ajuda, mas ainda deixa perguntas importantes em aberto. Quando a aplicação pode ser considerada concluída? O que o cliente vê enquanto o processamento está pendente? Como ele descobre que houve uma falha? O que acontece se apertar o botão novamente?
A jornada precisa incluir essas situações. Elas fazem parte da experiência que estamos prometendo.
Também precisamos validar se essa experiência resolve o problema do cliente. Uma jornada desenhada ainda representa uma hipótese. Conversar com usuários e testar o fluxo ajuda a verificar se estamos construindo algo útil.
A jornada revela responsabilidades
Considere um exemplo hipotético: o aplicativo informa que a solicitação foi recebida, mas a confirmação da aplicação depende de um processamento posterior no legado.
Se cada time olhar apenas para sua entrega, todos podem considerar o trabalho concluído. O aplicativo enviou a requisição. A API registrou o pedido. O legado recebeu a informação.
Mas o cliente continua esperando.
Ao partir da jornada, surgem responsabilidades que a divisão por componentes pode esconder. Alguém precisa definir os estados da operação, garantir que o resultado volte ao aplicativo e estabelecer como uma solicitação pendente será investigada.
É nesse ponto que precisamos esclarecer quem articula as dependências, quem decide em caso de dúvida e quem responde por cada etapa.
Uma equipe pode executar sua parte corretamente e, ainda assim, participar de uma jornada que falha. Por isso, acompanhar o resultado completo precisa fazer parte da organização do trabalho.
Dependências precisam virar compromissos
“Vamos integrar os sistemas” é uma intenção. Para orientar a construção, precisamos de acordos concretos.
No exemplo do investimento, os times precisam combinar:
- O significado de cada status da operação.
- O prazo esperado para apresentar a confirmação.
- O tratamento de solicitações repetidas.
- O procedimento quando uma operação fica sem resposta.
- As informações necessárias para investigar uma falha.
Esses acordos influenciam a arquitetura.
Se o processamento acontece depois da solicitação, pode ser necessário consultar o status ou receber uma notificação. Se uma tentativa pode ser repetida, precisamos evitar aplicações duplicadas. Se há uma falha entre sistemas, precisamos conseguir rastrear a operação.
A tecnologia passa a responder a uma necessidade identificada na jornada. Temos um motivo concreto para discutir integração, processamento assíncrono, idempotência e observabilidade.
O que muda para quem lidera
Esse raciocínio amplia as perguntas da liderança.
Além de acompanhar tarefas, precisamos verificar se os times conseguem tomar as decisões que o fluxo exige. Uma aprovação depende de três áreas? Uma mudança precisa de alinhamento manual? Uma falha chega à operação sem contexto suficiente?
Esses pontos revelam necessidades de coordenação, autonomia e acesso à informação.
A resposta pode envolver ajustar uma responsabilidade, estabelecer um contrato entre serviços ou simplificar uma aprovação. Cada mudança deve responder ao problema encontrado.
Uma forma prática de começar é escolher uma jornada importante e percorrer tanto o caminho esperado quanto as principais falhas.
Em cada passagem entre equipes, perguntar:
Quem assume a próxima etapa e qual compromisso permite que ela aconteça?
Essa pergunta ajuda a transformar um desenho de fluxo em um acordo de entrega.
O critério de conclusão também fica mais claro. No investimento, entregar a tela e publicar a API são marcos da construção. Concluir a jornada exige demonstrar que o cliente consegue solicitar, acompanhar e conhecer o resultado da aplicação, inclusive quando algo sai do esperado.
Antes de distribuir o trabalho, precisamos compreender o caminho que queremos fazer funcionar. É esse caminho que dá sentido às responsabilidades, aos compromissos e às decisões de arquitetura.
Top comments (0)