Manobra reversa: desenhar a jornada para definir como entregar

Thiago Adriano — Tue, 06 Oct 2026 08:25:54 +0000

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.

PDLC e SDLC: conectando produto e desenvolvimento de software

Thiago Adriano — Sat, 03 Oct 2026 15:01:01 +0000

Imagine desenvolver uma aplicação com uma arquitetura bem definida, testes automatizados e deploy funcionando. Mesmo assim, depois do lançamento, poucas pessoas utilizam o sistema.

O software funciona, mas ele resolve um problema relevante para o usuário?

Essa pergunta ajuda a entender a relação entre PDLC e SDLC, dois conceitos que conectam decisões de produto à construção de software.

O que é PDLC?

PDLC — Product Development Life Cycle é o ciclo de desenvolvimento do produto. Envolve descobrir problemas, validar hipóteses, definir uma solução e acompanhar seus resultados.

Uma forma de organizar esse ciclo é:

Descoberta: entender o público, suas necessidades e o problema.
Validação: buscar evidências de que o problema existe e a solução proposta faz sentido.
Priorização: definir o que será entregue primeiro.
Construção e lançamento: disponibilizar uma primeira versão.
Evolução: acompanhar o uso, coletar feedback e ajustar o produto.

A validação pode começar com entrevistas, protótipos e experimentos, antes de investir na implementação completa.

O que é SDLC?

SDLC — Software Development Life Cycle é o ciclo de desenvolvimento do software. Organiza as atividades necessárias para construir, operar e manter uma solução.

As atividades mais comuns são:

Requisitos: definir os comportamentos esperados e os critérios de qualidade.
Projeto e arquitetura: planejar componentes, dados e integrações.
Implementação: desenvolver as funcionalidades.
Testes: verificar comportamento, segurança e confiabilidade.
Implantação: disponibilizar o software no ambiente de uso.
Operação e manutenção: monitorar, corrigir problemas e evoluir.

Essas atividades podem ocorrer de maneira iterativa, com entregas pequenas e feedback frequente.

Comparação prática

Aspecto	PDLC	SDLC
Foco	Necessidades do usuário e valor do produto	Construção e qualidade do software
Pergunta central	O que vale a pena construir e por quê?	Como construir, entregar e operar?
Evidências	Entrevistas, experimentos e métricas de uso	Testes, métricas técnicas e comportamento em produção
Decisões	Público, proposta de valor e prioridades	Arquitetura, implementação e implantação

Exemplo: um sistema de métricas de treino

No PulsoNexo, meu projeto de acompanhamento de treinos com integração ao Polar, podemos aplicar os dois conceitos.

No PDLC, uma hipótese seria: reunir frequência cardíaca, zonas de esforço e volume semanal pode ajudar o atleta a compreender sua rotina de treino.

Para validar essa hipótese, podemos apresentar um protótipo e observar se essas informações são compreendidas e úteis. O resultado orienta quais funcionalidades devem entrar na primeira versão.

No SDLC, transformamos essa proposta em software: integração com o Polar, API, armazenamento dos treinos, dashboard e testes. Também precisamos tratar autenticação, falhas de sincronização e proteção dos dados.

Depois da entrega, o uso pode revelar que os atletas consultam mais o histórico semanal do que os detalhes de cada treino. Esse aprendizado retorna às decisões de produto e orienta as próximas entregas.

Como os ciclos se conectam?

PDLC e SDLC são complementares. Em um produto digital, o desenvolvimento de software participa da construção e da evolução do produto.

As decisões de produto orientam as entregas técnicas, e os resultados dessas entregas ajudam a revisar as decisões de produto.