Em 1975, Frederick P. Brooks escreveu o revolucionário The Mythical Man-Month. Quarenta anos depois, esta série de artigos pretende revisar as afirmações e os argumentos do autor. Quanto o ofício da Engenharia de Software evoluiu desde então?

Capítulo 7: Why Did the Tower of Babel Fail?

Neste capítulo, Brooks novamente ataca o problema da comunicação num projeto de software e como ela impacta a organização do projeto.

Podemos ver aqui a ênfase dada pelo autor a estes aspectos à medida em que ele se aprofunda no tema capítulo a capítulo.

Aprendendo com o fracasso da Torre de Babel

O projeto da Torre de Babel falhou por causa da deficiência na comunicação e na consequência disso, na organização.

Eu não escondo de ninguém a minha fé cristã. Um dos seus fundamentos é extrair princípios didáticos das histórias do Antigo Testamento. Portanto, neste ponto me sinto muito confortável em comentar a analogia de Brooks entre projetos de software e a história bíblica da Torre de Babel.

Se você me conhece sabe que não desprezo ninguém simplesmente por não ter a mesma fé ou mesmo por se proclamar ateu. Entretanto, sou resoluto em afirmar que ignorar a sabedoria contida nas histórias antigas da Bíblia por preconceitos filosóficos quaisquer não é muito inteligente.

Um resumo do episódio da Torre de Babel é o seguinte:

  • A população começou a crescer rapidamente após o dilúvio.
  • Obviamente todos falavam uma língua comum.
  • Os líderes da época decidiram construir uma grande cidade para unir toda a população mundial em um lugar.
  • Eles também decidiram construir uma torre muito alta para ficarem famosos, tal como os grandes faraós que construíram as pirâmides de Egito.
  • Deus, vendo que não havia limites para a maldade dos homens, a soberba, o orgulho, a clara desobediência ao mandamento de popular toda a terra e não só uma região em particular, decidiu confundir a língua das pessoas.
  • Resultado: o projeto foi abandonado, já que os diferentes grupos de pessoas não mais conseguiam se entender.

O texto completo da história:

E era toda a terra de uma mesma língua e de uma mesma fala.

E aconteceu que, partindo eles do oriente, acharam um vale na terra de Sinar; e habitaram ali.

E disseram uns aos outros: Eia, façamos tijolos e queimemo-los bem. E foi-lhes o tijolo por pedra, e o betume por cal.

E disseram: Eia, edifiquemos nós uma cidade e uma torre cujo cume toque nos céus, e façamo-nos um nome, para que não sejamos espalhados sobre a face de toda a terra.

Então desceu o Senhor para ver a cidade e a torre que os filhos dos homens edificavam;

E o Senhor disse: Eis que o povo é um, e todos têm uma mesma língua; e isto é o que começam a fazer; e agora, não haverá restrição para tudo o que eles intentarem fazer.

Eia, desçamos e confundamos ali a sua língua, para que não entenda um a língua do outro.

Assim o Senhor os espalhou dali sobre a face de toda a terra; e cessaram de edificar a cidade.

Por isso se chamou o seu nome Babel, porquanto ali confundiu o Senhor a língua de toda a terra, e dali os espalhou o Senhor sobre a face de toda a terra.

— Gênesis 11:1-9

Brooks inicia então uma auditoria gerencial do projeto Babel. 🙂

Ele ressalta alguns pontos:

  • Eles tinham um objetivo claro.
  • Dispunham de mão-de-obra e matéria prima abundante.
  • Tempo não era um problema, não havia um prazo estrito (e os homens viviam mais naquela época).
  • Embora tocar no céu provavelmente seja uma hipérbole, o projeto nunca chegou a atingir limitações técnicas.

Então porque o projeto falhou? Segundo o autor, a causa foi a interrupção na comunicação, que leva à desorganização, pois assim não havia como coordenar o projeto.

Basicamente, eles perderam a capacidade de falar claramente uns com os outros e, segundo o autor, isto leva a discussões infrutíferas, sentimentos feridos, inveja e vários outros problemas.

Comunicação

