Sua Liderança Molda a Cultura De Sua Empresa (E Não O Fliperama Na Sala De Recreação)

Escrevi um post no blog da Arivo que achei que seria relevante postar aqui. Não se aplica apenas a TI, mas muitas do que escrevi foi baseado no que eu vejo na área.

Aqui está o link:

https://arivo.com.br/blog/blog/2013/11/21/sua-lideranca-molda-a-cultura-de-sua-empresa-e-nao-o-fliperama-na-sala-de-recreacao/

1 ano de startup: lições aprendidas

Imagem

Faz 1 ano que eu e meu sócio colocamos no ar o Arivo, um sistema de CRM para pequenas e médias empresas. Não gosto muito de chamar a empresa de startup, porque isso faz as pessoas lembrarem do filme do Facebook e de empresas que recebem investimento de milhões e escritórios com máquinas de sorvetes, e nós não temos e nem fomos atrás dessas coisas. Mas acho que temos ingredientes o suficiente para poder usar essa palavra para nos definir.

Acho que sempre que dedicamos tempo a algo, o mais importante é poder dizer que conseguimos aprender algo. E é por isso que achei importante fazer este balanço do que aprendi neste ano. Além disso, quem sabe isto possa ser útil para algum outro desenvolvedor que também esteja pensando em criar sua própria empresa, colocar seu próprio aplicativo no ar, ter seu próprio produto.

Procurar resolver um problema mais claro

Nós tivemos algumas razões para escolher um CRM como produto, mas acho que da próxima vez que lançar um produto vou tentar levar em consideração a questão ‘qual problema queremos resolver?’ ao invés de ‘qual produto lançar?’.

Não estou dizendo que um CRM não resolve um problema. Mas esse tipo de sistema apesar de muito útil para uma empresa, não necessariamente é considerado algo que uma empresa PRECISA ter. Isso significa que menos pessoas estão procurando por isso. E como CRM é um conceito mais dfundido em empresas maiores, oferecer este serviço para pequenas empresas significa que você precisa educar algumas pessoas sobre o conceito.

Some isso ao fato de que CRM é uma das primeiras coisas que as pessoas pensam em fazer quando querem lançar um SaaS. Quando lançamos vimos que existiam alguns produtos no mercado, mas não parecia ser um número tão alarmante quanto se vê na internet em inglês. Mas hoje em dia, cada vez que eu pisco o olho aparecem dois novos CRMs para pequenas empresas. Concorrência é algo saudável, mas quando ela é muito numerosa isso pode causar efeitos ruins para todos, como o achatamento dos preços.

E se eu acho tão problemático um CRM, porque não desistir e fazer outra coisa? Uma das razões eu cito em um dos parágrafos abaixo. Mas também porque já investimos tempo e dinheiro nisto e uma das partes mais difíceis já passou. Além disso, pela experiência de várias empresas de SaaS que esse é um negócio que leva bastante tempo para engrenar. Acho que temos hoje um produto sólido. Mas com certeza quero no futuro lançar outros produtos.

Não faça tudo que seus clientes pedem

Alguns de seus usuários vão perguntar sobre alguma funcionalidade que seu software não tem. Talvez você ainda não tenha implementado a funcionalidade porque não teve tempo, mas na maioria das vezes eles vão perguntar de algo que você nem pensou em fazer. Você, como desenvolvedor, vai sentir que deve implementar isso, que pode garantir mais um cliente pagando, mais uma grana entrando por mês para você poder gastar em games.

Mas a verdade é que esses usuários pedindo por funcionalidades não estão tão investidos assim em seu produto. A maioria das vezes em que cedi e implementei uma funcionalidade específica, o usuário que pediu não se tornou um cliente pago. E depois quase ninguém usou aquela funcionalidade.

Existem duas alternativas melhores para este caso. Uma delas é esperar até que mais usuários peçam pela mesma funcionalidade. Se ela for tão importante assim, mais gente vai pedir por ela. E a segunda é usar o bom senso e tentar chegar em uma versão da funcionalidade que possa ser útil para mais usuários. Talvez essa versão não atenda 100% da necessidade desse usuário que pediu pela funcionalidade, mas se for boa o suficiente para a maioria que precisar dela, ótimo.

