Tenho estudado um pouco sobre motivação, principalmente por causa das consultorias que tenho feito. Tenho encontrado todos os dias confirmações de que temos grandes erros acontecendo no meio corporativo. Hoje eu quero falar da medição de performance e seu impacto na motivação e na entrega, e para isso vou começar com um texto que vem do livro “Agile Software Development – The Cooperative Game” do Alistair Cockburn e está disponível no site dele também, onde há um capítulo de exemplo (veja minha review na página de livros indicados).

“Picking Dandelions
Dandelions were beginning to clutter our back yard. Having three children aged 10 and under, I concocted a brilliant solution: I offered them one cent per yellow flower and ten cents for any dandelion in the seeding stage. For five to ten dollars a year, I thought, we’d get rid of dandelions in a few years.
The kids brought in bags of dandelions, and I paid out the cash.
On the third year, I commented to my now 12-year-old, Cameron, that it looked like we had more dandelions than the previous year.
He said, “Sure. Last year I ran around, dancing and waving all the white dandelions around. When Sean asked why I wasn’t just putting them into the bag, I said, ‘I’m planting money for next year!’” ”

Traduzido:

“Pegando dentes-de-leão
Dentes-de-leão estavam se amontoando em nosso quintal. Tendo três filhos com 10 ou nenos anos, eu inventei uma solução brilhante: lhes ofereci um centavo por uma flor amarela e dez centavos por semente de dente-de-leão. Por cinco a dez dólares por ano, pensei que nos livraríamos de dentes-de-leão em poucos anos.
Os garotos trouxeram sacos de dentes-de-leão, e eu paguei em dinheiro.
No terceiro ano, eu comentava com meu filho Cameron, agora com 12 anos, que parecia que tínhamos mais dentes-de-leão que no ano anterior.
Ele disse: "Claro. No ano passado eu corri em volta, dançando e agitando todos os dentes-de-leão. Quando Sean perguntou por que eu não estava só colocando-os dentro do saco, eu disse: 'Estou plantando dinheiro para o próximo ano!" ”

É um texto curto e divertido, não é? Quem iria esperar esse final de história? Somente quem já está acostumado com os conceitos que vou expor neste post agora. Os conceitos ainda estão um pouco brutos, estou estudando ainda para depurá-los, há livros para comprar, e muito mais estudo a fazer. Este post é um primeiro passo para trazer isso para vocês.

Vamos tentar entender o que aconteceu com Alistair, qual foi o problema que ele teve? Ele estava pagando por entrega, ou seja, por dente-de-leão. Seu filho entendeu isso. Nada mais racional do lado de Alistair do que prever que em pouco tempo estaria livre das plantas. Mas ele não contava que os incentivos dele eram diferentes dos incentivos do seu filho. Para ele, o objetivo era limpar o jardim. Para seu filho, o objetivo era ganhar o máximo de dinheiro possível fazendo algo que o pai pediu. Quem ouvisse a história até a metade nunca saberia que havia uma divergência entre os incentivos de cada um. Eles pareciam idênticos, até o problema aparecer.

O primeiro problema então é a falta de comunicação. O pai deveria ter deixado claro que o objetivo era limpar o jardim.

Ainda assim, há um segundo problema. Mesmo que a comunicação se desse conforme o esperado, isso não significaria que o filho iria sustentar o objetivo do pai, e não o seu. Seus objetivos eram claramente conflitantes, já que para o filho ganhar muito dinheiro sempre deveriam haver muitos dentes-de-leão no jardim.

Vamos fazer um paralelo com a forma com que a indústria de software remunera seus funcionários. Entre os mais comuns estão:

• salário mensal + hora extra,
• salário mensal e hora extra proibida,
• pagamento por hora,
• pagamento por linha de código,
• pagamento por entrega.

Assumindo que os funcionários tem como objetivo ganhar o máximo de dinheiro possível, o que vai acontecer nos cenários onde a remuneração é atrelada ao tempo, como nos casos de salário mensal + hora extra, e pagamento por hora? Se para o funcionário ganhar mais, ele precisa trabalhar mais, então ele vai ter que ter trabalho pra fazer. Isso implica que se ele fizer tudo no horário certo e for pra casa, ele não vai maximizar seu salário. Para reverter isso, ele tem algumas opções: deixar os bugs correrem soltos e depois corrigir na hora extra, inventar funcionalidades desnecessárias ao projeto (goldplatting), inventar trabalho (análises desnecessárias, etc), trabalhar com arquiteturas difíceis de manter, tentar aumentar o escopo do projeto, e por aí vai. Nenhuma destas opções é boa para o projeto, mas são boas para o salário do desenvolvedor. E esses dois casos sozinhos devem ser a maioria do mercado.

Há o caso do pagamento por linha de código. Nesse caso, fica óbvio que o desenvolvedor vai criar a maior quantidade possível de linhas de código. Vai comentar tudo, vai criar declarações desnecessárias, loops que pouco fazem e por aí vai. Já imagine classes de 2 mil linhas e o inferno de manutenção. Pelo menos o pagamento por LoC é raro hoje em dia.

No pagamento por entrega, o objetivo é entregar. Nesse cenário, o desenvolvedor vai focar na entrega. Não vai inventar nada que não esteja focado na entrega, porque se isso acontecer o pagamento dele diminui ou atrasa. O problema é que nesse cenário o desenvolvedor faz a entrega a qualquer custo. Mesmo que para entregar mil reais em valor ele precise destruir dois mil reais. Se ninguém estiver medindo onde os 2 mil reais foram perdidos, então tudo bem. E não imagine que você vai conseguir resolver o problema na engenharia ou no conceito de pronto, porque ele vai dar um jeito de dar a volta nesses conceitos. Exemplo: precisa de testes, ok, vamos fazer testes inúteis, que não tomem tempo. Além disso, ele vai barganhar no custo de cada entrega, dizendo que as coisas são maiores do que são.

Em todos esses casos há ainda o problema do hiperfoco. O desenvolvedor hiperfocado na meta não olha para os lados, não pensa criativamente. E desenvolvimento de software é um trabalho criativo, ou seja, a performance do desenvolvedor vai cair caso você faça ele focar, porque ele não vai conseguir resolver os problemas. Há diversos estudos comprovando isso (vou colocar algumas referências no final).

