Desenvolvimento de Software e o StakeHolder do projeto, ou a falta dele.

O título deste Post é  recorrente nas rodas de profissionais na nossa área. Sempre algum colega afirma: “não estou feliz”. Meu projeto não anda. Cada pessoa da empresa tem uma ideia sobre o mesmo. Não sei se já passou isso pela sua cabeça.

Eu costumo dizer que trabalhar com produção de software é uma tarefa de Hércules.

Mas se você observar, fazer sistemas não é um bicho de sete cabeças. Cada profissão tem suas “complexidades”. Não significa que o que é complexo é difícil. Complexidade e dificuldade são coisas diferentes.

Em minha opinião, as maiores dificuldades para nós, profissionais que produzem software – seja como Analistas de requisitos, Analistas de Sistema, Programadores, Arquitetos de Software, Engenheiro de Software, Programador ou Analistas de Testes – não é o software que precisamos produzir, mas sim, as dificuldades do ambiente em que estamos inseridos.

O problema é fazer software com prazos irreais que geram  projetos sempre atrasados, desentendimentos intermináveis sobre escopo (tem sistemas que começam com escopo reduzido, mas que viram uma verdadeira  sopa de pedra), requisitos incompletos, sem stakeholder (https://pt.wikipedia.org/wiki/Stakeholder),  ou stakeholder despreparado,  sem orçamento ou orçamento financeiro irreal.

Se analisarmos logicamente, saindo fora da caixa (me refiro a pensar sem emoção, sendo racional), podemos perceber que o problema não está no produto a ser produzido, ou seja, no sistema que temos que fazer.

Eu realmente acredito que é possível fazer software de qualidade, no prazo, dentro das estimativas, sem ter que brigar com os usuários, com os pares, ou ficar p*** da vida.

Enfim  a chance de tudo dar errado começa quando você  é contratado e seu contratante inicia a conversa pela célebre frase “Preciso desenvolver um sisteminha”).

Fazer software é um produto Industrial. Vender software é uma ação comercial. Implantar software é um serviço.

Quando uma Empresa se propõe a adquirir uma solução de terceiros, precisa entender com clareza o que a solução faz, e adaptar (customização) a solução aos seus processos, ou seus processos à solução. Um Stakeholder sem força, ou inadequado às funções pode estragar todo o processo de implantação, levando a uma insatisfação mútua dos atores envolvidos.

Luciano Basile 

Arquiteto de Software

CEO de i-Coll Soluções Integradas

2017-12-14T10:25:46-03:0012/10/2017|Gestão|Nenhum Comentário
Translate »