Isso parece óbvio, mas quando você acha que vai coseguir fechar mais uma venda para sua empresa escrevendo algumas linhas de código você fica muito tentado a ceder.

Não aposte tudo em uma funcionalidade

Acredito que quem lança um produto na internet conheça vários casos de sucesso e tenha estudado as estratégias que essas empresas usaram para chegar onde estão. Parece simples, parece fácil. É só imitar algumas dessas estratégias, e ir arrumando um espaço para guardar a pilha de dinheiro que vai chegar quando sua empresa bater o Google e a Apple em faturamento.

Ou você tem uma ótima idéia de algo que seu software pode fazer, que vai ser tão legal que seus usuários vão sair na rua contando para todo mundo, tatuar em seus corpos sobre seu software e você vai se tornar um dos maiores casos de marketing viral da história.

Infelizmente, nada é tão fácil. As estratégias das empresas famosas deram certo por conta de vários outros fatores, como networking, timing e um pouco de sorte (e talvez um bocado de dinheiro). A sua ideia fantástica talvez não seja tão fantástica para os outros, ou talvez seja, mas as pessoas não estão espalhando sua mensagem.

Não aposte tudo em sorte. Experimente, implemente essas funcionalidades que podem dar certo e tornar sua empresa um grande sucesso. Mas não conte com isso. Tenha um plano A, B, C, que sejam mais realistas.

Desenvolvimento é a parte mais fácil

Como desenvolvedor, programar é a parte mais fácil do trabalho simplesmente porque você tem mais experiência, foi treinado nisso. Mas além disso, desenvolver um sistema é uma atividade muito mais objetiva que a maioria das outras coisas que você pode fazer por sua empresa, como marketing, vendas, atendimento aos clientes, etc.

Você sabe se conseguiu entregar uma funcionalidade nova ou corrigiu um bug e sabe quanto tempo mais ou menos essas atividades vão tomar. Mas escrever o texto de sua home page, acertar o SEO, enviar e-mails para usuários, são algumas das coisas que você faz e não sabe muito bem se o resultado é bom o suficiente ou se vale a pena gastar um pouco mais de tempo. E talvez mesmo investindo muito tempo, no final o resultado que você esperava pode não ser alcançado.

Por isso é importante ter um roadmap das funcionalidades mais importantes de seu software para que você possa pelo menos entregar essas funcionalidades e ter tempo para fazer outras atividades necessárias. E ter outras pessoas em quem você confia na empresa para dividir e delegar o trabalho também ajuda bastante.

A satisfação de ter seu próprio produto

Acho que o melhor de lançar um produto é sentir um reconhecimento maior do que em outros tipos de trabalho como desenvolvedor. Ver pessoas usando e pagando por algo que você não só codificou, mas que você ajudou a transformar em produto, participando diretamente nas decisões, é muito gratificante.

Você pode desenvolver softwares sobre medida para clientes que te paguem para isso, mas mesmo que seu cliente goste muito do resultado e pague direitinho, você não sente que o sistema qu você fez saiu de suas mãos. Você se sente como uma ferramenta. Se você trabalha em uma grande empresa, desenvolvendo um produto, você não sente que está fazendo tanta diferença, porque existe muita gente envolvida. Muito provavelmente você nem participa das decisões de produto.

Algumas lições mais técnicas

Sobre as principais ferramentas que utilizei:

Ruby on Rails: este framework e a linguagem Ruby me permitem não só criar sistemas muito rápido, mas alterá-los e mantê-los. Já tinha experiência prévia com Rails, por isso não cheguei nem a cogitar outro framework para este projeto.

AngularJS: por muito tempo não utilizei nenhum framework para Javascript. Estudei um pouco dos mais conhecidos e resolvi utilizar o AngularJS neste projeto. Ele me permite fazer algumas coisas bem complexas de forma relativamente simples. Mas de vez em quando algumas coisas que deveriam ser simples são bem complicadas de se fazer, exigindo que você conheça bem como o Angular funciona para conseguir implementar. Ele também é um pouco lento em alguns browsers, como algumas versões mais antigas de IE. Gostei bastante do AngularJS, mas não sei se usaria em um próximo projeto. Acho que ainda não surgiu um framework javascript maduro e simples para ser a escolha definitiva para este tipo de ferramenta.

