Peopleware: como conciliar pessoas e processos

Escolher entre confiar mais em pessoas ou em processos é uma das falsas dicotomias que domina a mentalidade de muitos profissionais da área de gestão de projetos e empresas. Nesse artigo, eu explico como conciliar esses conceitos de forma a harmonizar as pessoas do seu projeto com os processos que as ajudam a fazer o que precisa ser feito.


Enquanto olhar para frente, em busca de novas técnicas e métodos, é necessário e nos mantém atento às mudanças, olhar para trás nos ajuda a encontrar o que é sólido e constante. Você vai encontrar solidez naquilo que chamamos de "clássicos". Na própria definição dos clássicos está inserida essa noção de que há algo ali que vai sobreviver ao tempo.

Temos nossos próprios clássicos na área de gestão e na área de engenharia de software. A forma que eu encontrei de nos manter sempre conectados aos temas que são sólidos foi batizando as edições do meu programa de treinamento online, o Software Zen, com os nomes de autores clássicos como Peter Drucker, Russel Ackoff, Edward Deming e Fred Brooks, para citar apenas alguns. Ao revisitar esses autores — o que fazemos o tempo todo nesse programa de treinamento — você recupera o que há de realmente sólido para se apoiar enquanto lida com os problemas de um mundo que não pára de mudar.

Revisitando Peopleware

Na edição atual do Software Zen, eu voltei minha atenção para o Tom DeMarco, que merece a homenagem não só pelo conjunto da obra, mas principalmente por seu trabalho no livro Peopleware, publicado em 1987 em co-autoria com Tim Lister. Com o intuito de me preparar para o aquecimento da 8a. edição do Software Zen, eu li Peopleware novamente (a primeira vez que eu o li foi a mais de quinze anos). Mas dessa vez, eu o li com o espírito de reintegrá-lo com o que sabemos agora em 2018, mais de 30 anos depois.

Peopleware trouxe algo sólido para a área de engenharia de software. Algo que podemos usar como fundação para construir o que falta em cima. Ele documentou a descoberta do papel essencial que as pessoas cumprem no resultado de um projeto de software. Talvez essa constatação seja óbvia para você que está lendo isso agora. Mas nem sempre foi, e ainda não é pra todo mundo. Na verdade, o fato de ser óbvio para alguns e não tão óbvio para outros é uma das grandes fontes dos conflito que encontramos na hora de coordenarmos nossos esforços de mudança e melhoria de processos nas empresas.

Indivíduos e Interações mais do que processos e ferramentas

Ao definir que “valorizamos mais indivíduos e interações do que processos e ferramentas”, o Manifesto Ágil resume em uma única linha o que Tom DeMarco e Tim Lister precisaram defender em um livro inteiro. Peopleware (de forma consciente ou inconsciente) definitivamente abriu caminho para o surgimento de métodos mais leves, e que posteriormente se tornariam os Métodos Ágeis que conhecemos hoje. A obra liberou um pêndulo que estava preso na extremidade da busca pela conformidade a processos pesados definidos a priori por quem não executava de fato o trabalho que precisava ser feito.

Poucos anos depois de sua publicação, esse pêndulo oscilou gradativamente para o outro lado. O lado da leveza no design dos processos, e para uma confiança maior na capacidade de auto-organização das pessoas para entregar software funcionando. Isso foi bom, muito bom.

Mas o problema ainda não está resolvido (pelo menos não na cabeça de muitas pessoas). O cabo de guerra continua. Gestores precisam lidar com riscos e perdas; e eles só conhecem uma forma de mitigá-los: com controle. Controle de prazos, controle de escopo, de esforço, de orçamento, etc. O problema é que quando nos acostumamos a mitigar riscos com controle, nem sempre estamos conscientes do que perdemos ao fazer isso. Uma das grandes perdas que esse tipo de abordagem gera é a perda de eficácia.

Como a gestão baseada em controle reduz sua eficácia?

A grosso modo, há duas formas de você se relacionar psicologicamente com seu trabalho. Você pode assumir a responsabilidade pelo sucesso do projeto (fazer o que precisa ser feito) ou, por necessidade de controle, você pode estruturar um processo e direcionar as pessoas a se comprometerem com a responsabilidade pela execução do processo (fazer o que o processo pede para ser feito). A diferença entre as duas posições é crucial.

No primeiro caso, você assume o papel de protagonista (seja qual for a função que você desempenha no projeto) e atua de forma proativa para que o projeto resolva bem o problema que o seu cliente precisa ter resolvido — o que é basicamente a definição de um projeto eficaz. No segundo caso, você segue o processo, segue suas normas e “confia” que o processo foi desenhado de tal forma a gerar o resultado desejado. Nesse caso, você transfere a responsabilidade de sucesso (ou de fracasso). Não é mais sua, mas do processo. Sua forma de agir, nesse caso, é desviada para assegurar a conformidade do que você faz ao processo, pois há uma noção não explícita, mas subentendida, de que o processo é (ou deveria ser) garantidor do resultado.

