Sentado num quarto de hotel, longe de casa, com a televisão passando imagens sem som, uma tela de computador cheia de parênteses na minha frente, sentindo uma imensa felicidade por ganhar a vida fazendo aquilo que escolhi, e principalmente, por (re)descobrir o quão divertido e empolgante pode ser esse caminho.

Meu filho, de um ano e meio, me ensina todo dia a ser curioso, a não parar de aprender, me relembra como é bom descobrir o mundo, entender como as coisas funcionam, aprender com os erros. Vejo nele a alegria de perceber pequenas coisas, de querer mais, por mais que isso algumas vezes incomode quem está ao redor.

As pessoas costumam crescer, buscam conforto, buscam um canto macio e aquecido para encostar, um cubículo para se sentar todo dia fazendo o mesmo trabalha de sempre, sem aprender, sem questionar, muitas vezes em entender, ouvindo e dizendo as mesmas coisas todos os dias. As pessoas crescem e perdem aquela alegria da criança ao aprender, se esquecem como é bom entender, perguntar o porquê, colocar a mão onde não é para mexer.

Eu não consigo entender como alguém escolhe se tornar um programador, um desenvolvedor, e não alimenta a curiosidade, não alimenta a vontade de aprender. É pelo salário, já me disseram. Pode ser, mas garanto que estão perdendo o melhor da brincadeira. Eles vão conseguir uma vida confortável, comprometer o orçamento com o que quer seja e logo o lado financeiro não será mais suficiente. Surgirá uma sensação de vazio, de inutilidade, de frustração por trabalhar com algo que não traz nenhuma satisfação, por desperdiçar metade do dia numa vida vazia, metade da vida numa função sem atrativos.

Com a participação de alguns amigos, passamos a compartilhar experiências, conhecimento e novidades com os demais colegas de trabalho. Existem sempre aqueles que nunca estão interessados, como queiram. Mas existem aqueles que logo se tornam sedentos por conhecimento, por novidades, que começam a compartilhar o que sabem, o que descobriram, e isso começa a formar um círculo virtuoso. Essas pessoas passam a relembrar daquela alegria infantil de aprender e entender o mundo, e começam a contaminar as pessoas ao redor, aumentando esse círculo. O ambiente de trabalho passa a ter um clima melhor, apesar de tudo; as pessoas passam a se respeitar mais, a se conhecer melhor, a nutrir admiração uns pelos outros. Obrigado a todos por isso.

Não deixe aquela curiosidade infantil e a vontade de descobrir o mundo morrerem em você. Vale todo o esforço, eu posso garantir.

A cilada típica em ambientes corporativos:

E agora, quem poderá nos ajudar?

Infelizmente, e-mails e reuniões, mesmo em ambientes ágeis, são inevitáveis, e na maioria das situações, tóxicos. Reuniões de 2 horas de duração ou 50 emails diários são sinais claros de que as coisas não andam muito bem.

Atitudes ágeis tendem a evitar “enrolações” que desviem o foco da equipe ou desacelerem a produtividade. A seguir, algumas estratégias e dicas que podemos aplicar para quebrar um pouco essas práticas corporativas cascateiras, ajudar a manter o foco da equipe e produzir mais.

Reuniões

Simplesmente evite reuniões, com temor! Tente resolver os problemas com conversas cara-a-cara, na sua mesa mesmo. Se precisar discutir um assunto por mais de 5 minutos, convide as pessoas envolvidas para um cafézinho, de preferência em pé.

Se não puder evitar a reunião, defina com antecipação: 1) o(s) objetivo(s) e 2) a duração máxima. Limite qualquer reunião a no máximo 5 participantes e duração de 15 minutos. Acredite: é suficiente.

Se um problema for muito complexo para ser resolvido em uma reunião de 15 minutos, quebre o problema em problemas menores, e discuta um de cada vez. Os próximos problemas devem ser discutidos somente quando o problema anterior for resolvido.

Antes de começar qualquer discussão, faça com que todos presentes tomem ciência dos objetivos e da duração máxima. Assim que alcançarem os objetivos ou o tempo se esgotar, termine a discussão imediatamente! Não dê oportunidade para que alguém inicie uma nova discussão desnecessária.

Diga não! Em certas ocasiões, é a melhor resposta. Se você não é o responsável por determinado problema, desconhece ou não pode ajudar plenamente, simplesmente diga “não, obrigado”.

E-mails

Alguns problemas podem ser resolvidos com um simples e-mail, é verdade. A única regra que devemos seguir é a do “passa, repassa ou paga”. Não deixe os e-mails passarem das tréplicas. Se depois de 3 e-mails o problema ainda não foi resolvido, convide os envolvidos para tomar um cafezinho.

E-mail não é chat. O time deve conversar cara-a-cara, incluindo os clientes. Trocar mais do que 5 e-mails diários entre a equipe é um mau sinal. Se não puder falar pessoalmente, use o telefone ou skype ao invés de mandar um e-mail que pode ser facilmente ignorado pelo destinatário.

E-mail não é documentação. Não é preciso enviar um e-mail a cada decisão tomada pelo cliente ou pelo time. Se algo importante foi decidido, converse pessoalmente com os envolvidos.

Finalmente, use o e-mail com sabedoria, para trocar informações importantes e relevantes entre a equipe. E-mail não deve ser regra, e sim um suporte para comunicação entre a equipe. Lembre-se: quanto mais e-mails você enviar, maior a chance de ser ignorado.

Resumo

Reuniões e e-mails são tóxicos. Evite-os! Se não puder evitar, use-os com sabedoria.

