Os 5 erros mais comuns em Equipes de Desenvolvimento de Software
![matteus.dev 3](https://matteus.dev/wp-content/uploads/matteus.dev_3_-1024x617.webp)
Código em produção sem testes
É comum criar software a partir de poucas confirmações das operações de listagem, criação, atualização e remoção. O interessante é a velocidade com que se entrega o software, porém não há garantias sobre o que pode acontecer quando algo além desses casos triviais acontece.
É por isso que é necessário criar casos de teste. Com eles, simples comandos verificam a resposta de cada função em casos extremos, para confirmar que a resposta adequada é apresentada ao usuário e que o sistema toma as medidas necessárias para contornar o problema.
Provocação: Faça isso com frequência e veja tudo desmoronar.
Falta de mão de obra qualificada, ou equipe muito pequena para atender o projeto
Parece algo óbvio e até clichê alertar sobre esse erro, mas é mais comum do que imaginamos. Imagine delegar a um pedreiro a construção de um edifício, que requer conhecimentos de solo, engenharia e arquitetura, legislação, design? É o que acontece quando se acredita que um desenvolvedor ou uma pequena equipe dão conta de construir, em pouco tempo, um software robusto e confiável como WhatsApp ou YouTube.
E se o prédio cair? A culpa é do profissional, ou de quem negligenciou todo o processo e delegou uma missão impossível à equipe?
Tenha em mente que é possível publicar o software com funcionalidades limitadas, em pequenas partes. Inclusive gratuitamente. Assim, é possível testar o que ganha adesão do público e obter um feedback.
Não acompanhar com reuniões a cada sprint
A inexistência de uma cultura de planos e métricas faz com que a comunicação seja prejudicada. Com a premissa de que é melhor trabalhar do que ficar fazendo reuniões, os breves momentos tão importantes para ajuste de engrenagens acabam sendo deixados de lado.
Para ter certeza de uma entrega satisfatória, é preciso acompanhar de perto o progresso e alinhar o trabalho de acordo com as expectativas do dono do produto. Delegar criação de funcionalidades e correção de bugs com longa data e sem intervalos com verificações, cria um risco muito maior de frustração na entrega.
Estimar o tempo para entrega sem um histórico de referência
Provocação: Faça isso com frequência e veja tudo desmoronar.
Para uma estimativa mais próxima da realidade, é preciso analisar os pontos principais:
- Quanto vale a hora do desenvolvedor
- Qual complexidade de cada tarefa
- Quanto tempo demanda a complexidade
- Métricas de projetos anteriores – histórico
Uma planilha que contém suas médias de nível Fácil a Complexo nos ultimos projetos é de extrema utilidade nesse momento.
Tabela de Horas/Complicadores/Valor definida
![](https://www.matteus.dev/wp-content/uploads/tabela-complicadores.png)
Lista de tarefas definida
![](https://www.matteus.dev/wp-content/uploads/tabela-tarefas.png)
Resultado gerado automaticamente via Excel
![](https://www.matteus.dev/wp-content/uploads/tabela-resultado-1.png)
Código em produção sem auditoria de performance
Com a grande quantidade de plataformas, plugins, bibliotecas, integrações… estamos acostumados a valorizar apenas a produtividade que se consegue com código pronto. E sim, é vantajoso e boa prática contar com ferramentas que acelerem o processo e evitem que se “reinvente a roda”.
No entanto, é possível notar que, quanto mais uma aplicação demora para entregar sua resposta, mais aumenta a a taxa de rejeição de usuários. É por isso que é preciso considerar a criação de funcionalidades por conta própria, ao invés de utilizar código de terceiros.
Ao criar um código próprio, investe-se mais um tempo para trabalhar no código, mas em contrapartida, tem-se a certeza de que não está sobrecarregando o sistema com códigos, estilos, imagens inutilizados e se consegue construir código mais limpo e objetivo, com o mínimo necessário para realização da funcionalidade.
Erros são aprendizados
Ninguém erra de propósito, mas um código com muitos erros significa pouca qualidade de código. É necessário avaliar se o tempo para construção do software foi/está suficiente e a estratégia de testes é consistente. No mais, erros servem de aprendizado e, uma vez identificados, devem ser corrigidos de forma que não aconteçam mais em todas as partes do sistema.
Quer saber mais sobre como funciona? Fale com um desenvolvedor agora mesmo!O conteudo foi útil? Isso é fantástico. Quer incentivar mais posts como esse? Mostre seu apoio com qualquer valor.
Chave PIX: d0311e58-cb6e-4d47-b3d8-3d4254763ce7