Times de verdade são raros. Times maduros são raríssimos. Tanto mais em uma cultura que ainda não percebeu quanto desperdício e mal estar causa toda vez que desmonta um time ou não dá bola para seu desmanche. Um economista chutador não hesitaria em cravar que os timecídios custam bilhões de dólares anualmente. Ele não estaria errado. Porque é difícil e demorado formar um time de verdade.

Formação: O Parto

Dado um desafio, quase sempre nebuloso e ambíguo, é preciso descobrir e classificar as competências necessárias para vencê-lo. Tentamos simplificar a coisa com profissionais full-stack. Só para relembrar como são mentirosos os atalhos e ineficazes os times de iguais. Cedo ou tarde vamos descobrir que só a variedade de talentos e interesses será capaz de absorver toda a variedade que virá das partes envolvidas.

Esses talentos (o que sabem fazer) e interesses (o que pretendem aprender) precisam se encaixar. A isso chamamos entrosamento. Sabemos que ele não acontecerá do dia para a noite. Desconfiamos que ele pode não acontecer. 

Inventamos divertidos jogos e dinâmicas para team building – para a formação de times. Alimentamos a esperança de que seria possível acelerar com brincadeiras algo que só ocorre quando a conversa é séria. Entrosamento de verdade só é alcançado quando o time resolve conflitos e problemas de verdade. Quando cria confiança. Os jogos, neste momento, não servem para muita coisa além de quebrar o gelo e provocar risadas ou vergonha alheia. 

Só saberemos se aquele time-todo tem potencial para ser maior que a soma das partes jogando-o, o quanto antes, para as feras (aka stakeholders). Todo parto é um choque de realidade. Não há razão para adiar este encontro. Porque só assim o time conhecerá as fronteiras, interfaces e modos que guiarão o seu funcionamento. 

Confrontação: A Infância Difícil

Toda novidade causa estranheza e algum nível de desconforto. Estamos tratando de um grupo de pessoas que foi reunido pela primeira vez e jogado em um contexto diferente. Ainda que o ambiente seja receptivo, haverá desconfiança. Haverá insegurança. E tudo isso é muito normal. Usando aquele raciocínio linear proposto pelo modelo de Tuckman², entramos na etapa de confrontação (storming).

Nosso principal objetivo aqui é reduzir o frio na barriga – é eliminar o grosso das incertezas. Para tanto, precisamos fazer perguntas e testar as respostas em ciclos bem curtos. Estamos tateando no escuro, descobrindo um caminho. Por isso os ciclos rápidos de feedback são cruciais. 

O modelo de Tuckman, cuja versão original é de 1965, não esconde o jeito cascata de pensar. Cabe aqui a observação de que a confrontação (storming) pode ocorrer a todo instante e isso não é necessariamente ruim. Um time em que tudo parece estar funcionando o tempo todo é muito mais preocupante do que um time onde os confrontos são relativamente comuns. 

Este primeiro confronto merece destaque porque é ou deveria ser a única infância de um time. Acontece que cada mínima mudança em sua estrutura significa um novo começo. Justificável ou não, cada troca de membros de um time é quase um reset. Porque afeta todo mundo. 

Normatização: A Confiança Adquirida

Um time se estabiliza quando há confiança compartilhada entre os membros e entre estes, como entidade única, e as demais partes envolvidas. Palavra chave: CONFIANÇA. 

Confiança = (credibilidade * intimidade) / risco

Para entender³:

• Credibilidade: coloco a mão no fogo por fulana/o?
• Intimidade: quão bem a/o conheço?
• Risco: o que pode acontecer se fulana/o pisar na bola?

Confiança de verdade não acontece por decreto nem é garantida por diplomas ou certificados. A única maneira de saber se podemos confiar em alguém é confiando, ensinou Hemingway. Confiança se ganha e se perde no dia a dia. Caramba, estamos cansados de saber disso. Mas, por favor, me siga. Imagine um time com 5 pessoas. 

R = (N (N-1))/2

R é o número de relações possíveis em um time. N é o tamanho do time. Neste caso, temos 10 relacionamentos. São dez relações de confiança que precisam ser cultivadas. Insisto: isso não acontece da noite para o dia.

Pense em todos os membros de seu time atual. Há  quanto tempo vocês estão juntos? Você colocaria a mão no fogo por todos? Quanto tempo demorou para você desenvolver essa (des)confiança? 

Velozes e Curiosos

“É incrível o quanto a gente consegue enxugar – em termos de documentos e processos – quando há confiança mútua.”
– Daryl Kulak e Hong Li⁴

Confiança = Velocidade. Velocidade na tomada de decisões e em resoluções de conflitos. Velocidade dos ciclos de feedback. Velocidade que destaca um time.

Quanto tempo um time demora para atingir essa velocidade, esse nível de confiança? Quanto isso custa? Cada timecídio representa esse custo multiplicado por dois. Porque aquilo que foi descartado deverá ser reconstruído do zero.

Se ser enxuto de verdade significa combater desperdícios, então uma de nossas prioridades deveria ser a redução drástica dos timecídios. Algumas sugestões:

• Enxergar PRODUTOS e não projetos;
• Contratar PESSOAS FÍSICAS COMO PESSOAS FÍSICAS;
• Reconhecer e bonificar O MÉRITO DOS TIMES e não dos indivíduos;
• Incentivar e bonificar a LONGEVIDADE DOS TIMES;
• Ler Peopleware e entender porque burocracia, mau uso do tempo, prazos mentirosos e desleixo com a qualidade são desmotivadores e, consequentemente, causas comuns de timecídios.

Quanto tempo dura um time de verdade? Quanto deveria durar?

Notas

1. Tom DeMarco e Timothy Lister (Dorset House, 1987-2013). Em edição tupiniquim, a tradutora Kátia Aparecida Roque optou por Equipecídio (Makron Books, 1990).
2. https://pt.wikipedia.org/wiki/Modelo_de_Tuckman
3. Surrupiei a fórmula de The Fractal Organization: Creating sustainable organizations with the Viable System Model, de Patrick Hoverstadt (Wiley, 2011).
4. The Journey to Enterprise Agility (Springer, 2017). Veio do mesmo livro a afirmação seguinte, Confiança = Velocidade. Este é o primeiro princípio do Pensamento Sistêmico colocado por Daryl Kulak e Hong Li.
5. Foto de Toa Heftiba no Unsplash

Um time maduro sabe o que quer e se garante. Ele é necessariamente viável – capaz de sobreviver e prosperar de forma autônoma. O que não faz dele uma bolha. Porque um time verdadeiramente maduro sabe que é um sistema aberto e entende que não tem utilidade fora de seu ambiente ou deslocado de seu propósito. Um time de verdade não é apenas reativo – orgânico – na má interpretação dada a essa palavra. Um time maduro exerce influência e coevolui com seu meio. Ele experimenta, aprende e propõe mudanças. Um time maduro não copia, rouba.

Grandes Times Roubam

Pablo Picasso: “Bons artistas copiam, grandes artistas roubam”. Eles não roubam o produto final, a obra prima. Isso dá cadeia e não tem graça nenhuma. Assim como não tem graça chamar times de squads porque isso parece moderno ou bonitinho. Esquadrão nunca foi um sinônimo simpático para TIME. 

Grandes times, assim como os grandes artistas, roubam a inspiração que levou àquela obra ou produto. Chamar time de squad é só perfumaria. Aliás, a cópia do modelo Spotify entra no rol dos problemas que causamos porque estávamos apressados demais para acionar o nosso senso crítico². Os chapters e guildas – outros termos vendedores porque diferentes – nada mais são do que releituras das antigas Comunidades de Prática³. Pequenas adaptações que foram apresentadas de forma a justificar ou disfarçar uma organização matricial⁴. Quem copia sabe que o modelo não funcionou nem no Spotify?