Se identificou com alguma situação? Acha que essas dicas “choveram no molhado”? Concorda, discorda, quer complementar algo? Use os comentários.

Reflexão: quais dessas práticas você aplica no seu cotidiano profissional?

Um amigo escreveu isso há algum tempo e tive a oportunidade de reler hoje.

Sometimes things go wrong: hardware is not acting as expected, the API you rely on is not reliable, some vital information is missing. But you don’t care, as you are a hero, a tough Charles Bronson-like guy that will accomplish the mission no matter what.

Another project is saved? Maybe. But someone made a very stupid choice and will pay for it. And I’m talking about you, Bruce Lee.

In six months nobody will remember the adversities you’ve been through. The sleepless nights. The weird bugs. The managers on you back, asking for status reports every five minutes. But something will linger: your name in the source code. It will be there in the SCM, ready to prove that you are a lousy coder and committed buggy/ugly code.

So, next time you find yourself in this kind of situation, take a deep breath and raise the red flag. Share the problem. It’s not fair to chain yourself to something bad just to show that you are tough.

Eu deveria ter levado esse texto impresso para a Venezuela.

Update em 02/05:
Igor Musardo repostou esse post, e adicionou um excelente vídeo da palestra do DHH na Rails Conf 2009. Recomendo que assistam.

Imagine que você receba a seguinte especificação:

Pegue uma folha de papel A4. Sob a mesa, dobre-a ao meio. Coloque a folha dobrada sobre a mesa.

A especificação parece clara e simples, mas aposto que dobramos as folhas de forma diferente, obtendo resultados diferentes. Eu dobrei a minha folha verticalmente, enquanto provavelmente você dobrou horizontalmente, obtendo uma forma próxima de um quadrado.

Qual foi o problema?

Eu criei uma especificação tendo em mente exatamente o que eu queria. E eu acreditei que aquilo era mais do que suficiente.

Você pegou uma especificação, aparentemente muito simples, e sem questionar seguiu os passos que julgou corretos.

Não houve comunicação, cada parte presumiu coisas e o resultado final não foi o esperado.

O grande diferencial das ditas metodologia ágeis é exatamente permitir a comunicação rápida, clara e sem ruídos entre todos os membros da equipe. Isso não tem nada a ver com post-its, gráficos ou ferramentas na Internet. É por isso que estamos vendo-as falhar, e é por isso que o seu projeto, e o meu, também estão falhando.

É por isso que relacionamentos chegam a níveis insuportáveis de convivência, casamentos terminam, empregos viram um inferno. É por isso que ocorrem desencontros, é por isso que clientes recebem algo que não pediram e que não os atendem.

É por isso também que não consegui comprar um mísero pão doce quando estive fora do país.

Comunicação é, na minha opinião, o fator mais importante, e o menos valorizado. É tudo isso que eu falei, e mais um pouco.

(Escrito pelo autor em 26/01/2009, e muito pouco ou quase nada mudou desde então)

Durante o almoço eu estava conversando com um colega e citei que, se tivesse uma empresa, gostaria de contratar um programador/desenvolvedor/engenheiro que fosse preguiçoso. Por meio minuto ele deve ter imaginado que eu estava louco, ou que queria abrir transformar minha empresa imaginária numa repartição pública.

Vou tentar ser breve na explicação.

O primeiro ponto é que uma pessoa preguiçosa, dentro desse contexto, é completamente diferente de uma pessoa acomodada, encostada ou vagabunda. Uma pessoa preguiçosa, novamente nesse contexto, é aquela que se incomoda de fazer várias vezes ao dia a mesma tarefa, e encontra meios de automatizar isso.

Um caso real: eu trabalhei numa projeto em que era necessário compilar os fontes, passar os binários resultantes (executáveis, DLLs ou JARs) por um software proprietário para que esses fossem convertidos num formato que a plataforma proprietária entenda, e então utilizar um outro software para jogar esse binário convertido para dentro do dispositivo.

O segundo passo, a conversão dos binários, era freqüentemente esquecido, fazendo com que um binário desatualizado fosse instalado no dispositivo, desperdiçando tempo e estressando os envolvidos.

Um colega, preguiçoso, criou um passo novo que foi adicionado ao Maven para que essa geração fosse automatizada, reduzindo todo processo à compilação e instalação. Não fosse o software de instalação tão fechado, a coisa toda seria realizada num único processo.

O mesmo acontece com a utilização de testes automatizados. Poderíamos muito bem executar passo a passo todos os itens de uma planilha gigantesca cada vez que eu gerasse uma nova versão do sistema. Ao invés disso, escrevemos alguns testes automatizados (705 da última vez vi) que levam trinta segundos para executar toda vez que você altera o código. A cada nova funcionalidade, uma nova série de testes é escrita, fazendo com que a coisa seja menos trabalhosa para todos os envolvidos.

Automatizar tarefas repetitivas aumenta a produtividade, reduz drasticamente a possibilidade de que erros idiotas aconteçam e ainda te dá tempo para investir no que realmente interessa.

E você, está sendo preguiçoso ou acomodado?

Antes de qualquer outra coisa, escrevo esse post em forma de autocrítica e como um tapa na cara em mim mesmo. Espero que a carapuça sirva em você também.

Cena 1: dois programadores estão tomando refrigerante enquanto reclamam do site que um terceiro programador fez, deu certo e e acabou virando a principal fonte de renda do empreendedor.

Cena 2: um grupo de funcionários critica um colega que está ganhando mensalmente o equivalente ao salário com aplicações para iPhone e iPad com frase do tipo ‘isso aí até eu faço’, ou ‘é pura falta do que fazer’.