Falha total em cumprir o cronograma, falha em aderir às funcionalidades planejadas e erros no sistema são todos causados porque a mão esquerda não sabe o que a mão direita está fazendo. As equipes deslizam ao fazer pressuposições.

Quando equipes trabalham em diferentes módulos de um projeto elas começam a fazer pressuposições incorretas e vão se desviando do aos poucos do projeto inicial.

O autor exemplifica isso falando sobre uma rotina especifica, a qual é desenvolvida por uma equipe que pressupõe que a rotina será pouco utilizad e portanto não se preocupa com a sua performance. Porém, outra equipe planeja fazer uso mais intenso da mesma rotina e presume que ela vai ter um certo desempenho.

Enfim, isso é basicamente uma falha de comunicação que consiste em fazer suposições veladas sobre aspectos do sistema, o que ocasionará toda sorte de problemas no projeto.

Equipes devem se comunicar umas com as outras tanto quanto possível e em variadas formas: informalmente, em reuniões regulares com apresentações técnicas e por uma “pasta de trabalho” (workbook).

Para mitigar o problema acima Brooks sugere que todos os métodos de comunicação possíveis devem ser usados, o que inclui conversas informais, reuniões frequentes onde as equipes apresentam umas para as outras o progresso de seu trabalho e através de uma "pasta de trabalho", para a qual o autor dedica toda uma seção do capítulo.

A “pasta de trabalho”

Uma “pasta de trabalho” (workbook) não é bem um documento, mas uma estrutura imposta aos documentos produzidos no projeto.

Basicamente Brooks propõe alguns princípios para os documentos gerados por um projeto. Não irei entrar em detalhes porque os tópicos que o autor inclui no capítulo de proposições do livro falam por si. Vejamos:

  • Todos os documentos do projeto devem fazer parte da “pasta de trabalho”
  • A estrutura da “pasta de trabalho” precisa ser projetada cuidadosamente e no início do projeto.
  • Estruturar apropriadamente a estrutura da documentação sendo feita desde o início para que o que for escrito se encaixe em alguma seção já fique planejada e assim tudo fique organizado.
  • Cada membro da equipe deve ser capaz de acessar todo o material (aqui, numa atualização do livro, o autor sugere o uso de páginas web).
  • É crítico que as atualizações sejam feitas em tempo hábil.
  • Deve-se prestar atenção especial às alterações desde a última leitura.
  • É preciso ter destacados no texto o que foi alterado e quando, além de um sumário das mudanças.

Brooks diz que começou usando papel, porém o manual do sistema operacional que ele desenvolveu tinha 7 pés de altura. Então eles trocaram para microfichas, que são uma forma de "compactação de papel". Sabe aquelas cenas nos filmes onde uma pessoa olha numa máquina procurando noticias em jornais antigos? Pois é,está é a forma antiga de se armazenar impressos de forma compacta e duradoura, uma espécie de filme fotográfico que é então ampliado para visualização através de algum equipamento especializado.

Em sua revisão do livro, o autor sugere o uso dos meios eletrônicos já disponíveis alguns anos depois na época da revisão. Como já mencionei anteriormente, hoje temos ferramentas de comunicação instantânea que atendem todos os pontos acima de forma simples, eficaz emas tempo real.

Parnas (outro autor) argumenta que ter todos vendo tudo do projeto é errado. As partes em que alguém não trabalha deveriam estar encapsulados em interfaces bem definidas de forma que a pessoa somente conhecesse a fundo o que ela realmente desenvolve.

No texto original, Brooks diz que a sugestão de Parnas é uma receita para o desastre. Entretanto, na atualização do livro feita 20 anos depois ele diz ter mudado completamente de ideia, convencido pelo autor é amigo, Parnas. 😀

Em minha experiência, vejo que a abordagem de Parnas, isto é, encapsular partes do sistema que alguém não trabalha, é o padrão adotado e funciona até certo ponto. Entretanto, minha opinião é Brooks não estava totalmente errado. Ele, como gerente e arquiteto, assim como os demais gerentes e arquitetos, precisam ter um conhecimento global do problema, ainda que não em todos os detalhes.

