Boa tarde amigos!
Vimos no versículo de ontem a vigésima terceira parte da tradução de “The Cathedral and the Bazaar”. Hoje a parte seguinte.
Então, o que toda essa sobrecarga de gerenciamento nos compra [nos proporciona]?
Compre seu Ingresso Agora
Para entender isso, precisamos entender o que os gerentes de desenvolvimento de software acreditam que fazem. Uma mulher que conheço que parece ser muito boa nesse trabalho diz que o gerenciamento de projetos de software tem cinco funções:
- definir metas e manter todos apontados na mesma direção
- monitorar e garantir que os detalhes cruciais não sejam ignorados
- motivar as pessoas a fazer um trabalho chato, mas necessário
- organizar o desenvolvimento de pessoas para melhor produtividade
- ordenar recursos necessários para sustentar o projeto
Objetivos aparentemente dignos, todos esses; mas sob o modelo de código aberto e em seu contexto social circundante, eles podem começar a parecer estranhamente irrelevantes. Nós vamos levá-los na ordem inversa.
Minha amiga relata que grande parte do ordenamento de recursos é basicamente defensivo; uma vez que você tenha seu pessoal e máquinas e espaço de escritório, você precisa defendê-los de outros gerentes competindo pelos mesmos recursos e dos altos escalões tentando alocar o uso mais eficiente de um pool limitado.
Mas os desenvolvedores de código aberto são voluntários, auto-selecionados tanto pelo interesse quanto pela capacidade de contribuir para os projetos em que trabalham (e isso permanece geralmente verdadeiro mesmo quando recebem um salário para hackear código aberto). O caráter voluntário tende a cuidar do lado do ‘ataque’ da alocação de recursos automaticamente; as pessoas trazem seus próprios recursos para a mesa. E há pouca ou nenhuma necessidade de um gerente para “jogar na defesa” no sentido convencional.
De qualquer forma, em um mundo de PCs baratos e links rápidos para Internet, achamos bastante consistente que o único recurso realmente limitante é a atenção especializada. Os projetos de código aberto, quando eles naufragam, essencialmente nunca o fazem por falta de máquinas ou links ou espaço de escritório; eles morrem apenas quando os próprios desenvolvedores perdem o interesse.
Sendo esse o caso, é duplamente importante que os hackers de código aberto se organizem para obter produtividade máxima por meio da auto-seleção – e o meio social seleciona impiedosamente a competência. Minha amiga, familiarizada tanto com o mundo do código aberto quanto com grandes projetos fechados, acredita que o código aberto foi bem-sucedido, em parte porque sua cultura só aceita os 5% mais talentosos da população de programação. Ela gasta a maior parte do tempo organizando o desdobramento dos outros 95%, e assim observou em primeira mão a conhecida variação de um fator de cem em produtividade entre os programadores mais capazes e os meramente competentes.
O tamanho dessa variação sempre levantou uma questão embaraçosa: os projetos individuais, e o campo como um todo, seriam melhores sem mais de 50% dos menos capazes? Gerentes atenciosos entenderam por muito tempo que, se a única função do gerenciamento convencional de software fosse converter o menos capaz de uma perda líquida em uma vitória marginal, o jogo poderia não valer a pena.
O sucesso da comunidade de código aberto aguça essa questão consideravelmente, fornecendo evidências concretas de que muitas vezes é mais barato e mais eficaz recrutar voluntários auto-selecionados da Internet do que gerenciar edifícios cheios de pessoas que prefeririam estar fazendo outra coisa.
O que nos traz nitidamente à questão da motivação. Uma maneira equivalente e freqüentemente ouvida de afirmar o ponto da minha amiga é que o gerenciamento tradicional do desenvolvimento é uma compensação necessária para programadores mal motivados que, de outra forma, não teriam um bom trabalho.
Esta resposta geralmente é acompanhada de uma alegação de que a comunidade de código aberto só pode ser invocada apenas para fazer um trabalho que seja “sexy” ou tecnicamente doce; qualquer outra coisa será deixada por fazer (a menos que seja mal feita), a não ser que seja jogada para caçadores de cubículos motivados pelo dinheiro, com os gerentes batendo os chicotes sobre eles. Abordo as razões psicológicas e sociais para ser cético em relação a essa afirmação em Homesteading the Noosphere. Para os propósitos atuais, porém, acho que é mais interessante apontar as implicações de aceitá-lo como verdadeiro.
Se o estilo convencional, de código fechado e altamente gerenciado de desenvolvimento de software é realmente defendido apenas por uma espécie de Linha Maginot de problemas condizentes com o tédio, então ele permanecerá viável em cada área de aplicação individual apenas enquanto ninguém achar esses problemas realmente interessantes e ninguém mais encontra um caminho para desviar deles. Porque no momento em que há uma concorrência de código aberto para um software “chato”, os clientes saberão que ele foi finalmente abordado por alguém que escolheu esse problema para resolver por causa de um fascínio pelo problema em si – que, em software como em qualquer outro tipo de trabalho criativo, é de longe um motivador mais efetivo do que somente o dinheiro.
Ter uma estrutura de gestão convencional apenas para motivar, então, é provavelmente uma boa tática, mas uma estratégia ruim; uma vitória a curto prazo, mas a longo prazo uma perda certeira.
Foi esta a parte 24 da obra, no próximo versículo a vigésima quinta. Deus os abençoe!