Cena 3: um programador, desses acostumados a usar paletó, gravata e passar o dia em cima de diagramas de stick figures, setinhas e balões, profere sem o menor pudor: ‘Estudar uma tecnologia nova em casa? Eu só aprendo algo novo se for pago pra isso.’

Cena 4: um colega, inocente e empolgado, convida outro para participar de um Coding Dojo, e recebe como resposta: ‘programar depois do expediente? eu prefiro levar uma topada no dedão’

E a clássica cena 5: funcionários reunidos almoçando/tomando café/fumando/num happy hour e falando mal do coordenador/líder técnico/chefe/diretor/gerente/empresa em geral.

Pense um pouco e você vai perceber que, com certeza, já presenciou ou já fez parte de algumas dessas cenas.

Reclamar, ficar insatisfeito, criticar ou debochar é algo natural, faz parte da natureza das pessoas e, acho eu, até mesmo de certas espécies de animais. O problema aparece quando a crítica vira choradeira e nunca passa disso.

Eu trabalhei numa empresa pequena, com cinco funcionários, onde havia contato direto com o dono e com os clientes. A quantidade de coisas que aprendi ali, tanto profissionalmente quanto pessoalmente é algo que me ajuda até hoje. Porém, talvez pelo fato de eu ter ficado por ali mais tempo do que seria produtivo para ambas as partes, eu perdia tempo demais reclamando, me estressando e agindo de forma infantil e improdutiva. Chegou ao ponto de uma namorada dizer ‘que cada funcionário está na empresa que merece, e cada empresa tem o funcionário que merece’.

Até hoje penso nessa frase e apesar de toda a violência com a qual ela foi empregada, não deixo de notar a realidade por trás das palavras.

Um ex-funcionário do Google escreveu um artigo (se alguém ainda tiver o link, por favor me envie) em que conta que seus colegas reclamavam da qualidade do granulado usado nos doces que eram dados pela empresa no horário de trabalho simplesmente por não terem do que reclamar.

Já presenciei colegas reclamando da qualidade da churrascaria que a empresa escolheu para a confraternização de fim de ano, onde comeram e beberam de graça sem pagar um centavo que fosse. E, honestamente, era um local que eu não teria condições de levar minha família sem deixar uma parcela considerável dos meus rendimentos.

As pessoas, incluindo eu e você, deveriam parar de choramingar, de reclamar e de perder tempo com conversinhas inúteis e começar a meter a mão na massa, produzir coisas de que se orgulhem e que sejam úteis para outras pessoas.

Não estou me limitando ao discurso Go Horse de ‘não está feliz, peça as contas’. Estou dizendo para que você pense em como se tornar adulto, até mesmo em como se tornar economicamente autossuficiente (pela Nova Gramática).

Atualmente, o custo de se iniciar um projeto ou de se colocar uma idéia em prática usando a Internet é próximo de zero. Qualquer pessoa com iniciativa e, principalmente, acabativa, consegue colher bons frutos com praticamente nenhum investimento além do próprio tempo.

Fazendo uma conta de padaria: se você investir uma hora e meia por dia estudando e/ou implementando uma idéia, por mais absurda que ela pareça para os outros, em um mês você vai ter investido 45 horas, o que é tempo mais do que suficiente para aprender os fundamentos de uma nova linguagem ou apresentar um protótipo da idéia.

Hoje em dia você tem Rails, Sinatra, Django, web2py, uma lista imensa de ferramentas que permitem a criação rápida de aplicações, sem a perda de tempo de editar arquivos XML, descritores ou ficar desenhando bonecos de palitinho.

Pare de reclamar. Se organize. Tenha metas claras e reais. Pare de apontar o dedo e comece a trabalhar. Leve o problema a quem for devido ao invés de simplesmente adotar uma postura passivo-agressiva. Busque motivação onde ela não existe, ou vá respirar novos ares. Tente uma forma diferente de fazer as mesmas coisas, compartilhe conhecimento, ouça mais e aprenda mais.

Enfim, deixe de ser uma menininha chorona e comece a agir.

E, a propósito, parabéns ao Vinicius Teles e equipe pelo trabalho iniciado, concluído e bem feito.

Este é um assunto polêmico e que gera muita discussão nos escritórios de TI. Mesmo assim, tendo trabalhado em várias empresas, grandes e pequenas, presenciando vários projetos fracassarem por decisões arquiteturais (as gerenciais não contam nesse contexto), e os mesmos erros sendo cometidos repetidas vezes, sinto-me na obrigação de passar esta experiência e meu ponto de vista.

Escalabilidade, por definição

De acordo com a Wikipedia, escalabilidade é uma característica desejável em todo o sistema que indica sua habilidade de manipular uma porção crescente de trabalho de forma uniforme, ou estar preparado para crescer. Em outras palavras, um sistema deve estar preparado para suportar uma demanda crescente.

Pode ser classificada como:

• Carga de escalabilidade: um sistema distribuído deve ser fácil para ser expandido e usar sua gama de recursos para acomodar tanto exigências do mesmo sendo elas pouca ou excessiva.
• Geograficamente escalável: um sistema é geograficamente escalável quando ele mantém sua utilidade e usabilidade, não obstante como são usados os seus recursos.
• Escalabilidade administrativa: não importa a variação de informação que diferentes organizações necessitam compartilhar em um único sistema distribuído, ele deve permanecer fácil de ser usado e gerenciado.
• Escalabilidade funcional: capacidade de melhorar o sistema, adicionando novas funcionalidades com mínimo esforço.

Pode ser aplicada como:

