Erwin Rommel começou por ter um papel importantíssimo na invasão da França em 1939, utilizando uma técnica que aperfeiçoou até à quase perfeição: a Blitzkrieg, que consiste em concentrar o ataque numa força que que se movimenta muito rapidamente e em profundidade (de tal forma, que muitas vezes acaba por atacar o inimigo por trás!). Era tal fanático desta técnica que, mesmo quando ordens superiores lhe diziam para parar, ele ignorava-as e avançava intrépido surpreendendo e rompendo literalmente pelo inimigo adentro. Voltou a usar esta técnica com grande sucesso no Norte de África onde, mesmo em inferioridade numérica e com tanques e apoio aéreo mais fracos, conseguiu em 3 semanas retomar o controlo da Líbia. Teria chegado ao canal do Suez (uma conquista que poderia ter sido crucial no desfecho da guerra) se não tivesse esbarrado no bilhante general inglês Bernard Montgomery.

Bernard Montgomery era, ao contrário de Rommel, muito cauteloso e só avançava após ter acumulado uma força esmagadora de efectivos e abastecimentos que geria com uma capacidade logística extraordinária. Essa abordagem podia implicar ter tropas paradas durante um mês ou mais mas quando avançava levava tudo atrás como se fosse um tsunami. Durante o período de paragem, treinava intensamente as suas tropas simulando o mais realisticamente possível o cenário que iriam encontrar. Por exemplo, a primeira coisa que fez quando assumiu o comando do 12º Corpo do exército (que segundo ele estava muito à vontade) foi introduzir corridas de corta-mato regulares para todos, incluindo oficiais. Alguns destes últimos queixaram-se que, atendendo à sua ideia e peso, o exercício poderia ser fatal. Montgomery respondeu que era por isso mesmo que deveriam correr e morrer, a fim de que os pudesse substituir mais cedo.

Por último, o general norte-americano George Patton só apareceu mais tarde mas teve um papel crucial no avanço para a Alemanha após o desembarque na Normandia, em 1944. Patton era muito parecido com Rommel e gostava igualmente de utilizar a Blitzkrieg. Aliás, as suas ordens foram muito similares às de Rommel quando invadiu a França. Disse-lhes que avançassem sempre e ignorassem os flancos. Não queria receber relatórios a informá-lo quais as posições que estavam a ser mantidas: “Avançamos constantemente e a única coisa que nos interessa manter é a proximidade ao inimigo“. Chegou a ultrapassar as tropas alemãs que retiravam rapidamente para a Alemanha.

Além da estratégia utilizada, os três partilhavam um carisma fortíssimo e eram admirados (quase venerados) pelas suas tropas. Todos tinham estudado um livro clássico de estratégia militar de Von Clausewitz, segundo o qual o resultado de qualquer conflito é determinado pela razão entre “meios” e “vontade de lutar” em cada lado. Uma vez que não tinham grande controlo sobre os meios (o número de soldados e tanques não era algo que conseguissem manipular) aperfeiçoaram ao máximo a capacidade de incutir nas suas tropas a tal “vontade de lutar”. Por exemplo, ao contrário do que era costume na altura, todos eles circulavam pelo meio das tropas durante os treinos e durante as batalhas. Davam o exemplo em vez de mandarem fazer – em muitas investidas de alto risco, eles próprios iam no pelotão da frente. Conduziam frequentemente palestras motivacionais para as suas tropas nas quais afirmavam com tal veemência que iam ganhar a batalha que todos os soldados acreditavam fervorosamente na vitória e nem equacionavam a hipótese de derrota (e muito menos de retirada ou desistência). Até a maneira como apareciam fazia parte dessa motivação: Montgomery mandou instalar uma luz colorida no tecto do seu carro, para que todos o vissem nos exercícios nocturnos.

Ainda que não dê grande valor ao paralelismo recorrente entre estratégia militar e estratégia empresarial nem ande para aí a citar exemplos da “Arte da guerra” para justificar o comportamento de mercados competitivos, não pude deixar de reparar nas reminiscências entre Rommel, Montgomery e Patton com alguns líderes de empresas tecnológicas.

Por exemplo, a estratégia Montgomery de acumular tropas durante grande períodos de tempo enquanto as treina intensamente para o combate faz-me lembrar claramente Steve Jobs. A Apple lança novos produtos muito ocasionalmente mas quando sai um novo produto está extremamente bem equipado (em tecnologia, design, funcionalidades, robustez, etc.) varrendo avassaladoramente o mercado respectivo. Durante esses longos períodos, essas equipas ensaiam novas funcionalidades, alheando-se quase por completo ao “avanço” das restantes empresas. É um risco que correm mas a verdade é que, tipicamente, quando os concorrentes estão prestes a furar a Apple, esta lança nova investida que os volta a colocar muito à frente no mercado.

A estratégia inversa (Blitzkrieg) de avançar rapidamente sem parar sequer para perceber o que se passa à volta lembra-me um líder menos conhecido: Loic Le Meur. Para quem não sabe, ele é o fundador e CEO do Seesmic, um agregador de feeds de diversas aplicações sociais como o Twitter e o Facebook. Já acompanho a evolução do Seesmic há algum tempo (continua a ser a minha aplicação de twitter no android) e fico pasmado com a velocidade estonteante com que uma pequena equipa (42 neste momento, segundo o linkedin) produz novos clientes de Seesmic e novas funcionalidades todos os meses. Embora inicialmente o Seesmic tivesse sido pensado como um serviço de partilha de vídeos tornou-se entretando (Março de 2009) um cliente desktop de Twitter e Facebook. Poucos meses depois lançou a versão Web, ao que se seguiu a versão Desktop em Silverlight, uma versão para Blackberry, outra para iPhone, outra para Android…tudo isto enquanto adicionava novas funcionalidades como geolocalização, pesquisa, múltiplas contas, google buzz, etc. Se esta estratégia irá dar frutos, só o futuro o dirá, pois até agora a empresa tem-se aguentado à conta de capital de risco e, tanto quanto sei, (ainda) não é rentável.

