As implicações das diferentes formas de se organizar os profissionais de desenvolvimento e de infraestrutura

🇬🇧 🇧🇷

O movimento DevOps surgiu como uma mudança cultural para quebrar os silos existentes em grandes organizações, integrando melhor as equipes de desenvolvimento e operações por meio da colaboração. No entanto, essa colaboração pode acontecer de maneiras diferentes sob uma perspectiva organizacional: os desenvolvedores e especialistas em infraestrutura podem fazer parte de departamentos diferentes ou podem estar juntos em uma única equipe. Com os avanços nas ofertas de PaaS, é possível até mesmo imaginar os próprios desenvolvedores assumindo as responsabilidades das operações.

Nossa pesquisa no IME-USP (Universidade de São Paulo) investiga como as empresas produtoras de software estão organizando suas equipes de desenvolvimento e de infraestrutura. Para isso, estamos entrevistando profissionais de software para entender como as coisas estão realmente acontecendo no mundo real. Com nossa pesquisa, esperamos fornecer uma teoria para apoiar as organizações no desenho de suas estruturas organizacionais em direção à entrega contínua e no tratamento das consequências da escolha de uma determinada estrutura.

Com base na análise criteriosa das entrevistas realizadas, elaboramos uma teoria que descreve as estruturas organizacionais utilizadas pela indústria no mundo real sobre como o trabalho dos desenvolvedores e engenheiros de infraestrutura pode ser coordenado na busca pela entrega contínua. Descrevemos essas estruturas (departamentos segregados, departamentos colaborativos, departamento único e departamentos mediados por API) em detalhes em nosso resumo das estruturas organizacionais. Aqui neste post, resumimos cada estrutura com uma figura e sua legenda.

Para entender melhor tais estruturas, buscamos desvendar por que diferentes organizações adotam estruturas diferentes. Além disso, considerando a existência de vantagens e desvantagens para cada estrutura, queríamos conhecer as estratégias adotadas pelas empresas para superar as desvantagens de cada estrutura. Assim, por meio de um processo de pesquisa, para cada estrutura organizacional, investigamos suas condições, causas, motivos para evitar, consequências e contingências, conforme definido abaixo:

Então agora listaremos as condições, causas, motivos para evitar, consequências e contingências associadas a cada estrutura. Acabamos de submeter esses resultados a um processo de revisão por pares. O artigo completo submetido está disponível aqui. Na frente de cada implicação listada, há um código (por exemplo, SC01) para se referir em discussões. Em nossa pesquisa, chamamos essas implicações de “strong codes”, por isso as letras “SC”.

Departamentos de devs & infra segregados

A figura mostra um operador e um desenvolvedor, cada um dentro de um círculo diferente. Eles estão de costas um para o outro. A comunicação flui por meio de cartas, mais do desenvolvedor para o operador do que do operador para o desenvolvedor.

Figura 3 - Com departamentos segregados, operadores e desenvolvedores estão cada um em suas próprias bolhas. Eles não interagem muito diretamente, e a comunicação flui lentamente por meios burocráticos (sistemas de tickets).

Consequências

Departamentos de devs & infra colaborativos

A figura mostra um operador e um desenvolvedor, cada um dentro de um círculo diferente. Eles estão olhando um para o outro e estão de mãos dadas (com alguma dificuldade).

Figura 4 - Com departamentos colaborativos, operadores e desenvolvedores em diferentes departamentos procuram trabalhar juntos, mesmo que não seja fácil, por meio de contato direto e colaboração próxima.

Condições

Causas

Consequências

Contingências

Departamento dev/infra único

A figura mostra um operador e um desenvolvedor, eles estão dentro do mesmo círculo.

Figura 5 - Um único departamento cuida do desenvolvimento e da infraestrutura.

Condições

Causas

Razões para evitar

Consequências

Contingências

Departamentos de devs & infra mediados por API

A figura mostra um operador e um desenvolvedor, cada um dentro de um círculo diferente. O operador fornece uma interface que é consumida pelo desenvolvedor (notação UML).

Figura 6 - O time de plataforma fornece serviços automatizados para serem usados, com pouco esforço, pelos desenvolvedores (a API da plataforma medeia a interação entre os desenvolvedores e o time de plataforma). O time de plataforma e os desenvolvedores estão abertos para ouvir e apoiar uns aos outros.

Condições

Causas

Consequências

Contingências