• Escalabilidade Vertical (scale up): significa adicionar recursos em um único nó do sistema (mais memória ou um disco rígido mais rápido).
• Escalabilidade Horizontal (scale out): significa adicionar mais nós ao sistema, tais como adicionar um novo computador com uma aplicação para clusterizar o software. Você pode encontrar escalabilidade horizontal nos sabores Sistemas Distribuídos, Serviços de Componentes, SOA, System of Systems, etc.

Do ponto de vista do custo de desenvolvimento, manutenção e suporte, eu defino escalabilidade como: caro (complexo) vs. barato (simples). Porém, o que é caro nem sempre é bom… e vice versa.

Analogias com o mundo real

Nós gostamos de fazer analogias com coisas reais, são ótimas para expressar idéias e facilitar a comunicação.

Call centers, ou centrais de atendimento. Se você mora no Brasil provavelmente já perdeu algumas horas de sua vida pendurado no telefone tentando resolver um problema com sua assinatura de celular, internet, TV, energia elétrica, etc. Mas por que isso acontece?
Provavelmente, essas centrais de atendimento começaram com poucos funcionários, porém foram “projetadas” para crescer conforme a demanda. Basta contratar mais funcionários, dar treinamento e pronto: mais “nós” atendendo as requisições. Entretanto, o processo passa a ser mais complexo e mais burocrático, pois é muita informação para disseminar entre os funcionários. Resultado: alto custo para empresa e pouco resultado para os clientes. A espera ainda existe e quando finalmente somos atendidos, a sensação é de estar falando com um robô, que dificilmente entenderá seu problema e dará uma solução padrão ou insatisfatória para o mesmo.

O processo é adequado para escalar a demanda horizontalmente, o que o torna complexo e não garante a qualidade. Vale lembrar que o software apenas automatiza ou apóia a realização dos processos reais. Se o processo é complexo, o software será tão complexo quanto (e em alguns casos até mais complexo).

Um exemplo diferente: o Fusca. É um dos carros mais simples que existem, não precisa nem de refrigeração a água. Costuma-se dizer que pode ser consertado com um alicate e um rolo de arame. Seu custo de fabricação seria mínimo se comparado com o custo de um carro popular moderno. Ok, não oferece a mesma segurança, velocidade e conforto de um carro moderno, mas ambos conseguem transportar 5 passageiros ao destino desejado.

Mas o que um Fusca têm a ver com escalabilidade? Bem, imagine um congestionamento na véspera de um feriado, por exemplo. Tanto o Fusca quanto o carro moderno ficarão parados na mesma fila de farofeiros. Toda tecnologia, complexidade e custo da fabricação do carro moderno não o livra de um congestionamento. Não há projeto que consiga prever ou contornar esse problema.

Voltando para nossa realidade, em certos casos o custo não paga o benefício. Mesmo um sistema bem planejado, distribuído, separado em camadas e serviços independentes, pode não suportar a demanda, seja de carga ou de funcionalidade. O mesmo aconteceria com um sistema mais simples arquiteturalmente, com certeza. Porém, o custo e velocidade de desenvolvimento e manutenção seria bem menor.

O que fazer então?

Sistemas precisam evoluir de acordo com a necessidade. Projetar um sistema prevendo todos os possíveis “casos de uso” bem como suas hipotéticas cargas (ou acessos) é uma forte característica do waterfall. Sistemas mais simples arquiteturalmente evoluem mais facilmente, em outras palavras, escalam mais facilmente:

• Keep it simple, stupid! Soluções simples geralmente custam menos e trazem retorno mais rápido. Qualquer funcionalidade ou recurso que não agregue valor deve ser descartada. Simples assim!
• Simplifique requisitos. Clientes sem software costumam viajar nos requisitos. Converse, escute e entenda exatamente seus PROBLEMAS, então negocie e sugira uma SOLUÇÃO simples e rápida. E a entregue logo!
• Busque soluções prontas. As necessidades dos clientes, em muitos casos, são parecidas. Provavelmente existe alguma solução pronta que você pode entregar para seu cliente ao invés de desenvolver um novo [software que todos conhecem] do zero.
• Otimize sua infra-estrutura. Procure a melhor forma de deploy da aplicação. Qual hardware é mais adequado, qual sistema operacional e arquitetura. Faça tunning do webserver (workers, pool, memória), módulos e load balance. Utilize uma versão otimizada do interpretador, como o Ruby Enterprise Edition, JRuby ou Rubinius.
• Monitore sua aplicação. Uma vez que esteja em produção, monitore-a em busca de gargalos e possíveis pontos de otimização. Existem várias ferramentas para ajudá-lo nessa tarefa, como o Hoptoad, NewRelic, ou até mesmo o Rubinius Profiler.
• Otimize sua aplicação. O log é seu melhor amigo no desenvolvimento. Não ignore queries demoradas ou que geram N+1, otimize-as! Faça profiling, analise e otimize o código. Utilize caching para serviços externos e para páginas. Caching pode ser a melhor alternativa para turbinar sua aplicação, mas use-o com sabedoria. Bancos de dados não devem ser um problema, por isso saiba escolher a melhor distribuição para seu caso. Mesmo que NoSQL esteja na moda, não quer dizer que é a melhor solução para sua aplicação (a menos que seja necessário para o negócio).
• Simplifique o desenvolvimento. Fameworks ajudam bastante, mas use-os com sabedoria para não inflar o stack da aplicação. Em certas situações, vale mais a pena desenvolver algo simples do zero do que utilizar algo pronto, pesado e que precise ser adaptado para sua necessidade. Escreva menos: quanto menor seu código, mais rápido será sua execução. Camadas são perigosas: evite rodeios e escreva código que realmente interessa. E lembre-se: sempre existe uma ferramenta certa para cada problema.