Bootstrap: anteriormente conhecido como Twitter Bootstrap. Muito útil, me facilitou demais na hora de construir interfaces e páginas. Recomendo para quem não é muito bom em design.

Por enquanto esta é minha avaliação do último ano. Espero aprender mais coisas e talvez até descobrir que estava errado em algo que disse neste post. E quem sabe escrever as lições aprendidas em 2 anos, 5 anos, 10 anos, lições aprendidas escolhendo minha ilha particular comprada graças ao sucesso de minha empresa. E compartilhar o que aprender com outras pessoas, para quem sabe elas possam comprar suas ilhas também :)

Como escolher a melhor linguagem de programação para seu projeto

Você tem um novo projeto para começar, e com os ventos de esperança de código novo sem bugs antigos, vem também o peso de tomar uma decisão importante: qual linguagem de programação utilizar? Nesse caso, podemos generalizar a mesma questão para frameworks, bibliotecas e ambientes que você vai utilizar.

Novo projeto

Começando novo projeto

O primeiro impulso natural é partir para uma abordagem quase científica, que começa com a busca por “qual a melhor linguagem de programação” ou ainda “comparação java vs pascal vs resident evil”. A partir daí chegamos a tabelas de comparação, benchmarks, ou simplesmente artigos em defesa desta ou daquela linguagem. O que é ótimo porque podemos aprender com a experiência dos outros.

O próximo passo é misturar essa nova informação com a sua experiência de projetos passados e aulas na faculdade, carregar tudo no seu cérebro e processar levando em conta as seguintes heurísticas:

- Linguagens da moda: tome cuidado para não se deixar seduzir pela atual linguagem que está na moda, que todos os “hackers legais” estão usando ou querendo usar. Nada contra usá-las em projetos pequenos, para aprender e descobrir por experiência própria quais seus pontos fortes e fracos, mas muitas dessas modas vêm e vão muito rápido. Imagine a dor de cabeça que vai ser se você precisar montar uma boa equipe que precisa conhecer uma linguagem que quase ninguém domina. E como explicar para seu chefe ou cliente que seu sistema tem um problema que depende de um patch de correção que nunca vai sair, porque o pessoal que mantinha a linguagem de programação que você escolheu resolveu montar uma banda.

Moda

Moda

- Conforto: pergunte-se se você e o resto de sua equipe se sentem tranquilos para resolver qualquer problema que vá surgir usando essa linguagem, ou se só de pensar nisso começam a suar frio. A linguagem te faz se sentir o McGyver usando qualquer objeto para desativar uma bomba ou o Mr. Bean se atrapalhando com um guardanapo?

- Nível de ajuda externa: se você tem alguma experiência na área, deve ter algumas histórias de bugs misteriosos para contar. Se você precisar de ajuda para resolver algum problema, você consegue encontrar uma solução só de procurar a mensagem de erro no Google? Existe uma comunidade de bons desenvolvedores envolvidos com a linguagem, respondendo sobre dúvidas em fóruns e blogs? Existe alguma empresa que dá suporte a sua empresa mesmo se for final da copa do mundo com show de Elvis Presley (que foi encontrado vivo)?

- Equipe: caso você precise aumentar a equipe do projeto, é fácil encontrar mais profissionais que já saibam a linguagem? Ela é fácil de aprender? No geral, os programadores que usam essa linguagem de programação parecem ser espertos ou são do tipo de pessoa que acerta o sorvete na testa?

Equipe

Equipe

- Tipo de sistema: algumas linguagens são ótimas para um certo tipo de aplicação e precisam de adaptações horríveis para serem usadas em outros contextos. Mesmo que você ame a linguagem, que seja ela que você gosta de abraçar numa noite fria de inverno, nem sempre vale a pena fazer a coitada se contorcer e se machucar para satisfazer seus desejos mais obscuros (estou treinando para escrever contos eróticos).