Sobra somente o caso do salário mensal e hora extra proibida. Nesse caso, o desenvolvedor ganha sempre a mesma coisa, não importa o que faça. A motivação vai ter que vir de outro lugar. Se a empresa não motivá-lo ele vai virar uma pessoa apática, mas pelo menos não vai fazer 70 horas por semana e criar um monte de bugs. Como motivá-lo vai ficar para outro post, tenho coisas a falar sobre isso também.

O que eu quero que vocês levem deste post é: o que é reconhecido é feito. Se você pagar ou valorizar número de testes, espere ver milhares de testes na aplicação, mas não necessariamente testes efetivos. Se você valoriza linhas de código, os programas vão ser gigantescos, e por aí vai, você já entendeu.

“- Mas nem todo mundo quer maximizar o salário a qualquer custo”, vocês certamente dirão. Sim, há pessoas que possuem outros motivadores, mas os problemas que estou levantando acontecem a todo momento. A questão é criar uma cultura que incentive a automotivação, e não a motivação externa, mas, como eu disse, isso é assunto para outro post.

Eu trabalhei um bom tempo com uma metodologia muito interessante, que defendi por um bom tempo, o Balanced Scorecard. Hoje me preocupo muito com o BS em projetos criativos, pelos motivos que já citei. E pior, o BS é público, ou seja, não é só você se medindo, é a empresa inteira te medindo junto. Uma péssima ferramenta para motivar o funcionário. Se o objetivo é medir, meça, mas não divulgue, mantenha os dados na mão do gestor, que vai saber onde há problemas. No momento em que você libera a informação dos valores medidos o funcionário passa a se medir por ela.

Algumas referências interessantes sobre o assunto:

Veja esta palestra do Dan Pink sobre motivação. É de cair o queixo e ele compara o que a ciência sabe e o que as empresas fazem, e como isso não bate. Tem legenda em português:

Veja esta palestra sobre métricas ágeis apresentada no Agile 2009, disponível no InfoQ. Diversos fundamentos são colocados.

Veja o livro “Measuring and Managing Performance in Organizations”, citado na palestra acima. Ainda não li, mas está na minha lista.

E entenda o que um trabalhador do conhecimento quer de uma empresa, nesta thread do .Net Architects.

Ontem fiz uma palestra de apresentação de Scrum na IASP, uma universidade em Hortolândia. Foi uma apresentação de uma hora e meia, onde apresentei os problemas da engenharia de software hoje, alguns princípios da agilidade, um pouco da mecânica do Scrum, e como isso tudo se encaixa com a plataforma Microsoft. O público foi receptivo, e tiveram várias perguntas interessantes no final. Foi uma ótima experiência.

Seguem abaixo os slides da apresentação, e os links citados. (Agora só faltam mais seis.)

• Grupo de Scrum no Yahoo
• Scrum Alliance
• Site do Ken Schwaber
• Revista Visão Ágil
• Consultoria Giovanni Bassi
• Twitter Giovanni Bassi
• .Net Architects
• Podcast .Net Architects
• Grupo Online .Net Architects
• Twitter .Net Architects

Entre 6 e 9 de Outubro acontecerá o Agiles 2009, evento sobre agilidade, em Florianópolis.

O evento está com uma grade muito interessante, com figuras carimbadas da agilidade nacional, como Rodrigo Yoshima, Alexandre Magno, Rafael Sabbagh, Alexandre Gomes, Felipe Rodrigues, Manoel Pimentel, Renato Willi,entre outros. Há também palestrantes internacionais de peso, com palestras em Inglês e Espanhol.

Eu estarei lá, e como sempre, também um pessoal do .Net Architects. Estamos organizando a ida de São Paulo, e já confirmamos, com passagem comprada, o André Dias, o Victor Cavalcante, e o Raphael Molesim. Há ainda um pessoal do grupo de Floripa que deve ir.

Como acompanhar o evento? Pra variar, via Twitter. Já tem bastante coisa rolando lá na hashtag #agiles2009.

Se você não é de Florianópolis, sugiro avaliar ir pra lá. Além do excelente conteudo, o evento é logo antes do feriado de 12 de Outubro, o que vai garantir 3 dias de descanso na bela cidade.

Vejo vocês lá.

Acabo de responder um questionário de um aluno do Mackenzie sobre design patterns, que será utilizado em seu trabalho de conclusão de curso. Era curto (e isso é pré-requisito, ou eu não responderia), composto de apenas sete perguntas rápidas. Ele entrou em contato com alguns dos artigos que ando publicando sobre o assunto, e pediu meu feedback.

E porque estou contando isso pra vocês? Porque a terceira pergunta era essa:

Em algum projeto, durante a fase de análise, já foi detectado que a melhor solução era a não utilização de Design Patterns?

Fase de análise? Alguém ainda acredita em fase de análise? Parafraseando um twit meu, eu acredito em duendes, mas não acredito em fases de análise.

Minha resposta ao universitário:

Não entendo que exista uma "fase de análise". Isso leva a um modelo de desenvolvimento em cascata, que é prejudicial. E a analise arquitetural, que é feita um pouco antes do código, não deve chegar ao ponto de definição de padrões de codificação, mas sim a padrões arquiteturais. E mesmo essa, deve ser feita de forma incremental.

Não me estendi demais no comentário porque a pergunta já foi feita errada. Não é a primeira vez que entro em contato com conteúdo acadêmico fundamentado em práticas waterfall. As universidades, em sua grande maioria, estão presas à idéia de que construir software é igual a construir carros em uma fábrica, ou a construir uma ponte. Não é.

Temos que parar de "analisar o negócio" e voltar a escrever código. Milhões se gastam em papel, e proporcionalmente muito pouco em código funcionando. O overhead gasto em arquitetura, análise de negócio, análise de sistemas, documentação, gestão de projetos é grande demais. Tudo isso devia acontecer apenas como suporte do produto final funcionando. Temos que fazer análises arquiteturais, de sistemas, de negócio? Claro! Temos que ter uma fase para elas? Não, de forma alguma.