SIMPLIFIQUE!

Tenha sempre a palavra SIMPLES gravada na sua mente. Se uma coisa exigir muito esforço para ser feita, talvez nem valha a pena. Volte para o início, pense novamente e busque uma ALTERNATIVA mais rápida/fácil/barata. Quanto melhor for sua técnica, melhor serão suas escolhas. Pratique constantemente.

Para começar o post, segue esta história sobre gerenciamento que vi no blog do Gustavo Ribeiro:

Todos os dias, uma formiga chegava cedinho ao escritório e pegava duro no trabalho. A formiga era produtiva e feliz. O gerente marimbondo estranhou a formiga trabalhar sem supervisão. Se ela era produtiva sem supervisão, seria ainda mais se fosse supervisionada.

E colocou uma barata, que preparava belíssimos relatórios e tinha muita experiência, como supervisora. A primeira preocupação da barata foi a de padronizar o horário de entrada e saída da formiga.

Logo, a barata precisou de uma secretária para ajudar a preparar os relatórios e contratou também uma aranha para organizar os arquivos e controlar as ligações telefônicas.

O marimbondo ficou encantado com os relatórios da barata e pediu também gráficos com indicadores e análise das tendências que eram mostradas em reuniões.

A barata, então, contratou uma mosca, e comprou um computador com impressora colorida. Logo, a formiga produtiva e feliz, começou a se lamentar de toda aquela movimentação de papéis e reuniões!
O marimbondo concluiu que era o momento de criar a função de gestor para a área onde a formiga produtiva e feliz, trabalhava. O cargo foi dado a uma cigarra, que mandou colocar carpete no seu escritório e comprar uma cadeira especial.

A nova gestora cigarra logo precisou de um computador e de uma assistente (sua assistente na empresa anterior) para ajudá-la a preparar um plano estratégico de melhorias e um controle do orçamento para a área onde trabalhava a formiga, que já não cantarolava mais e cada dia se tornava mais chateada.

A cigarra, então, convenceu o gerente marimbondo, que era preciso fazer um estudo de clima. Mas, o marimbondo, ao rever as cifras, se deu conta de que a unidade na qual a formiga trabalhava já não rendia como antes e contratou a coruja, uma prestigiada consultora, muito famosa, para que fizesse um diagnóstico da situação. A coruja permaneceu três meses nos escritórios e emitiu um volumoso relatório, com vários volumes que concluía: “Há muita gente nesta empresa!”

Então o marimbondo mandou demitir a formiga porque ela andava muito desmotivada e aborrecida.

Então lembrei de uma imagem que ilustra perfeitamente esta fábula e retrata fielmente a “organização” de alguma empresas:

Dividir para conquistar: você está fazendo isso errado!

Quando uma startup passa a vender mais e ter uma procura maior por seus produtos/serviços (o que é bom), uma reação comum da “cúpula” é aumentar o quadro de funcionários visando atender a demanda. Logo surgem os problemas com a organização do pessoal e/ou fluxo de trabalho. A solução mais simplista (e óbvia) é a especialização: fulano faz isso, ciclano faz aquilo, e beltrano gerencia. Logo controles são criados, fluxos validados, centros de custo, documentos, reuniões, atas, comitês, gestão de pessoas e relacionamento, terceirização, cargos, departamentos… e nasce o monstro da burocracia, aka “enterprise”.

Com essa especialização, cada “módulo” (também conhecido como departamento) começa a perder o foco no GRANDE objetivo da empresa e passa a defender apenas seus interesses – a famosa MISSÃO da empresa passa a ser coadjuvante. O resultado? A empresa dobra ou triplica seu quadro de funcionários e na maioria dos casos, seu lucro bruto. Porém agora tem mais despesas com pessoal e gastos extras para manter esse novo modelo “enterprise”. Trocando em miúdos, continua na mesma!

Onde está o erro? Mais uma vez o FOCO está na solução ao invés de PROBLEMA. Se você ler meus posts anteriores vai ver que este é um tema recorrente. Então por que as empresas continuam fazendo as coisas erradas e cometendo os mesmos erros?

Idéias criativas surgem das pessoas diretamente relacionadas com os problemas e não de diretores, contadores, gestores, etc. Esse modelo “enterprise” é um overhead organizacional que só gera ruído e desperdício!

A solução é adotar agile!

SOLUÇÃO!? Mas qual era o PROBLEMA mesmo!? Sim, mais uma vez o foco é a solução ao invés do problema.

Como eu disse nos posts anteriores, acreditar que uma mudança drástica do processo pode mudar a cultura da empresa e pincipalmente as pessoas é o maior erro na adoção de metodologias ágeis. Mudam o processo mas não mudam as pessoas.

De uma forma simples e direta, agile resume-se a quatro valores:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Ou seja, pessoas, software, colaboração e feedback. Simples assim!

O manifesto ágil não cita nada sobre “enterprise”, sobre a implementação. Este é o grande desafio em sua adoção. Como seguir estes valores sem burocratizar e engessar o processo? Como criar uma relação de colaboração com os clientes? Como responder rapidamente a mudanças? Como eliminar o esforço que não agrega valor ao produto e/ou empresa? Como evitar politicagem?

Mantenha-se pequeno!

Otimize! Busque soluções para os problemas que impedem de produzir mais e com mais qualidade. Faça MAIS com MENOS. Foque no O QUE ao invés do COMO. Escale as pessoas verticalmente!