Levando tudo isso em consideração você não tem uma garantia de sucesso, porque a linguagem é só uma ferramenta. Mas pode dormir um pouco mais tranquilo, sabendo que você sendo responsável em relação a diversos riscos que muitos aventureiros não levam em consideração.

Mantendo a carreira atualizada mesmo sendo meio preguiçoso

“Você precisa se atualizar”. Este é o conselho de carreira mais repetido e menos discutível depois de “não estrangule seu chefe usando uma corrente feita de clipes”.  E essa cobrança por estar sempre por dentro de todas as tendências é muito maior em tecnologia. Tecnologia é uma das poucas áreas em que você pode entrar em coma e ao ser despertado descobrir que tudo o que você sabia nem é usado mais no mercado.

Acredito que ninguém se sinta muito motivado a estudar novas tecnologias e aprender novas habilidades só porque o mercado de trabalho fica repetindo isso em nossas orelhas. Algumas pessoas se motivam sozinhas a fazer isso, estão sempre fuçando nos frameworks da moda para fazer novos projetinhos, porque realmente gostam de lidar com tecnologias novas e ver o que podem fazer com seus novos brinquedos. Bom, eu não sou esse tipo de pessoa. E conheço muitas pessoas que gostam menos ainda de aprender algo novo. Como posso me manter motivado a me atualizar e não deixar minha carreira em TI entrar em coma?

“Estou super atualizado, já fiz os módulos 1 e 2 de datilografia.”

Torne seu trabalho mais fácil.

Sempre que estou aprendendo algo novo, meu principal objetivo é encontrar alguma ferramenta que transforme uma tarefa que eu levaria semanas e ficaria maluco em um passatempo agradável que leva alguns dias ou horas (ok, é um exagero, mas esse é meu objetivo). Ferramentas, frameworks, bibliotecas, linguagens são criadas para resolver problemas que as pessoas reconhecem que existem e se repetem.

Exercite outras partes de seu cérebro

Por mais que muitas pessoas não enxerguem, desenvolver software é uma disciplina que envolve muita criatividade. Criatividade para resolver problemas, para modelar soluções. E para alimentar sua criatividade você precisa de ideias diferentes, não ficar no marasmo de apertar sempre os mesmos botões. Uma das formas de se expor a ideias diferentes em nossa area é conhecer outros projetos, novas tecnologias. Às vezes o cara que projetou essa nova linguagem de programação que todos estão falando fez algo que ia te facilitar a resolver aquele problema que você quebrou a cabeça para resolver mais ou menos. E isso pode acontecer mesmo que você não vá usar essa nova linguagem.

Mantenha o motor do aprendizado aquecido

Se você parou de estudar por mais de um mês, deve saber como é difícil tentar aprender qualquer coisa nova. É como se a parte de nosso cérebro responsável pelo aprendizado funcionasse como um motor de carro velho. Você precisa colocar ele para funcionar senão ele nunca mais liga e você precisa vender ele no ferro velho (o motor do carro velho, não o cérebro). Por isso acho bom não parar nunca, com o medo de acabar parando para sempre.

Se esses itens não te motivam a continuar aprendendo, lembre-se também que você pode parar de receber o cheque no final do mês se não se atualizar, o que deve ser a pior forma de aprender uma lição.

Pequenas histórias de pequenas empresas milionárias

Eu já escrevi aqui que desenvolvedores tem vários recursos para se tornarem donos de seus próprios narizes e quem sabe mudar um pouco o mundo. Mas provavelmente muitos devem olhar para o que eu disse e se coçar para não postar um comentário como “ok amg, mas como é que eu vou brigar com o Google, IBM e Microsoft se nem sei fazer miojo?” ou “como eu vou montar uma equipe grande o suficiente para fazer um produto que alguém compraria? como eu pago esse pessoal? com o corpo??”. Por isso achei que era a hora de dar alguns exemplos, para quem sabe mudar a cabeça dos incrédulos e para inspirar os que já estão convencidos da idéia.

