5 padrões para evitar em seu projeto de Desenvolvimento de Software

Escrito com Luiza Nunes

Trabalhar com desenvolvimento de software é trabalhar também com cronogramas apertados, ideias complexas e, às vezes, pessoas com diferentes personalidades.

Nesse sentido, como primeiro post de uma série, gostaríamos de compartilhar algumas impressões e experiências que vivenciamos nos últimos projetos que trabalhamos. Esses “padrões” são basicamente comportamentos que acontecem ou aconteceram no dia-a-dia de equipes de desenvolvimento em que estivemos envolvidos.

Qualquer pessoa pode se comportar de acordo com esses padrões, muitas vezes de forma inconsciente. Por esse motivo, é importante reconhecê-los e discutir formas de evitar esse tipo de armadilha.

Para criar o artigo, utilizamos como inspiração e base o livro: ADRENALINE JUNKIES AND TEMPLATE ZOMBIES: UNDERSTANDING PATTERNS OF PROJECT BEHAVIOR. Mais informações aqui.

1) Concentradores de Conhecimento

Paula é uma profissional exemplar. É o porto seguro do time. Já está na equipe há mais de dois anos. Ela conhece a arquitetura do projeto, os detalhes do código e todos os problemas frequentes da aplicação.

Infelizmente, Paula nem sempre consegue compartilhar seu amplo conhecimento com os outros colegas. É possível notar que todos “sofrem” quando ela resolve se ausentar por um período. Por exemplo, quando ela não está é mais difícil chegar a uma solução técnica efetiva, ou falta entendimento da arquitetura para avançar em um determinado problema.

O time perde o ânimo, as pessoas ficam frustradas e a entrega entra em risco. Paula é, no fim das contas, uma concentradora de conhecimento dentro da equipe. Uma profissional exemplar e necessária, mas um grande risco para o projeto.

2) Críticos de Cinema

“A vida não é filme” já diziam os Paralamas do Sucesso. Qualquer projeto de software bem sucedido é realizado com trabalho constante e objetivos claros. É necessário que todos os membros da equipe estejam contribuindo para isso acontecer.

Pedro é um conhecedor profundo de diferentes técnicas de programação e de seu uso na indústria atual. Entretanto, Pedro não utiliza de maneira construtiva esse conhecimento. Em vez de parear com seus colegas e “sujar as mãos”, Pedro prefere redigir longos e-mails ou preparar apresentações detalhando o porquê a solução que está sendo desenvolvida tem problemas e como o projeto irá falhar se suas sugestões não forem implementadas.

Basicamente, Pedro percebe que seu principal valor para o projeto é criticar as decisões tomadas. Em alguns momentos, isso pode ser considerado como algo bom, em outros, é um comportamento não sustentável que tem como consequência a desmotivação do time, queda na produtividade e a falta de confiança entre as pessoas. As críticas são excelentes, contanto que sejam construtivas.

3) Cheiro de peixe podre no ar

Existem projetos que já começam com um desfecho previsível. Maico e Maria trabalham em uma pequena empresa de desenvolvimento de software. Um novo cliente está pagando muito dinheiro para essa empresa desenvolver o projeto. Muitas tecnologias, equipe pequena, prazos apertados, liderança que não sabe trabalhar em equipe, e contratos não muito claros.

A possibilidade do fracasso é iminente. Entretanto, ninguém fala abertamente sobre a provável derrocada. Os dias e meses passam e todos continuam trabalhando como se fosse somente mais um projeto.

Duas semanas antes dos prazos chegarem, o clima é pesado e a “cortina de fumaça” começa a desaparecer. Além disso, a autoconfiança é baixa e os relacionamentos entre os membros da equipe estão em frangalhos. O peixe podre já estava servido desde o começo da refeição. Os custos envolvidos para chegar até aqui foram altos e agora é hora de encarar a realidade. Até quando esperar o cheiro ficar insuportável? Maico e Maria ainda se perguntam.

4) Silêncio não quer dizer aceitação

Em qualquer projeto de software, existem acordos que são explícitos, como, por exemplo, um prazo específico ou uma tecnologia que deve ser utilizada devido a algum requisito do cliente. Existem outros acordos que são menos explícitos, como uma combinação importante realizada superficialmente pela equipe de desenvolvimento.

Rafael trabalha em um projeto que desenvolve um portal de notícias para um grande cliente. A gerente do projeto conclui que a equipe não está produzindo de maneira adequada e uma nova organização é necessária. Em uma reunião, ela comunica à equipe que mudanças irão ocorrer. A equipe em silêncio reflete sobre a possível mudança e perspectivas não são compartilhadas. A gerente sai da reunião segura de que todos estão de acordo.

Em três semanas, a produtividade está baixa. Os membros da equipe culpam as recentes mudanças no time como causa para o mau estado do código da aplicação. Rafael está perdido e sua gerente de projetos ainda mais. Ainda assim, não há comunicação.

5) Reuniões eternas

Reuniões são importantes para que os membros da equipe estejam alinhados. No entanto, conversas infinitas são reflexo da falta de confiança e objetividade para a tomada de decisões.

O projeto de Julia e Daniel começou recentemente, e o time ainda está trabalhando na configuração de ambientes e na definição das tecnologias que serão utilizadas. Há duas semanas que várias conversas acontecem, porém nada é definido e o resultado acaba sendo sempre uma nova agenda para uma próxima conversa ou encontro.

Julia e Daniel se sentem frustrados e desmotivados com a quantidade de tempo e dinheiro que está sendo desperdiçado durante essas semanas. O que era para ser interessante e desafiador se tornou uma tortura.

E você? Algum dos padrões acima soou familiar? O que você fez para resolvê-los? No próximo artigo da série, falaremos sobre como evitar ou atuar positivamente sobre esses padrões.