Inove! Não espere conseguir resultados diferentes fazendo sempre a mesma coisa. Busque novidades, opniões, experiências. Ouça seus funcionários, seus clientes. Estude, pesquise, arrisque, erre, acerte… continuamente.

Mantenha o foco! Tenha um GRANDE e único objetivo e certifique-se que todos acreditem nesta filosofia. É importante que todos comprem a idéia e o modus operandis.

Finalizando, este é apenas meu ponto de vista, baseado na minha experiência em diversas empresas grandes e pequenas, vivenciando problemas, errando muito e principalmente aprendendo com os erros dos outros. Agilidade pode funcionar bem em grandes corporações, desde que haja foco e que todos comprem a idéia. Você pode concordar ou não.

Nos últimos anos o mercado de TI cresceu exponencialmente. Surgiram desde pequenas empresas especializadas em construir websites até monstruosas fábricas de software com seus contratos milionários. Algumas com orçamento limitado outras com dinheiro jorrando pelos canos. Umas com problemas por falta de organização outras com problemas burocráticos. Bons profissionais vs. equipes de sobrinhos, habilidade técnica contra enxurradas de documentos… muito fracasso, pouco sucesso.

A meta é coletar as moedas até conseguirmos uma estrela

Surgiram muitas empresas especializadas em desenvolver software ou que têm um software como produto principal. Normalmente, essas empresas se preocupam apenas em satisfazer os investidores e se esquecem dos clientes. Focam em vender e deixam a qualidade de lado. Prezam pela imagem e ignoram os problemas.

É uma triste realidade que essas empresas tenham mais executivos do que programadores. Como diz o Luli Radfahrer, executivos são aqueles seres que se vestem com um pensamento fracassado, usam uma linguagem própria sendo uma mistura de termos que só eles entendem e 20% de palavras em inglês… não vivem os problemas reais da empresa. É como se estivessem em outro mundo: Mario World!

O mundo dos executivos: nuvens sorrindo

A maioria das empresas que têm problemas com desenvolvimento de software ainda estão vivendo na década de 90. Internet ainda é uma palavra assustadora. Programador é apenas um funcionário que sabe o que significam siglas de informática e sabem mexer no computador. Mudança ainda é encarada como algo arriscado, que deve ser planejado, estudado e aprovado pelo presidente, diretoria e gestores. A palavra da vez é processo e seu fiel companheiro é prazo. A burocracia é uma amiga que garante que as coisas não fujam de controle. Nesse cenário não há como fugir do waterfall.

O maior problema do waterfall são os papéis: cada um com sua “especialidade”. Alguém determina que um infeliz funcionário vai ser responsável por “levantar requisitos”. Faz um cursinho de UML e começa a escrever uma quantidade sem fim de Casos de Uso sem ter noção alguma do que seu trabalho afeta no processo. Então a “equipe” começa a ter muito “retrabalho”, uma vez que os clientes não estão satisfeitos com o que está sendo entregue. Logo percebem que devem fazer o “levantamento” mais detalhado e passam a engessar ainda mais o processo com reuniões, assinaturas, etc. Conclusão: tempo e dinheiro desperdiçados e nenhum resultado satisfatório.

Meu trabalho é digitar 4 8 15 16 23 42 a cada 108 segundos

Falta de foco? Profissionais não qualificados? Processo falho? Não apenas isso: não há comunicação, não há troca de experiências. O waterfall favorece o aparecimento da síndrome do funcionário público: “eu sou gerente: eu córdeno, não preciso saber programar”. As decisões geralmente são tomadas por uma única pessoa. Os projetos seguem o modelo de construção civil. Os profissionais se acomodam pois não veem perspectiva, não conhecem o processo completo, não são ouvidos e por isso não são valorizados.

O foco destas empresas está longe de ser tecnologia. Se concentram em suas buzzwords, processos e reuniões e se esquecem do produto, ou seja, o software. Focam mais na solução do que no problema. Fazendo uma analogia, essas empresas são como um barco furado, onde está entrando água mas há pessoas com baldes para retirá-la e mantê-lo flutuando. Se a agua subir muito, contratam mais pessoas para operar os baldes. Enquanto isso, os executivos ficam acenando como se nada tivesse acontecendo. Quando perguntam se há algum problema, nenhum fdp infeliz tem coragem para falar que o problema é o furo no barco!

As empresas que focam em tecnologia e nos profissionais, tipo o Google ou a 37signals, estão se dando bem e mostrando que agilidade não é apenas mais um processo… é algo real e que funciona!

Agilidade é sair fazendo as coisas de qualquer jeito

Diante do cenário caótico das empresas, um grupo de profissionais organizou um movimento a fim de unificar as práticas bem sucedidas e tornar o processo de desenvolvimento mais produtivo e pragmático: o manifesto ágil. Quem freqüenta esse blog sabe que nós somos fãs e seguidores das práticas ágeis, não porque somos fanáticos e acreditamos somente em uma verdade absoluta, mas por que já sofremos muito com projetos e empresas fracassadas, vivenciamos os problemas que compartilhamos neste blog, passamos noites em claro corrigindo código escrito por maus profissionais, acumulamos horas em reuniões suficiente para tirarmos brevê, tivemos que negociar com cliente, com o chefe, fazer entrevista, contratar, gerenciar, analisar, programar, testar… nós sofremos os problemas do waterfall na pele!