Resolvi pegar dois exemplos de empresas pequenas, que ficaram milionárias em um curto espaço de tempo, que não receberam nenhum investimento externo e que basicamente começaram como um empreendimento de uma pessoa só, empresas em que apenas o fundador fazia tudo no começo. Alguns podem dizer que U$1 milhão é pouco para uma empresa, e realmente é o que a maioria do pessoal que trabalha com Venture Capital iria pensar já que eles estão correndo atrás dos próximos Googles e Facebooks. Não sei vocês, mas eu já estaria bem confortável nessa situação, e principalmente orgulhoso de saber que aquele milhão fui eu que construí.

Tentei resumir ao máximo a história das empresas só para que o maior número de pessoas as conheçam, mas recomendo que os interessados se aprofundem, leiam as entrevistas completas, blogs e twitters dos empreendedores. E sem querer desmerecê-los, já que obviamente são pessoas muito competentes, pense se não poderia ser você contando essas histórias.

Twitpic

Em 2008, um sujeito chamado Noah Everett, na época um programador web, montou um site para ajudar a compartilhar fotos no Twitter, chamado Twitpic. Fez isso usando um único servidor, pagando do próprio bolso, desenvolvendo sozinho o serviço. Por um ano e meio ele era a única pessoa da empresa. Hoje a empresa tem quatro funcionários (Noah, seu pai, sua mãe e um programador contratado que ele nunca viu pessoalmente). Hoje o site é um dos serviços mais populares do Twitter, prestes a atingir a marca de 6,5 milhões de usuários e faturando aproximadamente U$1,5 milhões por ano.

Você pode assistir uma entrevista com Noah aqui (em inglês). E visitar o Twitpic aqui.

Balsamiq

Em março de 2008, o italiano Giacomo Guilizzoni fundou a Balsamiq Studios, para vender um software chamado Mockups, usado para fazer wireframes, muito úteis nas fases de prototipação de softwares e websites. Giacomo que já foi Engenheiro de Software Senior na Adobe, sendo um dos responsáveis pelo Adobe Connect por exemplo, gostava de desenvolver software, mas também se interessava muito por business e queria ter seu próprio negócio. Mesmo sendo uma empresa de um homem só (e ajudado pela esposa), ele conseguiu 5000 clientes em menos de 11 meses e só contratou o primeiro funcionário em 2009. Hoje a empresa é formada por quatro pessoas, contando com sua esposa e registrou lucro em 2009 de exatos U$1.139.919,59.

Você pode ler uma entrevista com Giacomo aqui. Outra mais recente aqui. O site da Balsamiq Studios é este aqui.

Se você conhecer mais histórias como essas, compartilhe conosco aí nos comentários. Me ajude a inspirar os próximos milionários.

Grails & Groovy: primeiras impressões

A maior certeza que você pode ter, se for seguir carreira como programador, é que você vai usar muitos frameworks e linguagens de programação diferentes. Alguns você vai odiar de coração, mas vai ser obrigado a usar. E quando um colega seu citar o nome dessa ferramenta, você provavelmente reagirá como se sua mãe tivesse sido xingada. Mas também haverá os frameworks e linguagens que você vai odiar menos, e que talvez, por comparação com o que você já usou no passado, você chegue até a gostar.

COBOL: não gostei

COBOL: não gostei

Alguns, como eu, nunca ficam muito satisfeitos e sempre estão a procura da solução perfeita. A resposta à pergunta mais levantada por quem precisa parir um projeto: “o que vamos usar?” Esses sujeitos estão sempre experimentando coisas novas, procurando alguma solução que não tenha os problemas que as outras tinham, e quem sabe um dia encontrar o cálice sagrado das soluções de sistemas. E eu TALVEZ tenha encontrado algo bem próximo disso e que por acaso tem o nome de Grails (se você não entendeu está na hora de entrar num curso de inglês – aí CCAA, olha a oportunidade que vocês perderam de fazer merchandising no blog).

Não vou dar o veredito final porque ainda usei muito pouco Grails, em um projeto pequeno, em que um dos maiores objetivos era aprender Grails e Groovy. Mas para vocês terem uma idéia, o projeto envolvia integração com uma interface Flex (o RIA da Adobe) e usava JMS (o padrão de Mensageria Java). E mesmo assim, escrevi muito pouco código, quase nada de configuração e nenhum SQL (sim, o projeto tem banco de dados). Acho que o fato de eu ter tido pouco trabalho fazendo isto já mostra um pouco o porquê de eu ter achado o framework tão bom.

