Artigo por Rodrigo Carvalho
Desvendando a Estrutura Ideal: Como Alinhar Equipes de TI para Maximizar Inovação e Eficiência nas Soluções Digitais

Há força na união. – Lieutenant Uhura.

Entender a dinâmica dos times, particularmente nas organizações que entregam soluções digitais, é fundamental. O time é a unidade e força motriz para a entrega das soluções, e geram uma força contrária à performance da organização se não estiverem estruturados de forma consciente.

Os autores Matthew Skelton e Manuel Pais fizeram uma bem conceituada análise no livro Team Topologies, e este artigo aborda a estruturação de times considerando esta referência.

Aqui discutirei o tema, em cinco pontos de alta relevância, levando em conta as práticas DevOps, onde um mesmo time é responsável por todo o ciclo de vida da solução, desde a demanda até a implantação, e posterior monitoração e avaliação de feedbacks.

1. Competências Esperadas.

Sou médico, não mecânico. — Dr. McCoy

Para entender as práticas de estruturação, é importante começar pelo que se espera de um time. Considerando as práticas DevOps, a expectativa sobre times responsáveis por produtos e serviços são altas. Entre elas:

• Conhecimento do domínio e estratégia do negócio.
• Envolvimento desde a demanda até a entrega.
• Competência técnica para entregar a solução completa.
• Monitoramento e avaliação de feedback de usuários.
• Velocidade na reação a problemas.
• Agilidade para evoluções em resposta a feedbacks.

Para as equipes com estas competências, cujo trabalho está alinhado com fluxos que atendem às necessidades do negócio, Team Topologies define o termo Stream Aligned.

Importante lembrar que o foco das competências é para o grupo, não o indivíduo. Cada participante deve agregar a sua parte para garantir as competências esperadas. That ‘s ok, Dr. McCoy!

2. Tipos Fundamentais de Times Segundo Team Topologies

Fico feliz em ver que temos diferenças. Que possamos juntos nos tornar maiores que a soma de nós dois. –Surak

Considerando os quatro tipos fundamentais abaixo, a estruturação endereça a complexidade, e mantém o foco nas entregas de valor para o negócio.

Stream Aligned:

Como já explicado, este time é responsável por um ou mais processos da cadeia de valor. Idealmente teríamos apenas este perfil, e os demais devem trabalhar para viabilizar o trabalho deste tipo de time, que atende diretamente o negócio.

Platform:

Sendo a plataforma o produto que habilita outros produtos ou serviços, este time administra a plataforma de forma que o time Stream Aligned consuma serviços de maneira simples, e que conte com a garantia da operação e manutenção da plataforma (atualização de versões, monitoramento técnico, SLAs de serviços, manter infra estrutura, etc).

Deve interagir com o time Stream Aligned de maneira simples através de APIs. Tanto maior será o sucesso do provimento de soluções-como-serviço, quanto menor for a necessidade de interação.

Deve ter entre suas prioridades não apenas manter a plataforma atualizada e disponível, mas garantir que os serviços estejam sendo consumidos de forma correta e  com o mínimo esforço.

Em alguns momentos a colaboração entre o time de plataforma com o time Stream Aligned será mais intensa para garantir a capacitação necessária para o uso da plataforma.

Enabler:

Deve capacitar e apoiar os times Stream Aligned na execução de atividades ortogonais ao ciclo de entrega de soluções. Como exemplos destas atividades suportadas, temos técnicas como configuração e uso de ferramentas de automação de testes de deploy, e domínios de conhecimento tais como regulatório e segurança.

Atua como consultor especialista nas ferramentas de automação, domínios de conhecimento, e apoia a execução, minimizando a carga cognitiva do grupo Stream Aligned.

Complicated Subsystems:

Em alguns momentos aparecem temas de alta complexidade ainda não dominados pelos participantes Stream Aligned.

Como exemplo podemos imaginar um cenário que exija a inclusão de funcionalidades de Inteligência Artificial em um fluxo de atendimento. Sendo um tema novo e complexo, este exemplo pode exigir a montagem de um time dedicado para a implementação da camada de Inteligência Artificial. A responsabilidade pelo tema complexo é endereçada no tipo Complicated Subsystems, que deve interagir provendo solução de baixo acoplamento e de fácil uso.

Entre as vantagens da estruturação considerando os quatro tipos fundamentais, está a diminuição da carga cognitiva dos times (esforço mental para tratar os temas).

Os times Enabler and Platform, bem como os de Complicated Subsystems permitem aos times Stream Aligned que, mesmo tendo a responsabilidade fim-a-fim, tenham mais espaço para focar nos temas pertinentes para atendimento à cadeia de valor do negócio.

3. Tamanho do Time

Os preconceitos que as pessoas sentem umas pelas outras desaparecem quando elas se conhecem. -Kirk

