Lema, ou Motto (em inglês), “é uma ideia expressa por uma frase que serve de guia ou de motivação para uma pessoa […] condensam valores comuns que justificam uma ação comum” (definição completa da Wikipedia).
Sempre admirei pessoas que pregam e realmente seguem seus lemas. Boris Gloger e o seu famoso In SCRUM we trust, claramente inspirado no lema que está impresso no dólar americano – In god we trust. Tem também aqueles lemas “genéricos”, como o do filme Sociedade dos poetas mortos – Carpe diem, ou Aproveite o dia.
Ao meu ver, um lema ou mote não precisa ser original. A maioria dos lemas que já vi são simples reciclagens ou reescritas de lemas mais antigos. O que é importante no lema é que ele traduza a sua motivação, e condensem os seus valores.
Até então, meu sentimento em relação a um lema era esse: admiração. Até que estava lendo uma reportagem sobre a eleição do Barack Obama (coisa antiga) quando vi um cara segurando um cartaz com os seguintes dizeres:
There is no progress without change.
Nesse momento, tive uma epifania. Foi como uma lâmpada se acendendo na minha cabeça. Era exatamente isso que eu estava procurando!
Não é um lema original, pois não sou o autor, mas acredito que a frase traduz muito bem os meus valores e se conecta muito bem com os valores do trabalho que desenvolvo com métodos ágeis e Scrum. Não a mudança burra, mudar por mudar, mas a mudança atrelada ao conceito do progresso, da melhoriacontínua. Por isso mudei o título desse blog. Esse é o meu lema! Qual é o seu?
Há algum tempo atrás, em uma das discussões da lista Scrum-Brasil do Yahoo! Groups, escrevi uma mensagem que terminou virando post em um blog. Encontrei o post por acaso, em uma pesquisa pelo Google… e mensagem me chamou atenção, pois é uma das coisas mais difíceis que enfrento no meu dia-a-dia às voltas com desenvolvimento ágil de software: cobrar pelo valor, ao invés de horas. Interessante, hoje mesmo troquei idéias com um dos nossos consultores sobre isso: o mercado de desenvolvimento de software precisa mudar. Nós, desenvolvedores, não podemos cobrar pelo nosso trabalho como um trabalhador manual. Gosto de ilustrar com a seguinte estória:
Era uma vez uma empresa transportadora de cargas. Trabalhava transportando cargas bilionárias, petróleo e toda essa espécie de coisas. A menina dos olhos da empresa era um grande e novíssimo navio, que fora fabricado ao custo de 2 bilhões de dólares.
Um dia de serviço desse navio custava à empresa US$ 100.000 dolares. Após somente 6 meses de serviço, o navio simplesmente parou de funcionar. Foram chamados técnicos e mais engenheiros e mais mecânicos do fabricante, que ao término de 1 mês não conseguiram resolver o problema de jeito nenhum. 30 dias com esse navio parado siginificava um prejuízo de 3 milhões de dólares para a empresa, e seus donos estavam à beira de um colapso nervoso quando foi dada a idéia de chamar um especialista independente, que já tinha enfrentado problemas semelhantes e se saído muito bem, devido à sua experiência imensa com a complexa mecânica naval.
Eis que no dia seguinte, chega o especialista. Senta-se em frente a uma das partes do motor, tenta ligar, pressiona alguns botoes, balança a cabeça, murmura algo para si mesmo… e puxa uma chave de fenda da sua caixa de ferramentas. Desaparece por entre os motores por alguns instantes, e ao retornar diz: “problema resolvido”. Apenas ao toque de um botão, o motor responde e o navio começa a funcionar.
O presidente da empresa ficou impressionado, e perguntou ao especialista quanto ele lhe devia. O especialista respondeu:
– A conta é US$ 1 milhão, por favor.
O presidente da empresa ficou indignado, e falou:
– US$ 1 milhão por apenas alguns minutos de trabalho? Para apertar um parafuso? Eu sei que o meu navio é um navio de 2 bilhões de dólares, mas 1 milhão é absurdo! Pagarei somente se receber demonstrativo com todos os detalhes que justifiquem esse valor!
O especialista simplesmente balançou a cabeça afirmativamente e saiu.
Na manhã seguinte, o presidente recebe o demonstrativo com o detalhamento do serviço. Ao terminar a leitura, não hesitou e mandou que fosse paga no ato.
A nota fiscal dizia:
“Serviços realizados:
Visita técnica – cortesia
Apertar um parafuso – US$ 0,10
Saber qual parafuso apertar – US$ 999.999,90“
Em suma, um problema que era remexido há um mês e sem solução foi resolvido em poucos minutos. Um erro comum é querer fazer comparações entre complexidade x tempo. Isso é errado. Quando estimamos utilizando planning poker, levamos em consideração o tamanho de uma história, relativo à sua complexidade – esqueça as horas. Mesmo. Trabalhamos com processos empíricos, lembram?
E no final, uma estimativa é somente uma estimativa – não é uma previsão, não está gravado em pedra, e não precisam ser certas. A definição da palavra “estimativa” comprova isso, procure no Google. Obviamente, quando atingimos uma certa regularidade e melhoramos nossa exatidão das estimativas, ganhamos mais previsibilidade e temos melhores condições de nos planejar para o futuro. Mas isso é uma coisa que vem naturalmente, assim como a velocidade do time, e não pode ser forçada.
O ingrediente secreto do Scrum
E por falar em coisas que não podem ser forçadas, me lembrei de uma coisa que gosto de evidenciar em minhas conversas sobre Scrum e Agilidade: Em um âmbito mais abrangente, desenvolvimento de software é um processo criativo.
Você não pode forçar pessoas a terem idéias. O que podemos fazer é criar um ambiente propenso à boas idéias – como um terreno fértil. E esse é um dos vários ingredientes “secretos” para o sucesso, coisas que não estão escritas em nenhum manual – e que nenhuma ferramenta vai ajudar você à obter.