As universidades ensinam pouco aos estudantes, e quando dão para ensinar, ensinam isso: técnicas anacrônicas, despreparadas para a realidade. Os alunos chegam ao mercado de trabalho com a cabeça enviesada a favor de técnicas que não funcionam, e, dependendo da faculdade, ideológicamente estragados (principalmente se forem faculdades públicas).

Posso falar com autoridade sobre o assunto. Tenho aplicado, em paralelo à consultoria de arquitetura, também consultoria em agilidade. É comum o cliente entender a arquitetura, mas ainda ter problemas com processo, e acaba me perguntando como resolver, e aí aparece a consultoria de processo. Os resultados são impressionantes, e sempre muito positivos. E garanto: não existe fase de análise em projeto focado na entrega, ágil, produtivo.

Há muito o que caminhar ainda para que tenhamos uma profissão, para que possamos chamar nossa prática de desenvolvimento de software pelo nome de "profissão". Por enquanto, o que temos são discussões dispersas, práticas sem comprovação, e, sem dúvida alguma, ego demais.

Essa é uma questão com a qual me deparo frequentemente. Vou contar para vocês os cenários que tenho visto em muitas empresas, e que leva a escrever este post.

Fazer software é difícil:

• É difícil entender o que o usuário espera, o que o patrocinador do projeto espera, o que o gerente do usuário espera, e juntar tudo isso em uma solução única.
• É difícil fazer isso dar dinheiro.
• É difícil tornar isto prazeiroso para a equipe envolvida.
• É difícil conciliar todos estes interesses, muitas vezes opostos.
• É difícil encontrar uma boa arquitetura, onde exista equilíbrio na abstração, efetividade, e produtividade.
• É difícil encontrar bons profissionais, que gostam do que fazem, e são comprometidos com a empresa que trabalham, e não (só) com o salário que recebem.
• É difícil criar uma solução feita para enfrentar o teste dos anos, para o qual nenhuma técnica de testes (TDD, BDD, xDD) está preparada.
• É difícil escolher a plataforma correta para o desenvolvimento, incluindo a linguagem, a abordagem, e os princípios.
• É difícil, sobretudo, ter o envolvimento efetivo do usuário/cliente no processo de desenvolvimento.

E estas são só algumas das dificuldades. Se fosse tentar listar todas, o post seria sobre isso. Na verdade, teria que publicar um post beta para sempre, em revisão eterna.

Começo deixando isso claro, porque esse fato é reconhecido pela maioria das empresas. E reconhecendo-o, devem lidar com ele. Basendo-se nestas dificuldades, as empresas têm buscado soluções para estas dificuldades (problemas/oportunidades?). E boa parte destas soluções passam por proteger o desenvolvedor. O que significa proteger o desenvolvedor?

Proteger o desenvolvedor significa que os desenvolvedores devem ter a maioria dos problemas resolvidos para eles. Isso passa pela premissa de que eles são incapazes de resolver os problemas sozinhos. Por esse motivo, tira-se do desenvolvedor qualquer tipo de decisão, deixando a ele somente uma tarefa: codificar. Codificar o quê? O que o analista de negócios especificou. Como? Com o design do analista de sistemas. Com que técnicas e ferramentas? Com os frameworks corporativos, a (pré-definida) linguagem de programação homologada (atenção para o singular), e as abordagens (pré-definidas) pelo arquiteto.

Dessa forma, o codificador tem que tomar poucas decisões. Ele só tem que decidir o que não foi decidido para ele ainda. Neste estágio, não podemos mais chamá-lo de desenvolvedor, já que não desenvolve nada, só códifica. Todo desenvolvedor também é codificador, mas o oposto não é verdade.

Qual o problema com esta abordagem, que claramente vem de uma decisão gerencial? Enxergo de imediato dois:

O primeiro problema é assumir que o sistema de linha de montagem de uma fábrica de automóveis é plenamente compatível com o sistema de criação de um software. De que é possível alienar o trabalhador da informação, deixando para ele apenas um pedaço da montagem do software. De que é possível comunicar tudo o que é necessário com papel e diagramas. Enfim, de que é possível criar uma "fábrica de software", termo que devia ser apagado do vocabulário de qualquer pessoa que trate seu processo de desenvolvimento de software com seriedade. Estes sistemas, o de montagem de automóveis, e o de criação de um software não são compatíveis. Software é algo imaterial, que vive apenas na idéia das pessoas. Enquanto um desenho CAD é capaz de comunicar exatamente como uma caixa de câmbio deve ser produzida, um documento de especificação é incapaz de fazer o mesmo. Duas pessoas lendo o mesmo documento, ou mesmo falando com o mesmo usuário, terão idéias diferentes sobre o software a ser criado, não só no "o que", mas também, e principalmente, no "como". Entendendo isso, fica fácil perceber porque sistemas baseados em fábrica de software (seja ela interna ou externa à empresa), em linha de montagem, dão tão errado. Porque o software tem defeitos de especificação de negócios, de especificação técnica, e inúmeros bugs. Além disso tudo, nunca fazemos softwares parecidos (quem dirá iguais), enquanto que na linha de montagem de um carro, o carro é sempre o mesmo, mudam só alguns detalhes.

O segundo problema está na premissa que citei antes: os desenvolvedores são incapazes de tomar decisões sozinhos, não têm competência para isso, são incompetentes. Quando você trata o desenvolvedor como um incompetente, ele passa a se entender como um incompetente, e não se preocupa mais quando algo dá errado. Ele não busca mais a melhor solução, isso não é mais problema dele. Já que você está tratando ele como operário fabril, então ele vai se comportar como um. E já que ganha por hora, então o foco passa a ser fazer a maior quantidade de horas possível, que não vão dar em nada, já que ele sabe que nada dá em nada mesmo, porque é incompetente. A melhor maneira de acabar com o comprometimento de um desenvolvedor é tratá-lo como uma criança incapaz de tomar decisões.

Como resolver esses problemas? Atacando suas premissas. Primeiro: o desenvolvedor não é incompetente, e segundo: criar software é diferente de montar um carro. Como o assunto é proteger o desenvolvedor, vou falar da primeira. A segunda fica para outro dia.

