Conway’s Law
Áudio também disponível no Spotify, iTunes e na Pocket Casts.
É responsabilidade do CTO estruturar a empresa de forma ótima para o desenvolvimento de soluções, maximizando resultados. Para ser eficiente, ele deve fazer isso considerando a seguinte observação, proferida por Melvin Conway, em 1967 (há mais de cinquenta anos).
Qualquer empresa que projeta um sistema, inevitavelmente, produz um projeto cuja a estrutura é uma cópia da estrutura de comunicação da organização.
Esta afirmação, conhecida como “Conway’s Law”, vem sendo comprovada empiricamente e demonstrada em estudos rigorosos.
Produtos são “espelhos” das organizações que os produzem. (MacCormack, Rusnak e Baldwin)
A implicação prática da lei de Conway é que, a forma como “pensamos” nossas organizações tem impacto direto nos sistemas que desenvolvemos. Não é possível projetar microsserviços em uma organização com um time organizado de maneira monolítica.
Se desejamos que os componentes dos sistemas que produzimos operem com baixo acoplamento, coesos, e de forma alinhada, precisamos ter times que operem dessa forma. Equipes com autonomia mas sem alinhamento, produzem sistemas com baixo acoplamento mas que não entregam o resultado esperado.
A melhoria da comunicação entre os componentes de um sistema é consequência direta da melhoria na comunicação entre os times que os desenvolvem. Se dois componentes, em um sistema, estão se sobrepondo, então, há, na organização, dois times se sobrepondo.
Recentemente, começamos a ajudar uma organização, de porte médio, que deseja decompor suas soluções em microsserviços, de forma que, inclusive, os diversos produtos os utilizem de maneira compartilhada.
Observamos, imediatamente, que a organização atual dos times de desenvolvimento, em torno dos produtos, impossibilitaria o atingimento desse objetivo. Enquanto os times estiverem organizados por produto, terão seus “roadmaps” orientados pelo desenvolvimento destes produtos.
Se o desejo da organização é desenvolver serviços independentes e compor produtos a partir desses serviços, então, devem existir times organizados “por serviço”, “compondo produtos” a partir desses serviços.
É papel do CTO, independente do perfil demandado pela organização, explicitar com o time as características desejadas para os sistemas que se pretende desenvolver. Então, garantir que a organização esteja estruturada de forma compatível com essas características.
Mais posts da série Manual do CTO
- 6 de julho de 2020 Um exemplo prático da importância da lei de Conway
- 21 de maio de 2020 Hyrum’s Law (Lei das interfaces implícitas)
- 15 de janeiro de 2020 Lehman’s laws
- 2 de janeiro de 2020 A “execução” é, mesmo, sempre mais difícil que o “planejamento”?
- 20 de dezembro de 2019 Correlação não implica em causalidade
- 26 de novembro de 2019 As quatro origens da complexidade
- 17 de novembro de 2019 O custo da oportunidade
- 11 de novembro de 2019 A estranha, odiosa e íntima relação entre a burocracia e a forma como desenvolvemos software
- 21 de outubro de 2019 Management Debt (Dívidas da Gestão)
- 19 de outubro de 2019 As “quatro versões” de como as coisas acontecem na organização
- 14 de outubro de 2019 O problema do “espírito de startup”
- 26 de setembro de 2019 As diversas fórmulas da produtividade
- 13 de setembro de 2019 Aprender a dizer “NÃO”!
- 4 de setembro de 2019 Conhecendo e suportando a estratégia competitiva
- 28 de agosto de 2019 A importância de entender relatórios/análises financeiras
- 21 de agosto de 2019 Conway’s Law
- 27 de junho de 2019 Os diversos perfis de CTO
Ivan
Curti muito o novo formato em áudio.
Apenas uma crítica: o volume da vinheta entre as seções, na minha opinião, ficou um pouco alto. Me incomodou um bocado. Uso fones de ouvido.
Elemar Júnior
Editamos baixando o volume. Consegue ver se ficou bom agora ?