Depois de selecionar a plataforma de ERP que você acha que pode se adequar melhor à sua empresa, seria bom que o cliente preparasse um documento o mais bem explicado possível, um documento de requisitos. Na qual detalha o que espera que o ERP ou software de gestão faça, ele basicamente escreve “uma carta aos sábios”. Incluindo cada departamento da empresa (Compras, Vendas, Comercial, Produção, Qualidade, RH, etc.).
Dependendo do parceiro, este documento de requisitos torna-se mais detalhado ou mais genérico. A partir daqui, o parceiro de implementação realiza uma análise desses requisitos para iniciar o gerenciamento do projeto. Abaixo explicaremos o que consideramos que uma boa análise de requisitos por parte do parceiro deve se basear.
O que consideramos uma análise de requisitos ruim?
Análises excessivamente detalhadas são análises de trapaça. Neste caso basicamente o parceiro detalha com extrema precisão o que o software vai fazer, detalhando as tabelas e campos do banco de dados. Relacionamentos entre tabelas e telas de detalhamento.
São análises que levam muito tempo para serem escritas, às vezes até um ano. Eles têm muitas páginas, chegando a mais de 1.000 em muitas ocasiões. Em termos de imagem, parece muito bom e é muito profissional. Mas, em nossa opinião, eles são análises de trapaças. Eles são feitos assim porque no momento da implementação ou entregas, se deixamos de lado alguma coisa, algum campo ou algum desenvolvimento, eles virão até nós com a frase típica. “Isso não está na análise que fizemos, para fazer você terá que pagar a mais.” Cuidado com a análise de requisitos de armadilhas.
O que consideramos uma boa análise de requisitos?
As análises devem ser genéricas sem chegar a detalhes excessivos por parte de ambos, Especificando o que queremos que o software faça, incluindo documentos impressos Que têm um papel no circuito e podemos até nos ajudar com uma captura de tela para Esclarecer quais processos queremos que o software faça. Quando for validado por ambas as partes, a programação e a entrega prosseguem (explicaremos em blogs futuros). O cliente revisa o desenvolvimento e propõe suas
melhorias. Por parte do implementador eles são programados e a entrega é feita novamente. Pela segunda vez o cliente verifica novamente e indica novas melhorias ou alterações. (às vezes esta segunda revisão não é necessária). 2 revisões devem ser suficientes para fechar o desenvolvimento. Trabalhando desta forma não encontraremos surpresas ou a frase “isso não estava na análise”, já que escrevemos a análise em um nível genérico.