O gargalo de conhecimento
N o desenvolvimento de software há muitas maneiras de se transferir conhecimento sobre um produto para as pessoas que efetivamente o constroem. A produção pode ser severamente prejudicada, entretanto, se esse conhecimento é produzido mais rapidamente do que pode ser consumido. Esse é o gargalo da transferência de conhecimentos.
Recentemente, organizou um workshop para experiência de três formas diferentes de transferência de conhecimento em um ambiente de produção. O produto, nesse caso, era um avião de papel de desenho incomum projetado por um “designer-chefe”. A idéia era tentar formas diferentes de transferir o conhecimento de como construir o avião e comparar a produtividade relativa dos diferentes métodos, que foram:
- Documentação – Os trabalhadores receberam instruções escritas para a construção do avião.
- Engenharia Reversa – Os trabalhadores receberam um avião concluído que eles poderiam estudar a fim de reproduzir os passos necessários para construí-lo.
- Mentoring – O “designer-chefe” construiu um passo a passo do avião e os trabalhadores replicaram cada passo conforme ele foi realizado.
Os resultados foram interessantes.
Utilizando a Documentação, apenas uma pessoa de um total de 8 chegou perto de construir o avião em 5 minutos. Usando a engenharia reversa, 2 pessoas em 8 produziram um avião em cinco minutos. Usando o Mentoring, todos da equipe produziram um avião e em menos de cinco minutos disponíveis.
O gargalo da transferência de conhecimentos em software
Durante o desenvolvimento de software, a transferência de conhecimento acontece o tempo todo, e é fácil imaginar um desenvolvedor no papel do “designer-chefe” descrito no exercício anterior.
Vamos dizer que eu sou um desenvolvedor, e que descobri e escrevi um super código que contem uma nova técnica para ligar dados com os controles de uma interface visual, e que essa técnica forma um padrão que os meus colegas desenvolvedores querem saber. Se você fosse um dos meus colegas desenvolvedores, você preferiria que eu (a) lhe desse um documento que escrevi sobre a técnica, (b) lhe dissesse onde está o código e sugerisse que você descobrisse por si mesmo, ou (c), pareasse com você e implementasse o padrão para um novo conjunto de dados?
Agora, certamente, o pareamento com você toma mais do meu tempo, e pode parecer menos eficiente do meu ponto de vista. Afinal, eu poderia estar projetando e implementando o próximo padrão. Mas a produtividade da equipe como um todo, ao invés de minha produtividade pessoal, é que é importante. E mentoring ajuda a aumentar a produtividade da equipe, evitando os gargalos de transferência de conhecimento.