Escalar a agilidade – um dos objetivos originais do modelo Spotify – é um problema que já mereceu zilhões de palavras escritas e algumas berradas. Não tenho a menor pretensão de apresentar uma visão alternativa. Até porque nunca fui além de alguns poucos times e dezenas de pessoas sob minha responsabilidade. Entretanto, depois de trinta e tantos anos de carreira, posso falar sobre times maduros e suas ideias roubadas.

Por  Exemplo

Guildas e chapters são soluções para qual ou quais  problemas? O assunto me é particularmente caro porque ele justificou a criação deste finito há dezesseis anos. Criei este espaço para desenvolver e apresentar um trabalho sobre o Aprendizado inter-projetos. Em suma:

• Como fazer com que os times troquem experiências e evitem a reincidência de erros e problemas?
• É possível promover uma evolução homogênea dos times ao mesmo tempo em que lhes é oferecida a máxima autonomia?

As comunidades de prática e todas as suas versões pós-modernas – guildas, chapters etc – correm o mesmo risco. Passado o entusiasmo inicial, muito rapidamente elas podem ficar irrelevantes e vazias. Há um motivo bem quente para isso: o inferno nosso de cada dia. A correria tende a matar tudo o que não tenha aplicação imediata, promissora e barata. 

Na melhor versão dessas comunidades a participação é voluntária. O que tende a aumentar o interesse e a qualidade das conversas. No entanto, a participação é voluntária… Já me deparei com gente que deixou de ir aos encontros quinzenais por medo de ser percebido como alguém com a agenda folgada.

Conclusão: esses mecanismos de incentivo ao aprendizado são elegantes e cheios de boas intenções. O problema é que raramente encontram um ambiente que os favoreça. Insistimos em variações da mesma ideia desde o início dos anos 1990. Chamar encontros ou reuniões de lean coffee e ser generoso nos comes e bebes não adiantou muita coisa. Passa da hora de tentarmos coisas diferentes.

Por exemplo: 

• Pense em uma dupla ou time que você pode plugar em um time fixo de forma a oferecer funcionalidades adicionais por um certo período. 
• Pode oferecer, por exemplo, o necessário olhar de gente “de fora” em busca de oportunidades de melhoria. Se estamos falando de um time de desenvolvimento de software, temos aqui um plugin para a Refatoração Oportunista. Além do potencial ganho de qualidade, podemos esperar:
  • Polinização cruzada – difusão mais rápida e ampla de conhecimentos
  • Mais gente com condições de participar daquele projeto/produto
  • Treinamento com a finalidade de cobrir férias, licenças ou qualquer outra ausência minimamente previsível
• Na correria do dia a dia, quantos times têm tempo e recursos para fazer pesquisas e experiências? Falando novamente de software, quantos spikes em média os times realizam a cada sprint? Um time plugável pode oferecer tal possibilidade sem comprometer o que já foi combinado com clientes e usuários. 
• Em um prestador de serviços, esses spikes podem ser utilizados para a descoberta de novas oportunidades de negócio. Se tornam Spikes Interesseiros. Criam argumentos de vendas que vão muito além do blablablá “somos ágeis f*ckin’ black belt acreditados pra chuchu etc”.
• Pense nisso: times livres e plugáveis, sem formação ou propósito fixos, podem fortalecer os times fixos ao mesmo tempo em que promovem a troca de conhecimentos e experiências. Com a mão na massa, não em auditórios ou cafés.
• Por fim, mas não menos importante: os times livres parecem ser bastante adequados para os processos de on-boarding, para a acolhida e preparação de novos colaboradores.

Um time ou organização exala maturidade ao explorar alternativas e criar soluções. Os exemplos acima não sanam todas as questões colocadas. Não era essa a intenção. Assim como a originalidade absoluta não é meta de ninguém, nem dos artistas mais picassos. Porque ela, a originalidade total, não existe. Já a maturidade, seja de um time ou organização, não só existe como é fácil de ser percebida.

Assim como é fácil de ser destruída. DeMarco e Lister⁵ criaram até um nome para isso: Timecídio. Tema do próximo post. Até lá!

Notas

1. Trecho da música Selvagem dos Paralamas do Sucesso (Selvagem?, 1986).
2. Há tempo sapateamos nessa calçada infame. Em 1970, por exemplo,  interpretamos muito mal um artigo de Winston W. Royce e glorificamos o modelo Waterfall. Agora, apesar dos inúmeros avisos (compilados neste artigo, em inglês), fizemos o mesmo com o modelo Spotify.
3. https://pt.wikipedia.org/wiki/Comunidade_de_pr%C3%A1tica
4. https://pt.wikipedia.org/wiki/Departamentaliza%C3%A7%C3%A3o_matricial
5. Peopleware: Productive Projects and Teams (Dorset House, 1987|2013).
6. Foto de Anna Samoylova no Unsplash

É certo que o jeito Ágil de pensar – com iterações curtas e feedback rápido – nos ajuda a compreender e delimitar melhor o problema enquanto desenvolvemos e entregamos a solução. Mas qual é o marco zero? Qual deve ser o nosso ponto de partida? Se a gente soubesse o quanto esse primeiro passo influencia o desenho da solução seríamos um tanto mais cuidadosos.

Qual é o problema? Por que é um problema? Quem é afetado por ele? O que está envolvido? O que pode acontecer se a gente não resolver o problema?

Desenvolver o sistema X ou o app Y; Aumentar o market share; Reduzir os custos do processo Z; Melhorar a nossa imagem; Aumentar o faturamento em tantos milhões. Nada disso é problema.

Todas as frases acima sinalizam possíveis soluções. Mas dizem muito pouco ou nada sobre o problema. Foi por isso que o pessoal da Toyota inventou o 5 Porquês. Porque geralmente precisamos de cinco enxadadas para alcançar a raiz do problema.

Tratar a ferramenta 5 Porquês como guia para uma entrevista 1:1 é um desperdício e tanto. Porque ela só prova todo o seu potencial quando é combinada com outras ferramentas em uma Investigação Sistêmica². Este processo de descoberta deve envolver o maior número possível de interessados, interesseiros e encrenqueiros. Todos juntos no mesmo lugar. As respostas para cada porquê se desdobram em potenciais componentes do verdadeiro problema.

É um engano relativamente comum entender o Pensamento Sistêmico como uma forma de “ver o todo”. Ver o todo é só uma PARTE desse jeito de pensar. Se vemos só essa parte, perdemos o TODO do Pensamento Sistêmico.
(A recursividade é intencional. Na dúvida, releia o parágrafo).

Uma Rica Fotografia

Orientados pela ferramenta 5 Porquês podemos desenvolver uma Rica Fotografia (Rich Picture, no original em inglês). Esse modelo vem de uma das diversas propostas do Pensamento Sistêmico, a Soft Systems Methodology (SSM), de Peter Checkland. A fotografia é rica porque apresenta o contexto em toda a sua riqueza de diversidade, estrutura, relacionamentos e pontos de vista. DSRP: Distinções | Sistemas | Relacionamentos | Perspectivas. São as quatro regras que, em conjunto, nos ajudam a enxergar e compreender o mundo como ele realmente funciona. Ou seja, nos ajudam a pensar sistemicamente.