Olhando só para os aliados, temos dois generais com visões opostas que se completaram para levar a cabo a derrota dos alemães. Por um lado, só a capacidade de planeamento de Montgomery poderia garantir que o desembarque na Normandia tivesse sucesso. A complexidade logística de desembarcar centenas de milhares de tropas nas praias, em conjunto com o respectivo equipamento e abastecimentos é algo que exige meses de preparação prévia. Uma vez em terra, o avanço até à Alemanha queria-se rápido e fulminante, para não dar tempo às tropas alemãs para se reorganizarem. Aí, o papel do intrépido e impaciente Patton foi fulcral.

Situações diferentes exigem estratégias diferentes e, se quisermos tirar alguma lição para a estratégia empresarial, diria que as empresas com os dois tipos de liderança e que saibam usar a liderança certa no momento certo, terão mais hipóteses de sucesso.

Recentemente, lançou outro livro “Cognitive Surplus” que me apressei a encomendar. O livro começa com um facto interessante: por ano, a população americana gasta cerca de 200 biliões de horas a ver televisão. Por outro lado, o total de tempo gasto a fazer actualizações na Wikipedia é de 100 milhões de horas.

Provavelmente não vos surpreende esta desproporção, tal como a mim não me surpreendeu (apesar de ter ficado espantado com a quantidade de tempo que se gasta na wikipedia!). O que Clay Shirky defende é que esta desproporção existe  apenas porque, até há pouco tempo, não tínhamos alternativa para gastar o nosso tempo livre com baixo custo e que se coadunasse com o estilo de vida moderno (horário de trabalho alargado, famílias pequenas, isolamento social, …).

De facto, a geração mais nova (até aos 25 anos) já passa mais tempo na Internet do que a ver televisão. Pode ser a jogar WoW ou a ver filmes estúpidos no Youtube, mas não deixa de ser uma forma mais activa de passar o tempo. Pegando no exemplo do Youtube, é importante perceber que se trata de algo mais do que a mera difusão de vídeo – há comentários, há partilha e há, acima de tudo, a possibilidade de fazermos os nossos próprios vídeos. E tudo isto está tão facilitado que o esforço adicional para passar de consumidor (passivo) para produtor (activo) é practicamente nulo.

Não deixa de ser fascinante imaginar o potencial que há em pegar na bola gigante de tempo inútil que se passa em frente à televisão (o tal excedente cognitivo) e aplicá-lo de forma mais activa a produzir/comentar/partilhar informação. Podem ver uma apresentação do Clay Shirky fez na TED sobre este assunto aqui.

E vocês? Já começaram a usar o vosso excedente cognitivo?

Os testes unitários são pedaços de código que testam outros pedaços de códigos.

Supostamente, para se chamarem unitários, os pedaços de códigos a testar têm que ser pequenas unidades, mas como essa definição é ambígua, digamos que esses pedaços de código testam funções. Uma função tem inputs e outputs e os testes unitários verificam que para certos inputs obtenho sempre certos outputs. A parte do “sempre” é a mais interessante, pois abre caminho para a automatização desses testes. Posso ter uma ferramenta que corre todos os testes unitários sempre que eu quiser: de cada vez que compilo, de cada vez que faço commit das alterações no sistema de controlo de versões, de cada vez que gero um executável para o cliente, etc. Se algum teste falhar, serei avisado por essa ferramenta, e corrigirei um potencial bug em produção. Quando todos os testes passarem, terei mais confiança no código que acabei de desenvolver.

Mas ter confiança naquilo que faço não é o objectivo do desenvolvimento de software, quando muito será um (desejável) efeito secundário. O objectivo é que a aplicação resolva um dado problema sem erros.

Antes de continuar, gostava de partilhar convosco que desenvolvi a minha primeira bateria de testes unitários há 10 anos, quando o Kent Beck e o Erich Gamma lançaram o JUnit, uma das primeiras bibliotecas (talvez a primeira) criadas para auxiliar o desenvolvimento destes testes. Na altura, desenvolver baterias de testes unitários que corriam automaticamente quando se fazia uma versão da aplicação era um esoterismo. Entretanto, tornou-se prática mais comum e muitas das frameworks mais recentes trazem incluídas de raiz suporte para testes unitários, funcionais, etc. Surgiu inclusivamente o TDD (Test Driven Development) que leva a coisa mais longe – os testes devem ser desenvolvidos antes do código em si.

Desde essa primeira experiência com o JUnit que tenho acompanhado a evolução das metodologias  e ferramentas de testes. E tenho tentado utilizá-las nos projectos em que participo. Sem desprimor para os tutoriais e livros sobre testes unitários, os projectos em que participo são um pouco mais complexos que contas bancárias nas quais queremos verificar se o saldo nunca fica negativo. Tive alguma dificuldade em aplicar os princípios simplistas dos livros à complexidade de projectos que dependem de imensas interfaces, desde as várias Bases de Dados envolvidas aos Webservices, passando pela camada gráfica (GUI) e pelo processamento de quantidades massivas de ficheiros. Eu sei que devo substituir as interfaces por Mocks ou Stubs (objectos fictícios que emulam os objectos reais) ou usar Bases de Dados descartáveis que residem em memória só durante a execução dos testes. E fiz isso em vários projectos. Só que deparei-me com dois problemas:

• O custo de desenvolver testes unitários recorrendo a Mocks é enorme. Testar se o saldo de uma conta bancária nunca fica negativo é simples. Testar se foram feitas as queries correctas nas várias BDs, com múltiplos JOINs, GROUP BY’s e o diabo a quatro, é um pesadelo. Ou temos uma BD completamente populada com todos os casos possíveis e imaginários de acontecer em produção, ou dizemos ao Mock object quais são as queries que devem ser executadas e verificamos se realmente foram executadas (duh!). Mas este não é o problema mais grave…
• A maioria dos bugs que aparecem em produção não podiam ter sido previstos num teste unitário. Depois de o bug acontecer é (relativamente) simples fazer um teste unitário que o provoque (esta é aliás uma boa prática, nunca corrigir um bug sem primeiro desenvolver o respectivo teste unitário). Mas essa não é a questão. Em software complexo, a menos que os programadores sejam completamente desleixados, os bugs que acontecem em produção resultam de uma combinação de factores que é muito difícil prever. Muitas vezes resultam de coincidências ou de circunstâncias ambientais que nunca acontecerão na máquina de desenvolvimento. Resultam de problemas nas interfaces com outros sistemas e não no algoritmo da aplicação. Este é o problema mais grave.

Por curiosidade, fui à procura de issues abertos no confluence, um wiki desenvolvido pela atlassian que por acaso é também uma das minhas aplicações preferidas e deparei-me com este, relacionado com o RTE (Rich Text Editor) para editar artigos:

Insert line 1 of text into RTE
Insert line 2 of text into rte, highlight text and use ctrl-6 to make it a heading
Use backspace key to back from beginning of line 2 to the end of line 1
Look at the wiki markup. Line 2 will have tags around it for color and an asterisk for bold.

Reparem que este erro nem sequer tem interacções com Bases de Dados ou outras mas resulta de um conjunto de condições quase imprevisíveis (e só acontece em Safari!). Alguém poderia prever este erro? O facto de se desenvolver um teste unitário para resolver este erro dá-nos alguma garantia que não vai aparecer outra combinação estranha de condições no RTE?

A verdade é a seguinte: com mais ou menos custo, todas as funções de uma aplicação podem estar cobertas por testes unitários. Mas o que eu me tenho apercebido é que esses testes, na prática, não reduzem substancialmente o número de bugs em produção. E o que interessa é não ter bugs. Se preferirem o lado económico da questão digo-vos que o custo de cobrir a totalidade de uma aplicação com testes unitários é proibitivo. Cobrir 80% da aplicação é fácil. Mas os bugs com verdadeiro impacto estão normalmente nos 20% que faltam. É verdade que 80% é melhor que nada. Mas eu não me iludo com estes números. Prefiro uma equipa de testes a “bombardear” a aplicação durante uma semana que uma equipa de desenvolvimento a programar testes unitários durante um mês.

O cliente não quer saber se os programadores fazem testes unitários, quer saber se a aplicação não tem erros. No entanto, leio e oiço muitos programadores a gabarem-se que fazem testes unitários e como tal o seu software tem uma qualidade superior. Isso é puro narcisismo baseado em teorias. E pode também ser um placebo muito perigoso, pois corre o risco de tornar os programadores desleixados ou pior ainda, dar ideias a uns quantos gestores de que afinal podemos usar programadores incompetentes pois os testes unitários vão apanhar as borradas deles.

Há quem chame a isto o paradoxo do pesticida, aqui bem descrito:

The Damning Evidence: Things like Test Driven Development and Unit Testing give us the false impression that we’ve quashed the major bugs in the system when all we’ve really done is quash the obvious bugs, leaving the more subtle, painful, and difficult ones behind.  Many of these types of bugs are related to concurrency or particular complex data conditions that are difficult to express as unit tests.

Before anyone rants about this comment section claiming I think TDD is bad, or unit testing is evil, please hear me correctly:  Unit testing and TDD leave a false sense of security that we’ve managed to create stable software. They are a starting point to more complete testing, but they are not the end.  The meaningful problems are often in integration with other systems and modules, that are often left out of testing plans because of time constraints, schedule pressures, laziness and sometimes plain arrogance.

Exceptions: Small, simpler systems rarely suffer from these issues because testing is much easier.  This is mostly a complex software problem, at a level of enterprise development, large applications (e.g. Microsoft Word), or operating systems.

Mais recentemente, houve um pequeno arrufo entre o Bob Martin e os criadores do Stackoverflow precisamente sobre a utilidade dos testes unitários. Eis um excerto do Joel:

There’s a debate over Test Driven Development… should you have unit tests for everything, that kind of stuff… a lot of people write to me, after reading The Joel Test, to say, “You should have a 13th thing on here: Unit Testing, 100% unit tests of all your code.”

And that strikes me as being just a little bit too doctrinaire about something that you may not need. Like, the whole idea of agile programming is not to do things before you need them, but to page-fault them in as needed. I feel like automated testing of everything, a lot of times, is just not going to help you.

