Veja por que ignorar a lei de Conway para desenvolver softwares pode deixar de atender às expectativas do usuário
Em projetos de desenvolvimento de softwares, não é raro encontrar sistemas que não produzem o impacto transformador que se esperava. Por que isso acontece? A negligência à lei de Conway é uma das hipóteses.
Embora não seja um enunciado com estatuto científico, essa lei é uma teoria válida para muitos ambientes. Por ter uma tendência à transparência e ao afrouxamento da hierarquia, permitindo que a equipe da linha de frente de desenvolvimento lidere as próprias iniciativas, a lei de Conway ajuda a moldar novas maneiras de trabalhar e entregar valor ao usuário.
Outro motivo que faz a lei de Conway ter adeptos no mundo inteiro é que ela também desempenha um papel importante no tempo de construção dos sistemas, uma vez que a arquitetura dos produtos refletirá a estrutura de comunicação das equipes que fazem parte do processo de desenvolvimento.
Mas até que ponto deixar de seguir a lei de conway pode ser prejudicial para as organizações? E de que forma isso pode afetar no desenvolvimento de um software?
Questões como essas serão abordadas neste artigo, que traz: o que diz a lei de conway, quais os efeitos dessa teoria na prática e como ela pode auxiliar na estrutura das organizações para que o desenvolvimento de software vá além da teoria.
O que a lei de Conway diz
A lei de Conway é uma máxima de TI criada pelo cientista da computação e programador Melvin Conway, em artigo de 1967. Conway a enuncia assim, já na conclusão de seu texto:
A tese básica deste artigo é que, ao desenhar seus sistemas (no sentido amplo do termo), as organizações estão fadadas a produzir cópias de suas estruturas de comunicação.
De maneira mais simples, a lei pode ser enunciada assim: quando a organização projeta uma solução, ela inevitavelmente vai reproduzir as estruturas de comunicação vigentes dentro dela — para o bem e para o mal.
Então, se a comunicação entre as equipes da organização for complicada, a comunicação entre as camadas do software provavelmente também será difícil, proporcionando uma experiência ruim para o usuário.
Embora faça sentido já na formulação original, a lei de Conway ganhou popularidade anos mais tarde, quando foi citada por Frederick P. Brooks Jr. no seu livro The Mythical Man Month, um ensaio sobre engenharia de software.
Desde então, desenvolvedores ao redor do mundo seguem a máxima a fim de construir uma experiência com valor duradouro não só para o usuário, mas para as organizações.
Os efeitos da lei de Conway na prática
O primeiro corolário da lei de Conway é um alerta sobre a comunicação com as áreas de negócio. De nada adianta desenhar um sistema que simplesmente digitalize o processo de negócio vigente, por mais que ele seja considerado bom pela organização.
Outro corolário da lei de Conway está centrado na comunicação entre as equipes de desenvolvimento, já na fase de execução do projeto. A adoção de uma abordagem generalista e a criação de silos entre os times também são estrutura organizações que costumam afetar a qualidade da comunicação.
Leia também: 9 desafios comuns na adoção de metodologias ágeis
A lei de Conway inversa
A lei de Conway inversa faz o caminho de volta: a estrutura do software tende a ser replicada na organização. Ou seja, ter uma estrutura técnica de software que não é replicada para a sua organização pode trazer grandes problemas de comunicação, desenvolvimento e estratégia.
Nesse sentido, o DevOps é uma abordagem bastante poderosa para a TI. Afinal, a estrutura de TI deve evoluir para atender as necessidades atuais da organização e entregar soluções que se encaixam com a estrutura da equipe.
Ao implementar práticas DevOps, mitigando os silos de equipe e as lacunas da colaboração, você agrega valor ao desenvolvimento de software, alinhando a sua estrutura às necessidades do seu negócio.
Quando profissionais estão em equipes isoladas ou são resistentes às mudanças, a tendência é se desviar das metas de negócio, justamente por não ter uma visão clara dos resultados.
A cultura DevOps chega para criar maneiras de melhorar a eficiência das transferências e reduzir o desperdício nos processos de desenvolvimento de softwares.
Entenda: 5 práticas DevOps que você precisa implementar agora
Respondendo à lei de Conway por meio das estruturas organizacionais
De acordo com a lei de Conway, um software é fruto de um processo intelectual e colaborativo que reflete as ideias das pessoas envolvidas e as estruturas de comunicação entre as equipes. Mesmo que a organização mude a forma como desenvolve software, sem evoluir na estrutura organizacional, sentirá o peso da lei. Só desenhando estruturas que respondam ao enunciado que a mudança vai se refletir na qualidade dos sistemas. Mas como isso se traduz em ações?
Aliar áreas de negócio a TI a fim de redesenhar a jornada do usuário dentro do sistema, alinhando-o aos objetivos da organização, é um momento básico do desenho de softwares - ainda que de trivial não tenha nada, pois é nessa fase que ocorrem os principais erros.
Adotar equipes menores focada em serviços, em vez de times grandes e genéricos, pode gerar maior coesão e, consequentemente, melhores resultados com mais rapidez. Conway é implacável nesse sentido: qualquer arquitetura de software promissora sucumbirá frente a estruturas de times descuidadas, o que converge com princípios das metodologias ágeis e DevOps.
Uma organização, por exemplo, em que equipes trabalham de maneira totalmente autônomas operam naturalmente em uma arquitetura como microsserviços. No entanto, essa arquitetura não é adequada para todas as empresas.
Veja: Quando você precisa usar microsserviços?
Nesse caso, cabe ao CTO a responsabilidade de garantir que a estrutura dos times seja compatível com a arquitetura de software que se deseja implementar. Boas estruturas potencializam resultados. Estruturas ruins ou ingênuas destroem valor.
Um dos efeitos da lei de Conway é justamente levar a equipe a uma implementação que se encaixe na estrutura da sua organização.
Mas, mesmo com uma arquitetura adequada para a organização, a lei de Conway não garante qualidade do software. É preciso ir além. Vejamos a seguir.
Indo além da lei de Conway
No mundo inteiro, organizações criam grupos pequenos de profissionais de várias áreas que, com base na lei de Conway, se unem em torno de um projeto a fim de obter soluções criativas para o seu desenvolvimento. Os resultados, na maioria das vezes, são positivos.
No entanto, Josh McKenty, vice-presidente da Pivotal, em palestra, levantou alguns pontos interessantes em relação ao uso da máxima.
Segundo ele, equipes de qualquer tamanho podem funcionar melhor quando são coesas e, contrariando a lei de Conway, elas não precisam ser intimamente ligadas e se gostarem, mas precisam se respeitar e trabalhar em prol de um objetivo em comum. Para McKenty, pequenas equipes não são a única maneira de produzir qualidade e, de fato, o isolamento desses grupos pode levar a problemas em toda a organização.
De acordo com o VP da Pivotal, os limites erguidos pela lei de Conway tornam-se patológicos com o tempo, impedindo a comunicação e a colaboração. E isso se torna especialmente problemático em um mundo em que as empresas precisam responder mais rápido do que nunca às tendências.
McKenty acredita que as empresas precisam ir além da lei de Conway para impulsionar a inovação, pois agora elas podem fazer isso por meio de várias plataformas que organizam a comunicação e a colaboração dos times de desenvolvimento.
Saiba mais: Cultura DevOps: unindo forças para mais agilidade e eficiência
O que a Lei de Conway nos ensina
Como vimos, ignorar a lei de Conway no desenvolvimento de software pode causar problemas no sistema, principalmente em relação à qualidade. No entanto, adotar a máxima ao pé da letra pode fazer sua organização estagnar em relação às arquiteturas de soluções no que diz respeito a comunicação integrada.
Sabemos que as organizações têm necessidades diferentes em termos de arquitetura de software e geralmente sabem qual é a que permitirá atingir os objetivos de negócios. Entretanto, muitas vezes esquecem as implicações da estrutura das pessoas, em que equipes precisam ser montadas de acordo com a arquitetura que se espera.
Contar com uma empresa parceira especialista em soluções de TI, para avançar tanto em questões culturais da organização como em relação a adoção de novas tecnologias é fundamental para garantir maior colaboração e eficiência no desenvolvimento de softwares.
Para saber como a Supero pode auxiliá-lo a ter times mais integrados para resultados mais sólidos, entre em contato com um de nossos consultores.
