Considere um exemplo hipotético: uma empresa lança um sistema para que os funcionários peçam reembolso de despesas. A equipe entrega o que foi combinado, os testes passam e o projeto é encerrado. Os desenvolvedores seguem para outro trabalho. Depois, os pedidos começam a voltar para quem os enviou porque faltam informações, e o financeiro continua resolvendo as pendências por e-mail.
O sistema funciona, mas ainda não reduziu o trabalho de conferir os pedidos. Pode haver uma instrução confusa, um campo mal escolhido ou uma regra que ninguém percebeu durante os testes. Para descobrir, alguém precisa acompanhar os pedidos devolvidos e conversar com as pessoas que tentaram usá-lo.
Quem fará isso agora? Se a equipe já foi deslocada e o suporte só pode corrigir falhas, uma mudança pequena pode depender da aprovação de outro projeto. A empresa pagou pela entrega, mas deixou sem responsável a verificação de que ela resolveu o problema.
O que falta saber depois da entrega
O prazo e a lista de funcionalidades ajudam a organizar o trabalho. No exemplo do reembolso, permitem verificar se é possível anexar um comprovante, aprovar uma despesa e registrar o pagamento. Essas verificações são necessárias para colocar o sistema em uso.
Ainda falta saber se os funcionários conseguem fazer tudo isso sem pedir ajuda. Um pedido pode passar por todas as telas e chegar incompleto ao financeiro. Nesse caso, contar quantos pedidos foram enviados diz pouco sobre o trabalho que a ferramenta deveria poupar.
Seria mais útil examinar quais pedidos voltam para correção e por quê. Talvez a mesma informação esteja faltando em muitos deles. A equipe poderia ajustar a instrução desse campo e observar os pedidos seguintes. Se as devoluções continuassem, teria motivo para investigar outra causa, em vez de considerar a tarefa resolvida porque a tela foi alterada.
Em Products Over Projects, publicado em 2018 no site de Martin Fowler, Sriram Narayan defende equipes que continuam ligadas ao problema depois de entregar o software. Ele distingue financiar uma solução previamente definida de manter uma equipe capaz de verificar os resultados e rever o que construiu.
Aplicada ao exemplo, essa proposta exige reservar tempo para acompanhar o reembolso depois do lançamento. Também exige decidir quem pode interromper uma nova funcionalidade para resolver uma dificuldade que surgiu no uso. Sem esse acordo, até uma equipe que conhece bem o sistema pode ficar sem espaço para melhorá-lo.
Quem acompanha precisa poder mudar o sistema
Dar a alguém a responsabilidade pelo sistema só ajuda se essa pessoa ou equipe puder agir sobre os problemas encontrados. Receber reclamações, sem tempo nem autorização para mudar o software, tende a transformar essa responsabilidade em uma fila de pedidos.
No caso do reembolso, suponha que a exigência de um documento esteja causando as devoluções. O desenvolvedor pode alterar a tela, mas precisa entender com o financeiro se aquele documento é obrigatório em todas as situações. A mudança depende de uma decisão sobre o processo, além do trabalho de programação.
Por isso, o acordo entre as áreas precisa ser específico. Quem pode rever a exigência? Quem verifica se a alteração funcionou? Se o financeiro mudar uma regra, como a equipe de desenvolvimento ficará sabendo? São detalhes que determinam se uma reclamação poderá ser resolvida ou apenas encaminhada.
A equipe que mantém o sistema também deve conseguir consultar os motivos das devoluções, com acesso limitado aos dados necessários. Pedir que ela melhore o processo sem permitir que veja onde ele falha deixa a investigação dependente de relatos incompletos.
Isso tem um custo que precisa aparecer no planejamento. As horas usadas para acompanhar pedidos e corrigir o fluxo deixam de estar disponíveis para outras entregas. A liderança precisa decidir se a redução de trabalho no financeiro justifica essa dedicação, em vez de esperar que a equipe faça as duas coisas com o mesmo prazo.
A passagem para outra equipe precisa de tempo
Manter uma equipe responsável por um sistema não exige conservar as mesmas pessoas indefinidamente. Profissionais mudam de função, fornecedores encerram contratos e produtos passam a precisar de menos desenvolvimento. A continuidade depende de como a responsabilidade é transferida nessas mudanças.
Se outra equipe assumir o sistema de reembolso, a documentação pode explicar as regras de aprovação e como publicar uma alteração. Para receber o trabalho, porém, ela também precisa conhecer os problemas ainda abertos. Vale percorrer um pedido devolvido junto com quem o investigou, verificar os testes existentes e combinar a quem recorrer se aparecer uma dúvida.
Essa passagem ocupa tempo das duas equipes. Deixá-la para o último dia do contrato reduz a oportunidade de perceber o que está faltando. Um problema descoberto depois pode exigir localizar alguém que já saiu para entender uma decisão antiga.
Também há sistemas estáveis que não justificam uma equipe dedicada. Uma equipe compartilhada pode cuidar deles, desde que tenha capacidade para atender às demandas e que esteja claro como essas demandas serão priorizadas. O tamanho da equipe pode mudar conforme o trabalho; o atendimento não deveria depender de encontrar alguém disposto a ajudar por acaso.
Antes de encerrar o projeto, esse arranjo precisa estar combinado. No exemplo do reembolso, seria necessário indicar quem examinará os pedidos devolvidos após o lançamento e de onde virá o tempo para corrigir o que for encontrado. Se ninguém puder assumir esse trabalho, a decisão de deslocar toda a equipe ainda precisa ser revista.
