A equipe comemora o fim do projeto, e o sistema entra no ar numa sexta-feira. Rolando Bonaccorsi, engenheiro de computação com MBA executivo, descreve em análise geral um intervalo comum: na segunda de manhã, os primeiros chamados chegam, e ninguém sabe ao certo quem deve respondê-los. É nesse espaço entre a entrega e a rotina que muitas organizações descobrem que concluir e sustentar não são a mesma coisa, mesmo quando o relatório de encerramento já foi recebido pela diretoria.
Um projeto tem começo, meio e fim, com escopo, prazo e orçamento definidos. Uma operação não tem data de término: ela precisa funcionar todos os dias, absorver mudanças, corrigir falhas e atender quem usa o sistema. Por isso, a equipe que desenha uma solução e a que a mantém costumam trabalhar com lógicas diferentes, e o ponto de encontro entre elas precisa ser planejado com a mesma seriedade do código ou da infraestrutura.
Onde termina o projeto e começa a operação?
O projeto termina quando o combinado foi entregue e aceito, mas a operação começa antes disso, ainda durante o desenho da solução. Em operações de tecnologia, perguntas como quem atende o usuário, quem monitora o sistema e quem decide sobre uma mudança precisam ter resposta antes da entrada em produção, que é o momento em que o sistema passa a ser usado de verdade pela empresa.
Quando essas respostas ficam para depois, a equipe do projeto segue sendo chamada para resolver problemas que já deveriam ser de outra área. Isso consome o tempo que deveria ir para o projeto seguinte e deixa a operação dependente de pessoas específicas, não de processos. Sob a perspectiva de Rolando Bonaccorsi, o desenho da sustentação faz parte do projeto, e tratá-lo como etapa posterior costuma transferir custo para a fase em que ele é mais caro de resolver.
Um sinal simples de que o desenho falhou é a frase informal de que só quem fez sabe consertar. Ela revela conhecimento concentrado numa ou duas pessoas, sem documentação viva, sem roteiros de atendimento e sem treinamento de quem vai assumir. Num caso assim, qualquer férias ou troca de equipe vira um risco para o serviço.
O que muda na passagem de bastão?
A passagem de bastão, nome dado à transferência de responsabilidade entre a equipe do projeto e a equipe de operação, funciona melhor como processo do que como reunião de despedida. Em equipes maduras, a transferência acontece em etapas: a operação acompanha a fase final do projeto, assume tarefas simples sob supervisão e só depois responde sozinha pelo ambiente. Cada etapa tem critério de aceite, e esse critério é o que separa a entrega formal da entrega real.
Conforme detalha Rolando Bonaccorsi, o material entregue precisa ser útil para quem vai atender a madrugada, e não apenas para quem aprova o projeto. Tudo isso significa roteiros claros de diagnóstico, lista de dependências entre sistemas, contatos de quem pode ser acionado e um registro dos problemas já conhecidos. Documentação que só descreve a arquitetura, sem dizer o que fazer quando algo falha, raramente é aberta quando mais se precisa dela.
Será que um bom manual basta? Não basta, porque o manual envelhece. Sistemas recebem atualizações, integrações mudam, e o que estava correto na entrega pode estar errado seis meses depois. Por isso, a revisão periódica do material é tarefa da operação, com dono definido e data marcada, como qualquer outra atividade recorrente.
Por que o sucesso de um projeto não garante a sustentação de uma operação?
O sucesso de um projeto costuma ser medido por prazo e orçamento, enquanto o de uma operação se mede pela experiência de quem usa o serviço. Indicadores de disponibilidade, tempo de resposta a chamados e taxa de problemas que voltam a ocorrer mostram se a sustentação funciona. Acordos de nível de serviço, conhecidos pela sigla SLA, formalizam o que se espera de cada indicador e dão às duas partes uma régua comum.
Como explica Rolando Bonaccorsi, o risco de qualquer indicador é virar fim em si mesmo. Uma equipe que apenas fecha chamados rapidamente pode estar escondendo uma causa que se repete toda semana, e o número bonito no painel não diz isso. Medir também a reincidência e a satisfação de quem pediu ajuda permite enxergar o que o tempo médio não mostra.
Há ainda o custo de manter. Em operações de tecnologia, o orçamento de sustentação aparece diluído em licenças, infraestrutura, pessoas e melhorias, e muitas empresas só o enxergam quando uma falha cobra a conta. Reservar uma verba própria desde o início evita que a operação dispute recursos com o próximo projeto e permite planejar atualizações com antecedência.
Quem sustenta o que foi entregue?
Sustentar uma operação é, antes de tudo, uma decisão de organização. Alguém precisa ser responsável pelo serviço, ter autoridade para priorizar correções e conversar com as áreas de negócio sobre o que muda. Em empresas em que essa figura não existe, o sistema passa a ser de todos e, na prática, de ninguém, e os problemas esperam por alguém que os assuma.
Para Rolando Bonaccorsi, a equipe de sustentação também precisa de espaço para melhorar o serviço, não só para apagar incêndios. Uma operação que gasta todo o tempo em chamados urgentes não consegue automatizar tarefas repetitivas, revisar processos nem preparar a equipe para o que vem. Reservar uma parte da capacidade para melhorias é o que impede o acúmulo de pequenos problemas que, juntos, viram uma falha grande.
Entregar bem continua sendo importante, e nenhuma operação se sustenta sobre um projeto mal feito. A diferença está em entender que o fim do projeto é o primeiro dia de uma responsabilidade mais longa, que merece planejamento, orçamento e gente com nome e função definidos desde o início, antes que o primeiro chamado chegue.
