Squad de TI
Transferência de conhecimento no fim do contrato de TI: o erro de deixar para a última semana
Transferência de conhecimento não é evento final. Veja o que cobrar a cada ciclo do contrato e como testar se a equipe do órgão segue sozinha.
A transferência de conhecimento em contrato de TI não é uma entrega final. Ela acontece junto com a execução: documentação atualizada a cada ciclo, decisões registradas e a equipe do órgão acompanhando o trabalho.
Deixar tudo para a última semana costuma gerar um relatório que ninguém consegue usar. Este texto mostra o que cobrar do fornecedor durante o contrato e como testar se a equipe interna consegue seguir sozinha.
O custo de deixar a transferência para o encerramento
O formato é conhecido. O contrato prevê "transferência de conhecimento" como último item do cronograma, e a atividade vira uma reunião, um relatório e um termo assinado.
O problema é o que se perde até chegar lá. Conhecimento de sistema não está só no código. Está nas decisões que ninguém anotou, nas exceções de regra de negócio e nos motivos de cada integração ter sido feita daquele jeito. Quem construiu lembra de tudo isso na hora. Meses depois, nem essa pessoa lembra.
Um cenário hipotético, só para ilustrar. Um órgão contrata um sistema e, na última semana, recebe um documento extenso sobre a arquitetura. Dois meses depois, precisa mudar uma regra de cálculo. A equipe interna abre o documento e descobre que ele descreve o sistema como era no início. O que mudou ao longo da execução não está em lugar nenhum.
Há ainda um efeito de calendário. No encerramento, o fornecedor está fechando entregas, e a equipe do órgão está ocupada com a homologação. Ninguém tem tempo de aprender com calma.
Documentação viva em vez de relatório final
Documentação viva é a documentação de sistema que muda junto com ele. Ela é atualizada a cada ciclo, no mesmo ritmo em que o código evolui, e por isso nunca fica muito atrás da realidade. É assim que o repasse contínuo de conhecimento acontece sem depender de uma reunião final.
Na prática, quatro peças fazem a maior diferença:
- Decisões de arquitetura registradas. Um texto curto para cada escolha importante: o que foi decidido, quais alternativas existiam e por que aquela venceu.
- Instruções para subir o ambiente. O passo a passo que permite a outra pessoa colocar o sistema para rodar.
- Mapa de integrações. Com quais sistemas o seu conversa, por qual canal, com que dados e quem é o responsável do outro lado.
- Glossário do domínio. O significado dos termos do órgão como o sistema os usa. Um "processo" ou uma "unidade" pode ter sentido diferente em cada área.
O que o contrato deve prever sobre a entrega final do código, da documentação e dos acessos é assunto de outro texto: veja propriedade do código-fonte em contrato de software.
O que o órgão deve cobrar a cada ciclo
A tabela abaixo é boa prática de gestão, não obrigação legal. A exigência, quando existe, vem do edital e do contrato, e por isso vale escrevê-la lá.
| O que cobrar | O que evita |
|---|---|
| Documentação atualizada ao fim de cada ciclo | Um relatório final que descreve um sistema que já não existe |
| Registro das decisões tomadas no ciclo | Perder o motivo de uma escolha quando a pessoa que a fez sair do projeto |
| Relato do que foi entregue e do que ficou pendente | Descobrir só no encerramento o que nunca foi concluído |
| Um ponto focal técnico do fornecedor, com nome | Dúvida sem destinatário e conhecimento espalhado entre várias pessoas |
| Pessoa da equipe do órgão acompanhando as entregas | Aprender tudo de uma vez, na última semana |
| Ambiente reproduzível por quem não participou da construção | Um sistema que só roda na máquina de quem o fez |
No squad de TI da Evo Tech, por exemplo, cada ciclo termina com um relato do que foi entregue, do que ficou pendente e do que entra no ciclo seguinte, e o órgão conta com um ponto focal técnico. Para entender como o modelo funciona, veja o que é um squad de TI.
O papel do fiscal é conferir que isso acontece, ciclo após ciclo. Um registro por ciclo é fácil de verificar. Um relatório único no fim não é.
Como saber se a equipe interna consegue seguir sozinha
A pergunta não se responde com um termo de aceite. Responde-se com testes práticos, que podem ser feitos a qualquer momento da execução:
- Alterar algo pequeno sem ajuda. Alguém da equipe interna faz uma mudança simples, como o texto de uma tela ou uma regra de validação, e leva a alteração até o ambiente de teste sem acionar o fornecedor.
- Responder "por que está assim?" só com a documentação. Escolha uma regra de negócio ou uma integração e pergunte o motivo. Se a resposta só existe na cabeça de quem construiu, o registro está incompleto.
- Subir o ambiente a partir das instruções. Uma pessoa que não participou da construção segue o passo a passo e verifica se o sistema funciona.
- Localizar uma informação sem perguntar. Peça a alguém do órgão que encontre quem responde por uma integração ou onde está o histórico de uma decisão.
Se um teste falha, o melhor momento para descobrir é o meio do contrato, e não o fim. Registre o que faltou, peça a correção no ciclo seguinte e repita o teste. Cada falha encontrada cedo é uma lacuna que o fornecedor ainda tem prazo e equipe para fechar.
Nada disso elimina a necessidade de um fornecedor. Reduz o risco de que, no dia em que o contrato acabar, o órgão não saiba nem por onde começar.
Se a resposta é "não sei", vale fazer o teste agora, enquanto o contrato ainda está em andamento. Dá para começar pelo mais simples: pedir a documentação do último ciclo e verificar se alguém de dentro consegue usá-la.
Se o órgão está planejando uma contratação ou quer preparar a equipe interna para seguir com o sistema, a Evo Tech pode conversar sobre como organizar esse repasse desde o início. Conheça o trabalho com squad de TI e com sistemas sob medida.