Grails: o logotipo foi o que menos gostei.

Grails: o logotipo foi o que menos gostei.

Outro motivo para não bater o martelo é que ainda não parei para aprender Ruby on Rails. Está na minha lista de “coisas a fazer (ou não)”, mas da forma como é aclamado pelos rubistas, deve realmente ser muito bom. Bom, se bem que “Crepúsculo” é aclamado por muita gente e eu não estou a fim de ver um filme que mistura Malhação com vampiros emos. Mas o fato de Grails ter sido inspirado em Rails não me permite ignorar sua existência.

Minha experiência com o framework foi curta, mas espero poder usar eventualmente para outras coisas. Por enquanto ainda não usaria para um projeto principal, mas para algo menor não teria dúvidas. Seguem abaixo minhas observações sobre Grails:

  • a linguagem Groovy: não gostava muito de linguagens dinâmicas, mas talvez isto tenha sido por conta do período em que usava PHP. Groovy é uma linguagem muito agradável de usar (pelo menos te garanto que é MUITO mais agradável que Java) e que da mesma forma que Perl, te dá diversas formas de se fazer a mesma coisa. E assim como Ruby, te dá a opção de extender a definição de qualquer classe (como adicionar métodos a uma classe da API padrão por exemplo) e de usar closures (que a grosso modo funciona como os ponteiros para métodos e funções existentes em outras linguagens). Me agrada muito a implementação da linguagem, que te poupa de fazer checagens bobas como verificar se o objeto é nulo, ou concatenação de strings, tornando o código mais legível e mais fácil de escrever.
  • plataforma Java: isto é mais vantajoso para quem já trabalha com Java, mas de certa forma é vantajoso para todos pelo tamanho da comunidade Java. O Grails e o Groovy foram contruídos sobre a plataforma Java. Dessa forma, um código escrito em Java é aceito como código em Groovy, o que pode tornar o aprendizado um pouco mais fácil. Um código escrito em Groovy tem total interoperabilidade com código em Java, permitindo que você tenha um projeto com partes escritas em uma linguagem e partes escritas na outra. Tanto que você pode utilizar qualquer coisa que você já podia utilizar em Java (bibliotecas, frameworks, etc). Isso foi aproveitado pelos idealizadores de Grails, pois o framework tem como seus alicerces dois frameworks Java muito populares: Spring e Hibernate.
  • GORM: é o responsável por mapear seus objetos para os registros no banco de dados (daí a sigla ORM – Object-Relational Mapping), e utiliza o Hibernate por baixo do capô. Este é o melhor ORM que já vi, pois de fato torna o trabalho muito mais fácil. Como eu disse, não escrevi uma linha de SQL e também não encostei em nenhum XML de configuração para fazer o GORM funcionar. Utilizar o GORM é basicamente como eu gostaria que fosse utilizar um banco de dados orientado a objetos. Se GORM fosse uma mulher eu casava. Ah, mulher gostosa, claro.
  • plugins: Grails tem uma boa variedade de plugins para extender sua funcionalidade. O que mais me impressionou é a facilidade de se instalar um plugin em um projeto. É tão fácil quanto instalar algo usando apt-get, basta um comando (traduzindo para quem só usa Windows: é fácil pra caralho!). Em um projeto não Grails, normalmente acrescentar uma tecnologia nova, como funcionalidade de web-services ou um motor de busca, sempre gera um certo stress, a ponto de gerentes com mais experiência alocarem um bom tempo na agenda do projeto para a tecnologia ser incorporada sem problemas. Em Grails, você instala o plugin e usa o resto do tempo que seu gerente alocou para ficar pedindo convite para o novo Orkut! SE não fizerem um plugin para isso.
  • ambientes: o framework já vem preparado para rodar sua aplicação nos ambientes de teste, desenvolvimento ou produção, facilitando a configuração para essa divisão por estágios. E não só isso, quando você faz o download do Grails ele já vem com um banco de dados (HSQLDB) e servidor web (Jetty) para que você possa sair escrevendo código sem se preocupar em montar o ambiente na sua máquina.
  • testes: a parte de testes automatizados (tanto unitários quanto funcionais) faz parte do framework, o que faz com que ele reforce o uso dessas boas práticas.

