Quando os pergaminhos sobre gerenciamento foram encontrados, descobriu-se que existia um conceito fundamental que era a separação daqueles que “pensavam” daqueles que “executavam” o trabalho, com o objetivo de se atingir maior produtividade. Essa separação física e intelectual permitiu o sucesso das linhas de produção e sua eficiência, reforçando a bem sucedida aplicação do trabalho repetitivo, especializado e do ser humano como peça de uma grande engrenagem.

Neste contexto mecanicista, um trabalhador que quisesse ser considerado excepcional precisava se especializar na execução perfeita, rítmica, constante e volumosa daquela pequena parte que lhe cabia, seguindo o plano definido. Para todos os demais profissionais médios, existia sempre a cenoura e o chicote para lhes motivar sob a guarda dos supervisores comando-e-controle. E tudo isso funcionou muito bem por alguns anos, confeccionando o que conhecemos como a Revolução Industrial.

Hoje sabemos que a natureza do trabalho mudou em sua grande maioria. Temos menos profissionais apertando parafusos e menos soluções óbvias e determinadas. Criou-se complexidade nas interações de quem produz e de quem consome os resultados do trabalho. O chicote e a cenoura já não motivam como antigamente e tudo ficou mais incerto e não-previsível, exigindo menos -planos- e mais -planejamento-. Entramos, enfim, na Revolução do Conhecimento.

E da reflexão sobre essa nova era do conhecimento, que apresentou o trabalhador criativo, se popularizaram algumas ideias e filosofias como o Ágil; Gestão 3.0; Motivação 3.0; Aprendizado 3.0; e todas estas ideias que suportam colaboração; interação; soluções emergentes; aprendizado e ciclos de feedback constantes e curtos.

Para mais detalhes do contraste entre os velhos e novos conceitos de gestão no contexto da aparição do Ágil, veja meu post: Introdução à Filosofia Ágil.

Na Era do Conhecimento também começamos a entender que não existe (ou não deveria existir) a separação de quem pensa e quem executa, mas somente a partir da colaboração e interação entre os envolvidos é que seria possível emergir algo útil e adequado às necessidades complexas. O “executor”, de forma especial, passa a ser privilegiado por reunir o conhecimento estratégico e tático dos demandantes, além da experiência e aprendizados coletados da realização do trabalho em si e do feedback imediato de quem consome e usa efetivamente o produto ou serviço. Por estar mais próximo, portanto, e em constante contato com todos que se beneficiam daquele projeto, o “executor” detém a maior parte do conhecimento sobre aquele domínio; suas periferias e integrações e é quem melhor pode articular as estratégias sobre sua evolução.

Todavia, posto que todo esse discurso de trabalhador do conhecimento seja verdade, vivemos hoje então mais uma dissonância cognitiva, posto que aquilo que sabemos não é o mesmo que praticamos. E aqui me refiro à indústria de desenvolvimento de software em especial.

Considerando que o Ágil endereça a nova Era do Conhecimento, principalmente para quem trabalha com TI, e que o Scrum é o framework sob essa filosofia que mais se popularizou, vou usá-los para os exemplos que vou usar a partir de agora.

O desenvolvedor como executor tradicional

É muito comum você passar pelos corredores da sua empresa e ouvir um Product Owner e pessoas relacionadas ao “negócio” cogitando convidar um desenvolvedor para uma reunião. E o que se ouve algumas vezes é: “Não precisa chamá-los. Não vamos discutir nada técnico”.

Pra mim, quase tudo no parágrafo anterior está equivocado. Primeiro o fato das pessoas apenas “cogitarem convidar” o desenvolvedor já mostra uma separação forte sobre quem pensa o “negócio” e quem o executa, e as principais desculpas para isso são: “Não queremos interromper o desenvolvedor em suas atividades”; “Eles [os desenvolvedores] precisam focar em terminar a Sprint. Muitas reuniões vão prejudicar o desempenho” e claro “Não vamos discutir nada técnico!”. O segundo ponto que discordo é que, pasmem!, eles estão indo para uma reunião! :-O Mas esse é outro assunto 🙂