Portanto, a questão não é se todos devem ver tudo sobre o sistema, mas quem deve ver o que é em que nível de detalhe. Cada papel deve ter um nível diferente de visibilidade apropriado para a função exercida.

Além disso, frequentemente desenvolvedores precisam entrar em detalhes sobre outras partes do sistema ou mesmo sobre outros sistemas. Isso ocorre porque frequentemente a “interface bem definida” não funciona como esperado e você acaba tendo que depurar o problema. Seria bom que fosse algo raro, mas na realidade é muito mais comum do que gostaríamos.

Organização

Aqui Brooks fala da motivação para melhor organizar um projeto e de algumas formas de se fazer isto.

O propósito da organização é reduzir a quantidade de comunicação e coordenação necessárias.

Imagine-se em um projeto de médio porte com algumas dezenas de pessoas. Já pensou se tivesse que conversar com cada uma delas sempre que precisasse saber de alguma coisa?

Organização incorpora a divisão do trabalho e a especialização da função para desimpedir a comunicação.

A proposta inicial de Brooks é que definir papéis para cada membro da equipe diminui a sobrecarga de comunicação.

Especialização não significa que você vai fazer sempre uma única coisa. A mesma pessoa pode assumir dois papéis ou duas pessoas podem compartilhar um único.

Entretanto, é mais fácil falar sobre a arquitetura se existe um arquiteto responsável, assim como sobre a qualidade se existe um profissional de qualidade responsável.

Times multifuncionais ainda são a última palavra em organização de equipes, ainda que alguns detalhes possam variar em cada nova proposta que surge por aí.

A organização convencional usando uma árvore hierárquica reflete o princípio da estrutura de autoridade de que uma pessoa não pode servir a dois mestres.

Existe outro princípio bíblico de que você não consegue trabalhar para dois chefes.

A hierarquia que temos nas empresas reflete isso e, posso ainda acrescentar, mesmo as que tentam empregar uma organização matricial precisam alocar líderes para projetos e “donos” ou gerentes de produtos para centralizar decisões específicas, os quais ainda respondem para a gerência mais alta da empresa.

Assim como Brooks, eu não estou defendendo uma hierarquia rígida. Descentralização é algo bom. Faz bem ter equipes e mesmo pessoas “independentes” dentro de uma organização. Porém, invariavelmente, mesmo com uma menor quantidade de níveis hierárquicos, todos ainda precisam responder a um líder central que gere a visão e os objetivos da empresa.

Dependendo do tamanho da organização, por mais ágil que ela seja, podem haver ainda mais níveis de controle. Imagine uma empresa com mil funcionários e uma média de 100 equipes. Não há como uma pessoa centralizar o contato com todos. Em geral, as equipes serão divididas em áreas ou frentes de trabalho e gerentes serão colocados para gerenciá-las. Nesse ponto, um desenvolvedor geralmente terá “acima” dele o líder da equipe, o gerente de um grupo de equipes e depois o dono, presidente ou corpo dirigente da empresa.

Finalmente, é preciso entender que hierarquia não é um organograma que diz quem manda em quem. O papel dos líderes e gerentes é diminuir o atrito de comunicação, eles são os responsáveis por transitar a informação para cima e para baixo da hierarquia e também lateralmente pela comunicação com os demais gerentes de outras equipes, de forma que a informação relevante chegue ao alto escalão assim como para o estagiário.

A estrutura de comunicação em uma organização é uma rede, não uma árvore, então todos os tipos de mecanismos especiais de organização tem de ser planejados para sobrepor as deficiências da comunicação de uma organização hierárquica em árvore.

Continuando no mesmo raciocínio, a hierarquia não é deve servir como uma restrição para a comunicação, mas como um meio de torná-la mais eficiente. Porém, como o autor afirma, a comunicação muitas vezes pega um atalho e é feita de forma independente da hierarquia.

Aqui, a afirmação de Brooks mais uma vez se mostra verdadeira até hoje. Membros de equipes frequentemente precisa conversar sobre assuntos específicos com membros de outras equipes, gerentes ou mesmo com o dono da empresa.

Não há nada de errado com isso, portanto Brooks sugere que este tipo de comunicação deve ser facilitado e não prejudicado.