Se você assume que seu desenvolvedor é incompetente, você tem duas opções: capacite-o para ser mais competente, ou mande ele trabalhar em outra empresa. Então vamos combinar assim: você entende que seu desenvolvedor não é incompetente. Sabendo que seu desenvolvedor possui competência para fazer um bom trabalho, você não deve tomar decisões por ele. Ele deve ser capaz de tomar as decisões corretas. Isso significa que ele deve ser capaz de falar com o usuário, decidir sobre a implementação de um requerimento, e saber usar padrões. O arquiteto pode ajudá-lo nessas tarefas, mas não deve realizá-las para ele. O arquiteto deve inspirá-lo, deve fazer coaching, mas nunca codificar para ele, porque ele é competente o suficiente para isso.

E onde ficam os frameworks corporativos, os padrões, a reusabilidade no nível da corporação? Muitas empresas fazem esse tipo de framework para ganhar tempo, diminuir a quantidade de código que escrevem, e agora? Este tipo de framework deve surgir quando necessário, e deve ter uma amplitude muito limitada. Acredito que é possível ter um framework corporativo, desde que ele emerja das necessidades reais dos projetos, ou seja, sejam abstraídos a partir de algo real que precisou ser implementado, e que pode ser reutilizado. Nesse contexto, os frameworks acabam sendo estritamente técnicos, e não de negócio, e atendem necessidades reais dos desenvolvedores. Por exemplo, não é possível ter uma entidade cliente e um repositório de clientes que possam ser reutilizados em qualquer sistema, porque em sistemas diferentes os contextos de uso do cliente são diferentes. A entidade cliente é grande demais para ser utilizada sem abstração, ela é um requisito de negócio, e cada sistema modela um processo de negócio diferente, e enxerga o cliente de forma diferente. O que faz sentido é ter componentes que resolvem problemas técnicos, como um repositório base, por exemplo, ou um framework corporativo para conexão com banco de dados seguro, ou ainda um framework de autenticação. Estes podem emergir quando necessários, e devem ser feitos seguindo boas práticas, como o open closed principle, para que não se tornem um peso no processo de desenvolvimento, mas sejam uma solução real.

Na prática, o que acontece nas empresas, é que o gerente não confia na equipe que tem, e estando acostumado a trabalhar no estilo comando/controle, diminui as variáveis que deve controlar para facilitar o próprio trabalho. É algo que pode até dar resultado em trabalhos mais repetitivos, como a montagem de um carro (e há casos onde esse tipo de coisa também não é verdade, vejam o caso da Toyota), mas certamente não funciona em software. Aplicar teoria clássica da administração na gestão de software é algo, no mínimo, anacrônico. O que deveria estar acontecendo é um movimento dos gerentes funcionais atrás de atualização, de forma a se prepararem para lidar com o trabalhador do conhecimento do século XXI, que não reconhece mais fronteiras hierárquicas, é criativo, independente, e, sobretudo, competente.

Se você é gerente, deixo aqui minha pergunta para você: que tipo de gerente você quer ser? O que entrega, tem funcionários felizes, baixo turn over, preparado para as necessidades contemporâneas? Ou o anacrônico, gerenciando conforme as técnicas ultrapassadas que pregam comando, controle, e que geram funcionários insatisfeitos, que em pouco tempo vão trabalhar em outro lugar se você não lhes der um bom calhamaço de dinheiro? E se você é empresário de TI, a pergunta é: que tipo de empresa você quer ter: a preparada para um mercado dinâmico, que demanda qualidade E custo, ou a ineficiente, que briga no mercado com centenas de concorrentes muito parecidos, depende de um nicho muito específico para viver, e que pode tomar a rasteira de uma empresa mais eficiente a qualquer momento e ir à lona? Ah, e se você é gerente, e não se entende também como empresário do seu próprio centro de custo, você está com problemas. Hoje o departamento de TI é um prestador de serviços, mesmo internamente, e você pode, se não der ROI, ser substituído tão rapidamente quanto um fornecedor. Fique atento.

Em resumo: se você está protegendo seus desenvolvedores está criando um ambiente onde a solução dos problemas não aparecem naturalmente, está restrigindo a capacidade dos desenvolvedores de dar a melhor solução para um problema, e está atrapalhando, e não ajudando o departamento que gerencia. Não proteja seus desenvolvedores, proteja o investimento que a empresa fez em você quando o colocou em uma posição gerencial, e busque produtividade encarando de frente a realidade que faz o desenvolvimento de um software nos dias de hoje. Permita aos desenvolvedores criar, e ajude-os a chegar lá, capacitando-os, e fomentando a reutilização quando ela fizer sentido, de forma a alavancar a produtividade.

A algum tempo percebi uma dinâmica um tanto perigosa que acontece nas empresas que demandam software via fornecedores internos ou externos. Isso engloba praticamente todo o mercado corporativo, mas deixa de fora empresas que desenvolvem software de prateleira. O que vou escrever a seguir trata deste primeiro tipo de empresa.

Sempre que um departamento precisa de um sistema, ele precisa demandar este sistema para alguém. Seja a demanda repassada para um departamento de TI interno, ou para um terceiro, o foco com razoável frequência costuma ser custo. Quando o departamento é interno estamos falando de rateio baseado em horas internas de outro departamento da empresa, então a discussão é em torno de horas. Quando a demanda vai para fora da empresa a discussão é financeira. Grandes empresas mantém departamentos de compras responsáveis por comprar desde toner para impressora e papel higiênico quanto software, e o tom, principalmente em tempo de crise, é comprar focado em preço. Para se proteger as empresas geralmente apostam em especificações e estimativas bem feitas (algo que não existe), e SLAs. Assumindo que a especificação determina o que vai ser entregue, faz sentido que o critério seja preço. Quer dizer, faria sentido se software não fosse software. Comprar software assim é como comprar serviços de advocacia por preço. Você faria isso se estivesse em uma enrascada? Arriscaria seu pescoço? E porque então arriscamos o dinheiro das empresas?

Invariavelmente os fornecedores, sejam eles internos ou externos, vão ter que baixar o custo para atender o cliente, que quer uma Mercedez pelo preço de um Fusca. Frequentemente o cliente simplifica o escopo ao máximo, a fim também de baixar o preço, e remove itens fundamentais a qualquer software. De cara morrem coisas "inúteis" como log de erros, por exemplo. Design gráfico também costuma nem entrar no projeto. Outros itens, de tanta falta de demanda, às vezes nem são oferecidos pelos fornecedores. Coisas "inúteis" como análise estática de código, integração contínua, e claro, uma análise arquitetural e/ou um arquiteto acompanhando o projeto. Afinal, essas coisas "inúteis" só acrescentam custo e não valor (atenção para a ironia). Então o cliente fala que não vai pagar por isso.

