O que deve incluir a primeira versão do seu software empresarial?

Para a primeira versão, escolha uma tarefa que alguém consiga concluir. Inclua também o que permite terminá-la quando um dado está errado, um colega está ausente ou o sistema precisa de apoio.

Imagine uma segunda-feira de manhã: alguém abre o software, faz um trabalho útil e deixa um resultado em que a pessoa seguinte pode confiar.

Defina onde o trabalho começa e acaba

Imagine uma empresa de manutenção fictícia a criar um sistema de ordens de trabalho. Os primeiros utilizadores serão a pessoa que coordena o trabalho no escritório e uma equipa de manutenção. A pessoa responsável pela coordenação regista uma tarefa e atribui-a; a equipa regista o que fez. Depois, a coordenação verifica o resultado e fecha a ordem.

Isto pode ser uma primeira versão útil. «Um ecrã de ordens de trabalho» diz muito menos. A equipa consegue ver a atribuição? Alguém a pode corrigir? O que significa uma ordem estar fechada?

Defina as pessoas e o resultado antes de decidir quantos ecrãs criar. Um fluxo de trabalho completo pode exigir vários ecrãs e perfis. A contagem de ecrãs pouco diz sobre a possibilidade de usar o software no trabalho.

O guia do Governo britânico sobre a fase beta descreve a criação e o teste de um serviço que responde às necessidades dos utilizadores, incluindo o percurso completo e as pessoas que lhe dão apoio. O processo de entrega governamental tem requisitos próprios. Para esta empresa de manutenção, a pergunta útil é se o grupo escolhido consegue levar uma ordem até ao fim.

Inclua as dificuldades nesse âmbito

No nosso exemplo fictício, a pessoa responsável pela coordenação atribui uma ordem à equipa errada. A equipa apercebe-se antes de sair das instalações. Alguém tem de corrigir a atribuição, e as duas equipas precisam de ver qual é a versão atual. Deixar a correção para mais tarde abriria uma falha no trabalho que se comprometeu a apoiar.

Percorra o trabalho proposto com quem o executa. Pergunte quem pode criar, alterar, atribuir e fechar uma ordem, e quem pode ver a informação. Decida o que acontece quando o trabalho não pode ser concluído: talvez não haja acesso ao edifício ou seja necessário encomendar uma peça. A ordem precisa de um estado seguinte acordado e de uma pessoa responsável.

A segunda coluna depende da empresa. Se uma ordem só puder ser considerada concluída depois de emitida uma fatura, decida como isso acontece na primeira versão. Uma passagem acordada para o processo de faturação existente pode ser suficiente. Omitir esse passo sem o explicitar deixa a equipa descobrir a falha mais tarde.

Inclua o que mantém o trabalho a funcionar

A equipa vai precisar de dados reais das ordens. Decida que registos existentes têm de ser importados, quem os verifica e como são corrigidos os erros. Uma importação não se torna dispensável por não ter um ecrã apelativo.

Acorde quem cria e remove contas, responde às dúvidas do pessoal, investiga falhas e cuida do serviço. Inclua a ajuda ou as instruções de que o primeiro grupo precisa. Verifique o que acontece se o serviço ficar indisponível e como se pode recuperar a informação relevante.

O relato da Google sobre a transferência da responsabilidade operacional aborda verificações de preparação, documentação e formação. Descreve o contexto da própria Google, não uma estrutura de equipa obrigatória para uma pequena empresa. A ideia prática aqui é identificar quem vai operar e apoiar a primeira versão e garantir que tem o necessário.

Teste as incertezas antes de assumir o lançamento

Um protótipo pode ajudar a perceber se a pessoa responsável pela coordenação entende um ecrã de atribuições ou se a equipa consegue registar uma visita no telemóvel. Indique o que ele pode demonstrar. Uma demonstração convincente pode usar dados inventados e omitir permissões, armazenamento ou recuperação.

Antes de aprovar a utilização em produção, acorde que provas são necessárias para a versão real. No nosso exemplo, isso inclui testar uma ordem normal e outra atribuída à equipa errada, com os perfis previstos, num ambiente de teste separado. Confirme que uma equipa não consegue ver trabalho que não lhe diz respeito, que as correções chegam às pessoas certas e que o trabalho por concluir continua visível.

Escolha verificações adicionais de acordo com os riscos do sistema: registos importados, alterações simultâneas, recuperação após falhas ou volume de trabalho que tem de suportar. Uma única execução bem-sucedida não resolve todas estas questões. Atribua um responsável aos riscos por resolver e decida o que tem de estar resolvido antes de o pessoal depender do serviço.

Registe a versão que vai aprovar

O âmbito de uma primeira versão útil para a empresa de manutenção poderia ser:

• Pessoas: quem coordena e uma equipa de manutenção identificada.
• Trabalho: desde o registo de uma ordem até à conclusão acordada ou a um motivo explicitamente registado para continuar aberta.
• Apoio essencial: acesso por perfil, correções, registos iniciais necessários, ajuda ao pessoal e medidas de operação e recuperação.
• Provas de aceitação: os casos normais e difíceis acordados, mais verificações dos riscos identificados.
• Decisões em aberto: pessoas designadas para as responder antes de se aprovar o trabalho afetado.
• Para mais tarde: autosserviço para clientes, planeamento de rotas e faturação automática, sujeitos à passagem acordada para os processos existentes.

Reveja este âmbito com o pessoal, com quem é responsável pelo processo da empresa e com quem cria e opera o software. Todos devem conseguir explicar o que esta versão cobre e o destino do restante trabalho.

Criamos software empresarial à medida. Se quiser falar connosco sobre uma primeira versão, traga a tarefa que as pessoas precisam de concluir, o grupo que a vai usar e os pontos sobre os quais tem dúvidas. O âmbito, a entrega e o acompanhamento contínuo são acordados para cada projeto.

Perguntas sobre uma primeira versão de software