Os mitos de software são “falsas verdades” que existem no mundo da indústria de software. Tanto jovens engenheiros quanto pessoas mais experientes tendem a acreditar neles, distorcendo a verdadeira face do processo de engenharia. Os mais comuns são:
- Um bom manual, repleto de padrões e regras, fornecerá a equipe tudo que ela precisa saber
Desenvolvimento não é uma receita de bolo! Os clientes são diferentes, os projetos são diferentes, os programadores são diferentes, as prioridades dependem do projeto. Basicamente, TUDO é diferente. Não pense que um site de ecommerce que você desenvolveu para a empresa X valerá para a empresa Y, e vice-versa. O planejamento é fundamental e só então você poderá levantar os requisitos necessários e trabalhar em cima de um novo projeto.
- Caso ocorra atraso no cronograma este poderá ser contornado alocando-se mais programadores ao projeto.
Por mais que exista o conceito de “Fábrica de Software” não podemos pensar no processo de desenvolvimento como uma linha de produção. Ao se inserir um programador em um projeto, ele levará algum tempo para se familiarizar com o código e com o que está sendo feito, para então, começar de fato a produzir. Outro grande pecado que muitos gestores comentem é tratar o programador como “pedreiro”, como um “peão”. Se o o desenvolvedor não entende nada do processo da empresa para o qual está desenvolvendo, tenha certeza que não poderá contribuir da melhor maneira possível. Mais um vez, quero frisar: Desenvolvimento não é linha de produção. Alocar programadores para resolver um problema de cronograma poderá surgir efeito contrário, causando mais problemas!
- Terceirizar um projeto é garantia de tranquilidade e nenhum trabalho.
Quando um projeto é muito trabalhoso, requer know-how maior do que a sua equipe possui ou o cronograma está apertado, muitos optam pela terceirização achando que esta é uma garantia de tranquilidade e nenhum trabalho. Contudo, tome cuidado: Se a empresa X contratou você, você é o responsável pelo trabalho que está entregando. Ou seja, qualquer problema será um problema seu também! A maioria das empresas terceiriza o serviço, mas ao comprar o código, fica responsável por suas manutenções. Aí fica a pergunta: A terceirização fez o serviço direito? Comentou o código? Documentou o que foi feito? Sua equipe tem pessoal para trabalhar nesse código? Pense bem antes de terceirizar algo que não poderá trabalhar bem no futuro. É melhor recusar um projeto do que faze-lo mal feito.
- Um software pode ser construído observando-se o seu propósito geral – os detalhes podem ser levados em conta posteriormente.
Se você é desenvolvedor já deve ter se deparado com um usuário que só queria um ajustizinho no sistema: “só adicione um botão que faça isso e busque aquilo e faça isso ficar cor de rosa e brilhar girando”. Sim, essas coisas acontecem! Ao se pensar em um software deve-se mapear o máximo possível de suas funcionalidades a serem desempenhadas. É claro que em um primeiro momento é difícil pensar em tudo, alguma coisa ou outra vai entrar como correção. Mas pensar em algo básico demais e querer enfeita-lo demais depois, envolve mais tempo e o pior: retrabalho! Desenvolvedores geralmente não gostam de destruir algo para faze-lo de outra forma, pois o cliente mudou de ideia. Aliás, ninguém gosta. Como eu disse, existem exceções, mas se você não entende de desenvolvimento e só gerencia o processo, não pense que os seus “detalhes” são realmente detalhes quando viram linhas de código!
- Mesmo que os requisitos de um software mudem, as alterações são realizadas facilmente pois temos uma boa equipe que sabe como fazer o serviço muito bem.
Mais uma vez, se você não é desenvolver e não entende do processo, não julgue uma atualização como simples. Somente um programador poderá avaliar o quão simples uma alteração é – e muitas vezes, ela só vai realmente ter a ideia depois que estiver trabalhando com o código. Mesmo que você tenha uma boa equipe, modificações devem ser analisadas, discutidas com relação a sua viabilidade e testadas. Lembre-se sempre: alocar um programador requer algum tempo para que esse se familiarize com o que vem sendo feito. As coisas não são tão simples.
- Se o programa funciona, nosso trabalho está completo.
- Se o programa ainda não está finalizado e “rodando”, não posso avaliar sua qualidade.
Esses dois tópicos são assutadoramente passados adiante e você já deve ter ouvido isso de alguém. Se um programa roda isso não garante que o seu trabalho está feito. Todo o processo de desenvolvimento deve buscar a qualidade e apenas funcionar não lhe garante isso – ou seja, o processo da avaliação de qualidade não se limita a essa etapa. O seu código é bem comentado? Está bem feito? Otimizado? A tecnologia utilizada é adequada? Os banco de dados estão otimizados? Sua relações foram criadas corretamente? A infraestrutura do cliente suporta o que está sendo desenvolvido? Se o seu sistema foi feito para suportar vários acessos, ele realmente suporta isso? Um programa é mais do que o executável. Você vende todo o processo.
- O único produto que entregarei ao cliente é o código executável.
Em alguns casos, o produto “palpável” que o cliente recebe é somente o executável. Em outros, trabalha-se com o código fonte e com a documentação. Contudo, independente do caso, lembre que, como foi dito no item anterior: Um programa é mais do que o executável. Você vende todo o processo de desenvolvimento. Por isso, deve-se pensar e faze-lo com perfeição.
- O processo de planejamento fará com que criemos documentação volumosa que atrasará a execução do projeto, atrasando o cronograma.
Planejamento é fundamental! Muitas pessoas aindam confundem planejamento com “papelada” e estas estão terrivelmente enganadas! Mesmo trabalhando-se em um time Agile, planejar é fundamental! A documentação do projeto será trabalhada na melhor metodologia adotada mas um plano do que será feito deverá ser estudado antes de “colocar a mão na massa”. Somente com o estudo dos processos e necessidades do cliente você conseguirá criar um software que trabalhe com excelência!