Devemos evitar a definição prévia do tipo de fotografia que queremos. Processos ou cadeias de valor não são indicados porque restringem, logo de partida, a forma como vemos o problema. Além disso, passa da hora da gente entender que esse jeito linear de criação de valor não é onipresente, muito pelo contrário. Enfim, a Fotografia Rica deve nascer sem moldura, grades ou guias. As fronteiras e a lógica do modelo devem emergir. Partimos do problema como apresentado na primeira vez – mesmo que seja um simples “precisamos de um app” – e perguntamos: Por que precisamos de um app?

As discussões em torno das respostas nos permitem identificar as partes envolvidas e as relações entre elas. A classificação dos relacionamentos – forte, fraco, direto, indireto, entrada, saída, colaborativo, conflituoso, rápido, devagar etc – enriquece a fotografia. Parte da fotografia pode ser capturada na forma de um Mapa Causal (CLD – Causal Loop Diagram). Assim o modelo fica com um jeito de filme – ganha dinâmica.

Como essa fotografia é produto de um processo colaborativo, é de se esperar que ela capture diversos pontos de vista. Condenamos o processo e o ambiente se alguma perspectiva for favorecida ou ignorada. Se uma pessoa chave não puder participar, adie o encontro. Aliás, a falta de agenda pode ser um sinal de que o problema não é assim tão relevante. Pelo menos, não para aquela pessoa.

Um subproduto desejável da elaboração da Rica Fotografia é uma igualmente rica análise dos stakeholders (ou partes interessadas). Em uma única reunião somos apresentados não apenas às pessoas envolvidas (holders) mas também ao seu grau de envolvimento, aos seus pontos de vista e interesses (stakes). Isso é de suma importância em qualquer iniciativa porque, como ensinou Gerald Weinberg em The Secrets of Consulting (McGraw-Hill, 1985), “a despeito do que o cliente possa lhe dizer, sempre existe um problema. Não importa o que pareça a princípio, o problema é sempre com as pessoas”.

A bola chega redonda para DeMarco e Lister, que em Peopleware (Makron Books, 1990) emendam: “os principais problemas de nosso trabalho não são de natureza tecnológica mas sim sociológica”.

Conclusão

Vale a pena repetir sempre: não é o modelo; não se trata do entregável (sic). É o processo de elaboração que nos interessa. São as conversas que importam. É a criação de uma visão compartilhada do problema o que buscamos. Isso, por si só, fará você se apaixonar pelo problema? Talvez não. A sugestão aqui apresentada deve te deixar mais íntimo do problema. E problemas, assim como as pessoas, podem nos decepcionar quando desnudados. O que fazer com essa desilusão é outra conversa.

Que não será a próxima. Se hoje apresentei uma sugestão para tratar de um problema interno e específico, no próximo artigo eu pretendo falar sobre problemas externos e gerais – problemas que nos motivam a criar produtos ou serviços. Desconfio que eles sejam um tanto mais atraentes. Veremos.

Notas

1. Gerald Weinberg? Russell Ackoff? Tantos já falaram sobre isso que fica difícil decidir a quem creditar aquela frase.
2. Como eu queria que a gente tivesse adotado em português um termo bastante comum entre os pensadores sistêmicos: Inquiry – investigação, pesquisa. É bem melhor que análise, descoberta e exploração. Porque explica melhor o trabalho que realizamos.
3. Heart-it foi compartilhada por The ReflexMan no flickr.

Quem explora e desenvolve requisitos deve se preocupar com sete questões fundamentais. São testes executados várias vezes e em diversos momentos de um projeto. Segue a lista¹:

É Necessário?

O requisito realmente dá alguma contribuição, ainda que pequena, para a realização dos objetivos do negócio? Apesar de nossa insistência em perguntar a clientes e usuários pelo valor de cada requisito, a revalidação se paga. Porque podem aparecer funções, atributos ou restrições que, depois de certo tempo, perdem o sentido.

Também não pode existir, em nenhum tipo de projeto, um requisito que não se relacione com nenhum outro. Tratamos aqui de relações de dependência ou complementaridade, como visto anteriormente. Não há uma conta “diversos” em  projetos minimamente sérios.

É Compreensível?

No frigir dos ovos, um requisito é só “uma condição necessária para alcançar certo fim” (Houaiss). Nada justifica que seu entendimento seja difícil. Requisito é informação. E informação é “dado investido de relevância e propósito” (Peter Drucker). Informação é “a diferença que faz diferença” (Gregory Bateson). Por isso enriquecemos cada requisito com um conjunto de características que o explica e justifica: fonte, perspectiva, valor, relações e estado, pelo menos. Cada característica aumenta nossa compreensão sobre o requisito. Claro que, antes de qualquer coisa, a redação do requisito deve ser clara e objetiva. A estruturação não nos isenta da boa escrita.

Está Completo?

Um requisito que apresente pendências não deveria avançar em seu ciclo de vida. O solicitante aguarda alguma informação ou ainda precisa confirmar algo com alguém? Devemos oferecer nosso apoio, resolver as pendências e só então incorporar o requisito.

A recomendação é outra quando a pendência é fruto da insegurança de quem manifestou o requisito. Se é algo de muito valor, então acelere ou antecipe a realização daquele requisito. Coloque-o no topo da fila e faça com que entregas preliminares tranquilizem o cliente ou usuário. Mais sobre isso no último item da lista.

É Verificável?

Se não há a menor ideia sobre como a realização do requisito será testada, é provável que não seja um requisito. Atributos pra lá de ambíguos (tela bonita, processo rápido, operação fácil etc) também comprometem a testabilidade de uma solução. Eles devem ser evitados a todo custo. Todo bom requisito sugere, de maneira clara, pelo menos um teste que comprova sua realização.

É Viável?

O valor atribuído a cada requisito ou grupo de requisitos possibilita seu posicionamento vertical (eixo benefício) na matriz ao lado. Estimativas de custo de cada alternativa de solução² indicam a posição horizontal. Temos assim uma ferramenta que apoia a análise benefício/custo³ de todo o escopo de um projeto.

Pesadelos são descartados sem dramas. Dado o baixo valor agregado de determinado requisito, sua realização só faz sentido quando for uma bobeirinha – algo fácil e barato de construir. É a metade superior da matriz que merece nossa atenção. Se todas as alternativas fossem sonhos, com certeza você não estaria aqui. Projetos dignos de nota sempre oferecem algum tipo de desafio – módulos de muito valor cuja realização envolve alguma complexidade técnica e, consequentemente, alto custo.

Utilizamos valores relativos, tanto para benefícios quanto para custos, quando os números reais ainda estão distantes. Podemos utilizar escalas simples (Fundamental=3, Importante=2, Opcional=1) ou um pouco mais sofisticadas (a sequência de Fibonacci, por exemplo). Esta validação nos ajuda a definir o escopo ideal de uma solução. De quebra, ela sugere prioridades.

Está Priorizado?

A melhor imagem do escopo de qualquer projeto é uma fila indiana. Cada requisito incorporado merece uma posição única. No topo, temos tudo o que é fundamental para a realização dos objetivos do negócio. No fim, tudo o que pode ser cortado sem choro nem vela.

Quando é possível colocar em produção as entregas parciais, então os sonhos serão prioritários. Desta forma antecipamos a realização de valor. Caso contrário – quando tudo deve ser entregue em conjunto – começamos pelos desafios. Depois de entregar o que realmente importa, em havendo tempo e dinheiro, desenvolvemos algumas bobeirinhas.

Está Correto?

Enfim, resta saber se o requisito está correto. E o que garante sua correção? A assinatura do cliente ou usuário no documento de requisitos? Um contrato redigido pelo mais competente escritório de advocacia? Nada disso pode garantir que um requisito esteja correto. Só conseguimos 100% de certeza quando o requisito não é mais “uma condição para alcançar determinado fim”. Só temos total certeza de sua correção quando o fim é alcançado. Isso só é possível com a solução entregue e em funcionamento. O que pode demorar dias, semanas ou até meses para se confirmar.

