finito

Tag: Peopleware

  • Timecídio

    Timecídio

    Ti.me.cí.di.o (s.m.) 1. crime que consiste em desmontar um time, equipe ou grupo de trabalho 2. É tão notável quanto indesejável quando afeta uma unidade de trabalho  que estava gerando valor ou demonstrava potencial para tanto 3. O termo Teamicide apareceu originalmente em Peopleware¹. 

    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 Li4

    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
  • Se Apaixone pelo Problema

    Se Apaixone pelo Problema

    Nos dois artigos anteriores (1 | 2) tentei mostrar a necessidade de uma maior preocupação com o Domínio do Problema. Eles se concentraram no porquê. O texto de hoje ilustra como podemos nos apaixonar por problemas. A correta definição de um problema é parte do problema¹. Não é uma definição simples. Porque as diversas partes interessadas não enxergam o mesmo problema. Ou não o veem da mesma maneira. Talvez algumas nem reconheçam o problema. Isso pode ser consequência de uma organização meio biruta – sem noção do que quer. Porque o ambiente é cada vez mais incerto e dinâmico. O mais provável é que seja uma mistura disso tudo.

    É 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.

  • Eu Quero Ser Gerente Quando Crescer

    Você já ouviu uma criança manifestar o desejo de ser gerente? Eu não. Mesmo os filhos de gerentes bem sucedidos não parecem se interessar pela posição da mãe ou pai. Talvez porque eles, durante toda a semana de trabalho, cheguem em casa estafados e aborrecidos. Também pode ser porque raramente apareça em um desenho animado ou filme infantil um gerente ou chefe que não seja pintado como um vilão, mau caráter, interesseiro e desumano. Acho que não veríamos com bons olhos uma criança que desejasse tal papel. O que será que aconteceu com a grande profissão do século XX?

    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.

     

  • Peopleware

    Peopleware

    Outro Clássico com “C” maiúsculo que há tempos pede entrada em nossa biblioteca. Escrito por Tom DeMarco e Timothy Lister, mereceu duas edições, ambas publicadas pela Dorset House. A primeira em 1987. A segunda, com oito capítulos adicionais, em 1999. Salvo engano, apenas a primeira mereceu uma versão em português do Brasil, pela Makron Books em 1990. Nem preciso dizer que encontra-se esgotada (mas disponível nos bons sebos da vida, por enquanto. A versão original em inglês sempre está disponível). É impressão minha ou naqueles tempos éramos melhor servidos por nossas editoras? Deixa pra lá, o tema aqui é outro.

    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?”

     

  • A Receita e o Bolo de Fubá

    Série “De Brooks a Berkun” – 5ª e última parte.

    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?

  • Os Dois donos do Projeto (Totó)

    Série “De Brooks a Berkun” – Continuação da 2ª Parte.

    Fred Brooks encerra “O Time Cirúrgico”, terceiro capítulo de “The Mythical Man-Month”, falando que um sistema deve ter total Integridade Conceitual, e que isso só seria possível através da dedicação integral de um Arquiteto (System Architect, no texto original). Logo depois, em “Por que a Torre de Babel falhou?”, ele fala de dois líderes em um projeto: o Arquiteto (ou Diretor Técnico) e o Produtor. Mas o dito popular não ensina que “Totó com dois donos morre de fome”? Como um projeto pode ter dois líderes e não parecer uma organização confusa?


    Segundo Brooks, o Produtor é o cara que monta o time, divide as tarefas e elabora o cronograma. Também é ele quem cuida da aquisição de recursos durante todo o projeto. Portanto, na maior parte do tempo, o Produtor estaria interagindo com entidades externas ao projeto. Ainda assim, é ele quem estabelece padrões de comunicação e relatórios com o time.

    Já o Arquiteto (ou Diretor Técnico) é responsável pelo desenho do sistema a ser construído, seus módulos e também seu aspecto exterior. Interage principalmente com o time, resolvendo questões técnicas.

    Considerando que os dois perfis são necessários em projetos de qualquer porte, Brooks aponta três relacionamentos possíveis entre eles:

    • Arquiteto e Produtor são a mesma pessoa: possível em pequenos projetos (para Brooks, de 3 a 6 programadores). Mas uma combinação arriscada em projetos maiores. Brooks justifica: “Pensadores são raros; executores são raros; pensadores-executores são raríssimos”.
    • O Produtor é o chefe e o Arquiteto o seu braço direito: a dificuldade aqui, segundo Brooks, é o estabelecimento da autoridade do Produtor em questões técnicas. Ele diz que o entrosamento entre o Produtor e o Arquiteto é fundamental. E que o primeiro deve respeitar muito o valor do arquiteto.
    • O Arquiteto é o chefe e o Produtor o seu braço direito: segundo Brooks, este seria o arranjo ideal para equipes pequenas, enquanto o anterior (Produtor é o chefe) funcionaria melhor em projetos maiores.

    É impossível evitar o paralelo das sugestões de Fred Brooks com aquelas apresentadas por Jeff Sutherland (depois de Takeuchi e Nonaka ) em seu método chamado Scrum.

    Jeff Sutherland, ao contrário de Brooks, não deixa dúvida sobre quem ‘fala mais alto’ em um projeto. O Arquiteto, que no Scrum é chamado de Product Owner, tem a palavra final. Enquanto o Coordenador (Produtor), ou Scrum Master, trata de eliminar riscos e obstáculos que estejam impedindo o time de obter sua melhor performance. São, respectivamente, o “Navegador” e o “Piloto” em uma equipe de rally, uma analogia criada pelo próprio Sutherland.
    Este desenho faz lembrar também uma colocação de Tom DeMarco em um de seus principais trabalhos, “Peopleware”:

    “A função do gerente não é fazer as pessoas trabalharem e sim tornar possível que elas trabalhem.“

    Antes de encerrar o tema uma observação: Fred Brooks, assim como Scott Berkun, trabalhou na indústria, desenvolvendo ‘produtos’. Falta em seus ‘job descriptions’ do Arquiteto e do Produtor (Coordenador) a preocupação com um Cliente. Parece óbvio que o chefe, seja ele o Arquiteto ou o Coodenador, seja a principal interface da equipe do projeto com o cliente. Eu prefiro deixar que o Coordenador seja sempre o canal de contato principal com o cliente, independente de ter ou não a ‘palavra final’ no projeto. As questões técnicas e funcionais, na maior parte das vezes, deveriam ser solucionadas (ou direcionadas) pelo Analista de Negócio, apresentado no sub-capítulo anterior.

    A Outra função da Organização

    Quando falamos em Organização, Estrutura, a primeira imagem que aparece é a de um organograma. Nos preocupamos, quase que exclusivamente, em saber quem é que manda no pedaço e quem deve (ter o juízo de) obedecer. Fred Brooks diz que precisamos aprender a desenhar estruturas e processos que incentivem, e não que inibam a criatividade e a iniciativa. E lembra: “a Criatividade vem dos indivíduos e não das estruturas e processos”.

    Scott Berkun segue linha parecida dizendo que os “projetos dependem muito da habilidade do time em fazer uso do conhecimento de seus membros, de compartilhar idéias e trabalhar em sincronicidade, ao invés de seguir restritivas linhas de autoridade, uma rigorosa disciplina e uma compulsão a seguir ordens sem nenhum tipo de questionamento”.

    Esse embate é muitíssimo bem documentado por Domenico de Masi no livro “Criatividade e Grupos Criativos”. Domenico afirma que atravessamos uma fase caracterizada por um Cultural Gap, um fenômeno que “constrangeu os atuais knowledge workers, os trabalhadores do conhecimento, a se organizarem segundo os velhos princípios industriais”.

    Que seja só uma fase. Mas ainda não há muitos indícios de que esteja para terminar. Por exemplo, o termo “fábrica de software” é de uma infelicidade incrível. Um oxímoro, no meu ponto de vista. Por outro lado temos a consolidação de produtos como Linux, Apache, Eclipse e Firefox, que são criados em ambientes onde parece imperar o caos. Deve haver um meio termo, não?

    ===

    Na próxima semana, “Castelos de Areia…”, sobre engenharia de requisitos, integridade conceitual, especificações e trabalho criativo. (Título com bula, atendendo a pedidos, hehe).

    1. Takeuchi e Nonaka, “The New New Product Development Game”, Harvard Business Review (Jan-Fev/1986).
    2. Tom DeMarco e Timothy Lister, “Peopleware – Productive Projects and Teams”, 2ª edição – Dorset House (1999, 1987).
    3. Domenico de Masi, “Criatividade e Grupos Criativos”, Editora Sextante (2003).