Gestão de conhecimento do time

junho 6, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Eu tenho pensado um pouco sobre isso nos últimos tempos, então decidi falar aqui no blog porque possivelmente muitas pessoas têm questionamentos semelhantes.

Inicialmente vou contextualizar um pouco para depois ficar mais fácil de expôr algumas idéias. Meu time na Globo.com é formado atualmente por 3 desenvolvedores, 1 especialista em client-side e 2 arquitetos de informação (até semana passada eram 3). Temos um backlog de produto enorme, pois a equipe era formada apenas por 2 desenvolvedores antes da minha chegada em Janeiro. O resto do pessoal se juntou ao time em Março.

Uma coisa importante no Scrum (na verdade, em qualquer metodologia hoje em dia) é que os desenvolvedores sejam versáteis, e consigam atuar de várias formas diferentes, mudando de ferramentas, frameworks e linguagens sem problemas. Para que os desenvolvedores consigam fazer isso, é claro que é fundamental que eles estudem bastante e estejam sempre se atualizando, pois as opções de tecnologias disponíveis estão avançando muito rapidamente.

Outra coisa importante é que mais de um desenvolvedor do time seja capaz de realizar qualquer tarefa específica. Isto é importante pelo compartilhamento do conhecimento e para que seja possível lidar tranqüilamente com problemas pessoais, férias, etc. Neste sentido, precisamos pensar muito mais no conhecimento do time do que no conhecimento de indivíduos separadamente.

O que eu quero dizer com isso? Quero dizer que para um time andar bem, as escolhas de tecnologias idealmente devem ser moldadas em torno do time. Com a infinidade de opções que temos de frameworks web, APIs javascript/ajax, linguagens e componentes, não podemos nos dar ao luxo de ficar continuamente acompanhando as novidades e avaliando novas opções. Precisamos fazer algumas escolhas, e avançar com elas. É claro que isso pode e deve ser periodicamente revisto, mas é fundamental escolher algumas opções e se concentrar nelas.

Os 3 desenvolvedores do meu time têm experiência muito mais em Java do que em outras linguagens. Nossas aplicações são todas em Java, embora já estejamos fazendo experimentos com outras linguagens. Entretanto, concordo bastante com um artigo que saiu no InfoQ recentemente, que traz a idéia de que Java pode ser a última grande linguagem. Compartilho da idéia do autor de que provavelmente estaremos nos próximos anos escolhendo linguagens de uma forma semelhante à que escolhíamos frameworks Java nos últimos anos.

Java é uma linguagem de propósito geral. Gosto muito da linguagem e da plataforma. Mas com novas linguagens/frameworks direcionados para problemas específicos, é natural que em alguns nichos Java não seja a melhor opção. Penso que isso está acontecendo com mais força em aplicações web. Novas opções como o Grails, Django e Ruby on Rails oferecem um desenvolvimento muito mais produtivo do que Java em algumas aplicações. Java possui ótimos frameworks web, e já é uma linguagem muito madura. Mas quem já utilizou alguma dessas 3 opções que mencionei já pôde constatar o choque de produtividade delas contra a maioria dos frameworks web Java.

Conversei sobre isso com o resto do time e a minha opinião é de que devemos nos concentrar em torno de um conjunto limitado de opções, para que o time tenha um melhor rendimento. Com isso, o ideal é que o time conheça bem 2 ou talvez 3 frameworks web Java, 1 ou 2 das opções de alta produtividade web, e 1 ou 2 opções de framework javascript/ajax (jQuery por exemplo). As escolhas devem ser feitas pelo time em conjunto, de acordo com as aptidões e conhecimento agregado dos membros.

Trabalhando com um conjunto reduzido de opções, fica muito mais fácil compartilhar o conhecimento dentro da equipe, e conseguimos que os desenvolvedores conheçam bem esses componentes escolhidos e sejam produtivos com eles. Não adianta muito que um dos desenvolvedores saque muito do “melhor framework web da história desse país”, mas só ele conheça esse framework.

É melhor que seja utilizada uma opção que o time de uma maneira geral já conheça e seja produtivo. Pode ser que essa 2a opção não produza flocos tão crocantes como aquele outro framework, mas se é uma boa ferramenta para o problema e o time conhece bem, use essa mesma!

É claro que em algumas situações nós precisamos abrir mão de algo que conhecemos bem para utilizar uma opção que se adequa melhor aos outros membros do time. Vamor supor que um dos desenvolvedores saca muito de Tapestry e considera que ele é o melhor framework web Java. Se os outros 3 desenvolvedores já conhecem bem de JSF, provavelmente a melhor alternativa é que o time use JSF, e aquele desenvolvedor abra mão do Tapestry em favor do JSF. Pode ser que o Tapestry seja melhor tecnicamente do que JSF, mas os resultados têm que ser entregues pelo time, então as escolhas têm que ser feitas em torno das aptidões do time como um todo.

Tendo feito as escolhas de tecnologias, o legal é que os desenvolvedores se revezem com alguma freqüência entre as linhas de atuação, para propagar melhor o conhecimento e o time como um todo amadurecer. Eu por exemplo conheço legal de REST, mas os outros 2 desenvolvedores do time já implementaram alguns serviços e clientes REST, e com certeza têm plena condição de trabalhar em qualquer um dos serviços REST que eu implementei.

Aos poucos estamos aprendendo mais da parte client com o especialista do time, e ele também já está aprendendo um pouco de JSF, e com isso vamos todos amadurecendo. Essa gestão de conhecimento do time deve ser muito bem feita, para que os resultados do time vão melhorando progressivamente sprint após sprint. A decisão de se concentrar em algumas escolhas (mesmo que talvez elas não sejam as melhores tecnicamente) é muito importante para que o time se mantenha produtivo.