Tamanha distância não nos livra da busca pela correção dos requisitos. Qualquer coisa – modelos, protótipos, versões alpha e beta e paliativos afins – que minimize o frio na barriga das partes interessadas pode e deve ser utilizada. Desde que haja consciência de que apenas o produto final, devidamente entregue e em funcionamento, terá as respostas definitivas.

Notas

1. A lista acima não tem nada a ver com os famigerados checklists que divertem ou enganam leitores de algumas revistas populares. Porque não é simples como: sim, não, sim, sim, não, não, sim = 17 pontos: tô gordo! Não é possível aplicá-la em um ponto específico do projeto. São validações e testes que analistas e demais envolvidos executam diariamente. Obsessivamente.
2. É de quem vai construir a solução a responsabilidade por apresentar alternativas e respectivas estimativas. Para que esta ferramenta funcione direitinho, a turma de negócio fala sobre benefícios e o time técnico sobre custos. O embate, a tensão criativa, tende a fazer emergir a melhor solução possível.
3. Não estou inventando moda. Foram Tom DeMarco e Timothy Lister, em Peopleware (Dorset House, 1999), que sugeriram a análise benefício / custo. A grafia “análise custo X benefício” carrega dois equívocos: i) a suposta operação ( multiplicação ou subtração) não faz nenhum sentido matemático; ii) a colocação do custo antes do benefício é coisa de gente mesquinha.
4. Este artigo é uma releitura das sugestões apresentadas por Karl Wiegers em Software Requirements (Microsoft Press, 1999).

O tema parece cercado de um certo tabu. Fui puxado para ele depois de assistir a um vídeo de um famoso “guru” da tecnologia tupiniquim¹. Ele iniciou a conversa dizendo que esse negócio de cobrar por hora não faz mais sentido. Não na Economia do Conhecimento. Certo! O problema é que no resto do papo (um número de palavras que começa pela mesma letra) não tocou mais no assunto. E aí, se não por horas, vou cobrar como?

Nunca gostei da unidade “homem/hora” ou “hora técnica” (sic) porque ela é furada como um queijo suíço. Serve para trabalhos braçais e repetitivos. Mas não tem nada a ver com o trabalho criativo ou do conhecimento. Por dois motivos principais:

• Uma excelente ideia de solução pode aparecer em uma fração de segundos. Ela vale uma fração de seu valor-hora?
• “Todo esforço caminha no sentido daquilo que está sendo medido“. Esta frase de Tom DeMarco deveria ser chamada de lei. Se o cliente ou empregador mede (pede) horas, horas ele vai receber. Porque corpo presente não é evidência de mente presente.

Mas o que fazer se, apesar de todos os argumentos, o mercado ainda compra (e vende) horas? Eu insisto – teimo mesmo – em cobrar por serviço. Foram raras as vezes em que um cliente topou. O que me obriga a sempre ter na manga um taxímetro. Conta fácil, que só exige uma estimativa um pouquinho mais pensada sobre uma das seis dimensões que me ajudam a formar o preço de determinado serviço. Mostrarei abaixo o esquema que muito me ajuda. Na expectativa que ele lhe seja útil também, seja na hora de negociar um salário ou o valor de seus serviços.

Preço é Estratégia

Com certeza não é sua única arma estratégica, mas o preço sintetiza toda a sua estratégia. Como já escreveu Gerald Weinberg², “a determinação de preços tem muitas funções e a permuta de dinheiro é apenas uma delas“.  Através do preço você:

• Define seu mercado;
• Se diferencia da concorrência;
• Atrai (ou repele) determinados clientes (ou empregadores); e
• Delimita seus custos.

Pense nisso: de certa maneira, seu preço diz quem você é! Por isso é tão importante dedicar um tempinho toda vez que um preço precisa ser definido.

O ponto de partida não tem mistério nenhum. Você precisa de uma estimativa de custos e de uma margem de lucro. Ou de um valor médio de mercado. Você escolhe se ele representará um preço mensal, o valor total de um serviço ou a fatídica “hora técnica”. Este será seu preço base, aquele que aparece no centro do diagrama ao lado.

O diagrama exibe as dimensões ou fatores de ponderação que mais considero quando vou precificar um serviço. São seis dimensões de três tipos diferentes. Perfil do Freguês e Duração e Frequência podem funcionar como inflacionadores ou redutores do preço (+/-). A primeira indica apenas o quão atraente ou repugnante é aquele cliente. Ele é um mala ou um amor de pessoa? O histórico (vivido ou pesquisado) do cliente o fará aumentar ou reduzir o preço final.

A dimensão Duração o ajudará a contrabalancear os efeitos do perfil do freguês. Por exemplo: o cliente é muito chato, mas é um trabalho de curtíssima duração. Ou seja, “dá para aguentar sem a necessidade de furar seus olhos“.

Mas esta dimensão tem seu peso próprio. Até que ponto é desejável que aquele serviço ocupe sua agenda por um longo período? É a sua necessidade de uma certa estabilidade que o fará utilizar esta dimensão como um fator de inflação ou deflação de seu preço.

As duas dimensões do lado direito do diagrama, Criticidade e Complexidade, funcionam apenas como itens inflacionários. A Criticidade indica o quão valioso (e provavelmente urgente) é aquele serviço para o cliente. Quase sempre há uma relação direta entre valor, urgência e… Risco! Por isso esta dimensão representa acréscimos ao preço base.

Assim como a Complexidade, uma dimensão que lhe permite avaliar o quanto de seu cérebro será exigido na realização daquele trabalho. Não faz sentido, por exemplo, que você tenha um mesmo preço quando ministra um treinamento corriqueiro e quando faz uma consultoria daquelas bem cabeludas. Se lhe falta uma mínima noção sobre o tamanho da encrenca, aumente o fator complexidade. Se o cliente não consegue explicar a própria dor, idem. Normalmente isso é sintoma de um problema maior em estado de espera por uma luz – a sua luz!

As duas últimas dimensões funcionam como lembretes de que alguns fatores podem justificar uma redução do preço. A Oportunidade de Aprendizado é contraponto da complexidade. Acontece mais ou menos assim: “ok, o trampo é deveras difícil. Por outro lado, tenho a oportunidade de aprender a lidar com a tecnologia X e com o método Y”. Pronto, já tens uma boa desculpa para, antes mesmo de o cliente pedir, ceder um generoso desconto. Faz bem para a relação que o cliente seja comunicado de suas intenções (de aprendizado). Weinberg² de novo: “o preço não é uma coisa; é um relacionamento negociado.”

Por fim temos o Posicionamento, a contribuição daquele cliente ou serviço para sua colocação no mercado. Se prestar serviços para determinada organização enriquecerá seu currículo ou portfólio, talvez você ache justo cobrar um pouco menos. Se a execução de um dado serviço o ajudará a se diferenciar, talvez ele valha o investimento – e é assim que você veria o desconto concedido, como um investimento.

Matemática

O modelo “matemático” acima tem muito pouco de matemática. Sua aplicação depende, como vimos, de alguma intuição e muito tato. Depende também de boas informações sobre o cliente (ou empregador) e sobre o serviço a ser executado. Como foi colocado, as dimensões devem ser vistas como lembretes. E é claro que eu espero que você tenha os seus.

Ao ponderar o que tem valor para você, o preço aparece naturalmente. Se é verdade que hoje ninguém sabe o valor de nada, prove através do preço que o seu valor você conhece bem. E que sua dolorosa é justa.

Notas

