O projeto acabou. Quem responde pelo sistema agora?
O sistema precisa continuar funcionando depois que o projeto termina.
Se a sua operação depende de sistemas que acumulam regras, integrações e decisões ao longo do tempo, vale olhar para ownership, arquitetura e evolução como partes do mesmo problema.
Fale conosco
/fale-conosco
Conheça nossos serviços
/servicos
site/nucleop-com/article/01/o-projeto-acabou-quem-responde-pelo-sistema-agora/article-cover.png
8
66aece4c-a7ed-4cce-9ac8-529c2f122c90
Implantar um sistema encerra uma etapa. Quando ele passa a sustentar processos, regras e decisões da empresa, começa outra responsabilidade.
Newsletter
Um projeto de software pode terminar numa sexta-feira.
O sistema implantado por ele talvez continue funcionando durante oito anos.
Essa diferença parece óbvia até observarmos como muitas empresas administram seus sistemas internos. Existe orçamento para construir, cronograma para implantar, equipe para homologar, responsável pela entrega e uma data para encerrar o projeto.
Depois do go-live, essa estrutura começa a desaparecer.
A consultoria reduz a equipe. O projeto sai do portfólio. O patrocinador executivo volta a cuidar de outros assuntos. Desenvolvedores seguem para novas iniciativas. O backlog que sobrou perde prioridade.
Mas o sistema continua ali.
Continua executando regras de negócio, armazenando dados, concedendo acessos, integrando áreas, bloqueando operações inválidas e influenciando a forma como pessoas trabalham.
O projeto terminou.
A responsabilidade criada por ele, não.
Projeto e sistema têm ciclos de vida diferentes
Projetos existem justamente porque são temporários. Há um objetivo definido, algum tipo de escopo, recursos alocados e um momento em que aquela iniciativa deixa de existir como projeto.
Isso funciona bem para organizar uma implantação.
O problema começa quando usamos a mesma lógica para administrar aquilo que foi implantado.
Um sistema corporativo não permanece congelado depois da entrega.
A empresa muda preços, produtos, políticas, responsabilidades e processos. Pessoas entram e saem. Sistemas vizinhos são substituídos. Integrações mudam. Regras de segurança evoluem. Componentes técnicos envelhecem. Dependências recebem novas versões ou deixam de ser suportadas.
Mesmo que ninguém peça uma nova funcionalidade, o contexto ao redor do software continua mudando.
Portanto, “não estamos desenvolvendo nada nele” não significa que não existam decisões a tomar.
Significa apenas que essas decisões provavelmente estão acontecendo em outro lugar.
E talvez sem alguém enxergando o conjunto.
O vazio aparece depois que tudo aparentemente deu certo
Esse problema é mais difícil de perceber justamente quando a implantação funciona.
O sistema entra em produção, as pessoas começam a utilizá-lo e os chamados iniciais diminuem. A organização interpreta estabilidade como ausência de trabalho.
Durante algum tempo, isso pode ser verdade.
Até surgir uma mudança aparentemente pequena.
O financeiro precisa alterar uma regra. Uma nova área deve acessar determinadas informações. Outro sistema precisa consumir um dado que originalmente não seria compartilhado. Um componente técnico precisa ser atualizado. Uma exceção operacional vira recorrente.
Cada demanda isolada parece simples.
Mas cada uma também contém uma decisão sobre o sistema.
Quem pode mudar aquela regra?
Qual área define seu comportamento correto?
Uma alteração local pode afetar outro processo?
Quem decide se a solução deve entrar no sistema, no processo ou em outra ferramenta?
Quem conhece as dependências técnicas?
Quem responde quando duas áreas querem comportamentos incompatíveis?
Quando essas respostas não existem, o sistema começa a ser governado pela sequência das solicitações.
Quem pede primeiro ganha prioridade. Quem conhece alguém da TI consegue uma mudança. Quem sente mais dor pressiona mais. Quem conhece o sistema há mais tempo se transforma informalmente na pessoa que “sabe como funciona”.
Não existe ausência de governança.
Existe governança acidental.
Manter software não é o mesmo que responder por ele
É comum tentar resolver esse vazio atribuindo o sistema à equipe que faz manutenção.
Isso resolve apenas parte do problema.
Uma equipe técnica pode corrigir uma falha, atualizar uma biblioteca ou implementar uma mudança. Isso não significa que ela possa decidir qual regra de negócio deve prevalecer quando duas áreas discordam.
Da mesma forma, a área usuária pode conhecer profundamente sua operação sem possuir condições de avaliar o impacto de uma mudança sobre arquitetura, segurança, dados ou integrações.
Responsabilidade sobre um sistema corporativo não é uma única atividade.
Existem decisões de negócio, produto, operação e tecnologia convivendo dentro do mesmo ativo.
O erro é imaginar que colocar o nome de uma pessoa numa planilha resolve isso.
Ownership não significa fazer tudo. Significa garantir que as decisões relevantes tenham responsáveis identificáveis e que os conflitos entre essas decisões encontrem um lugar para serem resolvidos.
Pode haver vários responsáveis especializados.
O que não deveria existir é uma zona em que todos podem pedir mudanças, mas ninguém responde pelo efeito acumulado delas.
Sistemas envelhecem também pelas decisões pequenas
Software raramente se torna difícil de manter por causa de uma única decisão desastrosa.
O desgaste costuma ser incremental.
Uma exceção é adicionada porque um cliente importante precisa dela. Uma integração provisória permanece porque substituí-la não entrou no orçamento. Uma regra antiga continua ativa porque ninguém sabe se ainda é utilizada. Um acesso adicional é concedido para resolver uma urgência. Um relatório começa a servir como entrada manual de outro processo.
Individualmente, cada escolha pode ser defensável.
O problema aparece quando ninguém possui responsabilidade suficiente para observar o conjunto dessas escolhas ao longo do tempo.
O sistema continua funcionando.
Mas passa a carregar camadas de decisões que foram tomadas sob contextos diferentes.
É assim que algo tecnicamente saudável pode começar a se tornar operacionalmente difícil.
Não porque o código necessariamente ficou ruim.
Porque ninguém está administrando a coerência do sistema ao longo de sua vida.
Nem todo sistema precisa de uma estrutura de produto
O problema também não se resolve tratando toda aplicação interna como produto estratégico.
Seria trocar um vazio por burocracia.
Uma aplicação pequena, estável, com baixa criticidade e poucas mudanças pode funcionar muito bem com uma responsabilidade operacional simples.
Outro sistema pode exigir acompanhamento técnico mais próximo porque concentra integrações importantes.
Um terceiro pode ser central para a operação e precisar de decisões contínuas sobre regras, prioridades, experiência, segurança e evolução.
A estrutura deve acompanhar o papel que o sistema exerce.
Não seu tamanho aparente.
Uma aplicação com três telas pode ser muito mais crítica do que uma plataforma com dezenas de módulos se aquelas três telas controlarem uma etapa sem a qual a empresa não consegue faturar.
O critério relevante é dependência.
Quanto mais a organização depende daquele software para executar sua operação, maior precisa ser a clareza sobre quem responde por suas decisões.
Cinco perguntas revelam rapidamente o problema
Uma empresa não precisa começar criando cargos ou comitês. Antes disso, basta verificar se consegue responder algumas perguntas básicas:
- Quem decide quais regras de negócio aquele sistema deve representar?
- Quem prioriza mudanças quando diferentes áreas competem pela mesma capacidade?
- Quem acompanha riscos técnicos, segurança, dependências e obsolescência?
- Quem conhece os efeitos de uma alteração sobre dados, processos e sistemas integrados?
- Quem pode decidir que uma funcionalidade, integração ou até o próprio sistema não deveria mais existir?
Se as respostas mudam dependendo de quem é perguntado, existe um problema.
Se todas as respostas apontam para “a TI”, provavelmente existe outro.
E se ninguém sabe responder porque “o projeto já terminou”, o ciclo de vida do sistema está sendo confundido com o ciclo de vida da iniciativa que o criou.
O verdadeiro encerramento vem muito depois
Um projeto pode terminar quando sua entrega foi concluída.
Um sistema só encerra seu ciclo quando deixa de cumprir uma função para a empresa, suas dependências foram tratadas, seus dados tiveram destino definido e a operação já não depende dele.
Entre esses dois momentos pode existir uma distância de muitos anos.
É nessa distância que mora a responsabilidade menos visível.
Construir software cria mais do que uma aplicação. Pode criar uma nova dependência operacional, novas regras, novos dados, novas integrações e novas decisões que continuarão existindo depois que a equipe de projeto desaparecer.
Por isso, uma pergunta deveria fazer parte do encerramento de qualquer iniciativa que coloca um sistema relevante em produção:
Quem passa a responder por aquilo que acabamos de tornar permanente?
Se a organização só descobre essa resposta quando surge o primeiro problema sério, o projeto pode até ter terminado com sucesso.
A transição para a operação, não.
site/nucleop-com/article/01/o-projeto-acabou-quem-responde-pelo-sistema-agora/article-cta.png
Seu sistema virou parte da operação?
Quero receber
Veja como podemos ajudar
Quando uma aplicação passa a concentrar regras, dados, permissões e decisões, ela precisa ser tratada como parte da capacidade operacional da empresa, não como um projeto encerrado.
A Núcleo P desenvolve e evolui sistemas sob medida a partir do processo real, com atenção a regras, integrações, rastreabilidade e continuidade.
Receba artigos e análises sobre sistemas, tecnologia, gestão e estratégia, com foco em problemas reais, critérios de decisão e consequências para a operação e o negócio.