Voltando ao primeiro caso, ao de que a responsabilidade é das pessoas. Nessa forma de se relacionar com o trabalho, o processo está subordinado às suas necessidades enquanto elas tentam construir a melhor solução possível para o problema do cliente dentro das restrições existentes. O processo, nesse caso, precisa ser maleável, ajustável, leve. Precisa ser uma ferramenta que servirá como facilitadora para que você desempenhe sua função mais nobre: gerar valor solucionando problemas.

Por outro lado, no segundo caso é o processo o protagonista, e é você que fica subordinado às suas exigências. Você preenche documentos, participa de reuniões e executa uma infinidade de trabalho que não serve ao problema do cliente, mas ao processo de resolver o problema do cliente — o que são dois tipos de propósitos completamente diferentes. Nessa perspectiva, muita responsabilidade é atribuída ao processo e ele fica pesado. Ele precisa prever tudo, resolver tudo. A aderência a ele se torna a meta. Mas como o cliente quer o resultado (eficácia), as disputas entre cliente e fornecedor tornam-se inevitáveis e rapidamente começamos a jogar um jogo de contratos e salvaguardas, ao invés de um jogo de busca conjunta da solução para um problema de negócio concreto.

Em resumo, enquanto no primeiro a ênfase é em se confiar nas pessoas para que elas façam o que precisa ser feito, no segundo, o que se faz é confiar no processo, procurando-se garantir que as pessoas o sigam.

Surge então a dicotomia…

Olhando para essa diferença em foco e comportamento dos dois modos de agir apresentados até o momento, percebe-se que é muito fácil cair na armadilha de tratar a questão "pessoas" versus "processos" como uma dicotomia. O termo dicotomia se refere a uma divisão (ou contraste) entre dois conceitos representados como sendo opostos ou inteiramente diferentes.

Se você acredita que a disputa "pessoas" versus "processos" tem um ganhador, você vê a questão de forma dicotômica, você cai no problema da falsa dicotomia. Como diz meu amigo Henrique Bastos:

“Onde há uma dicotomia, há algo que falta ser entendido”.

Na falsa dicotomia, dois conceitos aparentemente opostos são colocados como sendo as únicas opções, o que acaba ocultando a possibilidade de conciliação das duas alternativas e, assim, gerar um entendimento mais profundo da questão.

Trinta anos atrás, Tom DeMarco e Tim Lister, nos ajudaram a descobrir a importância das pessoas para nossos projetos. Em 2018, o desafio não é a disputa pelo que é mais importante, se pessoas ou processos, mas a reconciliação dos conceitos de forma a encontrarmos a tão desejada harmonia entre esses dois conceitos.

Reconciliando pessoas com processos

Se você não consegue conciliar pessoas com processos terá problemas em se comunicar com uma outra pessoa que não acredita no que você acredita (ou que não passou pelas experiências que você passou). Muitas das disputas entre gestores tradicionais e praticantes de métodos Ágeis tem raízes nessa dicotomia, por exemplo. Ambos os lados defendem bem suas posições, mas falham por não tentar buscar um entendimento mais profundo da questão. Precisamos buscar ajustar o entendimento pré-existente de ambos os lados, ao invés de tentar mudar o outro lado completamente.

Processos são importantes, pois são eles que aumentam a eficiência das operações de negócio. Processos são o caminho para resolver o mesmo problema de forma recorrente. Processos o ajudarão a fazer mais em menos tempo.

Porém, há uma parte igualmente importante para o seu negócio que processos não resolvem e, em alguns casos, podem até atrapalhar. É a capacidade da organização de tomar as boas decisões que, quando consideradas em conjunto, geram as melhores soluções para os novos problemas que surgem para você e seus clientes a cada instante. É a capacidade da sua organização de ser eficaz. Processos não resolvem problemas novos, pessoas sim. Pessoas o ajudarão a fazer o que precisa ser feito.

Enquanto a sua eficácia é definida pelo “o quê” você escolhe fazer, sua eficiência é definida pelo “como” você faz. Assim, não é que “pessoas” são melhores ou mais importantes que “processos”, ou vice-versa. Ambos ocupam um espaço de importância no projeto que precisam se harmonizar para gerar um todo consistente.

Um dos grandes enfoques do Software Zen é ajudar as pessoas a desenharem seus processos. São as pessoas que atuam no projeto que precisam, colaborativamente, definir como vão se planejar e se organizar para produzir o que precisa ser entregue. Pelo menos em projetos de software, são as pessoas que fazem o trabalho que devem definir como fazer o trabalho. E elas o fazem tomando decisões sobre como trabalhar, testando essas decisões e validando seu resultado para encontrar o que funciona. O que funciona, fica e se torna processo; o que não funciona é descartado, e se reverte em aprendizado.

Sem pessoas tomando novas decisões nada se cria, sem processos que mantenham integradas as estruturas das boas decisões previamente tomadas, nada se conserva. No final, o que faz sua organização sobreviver e prosperar é apenas uma constante intermediação entre criar e conservar.

Está aí a essência da arte da gestão de projetos de software. Trabalhar para construir sistemas de trabalho que ajudem as pessoas a fazer cada vez melhor o que precisa ser feito.


Para saber mais: http://softwarezen.me