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 [1]) 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"[2]:

"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"[3]. 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).

Marcadores: de_brooks_a_berkun, gerenciamento_de_projetos, livros