Apesar disto tudo, não acho os testes unitários inúteis. Os princípios que estão por trás fazem todo o sentido e vou continuar a acompanhar a evolução das ferramentas nesta área. Sempre que desenvolvo componentes (bibliotecas) que vão ser utilizados e reutilizados em diversos projectos, crio os respectivos testes unitários. Esses componentes são normalmente independentes de factores externos e o custo de desenvolver os respectivos testes é facilmente amortizado pelos vários projectos que os utilizam. Mas a maioria dos projectos não são bibliotecas comuns para reutilização. São aplicações muito específicas e começa a ser difícil justificar o custo, ainda para mais quando não existe uma redução significativa dos bugs que aparecem em produção. Para reduzir bugs, é tremendamente mais efectivo fazer code-review (pair programming é um nome pomposo para code-review, que já existia muito antes do XP) ou ter equipas dedicadas só aos testes.

Resta-me referir uma grande vantagem dos testes unitários de que raramente se fala – documentação: não existe melhor forma de documentar uma função do que escrever os respectivos testes unitários. Bate de longe qualquer documento de especificação e inclusivamente os comentários do código, por uma razão muito simples. Nunca fica obsoleta, caso contrário o teste falha.

• Autonomia - Possibibilidade de trabalharmos à nossa maneira, no local e no horário que considerarmos mais conveniente, com planeamento e regras definidas por nós e não por outras pessoas, nomeadamente o “chefe”.
• Mestria - Possibilidade de desenvolvermos o nosso talento, de melhorarmos as nossas capacidades, de sermos bons em algo.
• Propósito – Possibilidade de fazer algo com impacto no mundo, que nos transcenda.

Vídeo – Drive: The surprising truth about what motivates us

Duas notas pessoais:

• O dinheiro é importante, mas apenas para garantir um nível suficiente de conforto. Como o Daniel Pink diz: “Pay people enough to take the money issue off the table”. A minha experiência diz-me que, para pessoas realmente boas e que gostam da sua profissão, a quantidade de dinheiro necessária para elas se deixarem de preocupar com isso é menor do que imaginam…
• Isto só funciona para tarefas não-mecânicas. E não nos iludamos – muitos profissionais altamente especializados passam o dia (infelizmente) a fazer tarefas mecânicas, apesar de terem capacidade para muito mais. E como tal, exigem grandes compensações monetárias, que nesses casos funcionam muito bem.

Isto não me faz sentido. Mesmo os mais capitalistas admitirão que a (desejável) competição entre empresas favorece o consumidor, ou seja, contribui para uma melhoria da qualidade de vida. Mas, estranhamente, essa obsessão pela satisfação do consumidor raramente deriva de uma obsessão pela satisfação própria. O que não deixa de ser irónico. Isto faz-me lembrar aquele ditado popular: “Para fazeres os outros felizes, sê tu primeiro feliz”. Quando olho à minha volta, vejo empresas com empregados infelizes a tentarem tornar os seus clientes felizes.

As pessoas que colocam a vida profissional à frente da vida pessoal são muitas vezes consideradas as mais produtivas e premiadas nas empresas, mas a mim não me convencem. Estou certo que existirão excepções, mas a verdade é que essas pessoas acabam por causar mais problemas no longo prazo:

• Podem desmotivar toda uma equipa ao trabalharem frequentemente noite adentro – ou os restantes membros ficam igualmente noite adentro por solidariedade e lixam também eles a sua vida pessoal, ou vão para casa sentindo-se mal por o seu colega de equipa ter ficado a trabalhar;
• São uma panela de pressão permanente, que pode rebentar a qualquer momento, sem aviso prévio. Um dia atingem o limite e, de repente, têm um esgotamento nervoso ou “passam-se da marmita” e abandonam o projecto;
• Como só vêem trabalho à frente, têm uma visão afunilada da realidade. Do ponto de vista estratégico, essa visão pode ser catastrófica para os projectos;
• A sua reduzida vida familiar/social limita-lhes a capacidade de tacto e empatia no relacionamento com os colegas.

Infelizmente, as pessoas que prezam a vida pessoal também têm um problema. Acham sempre que a vida pessoal é difícil de compatibilizar com a vida profissional por culpa dos outros. Dizem que a culpa é da empresa, que explora os seus empregados até ao limite. Ou então dizem que a culpa é do mercado concorrencial, que esmifra as empresas e não lhes dá outra hipótese senão esmifrar os seus empregados. E resignam-se com a situação porque acham que está fora do seu alcance mudar isso.

E têm razão. O mercado é realmente lixado. Muitos patrões até gostariam de deixar os seus empregados sair mais cedo ou ter mais dias de férias. Vá, muitos também não. Mas alguns, certamente. Só que eles não podem, porque senão a empresa deixa de ser competitiva e vai à falência e aí podem todos ir de férias muito tempo. É preciso ter consciência disto. E sentido de responsabilidade. Mas isto não implica que nos resignemos.

Pessoalmente, sempre prezei bastante a minha vida pessoal. Sou apaixonado pelo minha profissão mas não é só a minha profissão que me apaixona. No entanto, reconheço que tive muitas dificuldades em equilibrar as minhas paixões. Não sei se acontece isto noutras áreas, mas a informática consegue ser extremamente absorvente. Damos por nós a fazer noitadas em projectos que não vão a lado nenhum. As estimativas saem quase sempre furadas mas os prazos têm que se cumprir. Há uma jiga-joga permanente entre a capacidade de resistência dos programadores e as expectativas dos clientes. Não é uma empresa que faz isto, é todo um mercado. Mas, felizmente, tenho vindo  a conseguir esse equilíbrio. Não me resignei.

