Faço desenvolvimento de software há quase 10 anos. Por esta altura deveria ser gestor de projecto ou arquitecto de software. Na grande maioria das empresas este é o caminho natural de evolução: começa-se como programador, depois programador sénior e depois, se formos empenhados, em 5 anos passamos a gestores de projecto (para onde é que evoluímos nos 30 anos seguinte é um mistério que não parece preocupar ninguém!).

95% dos meus colegas de curso são agora gestores de projecto. Ao que sei passam muito tempo em reuniões e em frente ao outlook. Muitos deles parecem estar satisfeitos com essa posição, porque já estavam saturados de programar ou (e estes poderão ser os melhores gestores) porque nunca gostaram de programar. Talvez alguns estejam satisfeitos porque os benefícios financeiros são muito interessantes (muito mais interessantes do que se ainda estivessem a programar).

Sobram portanto 5%, que se dividem em dois: aqueles que resolveram criar a sua própria empresa e os arquitectos de software. Em relação aos primeiros, queria desejar-lhes muito boa sorte. Respeito-os tremendamente e gostava sinceramente que fossem uma percentagem maior porque são um dos motores de inovação que Portugal desesperadamente precisa. Em relação aos arquitectos de software, gostava de começar pela definição que aparece na Wikipedia, em que esta figura se prende com a complexidade crescente do software nos últimos anos:

The software architect concept began to take hold when object oriented programming (OOP) was coming into more widespread use (in the late 1990s and early years of the 21st Century). OOP allowed ever-larger and more complex applications to be built, which in turn required increased high-level application and system oversight.

De seguida, descreve as suas principais responsabilidades que incluem a definição de metodologias de desenvolvimento e o desenho ou escolha de frameworks sobre as quais assentará o desenvolvimento de uma certa aplicação. Não tenho dúvidas que isto são tarefas essenciais no desenvolvimento de software de qualidade. Mas porque razão tem que ser um arquitecto a fazê-las? Eu faço estas tarefas practicamente desde o início da minha carreira. Tinha eu 6 meses de experiência e já estava a propôr um standard para formatação do código à equipa na qual trabalhava. Sim, eu sei, é uma ideia ridícula mas dêem-me um desconto – eu era um novato! A questão aqui é: não é suposto todos os programadores serem arquitectos de software, na medida em que devem utilizar e melhorar metodologias e ferramentas para atingir os seus objectivos? Ou é suposto haver esta distinção elitista entre os ominiscientes arquitectos astronautas e os vulgares code monkeys?

Não percebo muito de construção civil mas suponho que faça sentido alguém ser arquitecto sem nunca ter montado uma parede de tijolos. O problema é que programar não tem nada a ver com montar tijolos. Só na cabeça de algumas gestores dilbertianos é que isso faz sentido. É que os tijolos do software não são rectangulares, assumem as formas mais bizarras e conseguir juntá-los sem que o resultado pareça um quadro surrealista não é, claramente, uma tarefa previsível ou repetitiva. Além disso, a Engenharia Civil tem centenas de anos de evolução enquanto a Engenharia Informática tem umas décadas. Isto nem se devia chamar Engenharia, pois esta pressupõe que utilizando princípios matemáticos podemos prever o comportamento de um “engenho”. A haver arquitectos certamente incluiriam nomes como Martin Fowler, Kent Beck, Joshua Bloch ou Linus Torvalds. Tanto quanto sei nenhum se intitula arquitecto. Todos eles continuam a programar e a ajudar outros a programar. O próprio Martin Fowler escreveu um artigo “Who Needs an Architect?”, no qual prefere o termo “guia” a “arquitecto”:

(…) came up with the best name I’ve heard so far: guide, as in mountaineering. A guide is a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff.

Note-se, eu acredito na arquitectura de software. Pensar como vamos ligar os componentes de uma aplicação é uma das tarefas mais interessantes no desenvolvimento de software. Mas é algo que tem que ser feito durante a implementação. Pensa-se, experimenta-se, adapta-se, re-experimenta-se, discute-se, re-experimenta-se, refactoriza-se, re-experimenta-se, num ciclo constante de desenvolvimento.

Precisamos então de arquitectos de software?

