Gerir um projecto de software em Angola: governação, aceitação e conformidade

Os projectos de software em Angola raramente falham por razões técnicas. Falham porque ninguém conseguia decidir, porque "concluído" nunca foi definido, ou porque o sistema chegou ao fim da construção e só então alguém perguntou como é que aquilo responde à ANPG.

Este artigo trata da parte que não é código: quem decide, o que conta como entregue, e que obrigações angolanas têm de entrar no plano desde o primeiro dia em vez de no último.

Decidir quem decide, antes de começar

A causa mais comum de derrapagem não é o âmbito — é o tempo de espera por decisões. Uma equipa que espera nove dias por uma resposta perde nove dias, e o custo é o mesmo quer esteja a construir quer esteja parada.

Defina três papéis por escrito antes do arranque:

• Patrocinador. Uma pessoa, com orçamento, que decide sobre alterações de âmbito. Não um comité.
• Dono do produto. Uma pessoa que responde a perguntas de detalhe em vinte e quatro horas e tem autoridade para o fazer sem escalar.
• Aprovador técnico do lado do cliente. Quem valida integrações, acessos e decisões de infra-estrutura.

Escreva também o prazo máximo de resposta e o que acontece quando é ultrapassado. A regra que funciona: passado o prazo, a equipa avança com a interpretação documentada e a alteração posterior conta como novo âmbito. Isto parece duro até à primeira vez que evita três semanas de paragem.

Definir "concluído" antes de construir

"Está pronto" é a frase que origina mais disputas em projectos de software. A prevenção é um critério de aceitação escrito por funcionalidade, acordado antes de a construção começar, e que inclua sempre estes quatro pontos:

1. Funciona com dados realistas — não com três registos de exemplo.

2. Os perfis de acesso foram testados, incluindo o caso de alguém que não deve ver aquilo.

3. O comportamento em erro está definido. O que acontece quando o serviço externo não responde, quando a rede cai a meio, quando o ficheiro está malformado.

4. Há evidência de teste entregue com a funcionalidade, não prometida para depois.

Num sistema regulado acrescente um quinto: o lançamento contabilístico ou o registo de conformidade resultante foi verificado, e não apenas o ecrã.

As obrigações angolanas entram no plano no início

Este é o erro que custa mais caro e é o mais fácil de evitar. Fiscalidade e conformidade não são uma fase final — são requisitos estruturais que determinam o modelo de dados.

Traga para a fase de desenho:

• Regras fiscais com data de efeito. IVA, retenções e limiares de aprovação têm de ser configuração com início e fim de vigência, para que um documento seja sempre calculado com a regra da sua data. Retrofitar isto depois significa reescrever o modelo de dados. Escrevemos sobre a mecânica em regras fiscais com configuração datada.
• [SAF-T](https://wise-hustlers.com/blog/saf-t-angola-ficheiro-contabilistico-erp-energia) a partir da mesma fonte que o reporte interno. Se for um processo separado, criou duas verdades contabilísticas.
• [Facturação electrónica](https://wise-hustlers.com/blog/facturacao-electronica-angola-2026-erp-petroleo-gas) e o estado de certificação junto da AGT, confirmado por escrito e não assumido.
• [Conteúdo local e reporte à ANPG](https://wise-hustlers.com/blog/conteudo-local-angola-anpg-software-conformidade), se operar no sector petrolífero. A qualificação de fornecedores deve ser calculada pelo sistema e auditável, não montada numa folha de cálculo antes de cada entrega.
• Multi-moeda. Kwanza e USD com taxa, fonte da taxa e data da taxa registadas em cada movimento.

A pergunta de controlo, feita ao fim da primeira semana de desenho: se a taxa de IVA mudar daqui a dezoito meses, o que é preciso fazer? Se a resposta envolver uma nova versão da aplicação, o desenho está errado e ainda está a tempo.

Controlo de alterações que não paralisa

Um processo de alterações demasiado rígido faz com que as pessoas o contornem; demasiado frouxo e o âmbito duplica sem ninguém decidir. O equilíbrio prático:

• Alterações dentro do critério de aceitação acordado: a equipa decide, regista e avança.
• Alterações que mudam o critério de aceitação: pedido escrito, estimativa de impacto em dias, decisão do patrocinador em quarenta e oito horas.
• Alterações que afectam conformidade ou contabilidade: nunca decididas apenas pela equipa técnica. Exigem o responsável financeiro ou fiscal, porque o custo de uma decisão errada aqui não é um atraso, é uma correcção retroactiva.

Mantenha um registo único de alterações com data, decisor e impacto. Não pela burocracia — porque daqui a um ano alguém vai perguntar porque é que o sistema faz uma coisa aparentemente estranha, e a resposta tem de existir.

Trabalhar com uma equipa distribuída

Boa parte dos projectos angolanos envolve equipas em fusos e locais diferentes. Três hábitos resolvem a maior parte do atrito:

Escreva as decisões, não só as discuta. Uma decisão que existe apenas numa chamada não existe. Um parágrafo escrito depois de cada reunião de decisão poupa semanas.

Sobreponha horas deliberadamente. Não é preciso um dia inteiro em comum; são precisas duas ou três horas fiáveis em que se consegue resolver algo em tempo real.

Demonstre com frequência. Uma demonstração de quinze minutos a cada duas semanas apanha mal-entendidos enquanto ainda são baratos. Um projecto que só demonstra no fim descobre o desalinhamento quando corrigi-lo custa mais.

Tenha ainda em conta a realidade da largura de banda. Se há utilizadores em campo, em plataformas ou em zonas remotas, a sincronização offline-first é um requisito de produto e tem de estar no plano desde o início.

A entrega, planeada desde o início

A transição não é um evento no último dia. Comece a prepará-la a meio do projecto:

• Formação por papel, não uma sessão única para toda a gente. Quem lança facturas precisa de algo diferente de quem aprova requisições.
• Documentação de operação — o que fazer quando algo falha, quem contactar, como restaurar.
• Credenciais e repositórios transferidos e verificados, não prometidos.
• Um exercício de recuperação, executado de verdade. Um plano de recuperação por testar é uma suposição.
• Um período de acompanhamento definido em dias, com âmbito claro do que está incluído.

O sinal de aviso mais útil

Se, a meio do projecto, ninguém do lado do cliente consegue responder à pergunta "o que é que este sistema tem de provar a um auditor?", o projecto tem um problema de governação independentemente de quão bem esteja a correr a construção.

Num sistema industrial ou regulado, a cadeia que interessa vai do negócio ao activo, à operação, ao material, à transacção, à aprovação, ao lançamento contabilístico, à conformidade, ao relatório e ao registo de auditoria. Cada módulo tem de preservar essa cadeia. É o que permite responder, meses depois, como é que um barril medido num tanque se tornou uma linha numa declaração fiscal.

Se quiser discutir como estruturar a governação de um projecto deste tipo, é este o nosso trabalho. As perguntas a fazer a qualquer fornecedor — incluindo a nós — estão em como escolher um parceiro de software em Angola.