Como?

Recentemente, Ben Huh, o fundador do famoso http://icanhascheezburger.com/, disse numa conferência que queria que a sua empresa duplicasse a facturação no próximo ano. Perguntaram-lhe se teria que duplicar o número de empregados, ao que ele respondeu:

Não. Basta-me duplicar a eficiência dos empregados que já tenho.

É exactamente isto que eu tenho feito – (tentar) duplicar a minha eficiência. Estar sempre a magicar formas mais inteligentes de resolver os problemas. Aumentar o valor/hora, em linguagem de consultor. E (agora vem a parte realmente surpreendente) manter a minha produtividade média. Ou seja, trabalhar cada vez menos horas mantendo a produtividade média constante. Dito ainda de outra forma, entregar aquilo que sempre entreguei…mas com menos esforço. Dito assim, pode parecer fácil, mas exige que dediquemos o dobro da atenção a todas as nossas tarefas, num esforço impiedoso de optimização. Implica que nos especializemos, o que é um contrasenso na maioria das carreiras nesta área. Implica que transformemos as mais monótonas e lineares tarefas (o chamado “encher chouriço”) em actividades de investigação. Implica nunca aceitar, questionar sempre. Implica nunca estar satisfeito. Implica nunca estar confortável.

Talvez vos tenha desiludido. Talvez isto seja óbvio para vocês e esperassem algo mais bombástico. Mas naquilo que observo à minha volta, isto não é assim tão óbvio. Vejo muita gente a queixar de trabalhar demais, mas não vejo as pessoas a fazerem algo para mudarem isso. Ou então, vejo pessoas a ficarem mais produtivas, e como tal, a trabalharem ainda mais!?. É a velha história: se eu já consigo correr bem os 10.000 metros vou tentar a maratona. Ou então não…Está nas vossas mãos.

I’ve been approached by a great many entrepreneurs since the Startup School talk who all tell a similar story. They found a niche, made a product for it, and then thought “what the hell, let’s do something crazy!” and decided to charge money for it. To their surprise, it worked and they’re paying the bills and growing.

While that’s fantastic, it’s also perverse. There shouldn’t be any element of surprise unveiled from that order of actions. It should come as a natural conclusion, but it doesn’t. Because the startup culture has caught this disease that there’s something unnatural in being profitable from the get-go. That making money early means you won’t make it big later.

Mais recentemente, o David foi convidado do Jason Calacanis no seu excelente This Week in Startups, numa entrevista que recomendo vivamente e em que a certa altura, David diz:

The only thing that matters in the end, is profit. Market share doesn’t matter. It matters if it leads to profits, otherwise it doesn’t matter.

De facto, esta ideia de que o software pode vir a ser todo gratuito, alimentada por gigantes com “bolsos fundos” como o google ou a ibm, parece fazer feliz muitos consumidores, mas a mim não me convence. Antes pelo contrário, tenho dado por mim a recusar-me a instalar ou utilizar software gratuito cujo modelo de negócio não consigo entender.

Inconscientemente, comecei a pensar nisto no momento em que comprei, de facto, a minha primeira aplicação. Já lá vão alguns anos, e tirando o Windows e o Office (licenças pagas pela empresa), o meu computador estava recheadinho de freeware, shareware e outros ware’s, resultado de longas pesquisas em sites como o freshmeat.net, tucows.com (lembram-se?) ou o download.com. Mas havia um “vírus” no meio daquela tralha toda. Era um editor inteligente (IDE) de uns cromos da república checa chamado Intellij e que era….surpresa…pago! Havia alternativas gratuitas claro mas, por diversas razões, acabei por cometer a loucura de pagar por aquela aplicação. Isto foi há quase 10 anos.

E sabem o que é irónico? Das dezenas de aplicações que eu utilizava, o Intellij é a única aplicação que ainda hoje utilizo. Pois é. As outras já nem me lembro do nome. Porque o meu dinheiro, e o de muitos outros clientes, pagou aos programadores pelo seu trabalho extraordinário, pelas evoluções (e revoluções) sucessivas de umas versões para as outras, pelo suporte imaculado, nunca deixei de utilizar o Intellij.

Isto não quer dizer que não tenha software instalado pelo qual não precisei de pagar. A diferença é que, agora, eu tento primeiro perceber o modelo de negócio que permite suportar essa gratuitidade. Se conseguir, utilizo. Se não conseguir, não utilizo. Por exemplo, utilizo o evernote gratuitamente porque ainda não atingi nenhuma vez o limite de 40 Mb de upload. Mas estou certo que muitos utilizadores já atingiram, pagando $5/mês e suportando, dessa forma, a evolução da aplicação. Outro exemplo é o dropbox – não tenho mais do que 2 Gb na minha dropbox folder, por isso não preciso de pagar. Mas é óbvio que há muita gente a dispender $10/mês para ter 50 Gb de armazenamento, e isso paga futuros desenvolvimentos dessa extraordinária aplicação (eu próprio já ponderei passar para esse plano, acho que é uma questão de tempo…).

Estarão vocês a pensar: mas que raio me interessa o modelo de negócio, se o software fôr útil e satisfizer as minhas necessidades? Bem, umas das razões já referi por alto mas volto a repetir:

O modelo de negócio é aquilo que garante futuras evoluções do software. Porque, por muito que o programador adore aquilo que faz, ele tem que comer, tem que pagar a casa, (mais cedo ou mais tarde) o infantário dos miúdos, etc. O Maslow percebeu isto há muito tempo – primeiro tenho que satisfazer as minhas necessidades básicas, como comer e dormir. O gozo de desenvolver software gratuitamente (por exemplo, em regime open-source) só existe depois de satisfeitas as necessidades básicas. Note-se que existe imenso software open-source com modelos de negócio viáveis, recorrendo por exemplo a serviços pagos à volta do produto como suporte, customização e formação.

Mesmo esquecendo a questão de suportar a evolução do software, temos outras coisas a perder se utilizarmos software sem modelo de negócio a suportá-lo. Por exemplo, existe um risco mais elevado do software ser descontinuado, e teremos que transferir os nossos dados para outra aplicação. E teremos que aprender uma nova aplicação.

Além disso, a verdade é que a melhor aplicação num certo mercado coincide, na maioria das vezes, pelo modelo de negócio mais claro. E a vida fica tão mais simples para todos (consumidores, produtores) quando há um modelo de negócio claro. É só criar uma página chamada “pricing”. Ou, pelo menos, na FAQ, responder frontalmente à questão: “Como é que ganhamos dinheiro?”. Simples, não é?

Em questões de remuneração, a minha opinião é que cada indivíduo deve ser tratado de forma individual (passe a redundância) – se produz mais, deve ganhar mais. Se produz muito mais, deve ganhar muito mais. “Produzir mais” não tem qualquer relação com antiguidade, cargos, etc. Para mim, não me faz confusão que um jovem de 25 anos ganhe muito mais do que seu colega de 45 anos, com iguais qualificações e funções. Percebo (e está estudado) que em diversas profissões (como o desenvolvimento de software) cheguem a existir diferenças de produtividade de 10x entre colegas. Aceito com humildade que alguém ganhe muito mais do que eu e sou capaz de reconhecer que não sou uma super estrela da programação ou da gestão de projectos. Claro que também reclamo o direito de ganhar muito mais do que certas pessoas que produzem claramente menos do que eu. Estes mecanismos criam uma competição interna na empresa que, se apoiada na justiça e na transparência, é saudável.

E sempre achei que a maioria da população era mesquinha, quando reclamava da exorbitância dos salários dos gestores de topo. Assumindo que lá tinham chegado por mérito próprio, concordo que recebam muito dinheiro pois o seu trabalho tem um impacto tremendo nos resultados da empresa. Por exemplo, não me chocava nada o salário que o antigo director da DGCI Paulo Macedo recebia, pois o aumento da receita fiscal que ele conseguiu (junto com a sua equipa, bem entendido) compensou em muito o seu salário.

Mas tudo isto é a minha opinião totalmente infundada e por isso foi bom ler o artigo do Sol apoiado em investigação académica recente na área das remunerações. Citando o artigo:

O economista suíco Bruno Frey realizou recentemente uma investigação onde analisou a influência dos salários no desempenho objectivo dos jogadores da liga de futebol alemã. As suas conclusões acrescentam mais sobre o porquê das consequências negativas da desigualdade salarial: nas equipas com maiores níveis de desigualdade, os jogadores que se percepcionavam na parte de baixo da curva (i.e., como auferindo menos) dimuníram o seu desempenho, enquanto os restantes apenas o mantiveram. No global, o desempenho destas equipas foi por isso pior que o das equipas com menores níveis de desigualdade.

Pelos vistos, aquilo que eu chamava mesquinhice é afinal uma reacção humana normal – os elementos que ganham menos sentem que nunca vão conseguir atingir o patamar das “estrelas” e desmotivam-se. Ainda que muitos defendem como sendo uma questão social ou ética, é afinal muito mais do que isso. Pelos vistos, se a empresa quer ser mais competitiva, terá que premiar os colaboradores com melhor desempenho mas uma diferenciação exagerada de salários e prémios poderá não ser o melhor caminho.

Especialmente nos mercados em que o capital humano é chave, como nas Tecnologias de Informação, a necessidade de adquirir e reter talento leva as empresas a investirem cada vez mais nas respectivas condições de trabalho. Claro que se o objectivo é adquirir talento é necessário fazer gala dessas condições por todos os meios disponíveis, e nesse aspecto o ranking compilado pela Exame e pela Heidrick & Struggles é bastante apetecível dada a visibilidade que tem ganho ao longo dos anos (e certamente uma mina de dinheiro para a consultora, que não será de certeza gratuita a candidatura a este ranking).

Segundo a informação disponível:

A eleição das Melhores Empresas para Trabalhar resulta de um rigoroso estudo da Exame/Heidrick & Struggles.

Numa primeira fase é enviado um inquérito ao colectivo de colaboradores de cada empresa, no qual se pede a opinião anónima sobre diversos temas, desde a transmissão de informação e relação com a chefia até à aposta na formação ou responsabilidade social.

Segue-se o inquérito à equipa de gestão, onde se questionam as práticas de recursos humanos na empresa. Finalmente cabe à consultora Heidrick & Struggles analisar os dados e, depois, aos jornalistas da Exame confirmarem as informações junto de cada empresa.

Não tenho dúvidas que um inquérito de opinião aos colaboradores, feito de forma anónima, seja um grande passo na criação de um bom ambiente de trabalho. E como defendo que o segredo de um negócio de sucesso passa sempre por uma equipa extraordinária, é natural que o bom ambiente de trabalho seja condição essencial para criar e manter essa equipa. No entanto, se fosse à procura da melhor empresa para trabalhar, desconfiaria deste ranking por várias razões.