Ora, se estamos na era do famigerado conhecimento; se não há mais separação de quem pensa e quem executa; se o “executor” é quem mais tem propriedade e domínio sobre o trabalho sendo realizado: por que ainda há tanta segregação entre negócio e tecnólogos? Por que ainda passamos “a pizza por debaixo da porta” do quarto fechado do desenvolvedor?

Há quem pense também que o desenvolvedor não quer ou não tenha as condições, habilidades e perfil para tomar decisões de negócio; pensar a interação com o usuário; ou dialogar com os envolvidos sobre seus problemas. Para quem pensa assim eu sugiro que use seu Iphone para acessar o Google e pesquise sobre a história do Facebook, no intervalo entre usar o WhatsApp e o Youtube. 😉 Aliás, usando o mesmo racional, o próprio Ágil deveria ser uma ilusão, posto que foi concebido por desenvolvedores de software “babões e não-sociáveis”.

Outra anomalia que acontece é dizer que eles decidem o “como fazer“. O Product Owner apenas e somente: 1) traz as histórias detalhadas; 2) descreve o propósito e a prioridade daquele item; 3) apresenta alguns poucos critérios de aceite; 4) prepara um protótipo de UX; e 5) desenha alguns cenários de teste. Sério?! O que sobra para ser decidido pelo desenvolvedor, se todo o incremento do produto já foi definido e detalhado? O programador decide se vai usar uma chave de boca ou uma chave de rosca?!

O executor tradicional como desenvolvedor

Apesar de quase que por inércia replicarmos os mesmos pensamentos e técnicas que sempre fizemos, promovendo a segregação, precisamos manter uma monitoria ativa sobre nossas ações. O mesmo vale igualmente para o executor que não quer mudar o jeito que trabalha “porque sempre trabalhou assim”. Ou seja, no nosso exemplo, é o desenvolvedor que precisa de alguém lhe falando o que tem que ser feito.

O consultor de empresas Waldez Ludwig retratou no longínquo ano de 2007 uma dependência entre o que chamou de “capataz” e “escravo” se referindo ao gerente/coordenador e ao funcionário mais abaixo na hierarquia respectivamente. Ludwig contextualiza que na era do conhecimento o que tem valor é a inovação e esta só pode ser gerada por pessoas que se preocupem com isso, criticando, portanto, os profissionais que teriam uma vocação forte para serem “escravos”, na analogia dele, reforçando a necessidade do “capataz”.

Acredito que muito dos motivos de vermos discrepâncias entre a prática e as novas descobertas e aprendizados gerenciais acontece ainda por estar presente em nós os resquícios do pensamento tradicional que influencia nossa forma de pensar e faz com que apliquemos os mesmos velhos conceitos maquiados numa nova “carroceria”. Por ter predominado por tanto tempo, a filosofia de gestão tradicional criou um “senso comum” que faz com que a energia gasta em se mudar e manter novas formas de pensar seja alta, ocasionando uma alta entropia em todo o sistema. E essa sabotagem que nos infringimos ao não conseguir quebrar esse vício afeta tanto quem pensa que “pensa” como quem pensa que só “executa”. Ambos precisam se libertar para alcançarem melhores resultados.

Não estou sugerindo a extinção do Product Owner nem mesmo estou sugerindo que o papel seja sempre incorporado pelos desenvolvedores. Mas seja quem for que represente o “dono do produto”, nesse mundo complexo de práticas emergentes, este precisa ser um facilitador [de verdade] da construção conjunta das soluções, explorando todo o conhecimento dos “executores”, incentivando que as mudanças nasçam da equipe motivadas pelos objetivos e visão do produto. E que os medíocres fiquem nas empresas medíocres.

Talvez só assim tenhamos de fato uma revolução do conhecimento e, só então, estaremos prontos para a próxima revolução.