Todos gostamos muito de software, e de avaliar novidades. Porém, não somos pesquisadores, somos desenvolvedores comprometidos com resultados. Essa decisão das escolhas do time é muito importante. Nosso tempo de estudo é limitado, portanto precisamos ser pragmáticos e focar nos resultados.

Anúncios

Scrum Master x Líder Técnico: nova faceta de um fenômeno recorrente

abril 7, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Essa semana eu troquei umas idéias com o Bairos sobre Scrum, e após acompanhar as discussões no post do Guilherme pensei ainda mais sobre o assunto deste post.

Eu já conheci inúmeros casos de profissionais que saíram da linha de desenvolvimento para assumir papéis gerenciais. Deixam de lidar diariamente com atividades técnicas para lidar com coisas mais ligadas à organização dos projetos, definição de estratégias, planejamento, etc. Em alguns casos as pessoas de fato desejavam esta mudança de atividades. Depois de desenvolver por alguns anos algumas realmente “enjoam” de atuar com desenvolvimento e preferem abraçar o caminho da gerência. Já em outros casos esta “escolha” na verdade não é um anseio autêntico do profissional, mas uma alternativa que ele inevitavelmente adota para poder continuar crescendo na carreira, ter mais responsabilidades, mais reconhecimento e mais grana.

Com a adoção do Scrum, freqüentemente o antigo líder técnico da equipe assume o papel de Scrum Master. Pela definição da metodologia a responsabilidade principal deste papel é a de eliminar impedimentos do time, e garantir que este tenha as melhores condições possíveis de trabalho para poder produzir bem. Isto acarreta numa mudança significativa para o líder técnico. Ele vai sair das “trincheiras” para ajudar o time a chegar da melhor forma possível ao final dos sprints. Seu contato com a arquitetura e desenvolvimento dos produtos inevitavelmente vai diminuir bastante, pois isto é responsabilidade do time.

O Scrum nos trouxe uma nova faceta para o fenômeno recorrente do profissional com alta capacidade técnica que muda seu perfil de atuação para atingir maiores objetivos de carreira e finanças. Sim, porque em todos os casos que já vi o Scrum Master é superior hierarquicamente na empresa que todos os integrantes do time, com raras exceções. Sendo assim, a escolha entre fazer parte do time ou ser o Scrum Master não tem muita margem para dúvida. Assumindo que a diferença financeira entre ser um membro sênior do time e ser o Scrum Master esteja na faixa de uns 30 a 40%, raros serão os indivíduos que irão decidir-se por continuar no time, se tiverem a opção de escolher. Certamente a grande maioria dos líderes técnicos é formada por profissionais que gostam muito de software, e renovam sempre seu interesse por novos desafios técnicos. Entretanto, todo mundo gosta e precisa de dinheiro, e isto obviamente pesa muito nas decisões.

Na teoria eu sou líder de equipe da Concrete, mas como atuo em tempo integral na Globo.com, sou parte de um time de Scrum. Isto quer dizer que provavelmente se eu estivesse alocado dentro da Concrete em um projeto com Scrum, eu seria o Scrum Master. Entretanto, na Globo.com eu faço parte de um time, e atuo bravamente nas trincheiras do desenvolvimento. Considerando essa dualidade da minha situação, eu penso bastante sobre estas questões do Scrum, e o que ele representa na carreira de um profissional de software.

Eu gosto muito de produzir software, e no horizonte que se apresenta à minha frente existem inúmeros desafios técnicos que eu ainda quero enfrentar. Estou longe de querer me afastar do contato técnico intenso que tenho a oportunidade de ter atualmente. Um exemplo que me vem à cabeça é o do Joshua Bloch. Eu nem sei qual é o processo de desenvolvimento que ele usa no Google e qual é o seu cargo oficial lá. Mas sei que ele é um dos caras mais sinistros que já trabalharam com Java e a experiência que ele acumulou em vários anos de desenvolvimento deve ser um ativo extremamente valioso para o Google. Tenho certeza que ele deve ganhar muito mais que a média dos gerentes de projeto de TI nos Estados Unidos. Ele é um fora de série, e é tratado como tal. Considerando um exemplo como o dele, será que vale mais para o Google deixá-lo intimamente ligado com desenvolvimento ou colocá-lo em funções talvez mais estratégicas? Será que os profissionais de ponta de tecnologia têm realmente espaço para continuar crescendo na área técnica ou é de fato inevitável uma mudança para papéis gerenciais em troca de mais responsabilidade e mais de L’Argent?

Considere um horizonte de vários projetos interessantes e desafiadores tecnicamente pela frente para você atuar. Suponha também que você vai poder escolher entre fazer parte do time que vai entregar estes produtos ou ser o Scrum Master dos projetos. E finalmente suponha que você vai ganhar exatamente a mesma coisa se escolher atuar no time ou atuar como Scrum Master. O que você escolhe?

Certamente eu posso e talvez mude de idéia no futuro, mas com o enorme tesão técnico que eu ainda tenho e com a quantidade enorme de desafios que eu ainda quero vencer “nas trincheiras”, pelo menos durante alguns anos eu faria parte do time. Tudo bem, eu ainda sou relativamente jovem (26 anos), ainda não sou casado (mas não falta muito) e não tenho filhos. Certamente a mudança das variáveis desta equação poderia mudar muito o meu ponto de vista. Mas por enquanto, considerando as suposições que eu falei, eu seria um orgulhoso combatente nas trincheiras, e continuaria me empenhando ao máximo para entregar software “do estado da arte”. Just my 2 cents 😉