1. Outra coisa que invejo em Gerald Weinberg, além da qualidade de seus escritos e de sua imensa produtividade, é sua não parcimônia ao detonar trabalhos alheios. Nada de jogo sujo ou briga de egos ou por espaço. Em seus livros ele cita artigos que não gostou, dá nome aos bois, mostra o que não gostou e apresenta seu lado. Sei lá o motivo, mas aqui em Pindorama a gente vive pisando em cascas de ovo. Apesar de alguns bois implorarem para ter seus nomes berrados.
2. Trechos surrupiados de um livro que, caso dependesse do título, não mereceria a leitura. Estou falando de “Consultoria – O Segredo do Sucesso”, trabalho do Weinberg publicado pela McGraw-Hill em 1990. O título original era apenas “The Secrets of Consulting“. Mas as editoras tupiniquins morrem de inveja das distribuidoras que traduzem nomes de filmes.
3. A imagem que ilustra este artigo é do sr. mzocoxito.

O gerente é uma invenção da era industrial, um mal necessitado pelos verdadeiros donos de negócios que precisavam ganhar escala. Deveriam funcionar como clones parciais e especialistas do manda-chuvas. Um especialista em vendas, outro em finanças e assim por diante. Os gerentes ocupam a camada intermediária de uma organização, entre o topo e os peões. Na teoria, e quase só na teoria, eles defenderiam o ponto de vista tático. Ou seja, trabalhariam com um horizonte de médio prazo. Quem está acima deles enxergaria mais longe. Quem está na base cuida do dia a dia, provavelmente sob os auspícios e chicotes de um supervisor ou líder técnico – um outro nível de gerente que vive a mirar o andar de cima com desejos inconfessáveis.

A necessidade de uma organização hierárquica criou na marra uma separação que não fazia sentido no século 18 assim como parece não fazer no século 21. Cérebro e mãos foram apartados artificialmente. Tanto que Henry Ford vivia reclamando que “quando contratava duas mãos, o cérebro vinha junto”. À base de pirâmide não era permitido pensar. Seus ocupantes deveriam apertar porcas e deixar todo o trampo intelectual para quem estivesse acima. E assim a posição do cérebro – do gerente – mesmo que limitada, virou objeto de desejo de todos que tivessem um mínimo de ambição. Não era só o maior salário. Era sobretudo o status, o inequívoco sinal de ascensão social.

Muita demanda, ofertas teoricamente limitadas. Neste jogo político, assim como em governos com inflada base de apoio, inventam-se cadeiras e postos. E o meio da pirâmide inchou para todos os lados. Na linha do tempo estamos entre os anos 1950 e 1980 (lá fora) ou 2000 (aqui no Brasil). Pois é, tem duas ou três décadas que olhamos para este meio de campo e perguntamos: precisamos de tantos gerentes assim? Aqueles que já passaram da página três têm outra questão: precisamos mesmo de gerentes?

G de Gerente, G de Gargalo

Se os proponentes dos métodos ágeis adoram falar que gerentes não são mais necessários, não deve surpreender a ninguém o fato deles – os gerentes –  serem tão pouco receptivos à ideia. Com outras palavras, é isso que diz Jurgen Appelo em Management 3.0, publicado em 2011. Desconfio que também sejam eles, os gerentes, os responsáveis pelo bloqueio do principal requisito das iniciativas BPM: a organização por processos. Não por ação, mas por omissão. Afinal, como aceitar e trabalhar por um modelo que não dê uma atribuição minimamente respeitável para os gerentes? Como acatar uma sugestão que, em sua origem, significou a extinção de diversas cadeiras de gerentes?

Que sejam sabotadas, sutilmente, as propostas de mudanças nada sutis. E provemos nosso valor mergulhando, com todo o tempo e saúde de que dispomos, nas questões do dia a dia. Pagamos para ver quem sabe mais do que a gente. Queremos ver quem nos tira daqui.

Não espere que um gerente confesse o parágrafo anterior. E não caia na armadilha da generalização. Os gerentes não são ruins por natureza. Mas estão, neste ponto da história, defendendo sua sobrevivência. Nada mais natural. Nada mais humano.

Mas, e daí? Devemos aceitar que os gerentes, assim como várias outras invenções do século XX, devem ser riscados do mapa? Eles são de fato supérfluos nos tempos da economia do conhecimento e do autogerenciamento?

G de Gratificante

Peter Drucker, ao tratar a organização por processos, sugeriu que os departamentos funcionais seguiriam existindo. Não mais com responsabilidades sobre as funções executadas, mas como formadores e provedores de especialistas. Tom DeMarco e Thimoty Lister, em Peopleware, cruzaram caminho semelhante: “o centro de aprendizagem mais natural para a maioria das organizações reside naquela mal falada instituição, na camada intermediária. Isso bate com nossa observação de que as mais bem sucedidas organizações que aprendem possuem um forte time de gerenciamento”.

Os gerentes não cuidariam apenas de ensinar, mas principalmente de montar e manter um ambiente onde o aprendizado acontece. Será que basta? Claro que não, como demonstra Henry Mintzberg em Managing – Desvendando o Dia a Dia da Gestão (Bookman, 2010). Seu modelo de gestão, ilustrado ao lado, sugere a existência de três planos e duas atividades principais vinculadas a cada um deles: Plano das Informações (comunicar e controlar), Plano das Pessoas (liderar e fazer conexões) e o Plano das Ações (executar e negociar). Repare também que o modelo indica três zonas de atuação: dentro da unidade de negócio, com o resto da organização e fora da organização.

Não é curioso como Mintzberg parece ignorar ou desconsiderar as sugestões anteriores, de ensinar e prover um ambiente que estimule a aprendizagem? Me arrisco a sugerir a existência de um quarto plano, central, o Plano da Aprendizagem Organizacional. Que também teria duas atividades principais (promover e difundir) e três dimensões (a unidade, a organização e o lado de fora da organização). Creio que este quarto plano responderia as críticas apresentadas por Jurgen Appelo em seu livro (sobre a falta de preocupação, no modelo de Mintzberg, com o Desenvolvimento de Competências e a Melhoria Contínua).

Não se engane, o modelo seguiria errado. Assim como é equivocada (e simpática) a Martie – monstrinho que representa o modelo Management 3.0 sugerido por Appelo. Porque, como confessa seu próprio criador: “todos os modelos estão errados. Mas alguns são úteis”. O bom gerente desconfia disso. O excelente tem certeza, por isso estuda todos os modelos e tenta colocá-los em prática. Não apenas em busca de paz de espírito e disponibilidade para seus filhos, mas porque ele sabe que seu principal trabalho é fazer com que outras pessoas trabalhem e evoluam. Sua responsabilidade é imensa. Por isso o papel do gerente pode ser tão gratificante.

Nada disso fará com que seus filhinhos manifestem a vontade de ser gerentes quando crescerem. Não importa. Eles também nunca dizem que serão otorrinolaringologistas.

Se nosso mundo, particularmente as organizações de TI, tivesse evoluído nos últimos vinte e poucos anos, este livro estaria defasado. O reli para elaborar esta entrada. E fiquei assustado com sua atualidade. Mesmo o conteúdo original de 1987, suas críticas e sugestões, permanece inteiramente válido. Até quando a dupla de autores se mete a falar sobre a ausência de janelas e o aspecto opressor e barulhento de muitas salas que acomodam desenvolvedores.

O livro é estruturado em seis partes: Gerenciando o Recurso Humano¹; O Ambiente do Escritório; As Pessoas Certas; Fomentando Equipes Produtivas; Deveria ser Divertido o Trabalho aqui; e Filho de Peopleware (que contém os oito novos capítulos). A escrita é simples, sem rodeios. Contundente em diversos momentos porque a mensagem é séria e os autores são sinceros. Como eles colocam no prefácio, Peopleware é uma coleção de histórias. “Cada princípio apresentado tem a sua história”. Boas histórias, oriundas de mais de 50 anos de experiência (somadas as de Tom e Timothy na época da publicação).