Porque isso acontece? Pois é, foi isso que eu descobri. Talvez vocês já saibam, mas para mim foi algo que de certa forma estava na minha cara, mas eu nunca tinha parado para ver.

A questão é simples: quem paga pelo software e quem paga pela manutenção? É muito frequente que o cliente final pague pelo desenvolvimento do projeto, mas não pelas pequenas manutenções subsequentes. O dinheiro sai do seu centro de custo somente no nascimento do projeto. Quem paga as manutenções geralmente é TI, que mantém uma equipe de suporte, alocada no seu centro de custo, debaixo do seu budget.

Esse fato leva o cliente a pedir o software mais barato possível. Os problemas e necessidades que vierem depois são resolvidos "de graça", ao custo do departamento de TI. E como o software foi feito de qualquer jeito, a manutenção é muito cara, o que leva a equipe de suporte a inchar cada vez mais, ou entregar cada vez menos valor. Quem disse que não existe almoço grátis?

Não é a toa que os CIOs são tão criticados por não entregar valor. Cerca de 80% do custo de TI vão para manutenção, e devido a essa dinâmica, uma manutenção cara que se originou nos próprios incentivos dados por TI.

Como eu disse no começo, essa é uma dinâmica perigosa, já que os custos do projeto são muito maiores do que o planejado, e o software não é feito para durar, mas para sair de qualquer jeito. E o trabalho do arquiteto é justamente fazer software para durar.

Gostaria de saber se isso é uma visão particular das minhas experiências ou se vocês confirmam esta visão. Comentários são muito bem vindos.

"You might think you already know what an estimate is. My goal by the end of this chapter is to convince you that an estimate is different from what most people think. A good estimate is even more different.
Here is a dictionary definition of estimate: 1. A tentative evaluation or rough calculation. 2. A preliminary calculation of the cost of a project. 3. A judgment based upon one's impressions; opinion. (Source: The American Heritage Dictionary, Second College Edition, 1985.)
Does this sound like what you are asked for when you're asked for an estimate? Are you asked for a tentative or preliminary calculation—that is, do you expect that you can change your mind later?
Probably not. When executives ask for an "estimate," they're often asking for a commitment or for a plan to meet a target. The distinctions between estimates, targets, and commitments are critical to understanding what an estimate is, what an estimate is not, and how to make your estimates better."

Primeiros parágrafos do livro "Software Estimation: Demystifying the Black Art", da Microsoft Press, que você compra aqui na Amazon por meros 50 reais.

É tão importante deixar claro que uma estimativa não é um contrato, não é um compromisso, que o cara abre o livro dizendo isso.

Quantas pessoas e empresas entendem isso?

Acho que esse parágrafo, por si só, resolveria 90% dos problemas comerciais decorrentes de mudança de escopo e desvio de prazo presentes no mercado hoje.

Estimativa == Cálculo aproximado.

Combinado?

Eu tinha falado antes das regras para desenvolvimento de software, segundo Patrick Hynds, e a última, a regra de quatro palavras dele, era essa:

"Sem especificação, sem estimativa"

Fiquei de falar um pouco mais dela, e esse post serve para isso.

A regra, a princípio, me pareceu óbvia e simples, mas isso é só uma impressão. Por isso quero falar dela aqui com mais detalhes.

Vamos começar pelo final, entendendo a segunda parte da frase. Preciamos entender o que é estimativa. Estimativa no dicionário (grifo meu):

Cálculo aproximativo que se faz de algo.

"Aproximativo" é a palavra chave. Significa que nada que seja uma estimativa é preciso, mas é aproximado. Pedir uma "estimativa precisa" é como pedir para subir para baixo, para sair para para dentro, e outros absurdos. Estimativa sempre é imprecisa, sempre é, no fundo, um chute. A não ser que você tenha uma bola de cristal, sua estimativa nunca vai ser precisa, a não ser que você considere desvios altíssimos (200% por exemplo) dentro da sua taxa aceita de precisão. Mas aí eu diria que você precisa rever seu conceito de precisão.

Sim, uma estimativa pode variar 200%. Ou 0%. É um chute, ele pode entrar no gol ou passar longe. E excelentes jogadores, com frequencia, também batem para fora.

Com isso claro, podemos falar da primeira parte da frase: especificação. Mas antes eu quero falar de como o mercado compra software hoje.

O modelo dominante hoje no mercado é comprar projetos fechados de software. Isso significa que o cliente determina o que quer, e os fornecedores dizem quanto vai custar. A visão geral, que entendo ser muito equivocada, é que o fornecedor é especialista, e vai conseguir um preço muito abaixo do que o próprio cliente conseguiria atingir, dada uma condição de competição.

A questão é que nesse cenário todos os fornecedores colocam a margem de risco no projeto. Nenhum deles vai assumir que a margem de risco é zero só para ganhar uma venda. Sabem porque? Porque não basta vender, tem que entregar. E é aí que o negócio complica. Sabendo disso, todo mundo coloca uma "gordurinha" no projeto, mesmo os departamentos internos, que atendem clientes da própria empresa.

Voltando então à especificação. É muito comum também no mercado brasileiro que a compra de software, seja ela interna ou externa, seja feita com base em uma especificação. Só que, se as especificações, da maneira com que em geral são feitas, só permitem a venda no estilo "Time and Material", ou seja, hora aberta. O cliente geralmente pede o que vai querer, e não como vai querer. O "como" é responsabilidade do fornecedor que ganhar a concorrência, ou do departamento interno de TI, caso seja ele o fornecedor. Só que dizer "o que" mas não "como" aumenta ainda mais o risco da estimativa, que já é, por definição, imprecisa, e portanto arriscada, porque o fornecedor pode errar feio na definição de como vai fazer o que o cliente pediu. O resultado é que o custo proposto para a execução do projeto acaba ficando muito acima do que seria se o "como" tivesse sido definido.

