Como uma maçã boa é estragada pelas demais

Vamos supor que você é diretor de uma empresa que desenvolve software. Você tem acompanhado toda essa literatura moderna sobre equipes auto-organizadas, métodos ágeis e coisas do tipo. Na sua empresa há quinze programadores efetivos que precisam ser distribuídos em três equipes para três projetos de igual importância. Destes quinze você classificaria quatro como brilhantes e agradece a todos os deuses que eles estão trabalhando com você e não com os concorrentes. Outros três estão um pouco abaixo da média e do restante do pessoal você não tem muito do que se queixar. A questão é: como organizar as equipes?

O melhor a se fazer é distribuir os seus astros e estrelas cada um em uma equipe, dar a eles um título diferente dos demais e fazê-los se ocupar de analisar o problema enquanto os outros cuidam do trabalho sujo, certo?

Errado. Isto era antes da era da auto-organização. Você acredita que projetar software é um trabalho criativo e, para trabalhos criativos, equipes com a liberdade de se auto-organizar são mais produtivas que as equipes baseadas em comando e cobrança. Então você faz tudo do jeito anterior, só que toma o cuidado para não dar títulos às pessoas e deixá-las escolher as próprias responsabilidades. Assim a equipe vai convergir naturalmente para a configuração de maior produtividade, certo?

Errado novamente. Psicólogos descobriram que em organizações sem hierarquia muito rígida as pessoas mais fracas tendem a se unir para atacar e expulsar as de maior destaque. Então é bastante provável que ao invés dos melhores jogadores se tornarem líderes naturalmente, eles acabem sendo fagocitados do grupo. Eles são consciente ou inconsciemente excluídos pelo simples fato de serem melhores.

Ninguém quer que suas estrelas sejam eliminadas pelos colegas. Elas deveriam estar lá para brilhar e liderar, não para serem atacadas. No entanto, parece que é isso que acontece. Pelo menos se acreditarmos nos psicólogos.

A solução mais óbvia então é separar as equipes por nível de habilidade e manter as pessoas de nível similar juntas. Talvez seja melhor, ao invés de distribuir as melhores cabeças, mantê-las juntas e distribuir os jogadores mais fracos. Assim eles vão poder aprender com os colegas e crescer.

A não ser que os psicólogos descubram que uma maçã podre estraga as demais.

EclipseFP 0.10 disponível

Demorou mas saiu. A versão 0.10 do ambiente de desenvolvimento Haskell EclipseFP está disponível para download desde a última sexta-feira (dia 30 de junho). O modo mais fácil de instalar o plugin (na minha opinião, claro) é utilizar o gerenciador de atualizações do Eclipse. Mais detalhes sobre download e instalação na página de downloads do projeto.

Para este release eu estive trabalhando principalmente em complementação de código, uma funcionalidade que tem sido muito requisitada desde a 0.9.1. Outro destaque é o editor para arquivos Cabal, contribuído por Leif Frenzel, que deve ser muito util para o próximo release, que deve incluir suporte para montagem e empacotamento com Cabal.

Esta versão exige uma plataforma Eclipse versão 3.2, diferentemente da versão anterior que rodava sobre Eclipse 3.1. É necessário atualizar sua plataforma para obter todos os benefícios do plugin. Isso não deve ser grande sacrifício, afinal você já deveria querer atualizar sua plataforma para aproveitar as correções de bugs e novas funcionalidades do Eclipse.