Um time não é apenas um grupo de pessoas trabalhando com um propósito comum, os participantes devem ter estreita e direta colaboração, comunicação ágil, autonomia de ação, e senso de propriedade sobre o tema.

Não se atinge esse perfil com muitas pessoas, as boas práticas indicam que um bom número está entre 5 e 9 pessoas (como o famoso two pizzas  team  – duas pizzas deveriam ser suficiente para alimentar o time –  citado pela Amazon).

Mas é importante deixar claro que esta é uma boa prática, e não necessariamente uma restrição. O importante é avaliar criticamente se o time, como célula da organização, atende a comunicação, dinâmica e comprometimento esperados.

Nos primeiros passos de uma startup, um único time, que geralmente inclui os fundadores, deve lidar com todas as competências esperadas. Mas a maioria das organizações lidam com múltiplos processos especializados na sua cadeia de valor. Um time que digitaliza o atendimento dificilmente terá todas as competências para tratar também o ciclo de faturamento. Portanto, para a maioria dos casos, precisamos de vários Stream Aligned para atender o negócio.

4. Interações e Comunicação

Sim senhor. Estou tentando preencher um momento de silêncio com uma conversa não relevante. – Data

A comunicação é um dos pilares da gestão e desenvolvimento, mas a autonomia e foco no que é relavante não deve ser impactado por comunicação que pode ser evitada.

As interfaces de comunicação estruturadas devem se manter ao mínimo necessário, e intensificadas pontualmente se precisamos superar dificuldades.

É importante avaliar como automatizar processos e simplificar interfaces para diminuir a necessiadde de interações, e aumentar a autonomia dos times.

O fluxo entre a demanda e a entrega se beneficiará se forem eliminadas interações que vão contra a agilidade. Camadas de aprovação gerencial, comitês de aprovaçao de mudanças, sincronismo entre times diferentes, e outras interações, em grande parte estão voltados para gestão de riscos e validações integradas. Esses objetivos também podem ser endereçados por automação e arquitetura desacoplada.

As necessidades de muitos superam as necessidades de poucos, ou de um. – Spock.

Desacoplamento e autonomia não significam isolamento. Os times que têm interface devem estar atentos se o produto do seu trabalho está sendo usado de forma correta e eficiente.

Por exemplo, se os times Platform ou Enabler perceberem dificuldades para a configuração e uso de APIs e ferramentas, devem intensifiar a colaboração com o time Stream Aligned consumidor. Sempre visando viabilizar a autonomia e não perpetuar a dependência. Deve ser um trabalho pró ativo. Entender o uso e feedbacks com quem se tem interface é um gatilho para melhoria, com simplificação de interfaces e ações de capacitação que minimizam a necessidade de interações.

5. A Arquitetura da Solução e a Conway’s Law

Melvin Conway, em “How do Committees Invent?”, avaliou que em qualquer organização que desenvolve sistemas (não somente sistemas de informação) produz um design que é uma cópia da estrutura de comunicação da organização.

Considerando a Conway’s Law, é preciso alinhar a estrutura da organização e linhas de comunicação à arquitetura desejada.

Sem o devido alinhamento, a estrutura da organização será uma força contrária à arquitetura desejada. Temos exemplos de projetos de arquitetura cujo princípio está em serviços isolados com fraco acoplamento, e acabam implementados com caracterísiticas monolíticas como reflexo da organização dos times e linhas de comunicação.

Para esclarecer este ponto, vamos ao um exemplo:

Uma estrutura de times que conte com um time técnico de DBAs que centralize o projeto de dados das aplicações muito provavelmente acabará com uma estrutura de dados monolítica na qual os times Stream Aligned ficarão expostos a risco de impacto no trabalho de outros times por dependências na estrutura de dados.

Se cada time Stream Aligned contar com a competência de projeto de dados de aplicação de maneira independente, sem precisar consultar o grupo DBA especializado, terá mais chance de êxito de seguir na arquitetura independente desejada.

Neste exemplo, o time de DBAs estaria deveria estar identificado com o perfil de Platform, tendo mais foco em manter a infra atualizada e otimizada, mas deixando o projeto de dados de aplicações e serviços com o time Stream Aligned responsável.

Conclusão

A estruturação dos times é fundamental e deve estar entre as primeiras preocupações da organização para a evolução das iniciativas.

O sucesso da estruturação depende do entendimento da cadeia de valor do negócio, das expectativas sobre as competências dos times, do alinhamento da estrutura e linhas de comunicação à arquitetura desejada, e do bom uso dos quatro tipos fundamentais de times.

Os times devem ser pensados no contexto da organização e suas iniciativas, e como uma abordagem estrutural para estabelecer uma organização competitiva, e evitar continuar lutando contra a complexidade sem o time adequado.