Trabalhar em equipe é um fato, às vezes não é fácil. Muitas vezes construir um time requer tempo e um bom trabalho de coaching. Práticas ágeis e/ou lean também podem te ajudar, mas muitas vezes isso não é o suficiente. Algumas empresas fazem um trabalho de RH mais forte na formação das equipes – já vi muitas esforços nesse sentido com bom aproveitamento também.

Quando participamos de um projeto, estamos em contato com todos os tipos de pessoas, às vezes de diversas culturas, timezones, idiomas e crenças – esta última palavra é que complica tudo muitas vezes. Essas crenças (assumptions) não são verdadeiras, o que pode levar a uma série de problemas e até mesmo anomalias (disfunções) na “equipe”.

Formando um time

Muitas vezes você não tem todas as pessoas de que precisa para um projeto. Logo, vem a necessidade de formar uma equipe, e formar a equipe é uma tarefa simples, mas em nenhum momento é fácil. Ultimamente, estou tendo a possibilidade de me envolver mais com esse tipo de tarefa, ajudar a formar equipes e também participar de processos de seleção.

Neste momento, várias questões me vêm à cabeça: que tipo de pessoa deve fazer parte do time? Desenvolvedores, sim, mas com qual experiência, com qual especialidade, com que tipo de habilidades? Essas perguntas não são nada fáceis de se responder, muitas vezes são existe uma única resposta, mas sim um conjunto de variáveis que implicam em uma série de trade offs.

Prova Técnica

Esta é uma questão bem polêmica, muitas pessoas acham que a prova técnica não prova nada, e eu concordo com elas. Outras dizem que prova muito, e eu concordo também. Talvez você tenha ficado confuso com a última frase 😀

Não vejo outra forma de avaliar o código de um desenvolvedor sem ver o código dele – existe uma exceção, mas vou comentá-la no fim do post. Bom,  voltando à questão: ok, prova técnica, mas o que avaliar?

Na minha concepção, API é algo que simplesmente não importa, porque na vida real qualquer desenvolvedor vai consultar o google ou o stack overflow ou outro site geek que tenha respostas certas e rasteiras.

Se API não importa, o que realmente importa? Para mim, é saber se o desenvolvedor *pensa* no problema, entende o problema e cria uma solução que o soluciona, levando algumas coisas em consideração, como por exemplo:

• Código Limpo
• Simplicidade
• Boa Lógica de Programação
• Separação de Conceitos
• Baixo Acoplamento e Alta Coesão
• Extensibilidade/Flexibilidade
• Otimização, se necessário for
• Tratamento de Erros

Para mim, um bom desenvolvedor é capaz de realizar um prova técnica sem utilizar frameworks ou bibliotecas, por exemplo, e atender perfeitamente a esses requisitos. Para mim, essas coisas importam e com certeza vão fazer a diferença.

Se você separar esses requisitos em dois grandes grupos, terá requisitos de implementação que existem no XP, por exemplo, e requisitos básicos de design (outra coisa que importa). Normalmente, eu dou um bom tempo para a realização desse tipo de avaliação, como por exemplo 24h, e o candidato pode realizar isso de cada vez e mandar a prova por e-mail em um formato zip, por exemplo.

A correria do dia a dia

Sei que muitos profissionais trabalham 8-10h diárias e ainda têm que ir para faculdade à noite, depois chegar em casa e ficar um pouco com a mulher :D. Neste caso, a prova pode parecer um pouco injusta, certo? Bom, aí há duas coisas: você pode deixar o candidato escolher o dia de receber a prova, mas mesmo assim ele terá 24h para resolução, e a outra a se fazer é esperar que o candidato vá ter dedicação e, mesmo com todas essas coisas, vai dormir umas horas a menos e fazer um bom código – isso é comprometimento e vale muito nos dias de hoje.

Nota boa na prova está dentro?

Negativo, a prova é só uma ferramenta, ainda precisamos de duas outras ferramentas que importam muito. A primeira é a avaliação do RH com os seus testes de risquinhos, comportamento etc… A outra ferramenta é a conversa técnica com o candidato, na qual costumo ver se a pessoa realmente fez a prova, e tento ouvi-la, ver como ela se expressa e qual é a sua visão das coisas. Com isso, posso ver as duas coisas que mais importam…

As duas coisas que importam

Além dos valores da empresa e outras coisas que sempre se levam em consideração, para mim existem duas coisas que realmente importam. A primeira é a *confiança*, mas essa só vem com o tempo – claro que uma boa indicação de uma pessoa que você confia ajuda muito, e esta é a resposta que fiquei devendo antes.

Tirando isso, o que mais importa para mim é a Adaptabilidade da pessoa. O quanto a pessoa consegue se adaptar a projetos com pessoas diferentes, culturas diferentes, tecnologias novas, velhas, legais, chatas, idioma, timezone, ambiente, horário, local de trabalho, forma de contratação.

Adaptabilidade é uma habilidade muito valiosa em um projeto. Se você é multifuncional, pode trabalhar com responsabilidades diferentes e, com essa habilidade, você não é uma peça estática, e sim dinâmica. Ser dinâmico é fundamental para o sucesso em uma empresa nos dias de hoje, e esse dinamismo não é só válido de projeto para projeto, mas dentro de um mesmo projeto no qual você não tem medo das mudanças e consegue realizar mudanças radicais de forma rápida e sem dor.

Pessoas que se adaptam fazem toda a diferença. Quando você confia nas pessoas e elas se adaptam e têm essa habilidade, o time é completo e você tem todas as condições de vencer os desafios de um projeto.

Finalizando, confiança e adaptabilidade importam muito para mim em um time de desenvolvimento, assim como outros valores e habilidades, mas essas são as habilidades essenciais que vejo para trabalhar em projetos complexos, distribuídos e dinâmicos.

Abraços.