O termo agilidade é bem popular atualmente: “precisamos agilizar nosso processo de desenvolvimento”. Como divulgação do manifesto ágil é algo muito positivo, pois mais pessoas podem conhecer e utilizar as práticas ágeis. Mas, como toda fama tem seu lado negativo, não seria diferente neste caso. Muitos profissionais “gafanhoto” estão utilizando esse termo como alavancagem profissional. Já tem gerente falando que RUP é ágil, arquiteto defensor de modelagem UML ágil, diagrama ER ágil, modelo de dados ágil, caso de uso ágil, cronograma ágil, etc. Ou seja, estão distorcendo totalmente o propósito e a filosofia da agilidade.

Como disse o Chapiewski, os programadores estão querendo ir direto para a sobremesa e esquecendo de comer seus vegetais. Agile é muito mais do que desenvolver iterativamente, fazer stand-up meetings e planejamentos ágeis. Não dá para ignorar todas as práticas de engenharia de software que realmente fazem com que a produção e mudanças em softwares sejam ágeis, sem contar todos os princípios e práticas que fazem uma diferença enorme.

O mercado que não é bobo já percebeu esse movimento migratório e lançou seus cursos de “Gerenciamento de projetos ágeis com MSProject”, “Desenvolvendo aplicações web com agilidade”, “Aprenda a programar com JUnit e TDD”. Não demorou muito para que uma massa de desenvolvedores colocasse o termo ágil em seus currículos. Pretensiosos demais em achar que um cursinho qualquer pode ensinar todo conceito e técnicas ágeis catalogadas por profissionais com décadas de experiência em desenvolvimento de software.

“Estou aprendendo Ruby on Rails por que o mercado está pagando bem“. do dia para a noite surgiram milhares de especialistas ágeis. O cara que programava em .NET ou Java no modelo tradicional (digitador de código), faz um cursinho rápido e de repente começa a desenvolver aplicações numa tecnologia que exige uma enorme bagagem conceitual. Faz tudo errado, pois não sabe realmente o que está fazendo, o projeto fracassa e ainda deixa a tecnologia com má fama. Isso aconteceu com PHP, ASP e está acontecendo com Rails.

Programar é difícil, não é um trabalho para qualquer aventureiro. É preciso estudar muito, se dedicar e principalmente, gostar! Não basta apenas estudar para conseguir uma certificação pois não garante nada. Deve-se viver a programação, participar de fóruns, contribuir com projetos open-source, discutir idéias, ser auto-crítico, ler muito, praticar, apreciar as boas práticas e abolir o que não presta…

Agilidade é propor soluções simples para os problemas

Agilidade não é anarquia, não significa “sair fazendo as coisas de qualquer jeito”, dizer “não” para documentação, etc. É uma mudança de atitude, uma nova maneira de enfrentar os problemas e propor soluções simples e práticas, é ter foco, é saber fazer mais com menos, é automatizar tarefas, é estar comprometido… agilidade é atitude.

Contratamos uma consultoria para implantar Scrum

Scrum é a metodologia da moda. Assim que começou a se popularizar entre a comunidade de desenvolvedores, não demorou muito para o que vários sites e blogs se dedicassem exclusivamente na sua divulgação, apresentando benefícios, artigos, guias, exemplos, certificados para imprimir e pendurar em uma moldura na parede, etc. Logo surgiram as consultorias especializadas em adestramento treinamento e implantação de Scrum nas empresas. Um pouco de política aqui e influência ali até que a INFO Magazine publicasse uma matéria dizendo sua empresa deveria usar Scrum como solução para todos os problemas.

Mais uma vez, a falta de foco e maturidade das empresas distorcem tudo. Muitas empresas “compraram” o Scrum como a solução pronta. Bastar treinar os funcionários, comprar blocos de post-it e tudo passa a funcionar bem e gerar lucro. Pagam um curso de “gerenciamento de projetos com Scrum” para os gerentes. Depois apostam todos as fichas em um projeto “piloto”. Fazem tudo que manda o manual: reuniões diárias, planing-pocker, quadro com post-its, etc. E o projeto… fracassa!

Queimando dinheiro

Então quer dizer que Scrum não funciona? Foi dinheiro desperdiçado? Tanto esforço para nada? Neste caso, devo dizer que sim! Se esqueceram do processo anterior falho, funcionários pouco qualificados e dos líderes sem foco. Escolheram aqueles funcionários mais “experientes” para serem o Scrum Master. Sim, aqueles mesmos que só sabiam escrever casos de uso e diagramas UML. Se esqueceram dos valores, dos princípios, da atitude, do relacionamento com o cliente. O pensamento não mudou, o foco ainda era no processo. Depois de tanto esforço, só deram outro nome o waterfall. Não demorou muito e surgiram os papéis, artefatos, documentos… ou seja, a empresa continua cometendo os mesmos erros!

Não importa a tecnologia ou processo se não souber usá-lo corretamente! E definitivamente Scrum não pode ser encarado como mais um processo bonitinho, com seus papéis, artefatos, bla bla bla. Um processo de software que funciona é aquele onde a equipe está realmente comprometida e tem experiência acumulada para enfrentar e resolver problemas ao longo do desenvolvimento da aplicação. O processo, ou metodologia, será meramente um nome para as práticas que a equipe conhece e utiliza naturalmente.

Resumo

Não há ferramenta, metodologia ou processo que substitua a atitude e experiência de um verdadeiro desenvolvedor ágil. Estude, pratique, esteja comprometido, estude denovo, questione-se, estude novamente. Revise seu código, estude mais um pouco, e principalmente, tenha atitude! Agilidade não é metodologia, é atitude!