Sabe aqueles gerentes chatos que dizem que tudo tem que passar por ele, que você não pode pedir nada diretamente para ninguém da equipe dele? Bem, ele tem um pouquinho de razão em que você não deve perturbar o trabalho de outra equipe. Porém, quando que se cria qualquer barreira para comunicação entre equipes, em minha opinião, o fracasso do projeto é o menor dos males que pode ocorrer. É incalculável o prejuízo causado por esse tipo de atitude ao longo do tempo.

A transmissão de conhecimento e a interação entre diferentes equipes e hierarquias devem ser sempre incentivadas dentro de limites razoáveis e meios de comunicação modernos, como aqueles mencionados no artigo anterior, devem ser disponibilizados para tanto.

Todo subprojeto tem dois papéis de liderança a serem cumpridos, aquele do produtor e aquele do diretor técnico, ou arquiteto. As funções dos dois papéis são bastante distintos e requerem talentos diferentes.

Já ouviu falar em PO (product owner) e líder técnico (tech lead)? As equipes de hoje tem exatamente esses papeis e vou demonstrar como e porque.

Em todos os projetos que participei até hoje houveram pessoas que cumpriram esses papéis de maneira diferente. Em um caso, um especialista financeira gerava o nosso backlog com o que era necessário implementar para usuários do setor bancário. Aqui na Atlassian, toda equipe tem um gerente que não serve para mandar no que fazemos, mas que ajuda a definir as metas da equipe em relação ao planejamento geral da empresa. A partir dessas metas, nós definimos o que será implementado e como.

O mesmo ocorre com o papel técnico. Empresas organizadas sempre colocam um arquiteto ou desenvolvedor sênior na composição de equipes.

Mesmo quando a alocação adequada não ocorre, o desenvolvedor mais experiente assume naturalmente a posição de liderança e as decisões técnicas importantes sempre passarão por ele. No caso do "produtor", aquele membro da equipe com mais tino para o negócio acaba ficando responsável por obter as informações necessários do cliente e outros stakeholders e “converter” isso num formato que possa ser lido por programadores. 😀

Qualquer um dos três relacionamentos entre os dois papéis podem ser bem efetivos:

  • O produtor e o diretor podem ser o mesmo.
  • O produtor pode ser o chefe e o diretor sua mão direita.
  • O diretor pode ser o feche e o produtor sua mão direita.

Sinceramente, não tenho experiência suficiente com gerenciamento para validar tal afirmação de forma abrangente.

Minha experiência me diz que a mesma pessoa somente poderia exercer de forma efetiva ambos os papéis, os quais – como afirmou Brooks – exigem habilidades bem diferentes, se o projeto for pequeno e os requisitos simples.

Além disso, para equipes de software, minha experiência me diz que é melhor ter o líder técnico para a equipe e o product owner como sua mão direita. Isto porque alguém não técnico, ou muito focado no negócio, tende a impor ideias não muito práticos do ponto de vista técnico, cronogramas absurdos, etc. Pode funcionar razoavelmente se ela também tiver um background técnico relevante, mas em geral pessoas não técnicas são péssimos líderes para equipes técnicas, eles simplesmente não se comunicam efetivamente.

Considerações

Esta é mais uma aula de Brooks no que se refere à comunicação e organização de equipes de software. Você pode ter achado repetitivo em relação a conceitos mais modernos, como métodos ágeis, mas lembre-se: estamos falando de 1975.

Basicamente, os princípios que podemos extrair deste capítulo são:

  • Um projeto precisa de documentação facilmente disponível para todos, porém cada pessoa deve acessar somente aquilo que é relevante para sua função. Meios automatizados, como um sistema interno de gerenciamento de conteúdo, são a melhor forma de fazer isto.
  • Uma organização deve se estruturar de forma a obter uma comunicação eficiente. Deve haver uma hierarquia de comando tornar a comunicação mais eficiente, assim como deve ser incentivada a comunicação independente da hierarquia quando necessário e razoável.

Espero que sua empresa implemente esses princípios de alguma forma. Não? Será que você pode fazer algo em relação a isto? 😉