Seu sistema funciona muito bem. Até que a pessoa que sabe por quê esteja trabalhando.
Imagine uma empresa que tem um sistema em funcionamento há sete anos. Ele foi criado em etapas. Primeiro, foi feito por uma software house. Depois, parte foi assumida por um freelancer. Mais tarde, outra equipe acrescentou um módulo B2B. A agência seguinte integrou o CRM. Alguém mais conectou os pagamentos.
O sistema funciona.
A empresa ganha dinheiro graças a ele.
Os funcionários o utilizam todos os dias.
Os clientes nem imaginam quantos processos acontecem nos bastidores.
Só há um problema.
Ninguém mais sabe exatamente como tudo isso funciona.
A documentação está parcialmente no Confluence. Algo ficou no Google Drive. Algumas informações estão em tickets. Uma integração foi descrita em um e-mail de quatro anos atrás.
E a coisa mais importante "acho que o Łukasz lembrava".
Só que o Łukasz saiu há três anos.
E durante três anos nada aconteceu.
Até certa manhã de terça-feira.
O sistema funciona. Então está tudo em ordem?
Esse é um dos estados mais traiçoeiros em que um sistema empresarial pode se encontrar.
Funciona.
Não há falhas.
Os usuários estão satisfeitos.
A equipe de vendas usa o aplicativo.
Os pedidos passam.
Os dados chegam ao CRM.
Os relatórios são gerados.
Então a reação natural é: Não mexamos. Para que fuçar em algo que funciona?
E, de fato, não há motivo para mudar um sistema funcional só porque é possível.
O problema é que o sistema pode ser tecnicamente estável e, ao mesmo tempo, muito instável do ponto de vista organizacional.
Ele pode funcionar hoje, mas ninguém sabe o que acontecerá quando for necessário trocar o servidor, o fornecedor da API, o domínio, a biblioteca, o método de autenticação ou uma parte do processo de negócio.
Ele pode ser eficiente, mas depender de uma única pessoa.
Ele pode ser seguro, mas ninguém saber onde estão todas as chaves de acesso.
Ele pode ser desenvolvido, mas apenas por alguém que conhece a história de todas as decisões.
E é justamente aqui que surge o conceito de bus factor.
Quantas pessoas podem desaparecer antes que o projeto comece a ter problemas?
Bus factor é um conceito muito simples, embora brutal.
Perguntamos: Quantas pessoas precisam deixar de estar disponíveis para que o projeto deixe de poder ser mantido de forma eficiente?
Se a resposta for: "Uma", temos um problema.
Se a resposta for: "Duas, mas ambas trabalham em outra empresa", temos um problema ainda maior.
É claro que não se trata de "desaparecimento" literal das pessoas.
Um programador pode sair da empresa.
Um freelancer pode encerrar a colaboração.
Uma software house pode deixar de atender o cliente.
Um administrador pode trocar de emprego.
A pessoa responsável por uma integração específica pode ir para outro departamento.
O detentor do conhecimento pode simplesmente adoecer ou ficar indisponível por algumas semanas.
Se, com ele, desaparece a capacidade de compreender o sistema, a empresa não tem um problema de pessoal.
Tem um problema de negócio.
O código nem sempre diz por que algo funciona
Alguém pode dizer: "Mas temos o código-fonte. Se precisar, um novo programador lê."
Em teoria, sim.
Na prática, o código responde principalmente à pergunta: como o sistema faz algo.
Nem sempre responde à pergunta: por que ele faz isso exatamente dessa forma.
E isso faz uma enorme diferença.
No código pode haver uma condição: "Se o cliente tiver um determinado tipo de conta, execute a operação X."
Um novo desenvolvedor pode encontrá-la.
Mas como ele vai saber o porquê?
Pode ser uma exigência de negócio.
Pode ser resquício de uma integração antiga.
Pode ser uma proteção contra um erro de uma API externa.
Pode ser uma solução temporária para um problema que existia há cinco anos.
Pode ser a solução para um caso incomum de um dos maiores clientes.
Pode estar ali por um ótimo motivo.
Ou por nenhum.
Sem contexto, é difícil avaliar.
Por isso, a documentação do sistema não deve se limitar a instruções:
"clique aqui, depois aqui".
A documentação mais valiosa muitas vezes descreve decisões e dependências, e não apenas o uso das funcionalidades.
O conhecimento mais perigoso é aquele que existe apenas na cabeça de alguém
As empresas muitas vezes têm documentação. Só que documentação nem sempre é a mesma coisa que conhecimento.
Podemos ter a descrição de uma API - mas não ter a informação de por que usamos justamente essa API.
Podemos ter instruções de implantação - mas não ter a lista de todos os locais em que a configuração precisa ser alterada.
Podemos ter a descrição da integração - mas não saber o que acontecerá quando o fornecedor externo mudar o método de autorização.
Podemos ter uma lista de servidores - mas não saber qual deles é crítico para um processo específico.
Podemos ter acesso ao repositório - mas não ter acesso à conta em que está a infraestrutura de produção.
São justamente esses elementos que podem transformar uma mudança aparentemente simples em uma investigação de vários dias.
A integração que funciona há cinco anos continua sendo uma dependência
Uma das áreas mais frequentemente ignoradas são os serviços externos;
- Pagamentos.
- SMS.
- E-mail.
- CRM.
- ERP.
- Mapas.
- Sistemas de entrega.
- Plataformas de marketing.
- Sistemas contábeis.
- Serviços de nuvem.
- APIs externas.
- Bibliotecas de código aberto.
Cada uma dessas coisas faz parte de um ecossistema maior.
Se o sistema usa dez serviços externos, não temos um único sistema. Temos um sistema mais dez dependências. E cada uma delas pode mudar.
O fornecedor pode alterar a API.
Pode encerrar o serviço.
Pode mudar o modelo de preços.
Pode descontinuar a versão antiga.
Pode introduzir novos requisitos de segurança.
Pode ser adquirido por outra empresa.
Por isso, também ganha importância o conhecimento sobre a origem dos componentes e as dependências de software. O NIST destaca, entre outros pontos, a importância do SBOM, ou Software Bill of Materials - uma lista formal dos componentes usados para construir o software. Esse inventário ajuda a entender do que o sistema é composto e a avaliar mais rapidamente o impacto de vulnerabilidades ou mudanças na cadeia de suprimentos.
Para o negócio, isso pode ser reduzido a uma pergunta muito simples:
Você sabe de que depende o seu sistema?
E agora imagine trocar a software house
Esse é um dos momentos em que todas as lacunas vêm à tona.
A empresa trabalhou durante anos com um único prestador. De repente, a parceria termina. Os motivos podem ser muitos; mudança de estratégia. mudança de orçamento. aquisição da agência. problemas organizacionais. falta de competências para o desenvolvimento contínuo. Ou simplesmente a empresa quer trabalhar com outro parceiro.
A nova software house pergunta:
"Onde está o repositório?" - Está.
"Onde está a infraestrutura?" - Está.
"Como fazemos o deploy em produção?" - "Não sabemos, era a equipa anterior que fazia isso."
"Como funciona a integração com o ERP?" - "Acho que por esse servidor."
"Quais são as nossas chaves API?" - "Devem estar no e-mail."
"Quais APIs são de produção?" - "Não sabemos."
"Quais processos são críticos?" - "Tem de perguntar ao Łukasz."
O Łukasz já não trabalha lá...
E é precisamente por isso que a transferência do projeto não é apenas a transferência do código. É preciso transferir também o conhecimento.
Documentação não é custo. É uma apólice
Em muitas empresas, a documentação é tratada como algo que se faz "quando houver tempo".
Ou seja, normalmente nunca.
Ou no fim do projeto.
Ou quando alguém perguntar.
Isso é um erro.
A documentação é um dos mecanismos que limitam o risco operacional. Não gera vendas diretamente. Não melhora a conversão. Não parece impressionante numa apresentação.
Mas numa situação de crise pode fazer a diferença entre: "vamos resolver isso hoje"
e: "primeiro precisamos de encontrar a pessoa que se lembra de como isto funcionava".
Nas novas diretrizes do NIST sobre planos de segurança, privacidade e gestão de risco da cadeia de abastecimento de software, documentar o objetivo do sistema, o seu estado, os controlos e a responsabilidade e comportamento das pessoas que o gerem é tratado como um elemento de gestão estruturada do sistema.
Isto mostra muito bem a mudança de mentalidade.
A documentação não é apenas uma ferramenta para o developer.
É um elemento da continuidade operacional da organização.
O que deve ser documentado?
Não se trata de criar documentação com 800 páginas que ninguém nunca vai abrir.
Uma boa documentação deve responder sobretudo às perguntas que surgirão quando algo mudar ou deixar de funcionar.
- Quem é o proprietário do sistema?
- Onde está o código?
- Onde está a produção?
- Como é o processo de deploy?
- Quais são os ambientes?
- Quais são as integrações críticas?
- De que serviços externos dependemos?
- Quem é o fornecedor deles?
- Que contratos e contas temos?
- Onde estão as chaves e os dados de acesso?
- Quem tem permissões?
- Como é o backup?
- Como é a recuperação do sistema?
- Que componentes open source são utilizados?
- Quais bibliotecas estão desatualizadas?
- Quais são as decisões arquitetónicas mais importantes?
- Quais elementos são críticos para o negócio?
- O que acontecerá se um determinado serviço externo deixar de funcionar?
Isto não é documentação "para programadores".
É um mapa das dependências do negócio em relação à tecnologia.
"Funciona, por isso não mexamos" pode ser uma estratégia. Mas é preciso conhecer o seu preço
Nem toda a empresa precisa de reconstruir um sistema antigo.
Nem todo o sistema legacy é mau.
Nem todo o código antigo precisa ser reescrito.
Pelo contrário - às vezes um sistema antigo e estável é uma solução muito melhor do que uma migração cara feita sem um motivo concreto.
O problema não é a idade do sistema.
O problema é a falta de conhecimento sobre o seu estado.
Se soubermos como o sistema funciona, quais dependências tem, onde estão os riscos e quem o consegue manter, podemos decidir conscientemente:
- mantemos,
- modernizamos,
- reescrevemos uma parte,
- migramos,
- ou não mexemos em nada.
Se não soubermos isso, a decisão "não mexer" não é uma estratégia.
É uma aposta.
Como é uma auditoria de um sistema herdado?
Quando um sistema existente chega a uma software house, o primeiro passo não deve ser: "Vamos reescrevê-lo." - Primeiro é preciso compreendê-lo.
Uma boa auditoria deve abranger, entre outros, a arquitetura da aplicação, o código-fonte, a base de dados, a infraestrutura, o processo de deploy, as dependências, as integrações, a segurança, o acesso aos serviços e a documentação.
Mas também é igualmente importante compreender o negócio;
- Quais processos são críticos?
- Quais funcionalidades são usadas diariamente?
- Quais módulos geram receita?
- Quais elementos podem ser desativados sem consequências?
- O que acontece quando uma determinada integração deixa de funcionar?
- Quais elementos são os mais arriscados?
Só depois de combinar a perspetiva técnica e a de negócio é que se pode dizer, o que realmente precisa de mudar.
A auditoria não precisa de terminar numa revolução
Às vezes o resultado da auditoria é surpreendentemente simples.
O sistema está em ordem, só é preciso:
- Completar a documentação.
- Organizar os acessos.
- Atualizar algumas bibliotecas.
- Transferir a propriedade das contas.
- Descrever o processo de deploy.
- Adicionar monitorização.
- Definir o backup.
- Introduzir uma segunda pessoa nas áreas que só um developer conhecia.
E de repente o bus factor muda de 1 para 3.
Não é preciso reescrever toda a aplicação.
Não é preciso deitar fora sete anos de trabalho.
Não é preciso construir tudo de novo.
Às vezes o maior problema não é a tecnologia.
É a falta de um mapa.
O sistema deve sobreviver às pessoas que o criaram
Esta talvez seja a regra mais importante: um bom sistema deve ser capaz de sobreviver à saída do developer.
Deve sobreviver à mudança de administrador.
Deve sobreviver à mudança de software house.
Deve sobreviver à reorganização da empresa.
Deve sobreviver a vários anos de desenvolvimento.
Isto não significa que cada programador tenha de compreender cada linha de código. Significa que o conhecimento crítico para o funcionamento do negócio não pode existir apenas na cabeça de uma única pessoa.
Porque um colaborador pode sair.
Um freelancer pode terminar a colaboração.
Uma agência pode desaparecer.
Um fornecedor pode alterar o serviço.
E a empresa ainda tem de funcionar.
A tecnologia deve ser propriedade da organização, não da memória de uma única pessoa
Isto é especialmente importante no caso de sistemas construídos ao longo de muitos anos.
Se a empresa paga pelo software, deve saber não só onde está o código.
Deve saber:
- o que possui,
- de que depende,
- quem tem acesso,
- quem o pode alterar,
- como pode ser implementado,
- como pode ser recuperado,
- como pode ser entregue a outra equipa.
O NIST, nos materiais atuais sobre due diligence de fornecedores, chama atenção, entre outros pontos, para a origem, a resiliência, as práticas de cibersegurança e as dependências na cadeia de abastecimento. Isso mostra uma direção mais ampla: as organizações cada vez mais devem saber não apenas quem forneceu o sistema, mas também de que o sistema é composto e quais riscos estão associados à sua manutenção.
Isto já não é apenas um tema para o departamento de TI.
É um tema de gestão de risco empresarial.
O pior momento para conhecer o seu sistema é uma falha
Pode-se dedicar alguns dias a uma auditoria.
Pode-se organizar a documentação.
Pode-se verificar as dependências.
Pode-se descrever a arquitetura.
Pode-se verificar os acessos.
Pode-se determinar quem é realmente responsável por cada área.
Pode-se reduzir o bus factor.
Ou pode-se esperar.
Até o momento em que o sistema deixar de funcionar.
Então, as perguntas serão exatamente as mesmas.
Só que a pressão será maior, os utilizadores estarão à espera, as vendas podem parar e cada hora vai custar dinheiro.
Por isso vale a pena fazer uma pergunta a si mesmo antes que surja um problema: Se amanhã desaparecesse a pessoa que melhor conhece o seu sistema, ainda saberíamos como mantê-lo?
Se a resposta for "não", isso ainda não significa que o sistema seja mau.
Significa que a empresa tem um risco oculto que até agora não precisou de acionar.
Na Web24, assumimos não só o código
Assumir um projeto existente é um trabalho completamente diferente de começar um novo sistema do zero.
Primeiro é preciso compreender o que já existe.
O que funciona.
O que é crítico.
O que é uma dependência.
O que é um problema.
O que é apenas o resquício de decisões anteriores.
E, acima de tudo, onde está o conhecimento sem o qual o sistema não pode ser desenvolvido com segurança.
Só então se podem planear as próximas ações.
Às vezes será modernização.
Às vezes crescimento.
Às vezes a organização da infraestrutura.
Às vezes a assunção da manutenção.
E, por vezes, simplesmente a criação de um bom mapa do sistema, que durante anos ninguém teve tempo de preparar.
Porque uma software house responsável não deve construir tecnologia que só funciona quando a pessoa certa está sentada ao computador.
O sistema deve ser maior do que a memória de uma única pessoa.
E a empresa deve ter a certeza de que, quando alguém sair, a tecnologia não sai com essa pessoa.