Na semana passada uma desconfortável discussão me pôs a pensar sobre os obstáculos culturais na aceitação de princípios ágeis no desenvolvimento de sistemas. A discussão ocorreu quando um amigo meu comentou comigo a respeito de uma metodologia que ele pretende aplicar em um projeto no qual está envolvido. Fiz questão que ouvi-lo com atenção, pois ele, além de ser uma pessoa da minha consideração, possui um background de sistemas muito diferente do meu. O que permite tentar entender outros lados de problemas em comum.

Logo nos primeiros instantes da conversa, percebi que a metodologia que ele estava a me explicar era nada menos que algo derivado de waterfall, onde, basicamente, um “sistema” é definido, por sábios analistas, em um conjunto de diagramas diversos, para depois passar por “estágios” de aprovações e assinaturas mil, e então finalmente cair nas mãos sujas de pizza dos programadores. Documentos. Documentos e mais documentos. Tudo para garantir que não houvesse mal-entendidos, nenhum “re-trabalho”, nenhuma oportunidade de “o cliente” pedir mais do que podia ou mudar de idéia depois de todos os acordos — simplesmente, a metodologia era sinônimo de controle total e absoluto sobre todas as “fases” de um projeto.

Eu não podia ouvir tudo aquilo e ficar calado. A primeira pergunta que eu fiz foi: quais problemas essa idéia vai combater? Ou, pra ser mais sincero com o eventual leitor, perguntei que problemas, observados na prática, seriam resolvidos com a metodologia. Sim, na prática, pois durante a conversa ele havia dado exemplos bastante hipotéticos e superficiais de problemas. Recebi como resposta um olhar de espanto, como se eu tivesse perguntado se a Lua era feita de queijo Minas. Deveria ser óbvio para mim quais eram os problemas! Na raiz de todos os males está a informalidade total no andamento dos projetos! Cliente conversando direto com programador! Sistema que foge às especificações! Cronogramas que não são cumpridos! Programador dando uma de arquiteto! E outras na mesma linha.

Diante de tantas certezas, vi que a conversa já não ia dar em nada, mas continuei o debate. Respondi que, no projeto em que eu estou trabalhando, uma situação de caos total foi revertida sem que a equipe tivesse que conversar em UML, sem que colocássemos travas no diálogo com o cliente… mas com muito, muito “re-trabalho”. Disse ainda que, do meu ponto de vista, os problemas eram de fundo humano: equipe mal qualificada e expectativas amadoras dos assim chamados responsáveis. E ainda afirmei que não acreditava em especificação perfeita, primeiro porque especificações e diagramas são feitos por seres humanos (ainda que na qualidade de iluminados analistas), e segundo porque software se trata de algo mutável pela própria natureza. (Ou então seria chamado “hardware”.) Não falei em termos tão professorais assim, ou ao menos, procurei ser humilde nas colocações.

Continuei dizendo que, por causa desse fundamento humano, a solução dos problemas, se é que existe, passaria por: apoiar o talento das pessoas, não ser reativo nas negociações, recrutar direito, apostar em um gerenciamento mais adaptativo (em nenhum momento usei a palavra “ágil”) de projetos. Certamente, soluções bem menos simples do que dar ordens de se produzir e seguir diagramas ao pé da letra. (Como se houvesse leitura “ao pé da letra”…)

Pensei que possuía alguma credibilidade, mas acho que a essa altura da conversa o meu amigo já não me via como desenvolvedor experiente, e sim como um encarregado que tinha ido trocar a água do bebedouro perto do qual estávamos e resolveu dar palpite sobre esse troço de sistemas. Tive que ouvir que eu estava “totalmente errado”, que esse papo de dar valor às pessoas era “a causa de nada funcionar”, que as empresas precisavam reter conhecimento através de documentação (no que ele está certo), e que “muitas empresas grandes” estavam trabalhando com essa metodologia. (Não citou as empresas e eu não questionei pra não ficar chato.)

O papo acabou logo depois, mas se alguém ainda está lendo e achou que brigamos, não foi o que aconteceu. Continuamos amigos igual antes. Mas dificilmente volto a ter uma conversa com ele sobre esses assuntos. Existe uma diferença cultural muito grande entre nós dois no que diz respeito a software, e é esse o assunto do post!

Em toda a minha carreira eu apostei na minha capacidade de resolver coisas, no meu domínio sobre as questões relevantes aos trampos com os quais me envolvi, na confiança que eu podia estabelecer com as pessoas em volta e, reciprocamente, na confiança que essas pessoas podiam ter em mim. Eu não sei trabalhar de outro jeito e nem quero mudar, pois várias vezes tive o prazer de ver as coisas funcionando/mudando justamente pelas minhas atitudes. Uma metodologia na base do diagrama, na base do analista/deus e programador/vassalo não é só inútil pra mim como simplesmente não me oferece condições de trabalho.

Por outro lado, não me lembro de ter visto esse meu amigo falar com orgulho a respeito de algum projeto do qual tenha participado. Percebo que sua carreira foi marcada por muito trabalho, muito esforço com equipes ruins, muita pedrada de cliente folgado. Chefes ignorantes. Tarefas monótonas. Isso tudo, sem a contrapartida de gostar do que faz, nem de conseguir se motivar observando os próprios sucessos, pode facilmente, na minha opinião, produzir um semeador de waterfall, como meu amigo parece ter se tornado. Para um perpetuador de waterfall, um sistema é uma coisa plana, composta de tarefas registradas em alguma linguagem esquemática pobre, que será transcrita para o computador por pessoas-robôs cujo maior erro é, eventualmente, pensar.

Uma coisa plana sem espaço para a confiança, nem para a imaginação — origens de todos os males, pelo bate-papo ao pé do bebedouro.

(Parte da motivação para este post veio de “What are the right conditions for agile adoption?“, de David Anderson.)