Em primeiro lugar, podem-se encontrar diversas discussões sobre este ranking que questionam estes resultados. Ainda que muitos comentários possam ser inseridos no tradicional “bota abaixo”, considero haver demasiada celeuma para não ficar desconfiado. Não que eu ache que os resultados foram viciados, mas os inquéritos comportam naturalmente bastante subjectividade,  e poderão não capturar da melhor forma o estado de espírito dos inquiridos.

Além disso, se analisarmos o ranking das empresas em 2008 (pdf) e 2009 (pdf), poderemos reparar que, em apenas um ano, algumas empresas sobem 10% e outras descem 10%. O que muda assim tanto no ambiente de trabalho em apenas um ano?

O número de empresas que aparecem no ranking é ridiculamente pequeno, e todas têm uma classificação superior a 60%. Será que as empresas que obtêm uma classificação inferior a 60% são convenientemente descartadas da tabela?

Mas isto são meras especulações minhas e poderão roçar a teoria da conspiração. Além disso, reforço que o simples facto de uma empresa estar disposta a fazer um inquérito de satisfação aos seus colaboradores de forma anónima a coloca imediatamente num patamar acima da média. E será certamente uma boa empresa para trabalhar. Mas será uma das melhores?

O que realmente importa são os resultados

Posso achar que uma certa equipa de atletismo tem as melhores condições porque tem um ginásio espectacular e ténis de última geração. Mas se não ganha provas, então esses factores poderão não ser assim tão importantes. Se calhar a equipa que ganha tem um treinador incrível. Ou tem uma alimentação esquisita, baseada em comida vietnamita. Ou fazem meditação transcendental antes das provas. Ou seja, não vale a pena tentar adivinhar os meios para chegar aos fins. Vamos antes olhar para os fins que funcionam, e andar para trás até perceber os meios que permitiram lá chegar. Confusos?

Deixem-me explicar de outra forma. O objectivo de uma empresa não é ter uma equipa espectacular. É produzir algo com valor, que seja reconhecido pelos seus clientes, gerando lucro. E para tal, precisa de uma equipa espectacular. Andemos então de trás para a frente. Quais são as empresas que geraram mais lucros o ano passado (por exemplo, ranking na área de TI)? Arrisco-me a dizer que existe uma correlação forte entre essas empresas e as melhores empresas para trabalhar, pois (pelo menos em TI) para gerar mais lucros que a concorrência tem que se ter uma equipa melhor. E se temos uma equipa melhor é porque a empresa é, muito provavelmente, melhor para trabalhar.

Mas o indicador definitivo da melhor empresa para trabalhar é muito mais simples do que isto tudo. Só que, infelizmente não é público. Chama-se turnover, que de acordo com a wikipedia:

In a human resources context, turnover or labor turnover is the rate at which an employer gains and loses employees. (…) High turnover can be harmful to a company’s productivity if skilled workers are often leaving and the worker population contains a high percentage of novice workers.

Isto é, se uma empresa é a melhor para se trabalhar, então porque haveria alguém de querer sair? Note-se, que tirando startups com meia dúzia de empregados, é idealista pensar que se obtém um turnover de 0% (ou seja, ninguém sai). Existem muitas vezes razões exógenas à empresa (por exemplo, mudança de residência) que levam uma pessoa a sair. Isso é inevitável e não há nada a fazer. Mas existem muitas empresas conceituadas na praça com um turnover elevadíssimo, e certamente que não serão todas por razões exógenas à empresa. Porque será? O grande problema desta abordagem é que não existe nem nunca existirá um ranking de turnover. Porque esse sim, seria um indicador perfeitamente objectivo das condições de trabalho de uma empresa. E aí, eu quereria saber como é que as empresas tinham chegado às primeiras posições. Teria sido com inquéritos de colaboração?

Um nota final para quem está à procura da “melhor empresa para trabalhar” – começa por descobrir quais as empresas que geraram mais lucros nos últimos anos, na área que te interessa. A seguir, tenta perceber qual o seu turnover, perguntando a quem trabalha ou trabalhou lá.

Here’s where location impacts your chances for success: location dictates the likelihood that you’ll be able to exchange ideas with likeminded individuals; it affects your ability to raise funding should you need it at some point in your venture; it affects how easily people will discover your product, interact with it or start adopting it; it affects how media (whatever media that might be) see you and your company.

Esta é uma questão recorrente quando se fala de empreendedorismo em Portugal – quão desvantajoso é, para alguém que quer criar uma empresa, ficar em Portugal? Normalmente, a questão gira à volta da carga fiscal e das (pouco flexíveis) leis do trabalho. Por vezes também gira à volta das dificuldades no financiamento. Mas o problema da percepção que o mercado (clientes e media) tem do nosso país não costuma ser referido, e merece reflexão. A verdade é que, mesmo em áreas de negócio fora da Web, a localização não impediu empresas portuguesas de se afirmarem lá fora. Veja-se o exemplo da Nelo Kayaks, líder mundial no fabrico de canoagem de alta-competição. Claro que, exceptuando talvez o turismo, a marca “Portugal” não é propriamente conhecida no mundo, e iniciativas como o About Portugal da AICEP são importantes para avançarmos nesse sentido e facilitar a vida às empresas portuguesas.