Os autores dialogam com o Gerente. Mas o livro não é direcionado apenas para eles. Todos que trabalham com TI, particularmente os desenvolvedores, têm muito a aprender e, por que não, se divertir com o texto. Compilei abaixo alguns dos diversos melhores momentos (traduzidos livremente da segunda edição) só para deixá-la(o) curiosa(o):

Se você se achar concentrado nas questões tecnológicas ao invés das sociológicas, você estará agindo como aquele personagem de vaudeville, que perde a chave em uma rua escura mas opta por procurá-la na via adjacente porque, como ele explica, “a luz é melhor aqui”.

A principal razão pela qual nos concentramos nas questões tecnológicas ao invés das humanas é porque elas são mais fáceis.

Nosso negócio é muito mais sociológico do que tecnológico, é mais dependente de nossas habilidades para conversar com outras pessoas do que das habilidades para conversar com máquinas.

Um ambiente que não tolera erros torna as pessoas mais defensivas.

Muitos gerentes agem como se as pessoas fossem peças intercambiáveis. Agem como se existisse uma mágica Loja de Pessoas onde eles podem ordenar: “Me mandem um novo Mark Zuckerberg, menos arrogante desta vez, por favor!”
N.T. Mark só tinha três aninhos quando essas linhas foram escritas. Claro que não é ele o citado na obra original. Mas não é que inventaram mesmo as mágicas Lojas de Pessoas? Teve gente que ficou milionária com isso, mesmo sem nunca contar com Zuckerbergs, Torvalds e Goslings em seus estoques. 

Estatísticas sobre leitura² são particularmente desencorajadoras: desenvolvedores, por exemplo, não possuem um único livro da área e nunca leram um. Fato horripilante para qualquer pessoa preocupada com a qualidade do trabalho neste campo; para caras que, como nós, escrevem livros, é trágico.

Produtividade deve ser definida como o Benefício dividido pelo Custo.³

Um centavo poupado no ambiente de trabalho é centavo ganho, diz a lógica. Aqueles que cometem tal julgamento são culpados por fazerem uma análise custo/benefício sem se beneficiar de um estudo do Benefício.
N.T. Mantive o jogo original com a palavra benefício. Não deixe de ler a nota 3 abaixo.

Pessoas sob pressão não trabalham melhor; elas apenas trabalham mais rápido.

A qualidade, muito além daquela requerida pelo usuário final, é um meio para a alta produtividade.
N.T. Neste trecho os autores também mostram a relação direta entre qualidade e autoestima. Ninguém se motiva com software escrito nas cochas.

Qualidade é grátis, mas apenas para aqueles dispostos a pagar muito por ela.

Em um ambiente de trabalho saudável, as razões pelas quais as pessoas não performam são falta de competência, falta de confiança ou falta de afinidade com os outros membros do time e com os objetivos do projeto. Elas não precisam de mais pressão para trabalhar. Precisam de uma nova posição, possivelmente em outra empresa.

A função do gerente não é fazer as pessoas trabalhar, mas sim tornar possível que elas trabalhem.

Existem milhões de maneiras de perder um dia de trabalho. E nenhuma para trazê-lo de volta.

Se sua empresa tem uma planilha para controle de horas trabalhadas, é possível que ela aponte o tempo de corpo presente, não de cérebro presente.
N.T. Então a dupla se preocupava muito com poluição sonora e telefones. Mal sabiam que a situação se degradaria a níveis impressionantes depois dos IM’s, redes sociais, smartphones e afins. A multitarefa é um mito que custa caro aos índices de produtividade de um desenvolvedor. Mas, definitivamente, tão ou mais equivocadas estão aquelas organizações que proíbem o uso das facilidades da vida moderna. 

Se sua empresa anda muito preocupada com um padrão formal de vestimenta, brocotó. Sinal de que ela está nos estágios finais da morte cerebral. Não há remédio. Procure outro emprego.

A supervisão visual é uma piada para desenvolvedores. Supervisão visual é para prisioneiros.

Pessoas que escrevem metodologias são espertas. Aquelas que as seguem podem ser idiotas. Elas não precisam ligar seus cérebros. Basta que comecem da página um e sigam pela Yellow Brick Road, como obedientes macaquinhos, até o final do projeto. A metodologia toma todas as decisões. As pessoas, nenhuma.

Documentação volumosa é parte do problema, não da solução.
N.T. Os autores citam, em outro trecho, pesquisa que mostra que 30% do trabalho de desenvolvimento é “papelório”, burocracia. Quanto os números mudaram nos últimos 20 anos?

Acreditar que os trabalhadores irão aceitar os objetivos corporativos de forma automática é sinal de ingênuo otimismo dos gerentes.

Você não pode se proteger da incompetência de seu pessoal. Se eles não estão a altura do trabalho a ser executado, você falhará.
N.T. Na tradução rápida encerrei com “você falhou”. Afinal, você os contratou. Mas mantive o tempo do verbo original, menos pessimista.

O cara gastou R$150 em um pôster bonitão onde se lê: “Qualidade é nosso trabalho número 1!”. Ah, tá falando sério? Caramba, juro que a gente pensava que era o trabalho número 21 ou 117 antes desse pôster ser pendurado ali na parede. Pensávamos que talvez estivesse entre “reduzir a cera dos ouvidos” e “fazer coleta seletiva do lixo” na escala de valores corporativos.

Aqueles caras maravilhosos que nos brindaram com a Metodologia com “M” maiúsculo não ficaram parados. Sua última proposta, o Movimento para Melhoria de Processos, é nova, brilhante, melhor, esfuziante e muito mais ambiciosa… Desta vez, eles levaram o “tamanho único” ao extremo. Seu modelo não atenderá apenas sua empresa, mas o mundo todo.
N.T. Pensou em CMMI, MPS.br e que tais? Não? Saca só:

Se você é um CMM nível 2 ou superior, lembre-se: os projetos que mais valem a pena são aqueles que o moverão para baixo em sua escala de maturidade.

Você nunca melhora se nunca muda.

O aprendizado é limitado pela capacidade de uma organização em manter seu pessoal.

Deve estar enterrada em algum lugar de nossa memória ancestral a noção de que o trabalho deve ser penoso. Se você sente prazer em algo, não deve ser trabalho. Deve ser pecado. E você não deveria estar recebendo por isso. Encontre outra coisa para fazer, algo que realmente se pareça com trabalho. Assim você poderá se sentir entediado, cansado e desiludido como todo mundo.

Notas

1.  Será que, se fosse escrito hoje, o livro ainda falaria de “Recursos Humanos”? Creio que sim, apesar da ditadura de uma escola neozenbudista que grita aos quatro ventos “não sou recurso” enquanto, no frio da teoria, segue sendo. Toda vez que é contratado para executar um trabalho.
2. Dias atrás foi publicada uma pesquisa que diz que o brasileiro lê, em média, 4,1 livros por ano. Se tirarmos os livros escolares (obrigatórios?), o número cai para 1,1. Qual será a média de nossos desenvolvedores, analistas e gerentes?
3. Já tem um tempinho que toco nesse assunto no {FAN}. Só não me lembrava que era inspirado pelo Peopleware. Costumo dizer que o termo “análise custo X benefício” (também apresentado assim: custo-benefício) carrega dois grandes equívocos. O primeiro é matemático. Faça as contas. Acho que faz mais sentido uma divisão, tendo o custo como denominador. Ah, não pretendiam que o termo funcionasse como uma operação? Então compute o terceiro erro. Porque o segundo é outro, de ordem psicológica. Colocando o benefício antes do custo sinalizamos que ele deve merecer mais atenção. A ordem usual (custo X benefício) soa mesquinha. E gera comportamentos mesquinhos. Como daquele cliente que pega sua bela proposta e vai direto para a última página conferir o preço e lamentar: “Isso tudo?”

