BrunoBemfica.NET > Cinco dicas de convivência(ou:Como evitar o ódio mortal da sua equipe)

Esse artigo é mais voltado a gestores do que à galera do #SouDev em si, e visa analisar as relações interpessoais em um ambiente de desenvolvimento de software, e algumas falhas(ou até mesmo gafes, dependendo do ponto de vista) que os gestores cometem no dia a dia. Semana passada, li um texto publicado no blog do Marcelo Furusawa, que falava sobre as 10 coisas que mais irritam os desenvolvedores. E partindo do “axioma” nº7, resolvi escrever esse texto. Sem mais delongas, vamos lá.

1)Gerentes não tem conhecimento técnico: E em sua maioria, nem querem ter. Mas querem mandar nos desenvolvedores. EM TESE, desenvolvedores são subordinados a arquitetos de software(não confundir com arquiteto da informação – papel muito em destaque nas empresas de TI hoje em dia e coisa que qualquer estariágio faz), engenheiros de software ou analistas de sistema. Mas todos bem sabemos que não é assim. Poucos são os gerentes que tem a noção de que são gerentes DO PROJETO. E muitas empresas dão o aval para que o gerente se comporte assim. Porém, em programação e em qualquer profissão, seja do meio de TI ou não, ninguém respeita um chefe que não sabe fazer o nosso trabalho. Ninguém gosta de dizer “fiz uma classe X que faz routing das socilitações na camada view”, e o gerente falar “ok, agora explica”. Sim, dá raiva. Não é necessário que o gerente saiba todas as linguagens e todos os termos técnicos. Mas saber o que é uma classe  já é um bom começo. Saber o que é MVC, saber o que é uma procedure, o que é ORM, isso já adianta. E dá aos desenvolvedores mais alguns anos de vida, devido à redução do stress e da frustração de se sentir falando com uma porta.

2)Estrelismos(a.k.a “Eu sou a lenda”, ou “Eu sou o projeto”): Alguns gerentes tendem a achar que eles são o projeto, e nada anda sem eles. Partindo dessa premissa, podemos afirmar que nenhuma metodologia ágil funciona, ou seja: É besteira. Se o gerente está doente e faltou dois dias, o analista continuará fazendo os diagramas, os programadores desenvolvendo, os testers testando – e óbvio, o comecial estará cobrando. Essa postura muitas vezes soa(e é) arrogante por parte do gerente, que parece estar dizendo que o seu trabalho é mais importante do que o dos outros. E quando se fala em trabalho em equipe, todas as partes são importantes.

3) Nunca questionar, contrariar ou negociar prazos do cliente: Isso é algo que (literalmente) tira o sono da equipe. Se o cliente estima um prazo, esse prazo deve ser repassado à equipe e caso não seja aceito, deve ser negociado com o cliente. Lembrando que se uma empresa contrata serviços de desenvolvimento de software, é por que ela NÃO desenvolve software, logo não sabe quanto tempo demora pra fazer. Ou, caso tenha uma equipe interna, a equipe já está saturada de trabalho ou não tem os skills necessários para esse trabalho. Não adianta contratar mais programadores, os que já estão no projeto terão de parar o que estão fazendo para explicar aos mais novos detalhes do software, e os mais novos terão um tempo de ambientação com o produto a ser desenvolvido, com o ambiente de trabalho, com os novos colegas, etc. Lembre-se: Nove mulheres não fazem um filho em um mês.

4) Não utilizar ferramentas adequadas: Muitas empresas tem sistemas próprios para controles de tarefas e atividades. Porém, é sempre importante ter tudo isso listado, organizado e detalhado. Utilizar o Microsoft Project(ou outra ferramenta semelhante, como o Planner, o Gantt Project e o OpenProj) não só é uma boa prática, como é sinal de BOM SENSO. Além de ficar muito mais fácil de apresentar o que está sendo feito para os seus superiores, e para o cliente. E tenha sempre em mente que cada vez que você ignora isso e passa tarefas via e-mail a um programador, Deus mata um bebê foca.

5)Não assumir falhas, ou complexo de Homer Simpson(”A culpa é minha, e eu coloco ela em quem eu quiser”): Isso é vital não só na gestão de projetos, mas em qualquer área de liderança. Gestores ganham a confiança e admiração quando conseguem admitir que erraram, além de aumentar isso quando se demonstram abertos a sugestões. Sócrates já dizia: “Só sei que nada sei”. E é sempre bom não esquecer que quando algo dá errado, o que devemos procurar não são os culpados, mas sim as formas de corrigir o erro e satisfazer a necessidade do cliente. O IDGNow publicou  uma boa matéria sobre isso, disponível aqui.

Bom, é isso. Espero que o texto ajude a diminuir conflitos entre as equipes e mostre algumas falhas cometidas. Ainda escreverei um texto semelhante, sobre programadores. Só espero que não digam que eu traí o movimento do #SouDev.

Abraços e keep coding!

Tags:conflitos, dicas, gestão, projetos