Se você se interessou em aprender mais, a InfoQ tem um livro gratuito (gratuito de verdade) chamado Getting Started with Grails. Para mais conteúdo, eu recomendo um livro não-gratuito chamado Beginning Groovy and Grails: From Novice to Professional. E para trocar experiências, já existe um fórum de Grails e Groovy brasileiro: o Grails Brasil.

Todo mundo odeia pair programming

Pair programming (ou programação pareada) é provavelmente a prática mais polêmica de extreme programming. É um dos poucos elementos de XP que tem seu valor questionado até por muitos desenvolvedores (além de gerentes e clientes). Provavelmente esta seja a razão para pair programming não ser tão praticada, ou utilizada apenas em doses homeopáticas (ainda mais considerando que pode ser utilizada mesmo sem XP ou algum método ágil). Porque existem pessoas em todos os papéis envolvidos no processo, que odeiam pair programming.

Quando um não quer, dois não fazem pair programming

Quando um não quer, dois não fazem pair programming

Muitas dessas pessoas conhecem as supostas vantagens de parear, mas torcem o nariz, mesmo que nunca tenha experimentado ou que tenham feito apenas uma tarde de experiência com o cara mais chato que conhecem no escritório. Mas na minha opinião, essa resistência não é criada por motivos muito nobres. Além do preconceito que já não é algo muito nobre, resolvi analisar algumas concepções erradas que as pessoas envolvidas tem sobre pair programming. Então venha comigo, de cabeça aberta.

Cliente

Se o cliente estiver contratando um serviço de desenvolvimento de sistemas, o problema provavelmente está no contrato. Muitos contratam esse tipo de serviço pagando pela hora dos desenvolvedores. Logo, quando ficam sabendo que em cada estação de trabalho vão trabalhar duas pessoas, já pensam que estão pagando o dobro do que deveriam pagar. Isso se resolve mudando o contrato para alguma outra forma que não envolva contagem de cabeças. Que aliás, sempre achei um jeito muito estranho de se vender este tipo de serviço, como se o número de pessoas (e não a qualidade) fosse determinante para o sucesso de um projeto. Vendendo a hora do desenvolvedor é como se você terceirizasse os riscos do seu RH e ainda lucrasse alguma coisa quando algum cara ruinzinho fosse contratado.

Se o que você está vendendo é justamente a consultoria para melhoria dos processos de desenvolvimento (o que provavelmente envolve pair programming), então você vai ter que vender todos os benefícios dessa prática. Para isto talvez o resto deste post ou outras referências te ajudem.

Gerente

Para o gerente, provavelmente a maior objeção é a questão da produtividade. Se formos cronometrar o tempo que uma dupla leva desde o começo até a entrega de uma tarefa, muito dificilmente os programadores pareados terão mais que o dobro da velocidade de dois programadores sozinhos. O problema de medir a produtividade desse jeito é que ela não leva em consideração a qualidade do que foi produzido e nem a transferência de informação e conhecimento que acontece durante pair programming. De qualquer jeito, medir produtividade desse jeito seria muito simplista. Em engenharia de software, uma gambiarra pode te fazer terminar muito rápido uma tarefa, mas mais para frente a equipe ter uma dor de cabeça de manutenção e gastar muitas horas resolvendo a gambiarra.

Falando em gambiarras, esta é uma das coisas que se pode evitar com pair programming. Com um co-piloto te vigiando, é muito menos provável que o desenvolvedor aposte numa solução rápida mas feia, porque afinal ninguém quer passar imagem de ser desleixado. Por outro lado, ter um co-piloto também evita que o seu super-mega-engenheiro que gosta de comer design patterns no café da manhã crie uma solução super complicada só porque é mais bonita, já que ninguém está olhando (e que depois ninguém vai entender ou vão gastar um tempão desfazendo). Tanto a gambiarra quanto o over-engineering podem custar muito em manutenção nas próximas iterações.