Quando pensei no título desta última parte da série busquei algo que fosse extremamente simples, uma receita culinária de um prato bem ‘default’. Mas que ao mesmo tempo parecesse único em cada ‘fornada’. O bolo de fubá foi uma lembrança imediata. Nunca vi dois iguais. Mais seco, mais molhado, dois ou quatro ovos, com queijo ou não… com vinagre!?! Pois é, achei mais de 30 mil ocorrências para “bolo de fubá” no Google. Minha família (mineira, obviamente) compartilha uma mesma receita. Mas o resultado é sempre diferente. Para algo que deveria ser incrivelmente simples: são só meia dúzia de ingredientes. Um mesmo processo. Um mesmo cronograma. Mas, surpreendente mesmo é a ilusão que todos nós que lidamos com desenvolvimento de sistemas já alimentamos pelo menos uma vez na vida: a ilusão de que existiria uma receita mágica, uma “bala de prata”, que nos ajudaria a entregar nossos projetos no prazo, dentro do orçamento e excedendo todas as expectativas de nossos clientes e usuários.

Se é quase impossível reproduzir com exatidão a simplicidade de um bolo de fubá, o que dizer de nossos projetos para desenvolvimento de software?

Em 1986 Fred Brooks publicou o artigo “No Silver Bullet”, que aparece como o capítulo 16 na edição de 20º aniversário de “The Mythical Man-Month”. No texto ele previa que em um horizonte de 10 anos não apareceria nenhuma evolução, nem tecnológica nem gerencial, que promoveria ganhos consideráveis de produtividade e confiabilidade. “Ceticismo não é pessimismo”, Brooks frisava. Nove anos depois, para a edição comemorativa, ele escreveu “‘No Silver Bullet’ Refired”, seu 17º capítulo. Responde algumas críticas e conclui que estava certo em sua avaliação.

Uma avaliação que pode ser resumida em uma frase apenas: “Construir software será sempre difícil“. Brooks fundamenta sua tese apresentando quatro propriedades (“irredutíveis”) da ‘entidade’ software:

• Complexidade: uma propriedade essencial, não acidental. Ou seja, software é uma entidade complexa por natureza, “talvez a mais complexa de todas as construções humanas”. De tal complexidade vem a dificuldade de comunicação entre os membros do time; dela deriva a impossibilidade de enumerar ou mesmo compreender todos os estados de um programa, e daí vem a falta de confiança. É da complexidade da estrutura que vem a dificuldade de se criar novas funcionalidades que não resultem em efeitos colaterais indesejados. Em suma e para usar um termo bem nosso, tupiniquim: Software é um “bicho de sete cabeças”. Ponto.
• Conformidade: “grande parte da complexidade que deve ser dominada pelo engenheiro de software é arbitrária, forçada sem rima ou razão pelas diversas instituições humanas e outros sistemas os quais suas interfaces devem conformar. Isso muda de interface para interface, de tempos em tempos, não apenas porque há uma necessidade, mas porque as interfaces são desenhadas por pessoas diferentes”.
• Instabilidade (de changeability): “A entidade software está constantemente sujeita a pressões por mudanças”. “Software pode ser alterado facilmente – ele é infinitamente maleável”.
• Invisibilidade: abstrações geométricas são muito úteis, mas não conseguem representar toda a complexidade de um software.

Brooks lista então uma série de avanços que podem ajudar a melhorar a qualidade de nossos projetos. Mas frisa que nenhum deles é uma “bala de prata”: Linguagens de alto nível (ele cita Ada – lembrem-se, o artigo é de 1986); Orientação a Objetos; Programação ‘Automática’; Programação ‘Gráfica’; etc. Na sequência ele lista alguns princípios que podem ‘atacar diretamente’ a essência dos problemas com software:

• Comprar ao invés de Construir: “a solução mais radical para os problemas com a construção de software é não construí-los”. De certa forma as ondas ERP e CRM livraram várias empresas de grande parte do peso da construção e manutenção de sistemas. Mas todas as organizações ainda demandam soluções específicas. Se não as constroem internamente, contratam serviços de desenvolvimento. Não acredito que um dia será possível comprar ‘pacotes’ (ou componentes ou serviços) para todo e qualquer tipo de problema de negócio.
• Refinamento dos Requisitos e Prototipação Rápida: “a parte mais difícil da construção de software é definir precisamente o que construir”. “Creio que é impossível para os clientes, mesmo aqueles que trabalham ao lado dos engenheiros, especificar completamente, precisamente e corretamente todos os requisitos do software antes de experimentar algumas versões”. Portanto, segue Brooks, “um dos mais promissores avanços é o desenvolvimento de métodos e ferramentas para a prototipação rápida de sistemas como parte do processo iterativo de especificação dos requisitos”.
• Desenvolvimento Incremental: ‘aumente’ (cresça) um software, não construa (no texto original, “grow, not build, software”). Para Brooks a metáfora da construção já deu o que tinha que dar. “Vamor olhar para a natureza e estudar a complexidade dos seres vivos ao invés dos trabalhos ‘mortos’ do homem”. Este princípio pode ser aplicado tanto no ciclo de vida do projeto quanto no ciclo de vida do próprio produto. Processos iterativos e incrementais já são comuns. Quase ‘carne de vaca’. O que é novo é a forma como o Google, por exemplo, ‘cresce’ e evolui seus serviços. Não se trata meramente de uma ‘manutenção’, e eu acredito que muitos de nossos produtos podem ganhar com esse novo enfoque. Independente do público e da tecnologia, diga-se de passagem.
• Grandes Designers: “Grandes projetos (designs) vêm de grandes arquitetos (designers). A construção de software é um processo criativo. Uma boa metodologia pode fortalecer e liberar uma mente criativa; mas não pode inflamá-la ou inspirá-la”. Brooks conclui: “a principal questão para a evolução da arte do software está centrada, como sempre esteve, nas Pessoas“. Não é por acaso que Brooks encerra seu livro recomendando a leitura de “Peopleware” , de Tom DeMarco.

Receitas, Metodologias, Processos…

E não parece ser uma mera coincidência que Scott Berkun inicie seu livro citando… “Peopleware”, de Tom DeMarco:

“A obsessão com metodologias é outra instância da ilusão high-tech. Deriva da crença de que o que realmente importa é a tecnologia…
Independente de qual seja o avanço tecnológico, ele cobrará seu preço com a deterioração da sociologia do time.”

Para Berkun, “a pior coisa é seguir cegamente um conjunto de regras e procedimentos só porque eles apareceram em um livro famoso ou porque são promovidos por um respeitado guru”. Berkun coloca que processos e metodologias são muito importantes, mas nunca serão ‘balas de prata’, entregadores de projetos bem sucedidos. E alerta para o perigo dos gerentes, em determinado momento de um projeto, “começarem a acreditar que o Processo é o Projeto”. Pode parecer absurdo, mas este ‘desvio’ é mais comum do que se imagina.

Um bom processo, segundo Berkun, apóia as pessoas e amplifica o seu valor. E seria o resultado da combinação de duas coisas: i) o que torna projetos e times bem sucedidos de uma maneira geral; e, ii) o que torna o projeto e o time atuais diferentes dos outros.