Sim, mas os arquitectos são também os programadores. Todos. Acabemos com essa distinção ridícula que só existe para justificar progressões na carreira de quem não quer ser gestor de projecto. Ouvi isto muitos anos e continuo a ouvir: “quem quer seguir uma carreira técnica evolui para arquitecto de software”. A teoria é que as empresas não querem pagar salários elevados a quem só programa porque fica demasiado caro. Então criam esta figura de arquitecto, que aparece no início dos projectos, qual Chuck Norris dos computadores, define uma arquitectura fantástica em 3 dias e segue para outro projecto porque este já ficou “bem encaminhado”. As mesmas empresas esquecem-se que programar é aquilo que elas fazem por excelência. Elas são pagas para produzir software que resolva os problemas de alguém disposto a pagar. Tudo o resto: arquitectura, documentação, gestão de projecto, planos de qualidade, etc., são artefactos que giram à volta da programação para complementar o produto final. A tarefa nobre devia ser a programação, não aquilo que anda à volta dela. Citando um artigo da devx:

Deliver code that does what the end users of the code need or want. No more, no less. From Web sites to database applications to games, it’s all about what your code will do for the end user and not about how you did it. Your end users don’t care if you used a Booch diagram or anointed blocks with arrows and written descriptions to communicate to the development team how you were going to build the software. They care only that the software works the way they expect it to.

Ok, agora que enfureci todos os arquitectos de software que possam vir a ler este blog, sinto-me obrigado a admitir que, embora todos os programadores sejam também arquitectos, alguns são melhores arquitectos do que outros, e por isso é normal e desejável que exista um elemento com mais experiência e mais jeito para estas coisas que tenha um papel mais importante no arranque do projecto. A meu ver, esse papel pode-se materializar da seguinte forma, depois de toda a equipa ter acordado numa arquitectura:

• Programar o primeiro componente da aplicação, porque esse servirá de exemplo para todos os seguintes. Além disso, desenvolver o primeiro componente demora muito mais que desenvolver os seguintes, por isso é vantajoso ser desenvolvido por alguém com uma produtividade elevada.
• Escolher o componente com maior número de dependências e implementá-lo, para que seja obrigado a interagir com o máximo de componentes desenvolvidos pela equipa e assim detectar facilmente falhas na arquitectura inicial ou problemas de implementação nos restantes componentes.

Pode parecer uma abordagem pouco científica mas tem funcionado muito bem comigo, espero que ajude outros (arquitectos ou não).

Há uns anos, quando começaram a aparecer os primeiros sistemas de backup online, ou seja, sistemas que mantêm uma cópia de parte do nosso disco rígido num servidor algures na Internet, eu fiquei um pouco céptico sobre a viabilidade deste modelo. Isto era numa altura em que a banda larga ainda não estava generalizada, em que era normal esperar-se uns largos segundos que os sites aparecessem no browser, em que as imagens eram uma dor de cabeça para descarregar. Eu só pensava quanto tempo não demoraria para fazer upload do meu arquivo de Outlook que tem cerca de 1 Gb (e não nos esqueçamos que a taxa de upload – taxa com que a informação é enviada a partir do nosso computador – costuma ser bastante inferior à taxa de download – informação recebida – na nossas ligações caseiras). Nessa altura, confesso que nem experimentei.

Com a massificação da banda larga, a coisa parecia mais promissora e cheguei a utilizar uns quantos serviços para backups online gratuitos, incluindo o famoso Mozy, mas a verdade é que, para quantidades de informação acima dos 100 Mb, o sistema era lento. Lento, no sentido em que tinha que correr durante a noite ou (com sorte) durante a hora de almoço. Acho que nos habituámos um bocado a isso, parecia uma coisa inevitável – se estamos a enviar informação para um servidor algures no mundo através da Internet, que ainda por cima é de borla, não podemos pedir mais.

Avançando um bocadinho mais no tempo, os discos externos passaram a ser tão estupidamente baratos e tão estupidamente mais rápidos que os Mozy’s e afins, que deixou de fazer sentido deixar o portátil ligado todas as noites só para fazer o seu “backupzinho”. Um gajo liga o disco externo no fim do dia, sincroniza os ficheiros com um desses softwares de sincronização que há para aí (normalmente estes discos externos trazem um) e em poucos minutos está feito.