Um bom exemplo é especificação baseada em casos e cenários de uso. São documentações de negócio, de alto nível. Dizem "a nota fiscal deve ser emitida clicando em x, y e z." Isso é "o que" deve ser feito (emitir a NF). O "como" vai ser definido pelo fornecedor, que não tem a menor idéia do que é o projeto. Dessa maneira o cliente está pedindo para pagar mais. Ah, e a todos os analistas de sistemas: MER e diagrama de classes têm o mesmo problema.

MER, use cases, diagrama de classes, todos vão gerar especificações incompletas? Vão. Qual o resultado? Estimativas ruins. Nesse cenário, dou um passo além das propostas de Patrick Hynds, e digo que estimativa, por ser imprecisa por natureza, em pouco se beneficia de uma especificação mais completa, mesmo que ela indique o "como". Digo isso porque ninguém sabe exatamente o que precisa quando compra um software, e mesmo que soubesse, isso poderia mudar, como de fato muda. Realizar uma especificação apurada em momento de escolha de fornecedor, ou seja, muito antes da codificação iniciar, é pedir para ter documentação desatualizada, ou seja, o projeto já começa com problema.

Como fazer então? Só há uma resposta: processo iterativo e curto. Nesse cenário as estimativas são trabalhadas com maior aproximação, e, ainda que imprecisas, tendem a ficar mais próximas do que será depois executado. Isso se deve porque a quantidade de informação a ser trabalhada é pequena, e porque o time trabalha com feedback constante entre, e durante, as iterações. Nesse cenário não faz nenhum sentido gerar estimativa para todo o projeto, a não ser que ela seja entendida como o que é: um chute.

Fica a dica então: compre desenvolvimento iterativo, e peça estimativas de períodos curtos. Não se engane.

O segundo dia do Scrum Gathering foi tão bom quanto o primeiro. Começamos com uma apresentação de marketing da ScrumAlliance, seguida depois de várias palestras. Uma palestra inesperada do Juan Bernabo, sobre Management 2.0 foi bem legal (alguns arriscaram a dizer que foi a melhor de todo o evento). O Fabio Camara, MVP de VSTS, falou de VSTS e Scrum, e, pelo que eu ouvi, causou bastante polêmica ao colocar a visão e experiência dele sobre o ScrumMaster. Gostei também da palestra de como apresentar Scrum para o cliente, do Fabiano Milani. Assim que ele colocar o Powerpoint no ar vou baixar, porque esse é um dos assuntos mais complexos no Scrum, na minha opinião.

O evento terminou com um painel onde os congressistas fizeram diversas questões à 4 palestrantes do evento. As perguntas foram muito boas, e eu, claro, não pude deixar de fazer a minha, que foi só parcialmente respondida. Questionei sobre o futudo do Scrum e, já que o Scrum agora pretende resolver os problemas de desenvolvimento de software, se devemos esperar ver agora uma melhoria naquelas estatísticas do Chaos Report do Standish Group. Ninguém se atreveu a dizer que sim.

O evento foi bem legal, atendeu às minhas expectativas, e teria me arrependido de não ter ido. A troca de experiências foi fenomenal, além de ter sido muito legal ter revisto figuras do mercado de agilidade, que eu não via desde que participei do painel de sistemas disbribuídos no lançamento do InfoQ Brasil, como Felipe Rodrigues, o Manoel Pimentel, o Victor Hugo Germano, Alexandre Gomes, etc.

Por falar nisso, o InfoQ Brasil vai fazer uma cobertura sobre o assunto, então fique ligado por lá se você quiser ver umas fotos do evento, além de obter mais informações.

Você também pode conferir o que houve no gathering pelo hashtag #ScrumGathering no Twitter. Bastante gente, eu inclusive, twittou sobre o evento. Em alguns momentos você chega a ver um chat entre o Victor Cavalcante e o André Dias…

Entrei em contato com algum material do Patrick Hynds, MVP de segurança. Eu não o conhecia, mas o pouco que vi me deixou muito claro que ele é uma pessoa muito experiente. Gostei especificamente de 4 regras que ele coloca como as que devem guiar o processo de desenvolvimento de software. Ele as chama de "regra de uma palavra", "regra de duas palavras", "regra de três palavras" e "regra de quatro palavras", e tem esses nomes porque são definidas com estas quantidades de palavras.

Elas são exatamente novidades, mas como são muito curtas e simples acabam tendo um peso juntas. Ao mesmo tempo que parecem óbvias, entendo que também podem ser um pouco polêmicas.

Bom, vamos à elas. Abaixo de cada uma coloquei a minha percepção sobre a idéia.

1. Status
   Verifique o status com frequência. E verifique ele cedo no projeto, porque quanto mais tarde mais caro vai custar corrigir o que não foi medido antes.
   Desenvolvedores novos devem passar status no mínimo uma vez por dia. Reuniões diárias, ao estilo daily meeting do Scrum são recomendadas. Profissionais mais seniors podem passar status com uma frequência um pouco menor, mas todos, sem exceção, devem passar status obrigatoriamente, sob pena de perda de emprego. Somente depois do status obtido e conferido é que algo pode ter o status de "pronto".
2. Nunca adivinhe
   Nunca assuma nada. Status não serve para nada se você só anotou o que outra pessoa te disse. Você tem que conferir que o status é o que é. Se você está colhendo o status e a pessoa que deve lhe passar este status não te comprova o status, você tem o direito de assumir o status que quiser, já que a discussão está no nível do achismo.
3. Não seja ansioso
   Desenvolva um conceito de "pronto" e se atenha a ele. Entenda que, em nenhuma situação, código concluído significa projeto terminado, por mais que você queira que signifique. Entenda também que "pronto" é um conceito binário: ou está pronto, ou não está. Não existe "pronto mas falta <coloque algo aqui – testes, documentação, etc>".
4. Sem especificação, sem estimativa
   Esse é muito legal, e vou tratar dele melhor em outro post. Em poucas palavras: qualquer estimativa deve ser baseada (e solicitada) com base em uma especificação que não deixe margem à dúvidas. Mas é mais que isso. Bem mais.

O primeiro e o segundo fogem bastante do conceito de times autogerenciáveis, já que claramente há alguém gerenciando o time, ou, no mínimo, colhendo status. Meu medo é só com o regime comando-controle, que é muito improdutivo, mas de resto tudo me parece justo, principalmente com times menos seniors, e com acompanhamento à distância, como no caso de terceirização ou times distribuídos.