Eu gosto de acrescentar uma terceira variável, tão importante quanto o projeto em si e o time, no momento da seleção/customização de um processo: o Cliente. Quando se trabalha na indústria, como é o caso de Berkun, raramente se dispara um projeto para um cliente específico. Daí sua omissão. Mas no mercado de prestação de serviços de desenvolvimento é altamente recomendado que o perfil (valores e a cultura) do cliente seja levado em consideração no momento da customização do processo. Em alguns casos o próprio cliente solicita a incorporação de alguns métodos e artefatos, quando não a adoção de um ciclo de vida específico.

Mas o importante aqui é entender que não existe e nem nunca existirá uma ‘metodologia mágica’, aplicável em vários projetos. Cada projeto exigirá um processo específico. Mas isso não significa que a organização sempre partirá ‘do zero’. Muito pelo contrário. A primeira variável colocada por Berkun acima é “o que torna nossos projetos e times bem sucedidos de uma maneira geral”. Trata-se de um corpo de conhecimentos único, exclusivo. E orgânico, já que o natural é que ele cresça e fique mais rico a cada projeto. Infelizmente, quando olhamos algumas particularidades do mercado brasileiro de prestação de serviços de desenvolvimento, percebemos que muitas empresas dão pouquíssimo valor para esse aprendizado, lançando mão de vínculos empregatícios muitos frágeis (PJs e afins), o que resulta em uma alta rotatividade de seus colaboradores. Há quem acredite que este tipo de conhecimento pode ser capturado e aprisionado em documentos e coisas do tipo. Não é o meu caso. A explicitação de conhecimentos, sua compilação em artefatos que podem ser recuperados a qualquer momento, é benéfica para todas as organizações. Mas não consegue representar nem um pequeno pedaço de toda a experiência adquirida por um time durante a execução de um projeto. Trata-se de outra ‘ilusão high-tech‘, para usar um termo do DeMarco, que tenta impedir que o peopleware tenha seu valor reconhecido.

Voltando ao Berkun. Logo no início de “The Art of Project Management” ele ensina três ‘lições-chave’ que guiam boa parte de seus métodos, guias e sugestões. São elas:

• Gerenciamento de Projetos e Desenvolvimento de Software não são artes sagradas: apesar do ar de ‘novidade’ que impera em nossa área, é crucial lembrar que existem ensinamentos que podem vir de outros lugares.
• Quanto mais simples for a sua visão do que você faz, mais poder e foco você terá em sua execução: estar sempre curioso e aberto à novas idéias é o que torna o crescimento possível. Uma visão simples de nosso trabalho pode facilitar sua comparação com outras coisas que existem ao nosso redor. Aumentamos assim a possibilidade de aprendizagem.
• Simples não é sinônimo de fácil: correr uma maratona é simples, certo? Basta começar a correr e não parar até alcançar o quadragésimo kilômetro. Você diria que é fácil? Liderança e gerenciamento também são difíceis, mas sua natureza – realizar coisas de determinada maneira atrás de um objetivo específico – é simples. Bolos de fubá e pães de queijo também são extremamente simples. Não consigo entender porque só aqui em Minas eles são realmente gostosos.

Epílogo

Encerro assim uma série de 5 partes (9 artigos separados) que iniciei com a intenção de homenagear Fred Brooks e sua obra prima, “The Mythical Man-Month”, e também para apresentar o ‘caçula dos gurus’ (ele detestaria o rótulo), Scott Berkun. Como eu disse lá no início da viagem, estes artigos não substituem de forma alguma o prazer de ler os dois livros. E, posso garantir, não cobrem nem 10% de seu conteúdo.

O retorno que eu recebi (infelizmente a maioria foi off-blog) compensou com sobras o trabalho. O próprio Scott Berkun deu uma olhada no trabalho. E comentou:

“I did read the tribute you wrote and was flattered by it. I wouldn’t compare myself to Brooks – maybe if in 25 years ‘the art of project management’ is even still in print can a few modest comparisons begin.”

Apesar de não concordar com minha comparação, Scott me presenteou com uma cópia autografada de seu livro. Ah, se ele soubesse como torço para que seu livro não permaneça atual daqui 25 anos. A longevidade do livro de Brooks indica, de certa forma, que não aprendemos muito. Ou que não aprendemos direito. Eu sinceramente gostaria que ambos se transformassem em relíquias, documentos de um tempo em que a gente estava brincando de aprender a desenvolver software e a gerenciar projetos.

O próximo passo, ensinou Brooks, é aceitar que “software é um dos mais complexos trabalhos manuais do homem. Tal complexidade demanda nosso contínuo aprendizado, a melhor utilização das novas ferramentas, uma melhor adaptação a métodos gerenciais, a aplicação do bom senso e, acima de tudo, humildade para reconhecer nossas falhas e limitações“.

===

1. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).

===

Créditos e Considerações Finais

As imagens utilizadas na abertura de cada capítulo da série são de Chema Madoz, fotógrafo espanhol que não faz nenhuma questão de esconder sua maior influência, o louco mestre Salvador Dali. Os puristas podem reclamar dos indevidos ‘mashups’ que fiz nas imagens. Entendam como sendo uma forma de forçá-los a visitar o belo site de Chema, onde as imagens podem ser vistas em seu formato original.

As demais imagens, diagramas rabiscados, foram surrupiados digitalmente de “The Art of Project Management”. Aliás, boa parte das fotos presentes no livro são do próprio Scott Berkun.
Que faz uma coisa que nunca vi em livros técnicos: lista os sons que ‘mantiveram sua sanidade’ durante as longas horas em frente ao micro. De Charles Mingus a Aimee Mann, passando por Beatles, Clash, Radiohead e Audioslave. O cara escuta de tudo. E tem bom gosto.

Jonas Fagundes, J. Werther, Roberto, Régis, José Papo, Ivo Michalick e outros amigos ‘ocultos’ deixaram sua contribuição, na forma de comentários neste blog ou no grupo de discussão CMM-Brasil. Muito obrigado a todos. Se você curte o tema e procura um bate-papo de alto nível, o grupo é uma grande pedida.

Guz Vasconcellos fará a revisão do texto antes de sua conversão para um arquivo PDF. O blog manterá a (bugada) versão original.

That’s all, Folks?

Claro que não. O finito seguirá com um artigo por semana, sempre girando em torno dos temas Engenharia de Software, Gerenciamento de Projetos, Arquitetura de Soluções, e tudo o mais que caiba neste ‘torto’ triângulo. Sugestões de temas? Quer trocar idéias? Levar palestras e workshops para sua escola ou empresa? Demorou!

Ops… err… Vc fez uma busca por ‘bolo de fubá’ e caiu aqui por engano? Ou então ficou morrendo de curiosidade? É o seguinte:

Ingredientes:
4 ovos
4 copos de leite
1 xícara e meia de açúcar
1 xícara e meia de fubá
2 colheres de sopa de manteiga
2 colheres de sopa de farinha de trigo
1 colher de sopa de fermento em pó
1 xícara de queijo (canastra ou parmesão) ralado
1 pitadinha de sal

Preparo:
Em uma vasilha misture os ovos, acrescente o leite e aos poucos coloque o fubá misturando bem. Coloque o açúcar, o sal, a manteiga e misture novamente. Junte a farinha de trigo e por último o fermento em pó. Leve ao liquidificador, batendo por alguns minutos. Volte com a massa para a vasilha e acrescente o queijo ralado.

Despeje numa fôrma untada e leve ao forno quente por mais ou menos trinta minutos.

Se vai ficar bom como o da minha Vó eu não posso garantir.
Não existe receita mágica, certo?