Recentemente, e dado o burburinho à volta do assunto, resolvi experimentar o dropbox. O dropbox não é simplesmente um sistema de backup (é um sistema de partilha de ficheiros entre vários computadores) mas, para efeitos deste artigo, é assim que eu o vejo. Um sistema de backup muito rápido. Muito mais rápido do que eu imaginei que fosse possível, mesmo tendo ligação de banda larga. A grande vantagem que tem sido apontada ao dropbox é sua facilidade de utilização – aquilo instala uma pasta especial no computador chamada “my dropbox” e a gente só tem que arrastar para lá os ficheiros que queremos fazer backup. Mal a gente larga lá o ficheiro, ele começa logo a enviá-lo para o servidor da dropbox. Tão ou mais interessante que a facilidade de utilização é que esse envio pode, dependendo do ficheiro, ser estupidamente rápido. Tipo, já larguei lá pdfs com 10 Mb que são “consumido” em poucos segundos.

Como gosto de perceber como é que estas coisas funcionam, tenho lido alguns artigos sobre este problema e percebi que, de facto, não só é possível que estes sistemas sejam rápidos a fazer upload dos ficheiros como é perfeitamente possível que brevemente estes sistemas venham a ser mais rápidos do que backups para discos externos USB.

Sem entrar em detalhes demasiado técnicos, eis as técnicas que se têm vindo a adoptar para este tipo de sistemas:

1. O envio de deltas em vez do ficheiro completo – Esta técnica consiste em enviar o ficheiro inteiro da primeira vez, mas posteriores alterações ao ficheiro não enviam novamente o ficheiro inteiro, enviam apenas o que mudou (o chamado delta). Por exemplo, imaginem um ficheiro word com 3 Mb ao qual acrescentámos apenas um parágrafo, aumentando o seu tamanho em 100 Kb. Um bom sistema de backup apenas envia esses 100 kb.

2. Comprimir os ficheiros ou deltas antes de enviar – Esta é mais ou menos óbvia. Para certos tipos de ficheiros podem-se obter ganhos assinaláveis, mas para ficheiros já por si comprimidos (por exemplo os mp3) as taxas de compressão não são grande coisa.

Estass duas técnicas são aquelas que, “oficialmente”, o dropbox assume utilizar:

Dropbox tries to be as smart as possible about uploading for the best possible performance. Before transferring a file, we compare the new file to the previous version and only send the piece of the file that changed. This is called a “binary diff” and works on any file type. Dropbox compresses files before transferring them as well. You also never have to worry about Dropbox reuploading a file – it’s smart about this, too. (from http://www.getdropbox.com/help/8)

No entanto, existem técnicas um pouco mais avançadas. Por exemplo, um artigo de 2001 intitulado “Low Bandwidth File System” diz o seguinte:

LBFS is a network file system which conserves communication bandwidth between clients and servers. It takes advantage of cross-file similarities. When transferring a file between the client and server, LBFS identifies chunks of data that the recipient already has in other files and avoids transmitting the redundant data over the network.

Para os meus leitores com um background mais técnico, posso adiantar que este sistema usa funções de hash (SHA-1) que aplica a blocos entre 2Kb e 8Kb no qual divide os ficheiros a enviar. Estas divisões são feitas cuidadosamente de forma a garantir que alterações pequenas nos ficheiros apenas afectam um destes blocos. Basicamente, na altura do upload, o ficheiro é dividido nestes blocos e é calculado o hash de cada um deles (o hash, também conhecido por resumo, é uma string bastanter pequena produzida por uma função matemática quando aplicada um conjunto arbitrário de dados – teoricamente é altamente improvável dois conjuntos diferentes de informação produzirem o mesmo resumo). Aquilo que é enviado ao servidor são apenas os hash’s dos ficheiros. O servidor guarda os tais blocos e os respectivos hashes. Se os hashes que o cliente envia já estiverem no servidor, quer dizer que ele já lá tem o bloco correspondente e por isso não é necessário enviar. Se não estiverem, então o cliente envia apenas essas blocos.

O mais interessante neste sistema é que dois ficheiros diferentes podem, por coincidência (ou não), ter alguns destes blocos em comum. Se pensarmos na quantidade de documentos que produzimos com base no copy&paste de outros documentos, é normal que assim aconteça. Foram feitos alguns estudos que comprovam esta teoria: os ficheiros do nosso disco têm muito mais em comum entre eles do que nós imaginamos. Isso quer dizer, utilizando esta técnica, quantos mais ficheiros tivermos em backup, mais rápido vai ser fazer upload de novos ficheiros. Mas podemos levar isto mais longe – até que ponto os meus ficheiros não são similares (senão mesmo iguais) a ficheiros de outros utilizadores? Certamente alguns pdf’s que fiz download da Internet ou  mp3’s são exactamente os mesmos que os de outros utilizadores. Nesse caso, o tal esquema de hashing irá funcionar na perfeição. E isso explica porque é que o tal pdf de 10Mb que larguei no “my dropbox” foi consumido em poucos segundos. Se calhar, a única coisa que passou na rede foram hashes, porque outro utilizador algures no mundo já fez upload do mesmo ficheiro ou de um muito semelhante.

E isto explica a minha arrojada convicção – se muita gente utilizar o dropbox (ou outro sistema de backup online), pode-se chegar a um ponto em que a probabilidade de haver, algures naquele espaço imenso, um ficheiro muito parecido ou igual àquele que estou a fazer upload é enorme. E mesmo que a largura de banda de um disco externo seja 100x superior à da minha ligação à Net, num dos casos estou a transmitir o ficheiro todo e noutro estou só a transmitir os hashes (~ 20 bytes, mais os envelopes dos pacotes de rede, vá 200 bytes). Se fizerem as contas verão porque, para ficheiros com alguns Mb, começa a ser mais rápido fazermos o backup para estes sistemas e não para o nosso disco externo.

Não queria terminar este artigo sem referir duas coisas. Isto são técnicas ao nível do protocolo, mas existem técnicas ao nível da infraestrutura do servidor também muito interessantes (como transmitir os blocos em paralelo para servidores diferentes com base no hash, etc.). Por último, existe um grande senão neste esquema de hashing (tinha que ser, não é?). É que se o sistema de ficheiros no servidor estiver encriptado, os mecanismos de similaridade entre blocos deixam de funcionar. Ou seja, dois ficheiros parecidos tornam-se totalmente diferentes um do outro quando os encriptamos – faz sentido que assim seja. No entanto, o dropbox encripta os seus ficheiros, o que me leva a pensar que não utilizarão esta técnica…ou terão encontrado uma solução para este problema?

Cada vez mais o desenvolvimento de software está a ser feito através de equipas distribuídas, por elementos geograficamente dispersos que raramente se encontram no mundo real. Penso que este caminho é inevitável – por um lado as pessoas querem melhorar a sua qualidade de vida, não perdendo tanto tempo em transportes ou files, não gastando tanto dinheiro na habitação tradicionalmente cara das grandes cidades, não sofrendo tanto com a poluição e o stress. Por outro lado, se as empresas portuguesas querem desenvolver soluções globais, as suas equipas devem ser igualmente globais, incorporando elementos de diferentes países, culturas e formação. Por último, a inovação passa claramente por não nos limitarmos ao brainpower disponível numa certa area geográfica.

Em contrapartida, vários estudos indicam que a proximidade dos elementos da equipa é um factor fundamental no desenvolvimento de software. Por exemplo, neste artigo (pdf) pode-se ler: “the gains from being at hand drop off significantly when people are first out of sight, and then most severely when they are more than 30 meters apart”. As metodologias ágeis insistem no contacto constante com a equipa e o cliente. Por um lado a comunicação explícita é muito mais fácil quando estamos a trabalhar todos na mesma sala, mas existe um outro tipo de comunicação tão ou mais importante que a comunicação explícita – a observação. Podemos aprender muito só por estar no sítio onde as coisas acontecem, ouvindo pedaços de conversas aqui, exclamações ou outras manifestações emocionais acolá. Chama-se a isto o contexto do grupo: saber quem realmente são os seus elementos, quais as suas características, como devemos falar com eles, aquilo em que são bons e aquilo em que não são bons, etc. Como trazer este contexto para equipas distribuídas?

Uma equipa da universidade de Saskatchewan fez em 2005 um estudo (pdf) que tentava responder ao seguinte: como é que se consegue manter o contexto do grupo em projectos open-source de alguma dimensão? Em particular, como é que o NetBSD, o Apache httpd e o Subversion, projectos de reconhecido sucesso, fazem para evitar, por exemplo, duplicação de esforço?

Após entrevistarem diversos programadores destes projectos, chegaram a uma supreendente conclusão. A solução parece residir em duas ferramentas nada sofisticadas: mailing lists e text chat (IRC). De facto, apesar destes projectos terem em média mais de 20 programadores activos e haver pouco particionamento do código (os commit logs mostraram que a maioria dos ficheiros foram sendo editados por múltiplos programadores), os entrevistados referiram serem raras as colisões e a duplicação de esforços.

De facto, as mailings lists e o text chat funcionam não só para comunicação explícita, mas também para comunicação por observação. Basta acompanhar a mailing list de um destes projectos durante alguns dias para ficarmos a saber quem pertence à equipa, quem trabalha no quê e quem irá trabalhar no quê assim como aferir um pouco a personalidade dos seus intervenientes. Obviamente, isto só funciona porque todos têm o cuidado de partilhar as suas intenções e o seu estado actual através destas ferramentas. Apesar da perda de eficiência que advém do facto de registarmos por escrito tudo o que fazemos (perde-se tempo a escrever um mail para cada coisa que fazemos ou planeamos fazer), toda a gente o faz, nestes projectos. Porquê?

Bem, provavelmente tem a ver com a motivação que está por trás de quem trabalha em projectos open-source: a reputação social. Uma das formas de construir essa reputação é precisamente participando activamente nas discussões do projecto, escrevendo mails com boas ideias, bem escritos e tecnicamente bem apoiados que mereçam elogios da comunidade. O desejo de criar esta reputação também explica a escalabilidade deste sistema tão simples. Muita gente coloca questões na mailing list na esperança que alguém responda, nomeadamente algum expert nessa área. Ora esse expert pode não estar disponível, ou pode não ter tempo para responder a essas solicitações. É comum alguém menos expert (ou pelo menos reconhecido como menos expert) aproveitar para mostrar as suas qualidades e responder à questão. Como a resposta também vai para a mailing list em geral, será devidamente avaliada por outros experts que eventualmente a corrigirão (embora não seja normalmente necessário). Se compararmos este mecanismo tão simples com o formalismo dos “module maintainers” (pessoas que assumem a responsabilidade de certos módulos), percebemos que este último não é escalável – muitas questões não serão respondidas em tempo útil já para não falar da duplicação de perguntas.

Aquilo que mais me interessou no estudo foi tentar perceber até que ponto este sistema de partilha de contexto funcionaria num projecto comercial, no âmbito de uma empresa. Há duas pistas no artigo que me levam a pensar que não funcionará:

• Alguns entrevistados referiram que em situações de grande pressão temporal (por exemplo a correcção de uma vulnerabilidade de segurança) surgiam por vezes problemas de coordenação, havendo duplicação de esforços. Os projectos closed source comerciais estão tipicamente mais sujeitos a pressões de tempo e deadlines apertadas que os projectos open-source, pelo que a perda de eficiência associada à actualização explícita constante do nosso estado poderia não ser compatível com os prazos do projecto.

• A motivação para adquirir reputação social por esta forma quase não existe nas empresas. Infelizmente, essa reputação está muito mais associada a cargos e hierarquias (e em alguns casos, antiguidade). Ninguém é promovido por discutir activamente numa mailing list mas sim por apresentar resultados – nesse sentido, as pessoas concentram-se em desenvolver o máximo de código e não a falar sobre ele. As colisões são raras porque o código é altamente particionado. Ao contrário dos projectos open source, é comum encontrarem-se ficheiros que são mexidos apenas por quem os criou. É claro que isso levanta outros problemas relacionados com a manutenção dos mesmos que fogem um pouco ao tema.

Acima de tudo, actualmente nada bate a eficiência de comunicação directa de uma equipa que trabalha no mesmo local. Mas será este modelo sustentável? Como referi na introdução deste artigo, a dispersão das equipas parece-me uma tendência inevitável. Claramente o desafio será encontrar mecanismos eficientes de partilha de contexto que as pessoas realmente utilizem e os projectos open source serão uma referência incontornável neste caminho, pois são indubitavelmente o expoente máximo da colaboração em equipas distribuídas.

Em praticamente todas as empresas de serviços existe um cancro com o qual temos que viver, quer queiramos quer não – o registo de horas gastas por contrato/projecto. Normalmente, esse registo é feito utilizando uma aplicação mais ou menos sofisticada (muitas vezes é apenas o excel) onde cada empregado insere diariamente quais as tarefas que executou e quantas horas gastou. A obrigatoriedade desse registo prende-se com a necessidade (legítima) de perceber quanto está a custar um determinado projecto, verificar se estamos a perder dinheiro, estimar melhor futuros projectos, etc. Acho que ninguém duvida da utilidade destes números – nenhuma empresa sobrevive muito tempo sem ter alguma percepção/controlo sobre a parte financeira dos seus projectos (excepto a Ben&Jerry’s, que no primeiro ano de existência não faziam ideia se estavam perder ou ganhar dinheiro com aquilo).

O problema é que a grande maioria das pessoas não gosta de ter de fazer esse registo. Algumas chegam a odiar essa tarefa, considerando-a a materialização suprema da burocracia, um empecilho completo à produtividade, um resquício da mentalidade de linha de montagem da era industrial, um “picar o ponto” disfarçado. Estou a falar de pessoas responsáveis, empenhadas e que gostam realmente de produzir coisas e não de perder tempo a registar que as produziram. Resultado: existe uma enorme resistência quando se introduzem estas ferramentas. Como é que garantimos então que toda a gente utiliza a ferramenta? Simplesmente impomos a sua utilização e os gestores das equipas usam a sua autoridade hierárquica para garantir que esta norma é cumprida. É claro que, como com qualquer norma que é simplesmente imposta, os objectivos saem logrados. As pessoas limitam-se a aldrabar o sistema de modo a terem o mínimo trabalho possível – por ex., em vez de registarem 2h na tarefa A, 2h na tarefa B e 4h na tarefa C, registam 8h na tarefa C e não se chateiam mais. Claro que qualquer análise financeira sobre dados viciados está comprometida à partida e, em suma, estas ferramentas dão apenas a ilusão de que estamos a controlar os custos.

Eu tenho uma teoria porque é que isto acontece. O erro que se comete é pensar na ferramenta de registo de tempos como uma ferramenta individual (como é por exemplo o word ou a calculadora), quando devia ser encarada como uma ferramenta cooperativa (como é um wiki ou um fórum de discussão). De facto, se encararmos o registo de tempos como algo em que todos os elementos de uma equipa estão a contribuir para um objectivo comum, começamos a perceber o que está a falhar.

Para começar, aquilo que o grupo ganha tem que superar o custo individual de introdução dos tempos. Ou seja, o elemento do grupo tem que sentir que ganha mais (ainda que indirectamente) ao contribuir para o grupo do que a alternativa individual (que é não utilizar a ferramenta). É por isso que os wikis funcionam – embora tenhamos o custo de escrever um artigo, sabemos que esse artigo vai ser revisto e melhorado por outros com custo zero (para nós). Sabemos ainda que existem outros a escrever artigos dos quais nós vamos beneficiar (com custo zero).

Por vezes, tem que haver um benefício individual a somar ao benefício do grupo, para compensar o custo: esta teoria poderá explicar o sucesso da ferramenta de bookmarking social delicious – primeiro que tudo eu faço bookmarks para mim próprio (acessíveis em qualquer computador), depois eventualmente irei partilhá-los com outros.

Voltemos então ao registo de tempos e coloquemo-nos na pele do elemento da equipa. Ele tem o custo de introduzir os seus tempos e não tira qualquer benefício disso. Dizem-lhe que beneficia a empresa, mas se ele não tiver acesso às métricas, aos gráficos, no fundo ao output da ferramenta, esse benefício não será claro. O problema é  que normalmente esse output só está disponível aos gestores de projecto e à direcção – o “povão” limita-se a fornecer os inputs. Mas mesmo que o output estivesse disponível para todos, ainda assim creio que não seria suficiente. Este é um dos casos em que tem que haver um benefício individual, para além do benefício do grupo. Porque não utilizar essa ferramenta para gestão individual de trabalho? O movimento GTD e similares deram origem a uma profusão de ferramentas de “produtividade”, algumas com sucesso considerável. Porque não mesclar a ferramenta grupal (de registo de tempos) com a ferramenta individual (de gestão individual de tarefas)?

Outro dos problemas típicos de ferramentas individuais é a excessiva normalização e a rigidez da sua utilização (formulários, dropdowns para tudo, muitas validações, …). Em ferramentas colaborativas, as regras não podem estar definidas à partida – o software tem que se ir adaptando ao comportamento emergente dos seus utilizadores (veja-se como exemplo a utilização de hashtags e o RT do twitter). No caso em questão, a definição e organização das tarefas nas quais se reportavam horas devia ser completamente aberta, permitindo ao grupo que convergisse numa metodologia que espelhasse a maneira como realmente trabalham (e que permitisse variações de grupo para grupo e de projecto para projecto).

Há muitos outros mecanismos que têm vindo a ser estudados no âmbito do software social que trariam certamente mais valias para este processo, como os mecanismos utilizados em jogos: não haverá semelhanças entre os objectos que vamos coleccionando num jogo e a nossa colecção de tarefas realizadas? Na realidade, a partir do momento em que fazemos o shift e passamos a encarar o registo de tempos como uma tarefa grupal, essa mal-amada tarefa passa rapidamente de monótona e inútil para divertida e importante, e os benefícios que se tiram dela (os outputs) passam realmente a ser decisivos no sucesso de uma empresa.

O recrutamento é um tema que me interessa particularmente pois defendo que o principal ingrediente de qualquer projecto de sucesso é a equipa que o desenvolve. Embora existam inúmeros factores a ter em conta (a começar pelo factor sorte), quase me atrevo a dizer que a empresa com um processo de recrutamento perfeito é a empresa perfeita. Claro está que não existe semelhante empresa, até porque não é possível definir o processo de recrutamento perfeito, mas não é por acaso que os líderes de mercado se caracterizam por serem extremamente exigentes nesse processo.

Se na fase do recrutamento nos preocupamos em descobrir e aliciar os melhores elementos para integrarem a nossa equipa, é igualmente importante garantir que essa equipa se mantém estável, sem grande rotatividade. Demora meses a formar totalmente uma pessoa (no sentido de ela chegar ao máximo da sua produtividade) e poderá demorar anos a construir uma equipa sólida, unida e em que as competências se complementam de forma harmoniosa. Infelizmente é raro encontrar essas equipas mas quando as encontramos é impossível ficar indiferente à energia que emana daquele grupo, lembrando uma imparável locomotiva a alta velocidade, somando sucessos atrás de sucessos.

O desafio consiste portanto em (1) constituir uma equipa excelente e (2) manter essa equipa sem grandes alterações o máximo de tempo possível. Isso leva-me ao dilema que dá título a este artigo. Devemos contratar pessoas sem experiência profissional (por exemplo, que acabaram agora o curso) para que seja mais fácil formá-las e integrá-las na cultura da empresa? Ou é preferível ir buscar pessoas já com alguma experiência profissional e porventura com vícios que não se coadunam com o espírito que pretendemos? Ambas as hipóteses têm vantagens e desvantagens:

A primeira é a preferida pelas grandes consultoras, precisamente porque têm uma cultura muito própria, investem imenso na formação interna (que chega a roçar a lavagem cerebral) e, verdade seja dita, poupam bastante em salários (mais baixos). De facto, pela minha experiência posso confirmar que esta hipótese é normalmente mais vantajosa nomeadamente a nível da integração das pessoas nas equipas. Aquilo que lhes possa faltar em experiência e maturidade é claramente compensado pela facilidade com que absorvem as metodologias, técnicas e até a maneira de estar da empresa. Também oferecem tipicamente menor resistência à mudança e o facto de receberem menos faz com que o custo em caso de má contratação não seja tão elevado.

Dito assim, pareceria que não havia dúvidas quanto a esta questão, mas tenho assistido a um fenómeno que faz destabilizar o raciocínio e que tem a ver com a dificuldade em manter as equipas. As pessoas gostam/precisam de experimentar vários ambientes de trabalho antes de “assentarem praça”. Isto é especialmente verdade para os melhores elementos, aqueles que são apaixonados pelo seu trabalho e sempre ávidos de conhecimento. Ora acontece com alguma frequência que esses elementos que entraram sem experiência profissional até estão satisfeitos com o seu trabalho e com a empresa mas, após alguns anos, começam-se a interrogar: “como será o mundo lá fora? não estarei a estagnar aqui?”. E saem. Se calhar vão fazer a mesma coisa para outra empresa, mas essa não é a questão – eles tinham de fazer isso, tinham de arranjar um ponto de comparação pois só assim podiam crescer internamente. É completamente legítimo pensar assim, e pessoalmente sempre apoiei todos os meus amigos/colegas que tomaram essa decisão.

Mas o dilema agudiza-se. Por um lado, é melhor contratar “virgens” mas mais cedo ou mais tarde os “virgens” vão querer conhecer outras realidades. Por outro lado, quem já “conheceu o mundo”, já satisfez o bichinho e é provável que se mantenha na empresa mais tempo. Só que essas pessoas invariavelmente têm mais problemas de integração, trazem vícios comportamentais difíceis de mudar. Algumas nunca se chegam a integrar completamente, impedindo a tal coesão essencial para as equipas funcionarem. Onde estará o equilíbrio?

Embora existe uma distinção clara entre jogos e software “utilitário” começando logo no objectivo inerente aos mesmos, isso não quer dizer que as lições de um não possam ser aplicadas ao outro. Por exemplo, uma das características essenciais de um jogo é ser divertido (o chamado fun factor), e os respectivos mecanismos são estudados há vários anos, tendo sido postos em prática em dezenas de jogos.  O mesmo não se pode dizer do restante software, cuja investigação se tem centrado em maximizar o valor para o utilizador, seja fazendo uma tarefa mais rapidamente, mais facilmente, com menor custo, etc. Porque não hão-de as aplicações tradicionais ser, além de úteis, divertidas? Não será a experiência de utilização tão ou mais importante que a utilidade das mesmas?

Amy Jo Kim, CEO da Shuffle Brain, tem estudado como se pode trazer o lado divertido dos jogos para o software, mais especificamente para o software social. Ela fez recentemente uma apresentação onde descreve 5 mecânicas de jogo para aumentar o fun factor e como estas podem ser aplicadas fora dos jogos:

• Collecting – Muitos jogos se baseiam na noção de colecções, items que vamos acumulando para utilizar mais tarde ou simplesmente para fazer parte do nosso portfolio. Este factor está bem presente nas nossas colecções de fotos no flickr ou músicas no last.fm.
• Points – A ideia de irmos ganhando pontos por concretizar tarefas é central a muitos jogos, e é um factor essencial para a nossa experiência. Existem vários equivalentes a isto no software social, como os ratings ou o número de visitas (quando públicos) aos conteúdos por nós produzidos.
• Feedback – O feedback é essencial num jogo para percebermos a dinâmica do mesmo, quando fizemos bem ou fizemos mal, para nos motivar (ou deprimir). Os comentários de um blog ou do youtube são talvez o equivalente mais imediato deste mecanismo.
• Exchanges – As trocas são uma das bases da interacção social e têm sido usadas pelos jogos para utilizar a (sdmpre surpreendente) dinâmica de grupos como forma de aumentar o interesse dos jogadores. Os twitter replies utilizam eficazmente este mecanismo para os mesmos objectivos.
• Customization – A criação do nosso personagem no jogo pode ser um factor importante na construção do ambiente de fantasia que caracteriza muitos jogos, mas mesmo sem fantasia, a customização da nossa página do twitter ou do nosso blog faz parte da nossa necessidade por transmitir uma identidade própria e diferenciada (e por vezes um pouco fantasista).

Para mais pormenores, não deixem de espreitar a apresentação:

link: http://www.slideshare.net/amyjokim/fun-in-functional-2009-presentation

UPDATE: Descobri por acaso que o PELF escreveu um artigo muito bom sobre esta apresentação. Recomendo a sua leitura.