Como decorre um projeto de software, da proposta à entrega

Uma das primeiras perguntas de uma organização que quer encomendar software é como vai decorrer o processo. Quando vão ver o quê, o que se espera delas, quando se considera o trabalho concluído.

Neste artigo explico as etapas por que passa um projeto, da primeira reunião à manutenção. As etapas não têm a mesma duração em todos os projetos. Num trabalho pequeno, várias cabem numa só reunião. Mas nenhuma é saltada, porque a etapa saltada volta no fim do projeto sob a forma de surpresa.

Primeira reunião

Na primeira reunião não falamos de preço. Tentamos perceber o que se pretende, como funciona hoje o trabalho e o que precisa de mudar. Quem vai usar o sistema, que dados vai tratar, com que sistemas vai comunicar.

No fim desta reunião, às vezes dizemos que não é preciso software à medida. Se um produto pronto resolve o problema, dizê-lo logo no início poupa o tempo de todos.

Descoberta

Se a necessidade não está clara, propomos uma curta fase de descoberta. Alguns workshops, uma análise dos sistemas e dados existentes, o levantamento do fluxo de trabalho passo a passo. O resultado da descoberta é um documento escrito: âmbito, perfis de utilizador, integrações, dados, riscos conhecidos e incógnitas.

É a fase mais barata do projeto e a que mais dinheiro poupa. Corrigir uma necessidade mal compreendida num documento é muito mais fácil do que corrigi-la no código.

Proposta

A proposta baseia-se no documento de descoberta. Para cada pacote de trabalho fica escrito o que será feito, quanto tempo leva, o que se espera da organização e segundo que critério será aceite. O que fica fora do âmbito também fica escrito. É aqui que se define com quem ficam o código-fonte e os direitos de propriedade intelectual e como funcionará a manutenção.

Conceção

Antes de escrever código, concebemos o modelo de dados, a estrutura de permissões e os ecrãs principais. Mostramos os esboços dos ecrãs aos utilizadores reais da organização. As objeções que surgem nesta fase são muito mais baratas do que as que surgem depois.

Se vão ser tratados dados pessoais, também se decide nesta fase que dados são recolhidos e porquê, quem os pode ver e durante quanto tempo são conservados. Não são funcionalidades a acrescentar depois, fazem parte da arquitetura.

Desenvolvimento

Conduzimos o desenvolvimento em ciclos curtos. No fim de cada ciclo, a organização vê uma versão a funcionar no ambiente de testes. Se algo foi mal compreendido, nota-se em poucas semanas.

A cada alteração correm testes automáticos. Se um teste falha, essa versão não avança. Contámos como fazemos isto no nosso próprio site num artigo à parte.

Testes e aceitação

A aceitação faz-se segundo os critérios escritos na proposta. Para cada funcionalidade, critérios concretos do tipo «nesta situação dá este resultado». A organização experimenta estes critérios com os seus próprios dados, os pontos que não cumprem são registados e corrigidos.

Quando os critérios de aceitação não estão escritos, a discussão sobre «funciona?» é inevitável. Explicámos porquê no artigo sobre critérios de aceitação.

Entrada em produção

A entrada em produção não é um dia, é um pequeno plano. Se há dados a migrar do sistema antigo, as migrações de ensaio fazem-se antes. Fica escrito como voltar atrás se algo correr mal. Os utilizadores recebem uma formação curta e, nas primeiras semanas, as perguntas têm resposta rápida.

Manutenção

Depois da entrega continuam as atualizações de segurança, as atualizações de infraestrutura e pequenas melhorias. O âmbito da manutenção e o prazo para tratar um problema ficam por escrito na fase de proposta.

O código-fonte, a documentação e os passos de implementação são entregues à organização. Assim, se um dia quiser continuar com outra equipa, pode fazê-lo.

O papel da organização

Em todas estas etapas é preciso um interlocutor do lado da organização. Alguém que conheça o fluxo de trabalho, responda às perguntas em pouco tempo e possa experimentar as versões intermédias. O que abranda os projetos muitas vezes não é um problema técnico, é a falta deste interlocutor.

Em resumo

Primeira reunião, descoberta, proposta, conceção, desenvolvimento, aceitação, entrada em produção e manutenção. As etapas encurtam ou alongam consoante a dimensão do projeto, mas nenhuma é saltada. Ter por escrito o que se entrega no fim de cada etapa evita surpresas no fim do projeto.