Gerindo conhecimento e aprendizado em equipes de desenvolvedores

Quando pensamos em uma empresa de desenvolvimento de software, pensamos logo na grande quantidade de conhecimento existente ali. Pessoas chegando, pessoas saindo, projetos começando, outros precisando serem mantidos em funcionando.

Pra quem vê de fora, vê como se fossem verdadeiros gênios os desenvolvedores de um time, que trazem consigo todos os conhecimentos encapsulados, prontos para o uso. Pra quem vê de dentro, sabe quantas áreas de conhecimento e níveis de compreensões existem ali. São linguagens, frameworks, bibliotecas, ferramentas, metodologias, paradigmas e tantas outras dimensões do conhecimento.

Alguns fatores tornam ainda mais difícil essa tarefa, tal como quando colaborador tem domínio sobre grande parte dos conhecimentos da empresa, das tecnologias e processos, e um belo dia resolve sair, é então preciso lidar com a “perda” de todo aquele conhecimento.

Por este e por outros motivos, gerir o conhecimento de um time de desenvolvedores pode ser uma atividade bem complicada. Mas, não desanime! Siga comigo no post, que ao final vou falar de uma solução bem interessante, o Roadmap!

Como saber “quem sabe o que” em um time técnico?

Tomar registro dos conhecimentos que cada desenvolvedor do time tem, não é tão simples. Um desenvolvedor pleno pode dominar algumas dezenas de “habilidades”, algumas com alto domínio de conhecimento, umas sendo melhoradas agora, enquanto outras estão apenas em um nível exploratório.

Uma ideia inicial é que cada membro registre suas habilidades e conhecimentos em um documento compartilhado. Outra forma bem eficiente é a visão do líder do time, que deve observar na dinâmica de trabalho quais membros conhecem melhor o que está sendo feito, quais podem ensinar, e quais precisam estudar um pouco mais.

Manter este registro atualizado também pode ser desafiador. Uma vez que na área de tecnologia é preciso aprender sempre, os níveis de conhecimento estão sempre em movimento.

Esta tarefa pode ser tão complexa que a maioria das empresas simplesmente não conseguem leva-la a frente. Uma planilha feita três meses atrás já não retrata mais a realidade.

Lidar com o contexto, com o volume de informações

Ao mesmo tempo que precisamos saber o que o time sabe como um todo, e quais as habilidades necessárias para lidar com tudo o que a empresa trabalha, isso pode gerar uma carga cognitiva grande demais sobre um desenvolvedor novo no time. O volume de conhecimento necessário para se trabalhar em uma empresa, em um projeto, pesam nos ombros das pessoas do time.

Uma forma adequada de lidar com o contexto, é ter uma lista dos conhecimentos requeridos por projeto. Assim, fica claro que um novo colaborador que irá trabalhar no “Projeto A” precisará aprender uma determinada lista de habilidades. O mesmo aconteceria se um desenvolvedor mudasse de projeto, e precisa-se passar por um nivelamento ao entrar no novo time.

Mantendo as fronteiras de conhecimentos mais “próximas”, a empresa economiza em treinamento desnecessário, em tempo, e principalmente, em quantidade de informação na cabeça do desenvolvedor.

Como lidar com a saída de um desenvolvedor do time?

Algo que costuma causar um balanço em empresas de desenvolvimento, é a saída de um bom desenvolvedor do time, perceber-se que alguns dos conhecimentos que ele tinha, ninguém mais tem no time.

Se isso for percebido antes do seu último dia de trabalho, o time terá ainda algum tempo para passar o conhecimento. Nem sempre é possível passar tudo o que se sabe, eventualmente algumas coisas serão apenas “pinceladas”, mas no geral a saída se dá sem a percepção nítida de quais conhecimentos estão sendo perdidos.

Se a falta de um conhecimento no time só for percebida após a saída daquele colaborador, é um grande problema lidar com essa perda de forma suave. Alguém precisará aprender algo novo (desconhecido de todos no time), e em poucos dias se tornar responsável por uma parte de um sistema.

Num mundo ideal, saberíamos detalhadamente os conhecimentos daquele colaborador, veríamos seus pares e montaríamos uma trilha de aprendizado “de emergência”, nas habilidades mais críticas ao menos.

O que aprender ao chegar na empresa?

Da mesma forma que a saída pode gerar uma demanda de estudos no time, a entrada de um novo desenvolvedor para a equipe é motivo de aprendizado.

O ideal é que cada projeto tenha sua própria trilha de aprendizado, que seja possível saber quem domina cada aspecto, bem como qual o nível mínimo de entendimento necessário para cada conhecimento. Pode ser necessário dominar um framework e algumas bibliotecas críticas para o projeto, enquanto outras basta entender o básico