E por último, mas não menos importante, pair programming é a forma mais orgânica de disseminar informações sobre o projeto, compartilhar conhecimento e formar a cultura de um time. É como se você tivesse coaching, treinamento, revisão de código, brainstorm e mini-reuniões o tempo todo, sem precisar parar a codificação. Se você faz rodízio dos pares muito dificilmente precisará se preocupar se seu programador McGyver sumir, porque provavelmente mais de um programador conhece aquele código. Sem falar na disseminação de boas práticas, truques e macetes específicos a bibliotecas e frameworks que só poucos conhecem. Essa dinâmica de trabalho também permite criar um processo de admissão de novos desenvolvedores muito mais realista. Algumas empresas colocam os candidatos para parear com programadores da empresa para sentir se aquele candidato se encaixa na equipe (avaliando tanto o perfil técnico quanto a compatibilidade da personalidade da pessoa com a equipe já existente).

Existem muitos que se empolgam com extreme programming e correm para aplicar, e que na verdade gostam mesmo é da promessa de que não vão precisar produzir pilhas de documentação, passar meses tentando adivinhar como deveria ser o design do sistema. Mas muitos desses caras aplicam XP deixando de fora coisas como pair programming (para não desperdiçar contagem de cabeças). É aí que a qualidade começa a cair, porque as duas principais formas de comunicação na equipe (documentação e pais programming) foram abolidas. Sem comunicação em uma equipe, você sabe o que acontece.

Desenvolvedor

Aqui eu vou assumir que estamos falando de um desenvolvedor que seja honesto e esteja compromissado com a equipe e com a qualidade do projeto. Por isso nem vou falar do carinha que preferia trabalhar sozinho só para poder ter mais tempo ao MSN, Twitter e Orkut e nem do programador que não está nem aí para a qualidade do que produz e só está preocupado em receber o salário e bater ponto. Esses não tem muita razão para gostar de pair programming (talvez não tenham razão nem para estarem empregados).

Mesmo para as pessoas honestas e esforçadas algumas das razões para odiar pair programming não são ditas em voz alta. Uma delas está relacionada ao ego, esta parte tão sensível de tantos programadores. Nisso se encaixam os dois extremos, tanto o cara que não confia muito no próprio taco e fica se perguntando se deveria refatorar tudo o que faz, quanto o programador rock star que tem muita experiência e se imagina capaz de escrever um software que faça seu trabalho. O primeiro vai preferir trabalhar sozinho para não ficar exposto ao julgamento de outra pessoa e o segundo por sentir que não precisa de ajuda e na verdade seu par só vai retardá-lo. Ambos seguem um raciocínio que ignora o fato de que um dos objetivos de pair programming é equilibrar a troca de experiências e de informações. O inexperiente aprende algo e o super experiente ajuda o time a se tornar melhor. Pair programming é um exercício de humildade.

Não quero ninguém me desacelerando no meu trabalho diário de SER FODA!

Não quero ninguém atrapalhando meu trabalho diário de SER FODA!

Provavelmente o fato dos desenvolvedores estarem confortáveis com a forma de trabalho atual seja a maior barreira para adoção de pair programming. Claro, você poder ficar no seu canto e fazer as coisas do seu jeito, no seu tempo é muito agradável. Também acharia super agradável trabalhar na praia, sem computador nenhum e podendo dormir o quanto eu quisesse. A grande questão é o quanto a predominância desse trabalho individual ajuda o trabalho em equipe, principalmente quando falamos de comunicação. Claro que a adoção de trabalhos em pares não significa que as pessoas não possam ter seus momentos de trabalho solitário, que em alguns casos são necessários (coisas que necessitem de muita concentração, como uma leitura por exemplo).

Talvez como complemento você se interesse por ler o excelente post de Obie Fernandez sobre o assunto “10 reasons pair programming is not for the masses” (em inglês), que apesar do nome é uma defesa da prática. Esse post foi escrito logo após o New York Times publicar uma matéria sobre o tema: “For Writing Software, a Buddy System“.