Aqui você tem um PPT dele explicando como prevenir a falha em projetos. Bem legal, recomendo.

Hoje foi o primeiro dia do Brazil Scrum Gathering, primeiro Scrum Gathering realizado fora da Europa e Estados Unidos, e eu estava lá. O dia foi o máximo, com uma abertura de, pasmem, Ricardo Vargas, chairman mundial do PMI. Seguiu depois com várias palestras de técnicas relacionadas a Scrum, e também casos de sucesso. Houve uma palestra sobre CMMi com Scrum. O ponto alto do evento foi um keynote do Ken Schwaber, feito virtualmente.

Minhas impressões:

O PMI está preocupado com a adoção massiva do Scrum. O Ricardo Vargas deixou claro que Scrum e PMI não são excludentes. Isso na teoria parece ser verdade. Na prática, como 99% dos PMPs praticam as propostas do PMI, são coisas diametralmente opostas. Em determinados monentos o Ricardo Vargas soltou algumas frases interessantes. A primeira foi que você não precisa respeitar o PMBoK, o que caiu como uma bomba para os muitos PMPs da platéia. A segunda foi que ele, Ricardo Vargas, não entende gestão compartilhada porque em projetos 90% das pessoas de qualquer equipe quer mais é ir embora para casa em vez de se envolver de verdade em um projeto. Isso, de cara, impede qualquer convivência entre PMI e Scrum. Mas enfim…

O keynote do Ken Schwaber eu achei fraco. Para o cara que é o presidente da ScrumAlliance, eu esperava mais. Ele praticamente resumiu vários pontos do curso de CSM, inclusive realizando um treinamento lá como todos, na hora. Isso foi ruim porque a maioria do público já entendia Scrum, e muitos eram CSMs, ou seja, não agregou. Depois ele abriu para perguntas, e eu tive a chance de fazer uma das várias perguntas que já tinha elaborado. Aproveitei para fazer uma pergunta que os xiitas de agile (xiitas nunca são bons) defendem com a alma: Projetos em Scrum falham? Reposta: Falham (para tristeza dos xiitas). Você pode perceber que o projeto é inviável financeiramente depois de algumas sprints, por exemplo. Ainda assim, ele disse que projetos de Scrum são feitos para não falhar. Oras, os defensores do waterfall também diriam isso… Mas enfim…

No final houve um coquetel no próprio hotel, e uma boa parte dos palestrantes e alguns participantes resolveram esticar em um happy hour, que acabou agora à pouco. Foi bem legal, porque pudemos trocar muitas experiências tanto no coquetel, quanto no happy hour.

Eu falei para todo mundo: US$ 200 por um evento desse, com os palestrantes que estavam lá, nesse nível, incluido até mesmo almoço, estava de graça. Quem não foi, e gosta do assunto, perdeu uma excelente oportunidade. O próximo gathering vai ser na Alemanha, ou seja, vai ficar bem mais complicado participar.

Meu post anterior resultou em alguns comentários interessantes. Nele eu disse que se um desenvolvedor quer virar gerente de projetos você tem problemas. Como pode ter muita gente que discorda do que eu disse e não comentou, resolvi, em vez de responder aos comentários, fazer este post. Aproveito aos que não comentaram e não concordam, a saírem do modo read-only e comentarem. Assim como os que concordam também.

A maior parte dos comentários passou pelo fato de eu estar generalizando, como de fato estava, e que nem sempre o caso cairia em uma das duas situações. Bom, toda regra tem suas exceções, mas eu sustento que as duas opções que dei atendem a imensa maioria do mercado. Eu resumi as opções assim:

"Em resumo: o cara quer ganhar mais, e você perdeu um desenvolvedor e ganhou um mau gerente; ou o cara não gosta do que faz e você perdeu um desenvolvedor e a empresa pode ou não ganhar um bom gerente."

Vou pular a discussão sobre remuneração, porque ela desperta menos polêmica. Seguindo na outra, bem mais interessante:

Porque eu não acho que uma pessoa com talento para gestão de projetos pode ser também um bom desenvolvedor? Porque eu acho que uma pessoa que ama codificar não dá um bom gerente de projeto? Porque?

Porque, como diz o título deste post, gerenciar projetos não tem nada a ver com desenvolvimento de software. Gestão de projetos sequer devia ser ensinada como parte de um currículo de tecnologia, e sim de administração de empresas, algo que já está começando a acontecer nas melhores faculdades. Gestão de projetos não tem nada, N-A-D-A, em comum com tecnologia. Ainda assim, os cursos nasceram em TI, e seguem focados em TI. E muitos codificadores vêem o cargo de gerente de projetos como progressão natural na carreira. Entendo que algumas pessoas busquem esta profissão, afinal, todo projeto precisa de um gerente de projetos (isso não é verdade, mas vou assumir como verdade e comento no final). Os codificadores estão, o tempo todo, trabalhando lado a lado com um GP. É natural que alguns se interessem.

A questão é que são coisas muito diferentes. As competências exigidas de um GP são absolutamente diferentes - senão opostas - às esperadas em um desenvolvedor de software. O primeiro deve saber lidar muito bem com pessoas, liderá-las, ser extremamente bem organizado, político e ter capacidade de raciocínio subjetivo, adorar se comunicar, gostar de fazer cálculos financeiros e projeções, e ter prazer em trabalhar com regras sociais. Do segundo espera-se análises concretas, lógica apurada, raciocínio rápido, capacidade de trabalhar longas horas focado na solução de um problema, ser interessado em maneiras novas de resolver velhos problemas, amar tecnologia, ser criativo dentro de um padrão lógico. Essas qualidades todas podem existir em uma única pessoa? Podem. É comum que isso aconteça? Não. Em geral são pessoas muito diferentes.