Mas na área do software, tirando o desenvolvimento à medida ou a consultoria que são, por definição, mais “locais”, a minha percepção (como cliente) não coincide com a do Fred (como fornecedor). Embora tenha curiosidade em saber onde estão localizadas as empresas que desenvolvem o software que compro/utilizo, isso não influencia minimamente a minha decisão. E acredito que muita gente não faça ideia onde foi desenvolvido o software que utiliza. Talvez os americanos não pensem assim. Mas então como explicar o sucesso de empresas como a JetBrains, que da República Checa destronou a Borland do posto de líder em editores para programação em Java?  Ou da Balsamiq, que está a conquistar o mercado das ferramentas de mockups a partir de Itália? Os media tradicionais (incluo aqui o techcrunch, mashable e afins) dão mais ênfase às empresas americanas? Sem dúvida, mas não foi certamente através desses media que eu descobri a maioria das aplicações que utilizo. O passa-palavra típico dos blogs e das redes sociais rapidamente atravessa fronteiras e pode ter um poder influenciador muito mais forte do que os media tradicionais.

De qualquer forma, o artigo termina com uma mensagem positiva, mas não deixa de ser um assunto digno de reflexão e do qual pouco se fala, talvez por também não haver muitas empresas portugueses a (arriscar?) desenvolver software à escala global.

Muitas empresas de IT não percebem isto. Dão aos seus programadores ou web designers ferramentas razoáveis ou boas, mas raramente dão as melhores, a menos que sejam de borla (muitas ferramentas open-source são melhores do que as pagas). Mas quando se trata de desembolsar, entram numa lógica puramente economicista de redução de custos, pensando que estão a poupar dinheiro. Este tema é de tal maneira crítico no desenvolvimento de software que faz parte do famoso Joel Test:

Writing code in a compiled language is one of the last things that still can’t be done instantly on a garden variety home computer. If your compilation process takes more than a few seconds, getting the latest and greatest computer is going to save you time. If compiling takes even 15 seconds, programmers will get bored while the compiler runs and switch over to reading The Onion, which will suck them in and kill hours of productivity.

Most programmers eventually have to manipulate bitmaps for icons or toolbars, and most programmers don’t have a good bitmap editor available. Trying to use Microsoft Paint to manipulate bitmaps is a joke, but that’s what most programmers have to do.

At my last job, the system administrator kept sending me automated spam complaining that I was using more than … get this … 220 megabytes of hard drive space on the server. I pointed out that given the price of hard drives these days, the cost of this space was significantly less than the cost of the toilet paper I used. Spending even 10 minutes cleaning up my directory would be a fabulous waste of productivity.

A grande ironia aqui é que as empresas que acham que estão a poupar dinheiro ao fornecer ferramentas que são apenas ok estão na realidade a perder dinheiro. O dinheiro que pouparam ao não comprarem o computador mais rápido vai-se reflectir no tempo a mais que demorará a fazer tudo. Poderá ser apenas uns segundo a mais em cada compilação, ou a arrancar o servidor local ou a copiar ficheiros. Mas isto são tarefas que são executadas centenas de vezes por dia, todos os dias. Esses segundos acumulados poderão representar, ao fim de um mês, um dia de trabalho.

Não se trata só de computadores. Falo de tudo o que pode aumentar a produtividade ao longo de anos com um custo inicial fixo (ou seja, não é um custo mensal): a cadeira, o monitor, o editor, o debugger, a BD, o profiler…Façamos umas contas para percebermos quão ridícula é essa suposta poupança.

Imaginemos uma vulgar empresa de que desenvolve software à medida e que tem mais do que 50 empregados. Vou utilizar valores fictícios mas aproximados da realidade, embora esteja a ser bastante conservador. Cada programador custa à empresa 30 euros/hora (obviamente, este custo contempla muito mais do que o salário – impostos, segurança social, seguro, instalações, custos administrativos, ferramentas, etc). A empresa poderá cobrar aos clientes 40 ou 50 euros/hora por programador mas isso não é relevante para este caso. É claro que não é fácil medir o aumento de produtividade que advém de utilizar uma cadeira melhor ou um compilador mais rápido. Por isso, vou ser bastante conservador e dizer que o aumento de produtividade por utilizar as melhores ferramentas é de 5%. Por exemplo, se antes o programador desenvolvia um caso de uso em 4 horas, agora demora menos 12 minutos. Não me parece descabido, basta que o tempo de compilação e de arranque da aplicação se reduza ligeiramente para ter este ganho.

Assumindo então um aumento de produtividade de 5%, podemos dizer que o programador passou a custar menos 5%. Ou seja, se antes custava 120 euros a desenvolver o tal caso de uso (30 euros/hora * 4 horas), agora custa 95% desse valor (114 euros).

Ao fim de um ano, esses 5% consistirão na módica quantia de 3000 euros. Portanto, se o dinheiro gasto em ferramentas num ano ficar abaixo dos 3000 euros, a empresa está na realidade a poupar dinheiro. Se tivermos em conta que não compramos licenças novas de software todos os anos, nem compramos cadeiras ou monitores novos todos os anos, percebemos que é possível comprar as melhores ferramentas e poupar dinheiro. Que raio, uma licença do melhor debugger de HTTP custa 279 euros (sem descontos de quantidade, na realidade este valor seria inferior)! O melhor issue tracker custa 44 euros por pessoa (assumindo uma licença para 50 utilizadores)!

Isto foi uma demonstração extremamente simplista e que reduz o problema a uma perspectiva meramente financeira. Mas este tema vai muito além da mera redução de custos. Tal como um chef terá muito maior prazer a cozinhar utilizando as facas que eles escolheu – afinal de contas ele saberá melhor do que ninguém aquilo que precisa – também um programador gostará mais do que faz e isso tem efeitos que vão muito além da fria perspectiva contabilística.