Você está no meio de um projeto quando o líder da equipe do cliente diz: “Precisamos que este fluxo de trabalho funcione para nossas três regiões — cada uma com regras de aprovação diferentes — e isso precisa ser garantido pela plataforma”. Você provavelmente conseguiria criar uma solução improvisada na implementação, mas sabe que esse é o tipo de coisa que o próximo cliente também solicitará.
Esta lição trata de identificar o momento em que uma solicitação do cliente deixa de ser uma tarefa de entrega pontual e passa a ser um trabalho de desenvolvimento do produto principal, além de esclarecer o que permanece sob sua responsabilidade como um Forward Deployed Engineer (FDE). Um FDE é um engenheiro que atua diretamente no ambiente do cliente, traduzindo as necessidades deste em trabalho de produto e engenharia.
Antes de decidir o que construir, você precisa definir qual é a verdadeira natureza da solicitação. Trata-se de “fazer funcionar para esta conta até sexta-feira” ou de “nos falta uma funcionalidade reutilizável, e este cliente é o primeiro sinal claro disso”?
Explore o contraste entre uma alteração pontual para um cliente e uma funcionalidade reutilizável.
Uma solicitação se torna estratégia de produto quando deixa de tratar apenas da configuração de um cliente específico e passa a apontar para uma funcionalidade ausente no produto. Você percebe isso quando o cliente não está pedindo apenas um resultado, mas sim uma regra que deve ser incorporada à plataforma.
Considere esta situação: o cliente deseja que aprovações específicas por região sejam aplicadas dentro da plataforma — não em uma planilha, não como uma etapa manual e não como um script personalizado que apenas sua equipe compreende. Isso indica que eles estão pedindo algo que exige design de produto, suporte de longo prazo e um contrato claro sobre seu comportamento.
Uma maneira rápida de distinguir as duas coisas é perguntar o que acontece depois que você sai. Se a solução exigir que você mantenha uma ramificação (branch) personalizada, um patch privado ou um comportamento de caso especial que ninguém consegue explicar sem suas anotações, ela está entrando no território do produto, pois necessita de uma interface oficial e de um plano de suporte estável.
Se precisa de suporte, precisa de design No momento em que um cliente espera que uma funcionalidade sobreviva a atualizações e novos usuários, trate-a como produto, e não como um truque de entrega pontual.
Mesmo quando algo deveria se tornar parte do produto principal, você ainda é responsável por manter o progresso do projeto. Seu trabalho é destravar o cliente sem reescrever o produto “por baixo dos panos” durante a implementação em campo.
Essa responsabilidade tem duas partes.
Primeiro, você mantém a entrega em andamento. Você transforma a solicitação em um requisito claro, identifica o que é viável na implementação atual e propõe um caminho provisório que seja transparente quanto às limitações.
Segundo, você protege a integridade do produto. Integridade do produto significa que ele permanece coerente como um produto único, e não como um amontoado de comportamentos específicos de contas que acabam gerando conflitos entre si com o tempo. Na prática, isso significa evitar forks (ramificações paralelas), evitar flags ocultas usadas por apenas um cliente e evitar assumir compromissos que coloquem a equipe de engenharia em uma situação sem saída mais tarde.
No nosso exemplo de aprovações, você poderia implementar um processo temporário que atenda à necessidade de auditoria enquanto reúne evidências para uma funcionalidade nativa. Você não está recusando a solicitação, está definindo a sequência de execução.
O aspecto complicado é que cada tipo de falha pode parecer “agilidade no atendimento” no momento em que ocorre. O custo aparece mais tarde, geralmente quando você já está trabalhando com outro cliente.
Veja alguns breves exemplos de como essas falhas geram custos futuros.