Tenho participado em implantações de software em empresas e com certa frequência ouço o usuário reclamar sobre a ferramenta implantada. A principal aponta para a não solução do problema.
Uma única questão paira no ar: Se o objetivo da ferramenta proposta é exclusivamente resolver uma questão, porquê ele fica sem resposta após muito tempo dedicado em análise, planejamento, desenvolvimento, treinamento e outras tarefas?
Isso não tem sido visto apenas em empresas sem processos definidos ou falta de profissionais devidamente capacitados, mas em muitas empresas de diversos tamanhos e com expressividade no mercado em maior ou menor grau de agravo.
Na mesma linha de raciocínio vemos profissionais de análise bem preparados nas técnicas de análise de requisitos e também equipes de desenvolvimento capacitadas e por dentro da documentação elaborada pela equipe de análise.
Estamos no caminho, porém não mitigamos todas as questões ainda.
Antes de qualquer coisa devemos recordar o objetivo macro ao decidirmos desenvolver uma ferramenta para uma organização. Esse objetivo está obrigado a alinhar-se com a missão da empresa, os objetivos globais do negócio para a partir daí prosseguir com os trabalhos.
Vou exemplificar o anteriormente exposto.
Uma empresa decide desenvolver dentro de um módulo de vendas um vínculo com o módulo de processo de produção para sugestão de vendas baseado nas quantidades produzidas, pois a variação do volume de insumos empregados na produção é díspar e influi diretamente no preço final e por serem produtos específicos não são elaborados mais de uma vez, todo projeto é um produto novo.
Essa é a regra de negócio baseada na missão da empresa: “Atender cada projeto único no menor prazo e melhor custo...”.
Nesse universo imagine a possibilidade do usuário da ferramenta e o analista não estarem alinhados à regra e a missão, o que não é impossível, visto a proximidade do usuário da tarefa e desta forma não deve ter toda a visão exposta aqui.
O gestor do negócio muitas vezes não se envolve no projeto como deveria e por esta causa o analista não dispõe de subsídio suficiente para levantar todos esses requisitos e por consequência deixar algo para trás.
Em decorrência a isso é possível deixar uma informação pelo caminho, não rastrear adequadamente um requisito e isso não ser informado na documentação para o desenvolvedor.
Por sua vez um documento pouco preciso dá brecha para o desenvolvedor utilizar a imaginação e achar a necessidade de um campo novo e isso pode modificar o escopo do projeto, ou seja, entregar algo que não será útil.
Desta forma a insistência esta em manter coerência entre a regra de negocio, as necessidades do usuário, acompanhar os requisitos e transmitir tudo isso de forma clara e adequada ao desenvolvedor para que ele possa entregar exatamente o programado sem mais e nem menos.