Aos que discordam de mim, e vão seguir este caminho, deixo uma mensagem clara: investigue, dentro de si mesmo, se você quer abandonar o Visual Studio, e passar a usar o Word e o Outlook o dia inteiro como principal ferramenta de trabalho. Se é capaz de, em vez de executar, somente assistir à execução. De ficar de fora do caminho de quem faz, e, na verdade, auxiliá-lo quando ele tiver problemas. Gerenciar não é mandar, é facilitar. Diante disso, acredito muito na figura do líder servidor. Você é capaz de servir à equipe, de, em vez de mandar, correr atrás do que eles precisam? Você vê um dia de trabalho que o dia inteiro foi gasto em reuniões de orçamentação como um dia divertido? E outro dia passado revisando performance do time com o RH? E outro ainda realizando resolução de conflitos interdepartamentais? Essas são tarefas de um gerente, e é bom que ele goste, ou vai viver infeliz, como acontece frequentemente. O trabalho tem uma visão interessante, quase romântica, mas será que os que o aspiram já se imaginaram nele pelo resto da vida? E se vê, então investigue em si mesmo o oposto: você realmente gosta de codificar? É algo que faz por paixão, do qual sente falta se fica algum tempo sem fazer? É algo que te dá prazer e gratificação?

Se você se vê nessa posição de gerente e gosta do que vê, perfeito! No entanto, não entendo ser possível que o ideal de felicidade de alguém seja ao mesmo tempo passar o dia em orçamentação e passar o dia codificando. São coisas muitos diferentes. É por isso que eu disse: uma das duas coisas essa pessoa não vai gostar de fazer. Eu jamais recomendo a uma pessoa que é apaixonada por codificação que trabalhasse em um cargo gerencial. Como não recomendo a alguém apaixonado por gerenciar pessoas que codifique.

Há uma pergunta que costumo fazer à pessoas que entrevisto: Você codifica nas horas vagas? Se a resposta é não, eu quero saber o porque. Isso diz muito sobre o quanto você gosta do que faz. Da mesma forma que gerentes apaixonados pela gestão financeira fazem planilhas para controlar seus gastos pessoais, programadores apaixonados às vees automatizam pequenas coisas com programas que fizeram, avaliam uma nova linguagem só porque ela parece interessante, e quando vêem um código na tela do cinema tentam entender o que ele quer dizer.

Apenas para fechar: Volto ao tema de projetos de software precisarem de um gerente de projetos. Não precisam. O mundo de TI está começando a perceber agora, conforme as metodologias ágeis afundam a figura do gerente de projetos e escancaram o fato de que times autogerenciáveis são muito mais eficientes. Esse perfil em TI vai virar peça de museu conforme percebe-se que o modelo baseado na figura controladora, responsável por ações de comando-e-controle, que o GP representa na maioria das organizações, é improdutiva, além de dispensável. Você pode até não concordar, mas somente se já viveu dos dois lados do muro (e nesse caso gostaria de ouvir suas experiências concretas).
Eu? Acredito na figura do facilitador de projetos, do derrubador de barreiras, algo que em Scrum chamamos de ScrumMaster. E ele não é um gerente de projetos.

Estava conversando com um cliente sobre um projeto. Ele me contava que tinha um desenvolvedor sênior trabalhando em algo importante para a empresa.

Perguntei:
- Sênior mesmo? - como quem já desconfia quase sempre que algum desenvolvedor de .Net se declara sênior…
A resposta dele:
- É, sênior, ele é um cara sério, está estudando e quer até virar gerente de projetos.
Minha resposta:
- Você está com problemas.

Se você tem um desenvolvedor na sua equipe que "quer virar" gerente de projetos você está com problemas. Sabe porque? Porque há apenas duas possibilidades para a origem desta aspiração:

1. Ele não gosta do que faz agora, ou;
2. Ele acha que ganha pouco.

Em qualquer dos casos você tem um problema na mão. Um problema que tem que ser resolvido.

Se for o segundo caso, o problema não é só seu ou da sua empresa. No Brasil entende-se que o superior hierárquico tem que ganhar mais que o subordinado, por diversos motivos que não vale a pena entrar agora. Não se admite que o "recurso do projeto" ganhe mais que o arquiteto ou que o gerente do projeto (deste muito menos, ele até usa gravata!). Não há o que fazer, uma pessoa do seu time quer ganhar mais, e a não ser que você queira inverter a maneira natural de pensar do brasileiro, você vai ter que deixar ele fazer algo que ele não gosta, não quer, ou não tem talento para fazer, para que ele possa ganhar mais. Afinal, esta é a única maneira de ganhar mais em alguns casos. Isso é um problema para você porque você vai perder um bom desenvolvedor, e a empresa vai, em geral, ganhar um mau gerente. Mais comum impossível. Quem não conhece um gerente sem a menor qualidade para gerenciar pessoas que era um bom técnico?

Se for o primeiro caso, então a empresa tem a oportunidade de ganhar um bom gerente. A má notícia é que você tem alguém no time que joga no Flamengo e está namorando o Real Madrid, ou seja, está com a cabeça em outro lugar. E, pior, trabalha sem emoção, sem paixão, sem envolvimento, já que o trabalho atual é só um meio de ele chegar aonde vai fazer o que realmente gosta. Há duas opções neste caso: você vê potencial e promove o cara, e deixa a empresa feliz com seu novo gerente. Ou manda ele virar gerente em outra empresa, já que você precisa mesmo é de um desenvolvedor.

Em resumo: o cara quer ganhar mais, e você perdeu um desenvolvedor e ganhou um mau gerente; ou o cara não gosta do que faz e você perdeu um desenvolvedor e a empresa pode ou não ganhar um bom gerente.

Como eu disse, em qualquer dos casos você está com problema: você vai perder um desenvolvedor. Que seja mais cedo do que mais tarde.

Todo mundo já sabe que vai rolar o Brazil Scrum Gathering dias 12 e 13 de Maio. Bom, estarei lá, como já disse aqui, e estou fechando uma entrevista com o Ken Schwaber, um dos pais do Scrum, se não for O pai.

Quero aproveitar então e levar as suas perguntas para Mr. Schwaber. O que você gostaria de perguntar a ele? O que você não entendeu, não concorda ou tem uma dúvida, e gostaria de saber?

Pois bem, essa é sua chance de tê-la respondida. Você pode me mandar um email em giggio [arroba] giggio.net, deixar um comentário neste post, ou enviar um comentário pelo formulário de contato aqui do blog. Não prometo fazer todas as perguntas sugeridas, mas as melhores com certeza vão entrar.