Expansão do Squad com Times Fixos e Times Virtuais

Papéis e Funções

Publicação da série sobre as diversas funções e posições em uma equipe de ProdOps, juntamente com as adaptações que o ProdOps faz no fluxo e na estrutura organizacional:

Literatura preliminar

Hierarquia de Cargos e Papéis
Expansão do Squad com Times Fixos e Times Virtuais

Especialidades ProdOps

Product Operations Tracker
Product Operations Specialist
Product Operations Manager
Product Reliability Engineer
Tech Product Manager

Introdução

Os serviços passaram por uma transformação digital desde a chegada dos computadores. Para abordar a estruturação dos times, é crucial retroceder até a consolidação da área de Tecnologia da Informação (TI) no início do século 21.

Naquela época, em sua grande maioria, os executivos de alto escalão responsáveis pela tecnologia adotavam um modelo matricial para estruturar suas equipes, as quais se dedicavam à entrega de projetos de software. As equipes eram formadas por profissionais especializados em diferentes áreas, visando uma abordagem multifuncional e colaborativa.

Após a entrega do projeto, as equipes de sustentação e infraestrutura assumiam a responsabilidade de operar o ambiente de produção, implementando as correções necessárias para garantir a estabilidade e eficiência contínuas. Vale ressaltar que, mesmo em meio a essa abordagem estrutural, as exceções eram mínimas, indicando a predominância desse modelo matricial na gestão de projetos e operações de TI.

Este modelo de projeto e sustentação se desenvolveu organicamente com a aprovação de orçamentos tradicionais baseados em CAPEX/OPEX, pois demonstrou eficácia notável para serviços analógicos e, por um longo período, atendeu às demandas da área de Tecnologia da Informação (TI).

No entanto, tornou-se evidente que esse formato apresenta desafios significativos quando se trata da evolução das aplicações, considerando o avanço constante da capacidade tecnológica e a crescente digitalização dos serviços. Este texto visa apoiar principalmente a transição do modelo tradicional para abordagens mais modernas, alinhadas com os processos de modernização, migração e evolução tecnológica.

É imperativo desenvolvermos a capacidade de formar equipes capazes de operar neste ambiente complexo, focando em entregas completas e integradas. Sem essa transformação, a inovação na nova era torna-se um desafio intransponível. A capacidade de adaptação e colaboração se torna fundamental para acompanhar as rápidas mudanças tecnológicas e garantir que as equipes estejam alinhadas com as demandas da era digital. Essa transição é crucial para impulsionar a inovação e garantir a relevância contínua no cenário tecnológico atual.

A estrutura para sustentar a cultura de produtos digitais envolve o desdobramento de iniciativas com alocação precisa de orçamento e a seleção adequada de perfis para os papéis essenciais. É crucial compreender como alocar recursos financeiros e preencher funções específicas para garantir o sucesso e a eficácia das iniciativas digitais.

Squad, o primeiro formato de time fixo

Apesar do time formato para um projeto no modelo antigo se dedicava – em teoria – a uma única agenda, constituindo um time fixo por determinado período, este time logo era desmontado na entrega do projeto e todo o conhecimento tinha que ser adquirido pelo time de sustentação. Por melhor que fosse o processo, a sabedoria ficava comprometida no repasse e não continuidade da equipe que “pensou” sobre o projeto.

O modelo de sustentação clássica deu lugar ao que passou a se chamar de Squad, times multidisciplinares que colocam aplicações em produções desde o início das experimentações para obter Feedback constante e frequente do usuário final.

Essas Squads têm a autonomia e responsabilidades por uma Value Stream (fluxo de valor) fim a fim, desde a ideação, a entrega e acompanhamento na produção.

Com o nascimento do que veio a ser conhecido como movimento Agile, novas formações estavam sendo testadas para apoiar as necessidades de evolução dos projetos que cada vez tinha um desejo de “Lead Time” menor com experimentação frequente, o time de projeto precisaria ser dedicado eternamente enquanto o sistema, agora sendo chamado de produto, durasse e fosse útil.

O modelo de Squad se consolidou pelo menos desde o método Extreme Programming, que trouxe o conceito de Whole Team (Equipe inteira) e Small Teams (times pequenos), se tornando a recomendação padrão para times efetivos encaixados nas novas necessidades de continuação.

O modelo da Squad preconiza a presença de perfis específicos na equipe, adaptando-se às demandas do serviço. A composição do time varia conforme o escopo; por exemplo, aplicações com maior ênfase em UX (User Interface) contarão com mais Designers e profissionais especializados nessa área, enquanto times de plataforma podem dispensar especialistas em UX. A flexibilidade na formação da equipe permite uma resposta mais precisa às necessidades específicas de cada projeto.

Pausa para um erro do mercado

Um formato de construção de equipes que causou grande influência a partir da metade da década de 2010 foi o chamado modelo Spotify, muita gente até hoje acha que foi este modelo que deu origem ao conceito de Squad.

Além de trazer à tona o formato de Squad, tentou resolver o modelo matricial que invariavelmente nasce quando a empresa precisa dividir as equipes para atender os contextos cada vez maiores.

A tribo é uma organização lógica como uma BU (Business Unit) ou empresa de um grupo.

Se tomar uma especialidade como Designer para exemplo, cada Designer de cada Squad de uma Tribo fariam parte de um capítulo de Designers. Todos os capítulos de Designers fariam parte de uma Guilda.

O modelo é simples e parece bastante lógico, mas as empresas tiveram dificuldade de encaixar na transição do modelo tradicional matricial para um novo formato que compita com modelo de nativo digital.

O principal problema encontrado neste modelo foi criar uma dupla camada matricial com líderes de novas estruturas fixas.

Acomodar um escopo matricial horizontal com um escopo vertical necessário para o formato de entrega de uma Squad requer outra forma de estruturar não somente as equipes, mas a direção destas, colocar mais gestores não é uma saída.

Capex na Nova Era

Os nativos digitais trocaram os projetos longos definidos para mais de um ano fiscal e deram lugar a projetos curtos revisados a cada trimestre, eliminando o modelo de sustentação e transformando no modelo de evolução contínua.

A organização passou a funcionar por produtos, estabelecendo fronteira clara por entrega de valor sob um mesmo contexto de negócio.

A transição entre o modelo antigo e a nova forma de distribuir o investimento passa pelo desdobramento das iniciativas por visões de produto que o Framework ProdOps auxilia com a construção do Product Deck, uma estrutura real de que times dedicados e virtuais são necessários para um produto funcionar, desde a ideação até a operação em produção.

Voltamos ao Product Deck mais à frente, precisamos entender a complexidade na formação de equipes.

Pausa para o segundo erro que o mercado vai cometer

A obra Team Topologies: Organizing Business and Technology Teams for Fast Flow consolida a sua estrutura literária sobre a Lei de Conway que diz que existe um link entre a estrutura organizacional e a estrutura de comunicação, propondo formatos de equipes para corrigir a estrutura de comunicação tão fragilizada nessa transição entre o modelo Projeto/Sustentação e times de produtos digitais.

A obra acerta na mensagem e falha na solução por um simples motivo, chegou tarde na proposta, o modelo de orientar a condução da formação de equipes tem que ser a partir da visão da estrutura necessária para o produto existir e é a forma mais eficiente para orientar que mensagens estão desalinhadas e não estruturando times previamente sem entender qual ciclo a mensagem se disvirtua. É como receitar um remédio genérico sem entender qual a doença.

Time do Produto

Na construção do Product Deck, uma das seções prioritárias é mapear qual o time necessário para o produto funcionar, muitas vezes entendemos que o time é apenas a estrutura para o Delivery do mesmo, mas em acionamento de incidentes, o time necessário é aquele que precisamos acordar as 3 da manhã. Se voce não está nesse acionamento, tem algo errado acontecendo com sua estrutura, não temos um Squad.

Time Virtual de Produto

O surgimento da gestão de produtos digitais nas últimas décadas veio para complementar o cenário matricial, fornecendo a estrutura necessária para equipes fixas continuarem evoluindo e não apenas sustentando.

Um conceito que o Framework ProdOps quer trazer para a discussão é a capacidade de dilatação de equipes, o quão escalável conseguimos mobilizar e desmobilizar equipes quando necessárias.

É importante ressaltar que falaremos o tempo todo sobre papel e não cargo, vai depender da quantidade de esforço e tempo necessário de execução para transformar este papel em cargo ou atribuir para um cargo existente.

Exemplo no Ecommerce

Estruturar um entendimento à partir de um exemplo real é mais fácil para estabelecer o conceito com a abstração concreta de como impacta na vira real. Usaremos o exemplo comum em um Ecommerce para estabelecer critérios básicos da estrutura.

Um Ecommerce pode ser dividido em Cohorts por jornadas ou agrupamento funcional, exemplo disso é o catálogo de produtos, são tantas as responsabilidades, que podem existir equipes para cuidar de PIM (acrônimo em inglês para o inventário de produtos), promoções, cupons, vitrine, Checkout, pedidos, etc.

O Marketplace é um modelo comum que empresas de Ecommerce fornecem para ampliar seus negócios oferecendo a lojistas a capacidade de venderem por meio de sua estrutura. Para isto, fornecem uma plataforma de gestão que o lojista deve subir seu catálogo com suas ofertas na plataforma de Ecommerce comum.

Como pode perceber na imagem anterior, geralmente têm equipes e aplicações duplicadas com escopos similares que as empresas querem eliminar para reduzir custos e melhorar a gestão do serviço.

É muito comum tomar a decisão de unificar sistemas com uma mesma equipe para ter esse controle de escopo.

Um problema dessa abordagem é que existe uma agenda de necessidades de cada área e a integração entre produtos de Marketplace e Ecommerce tem escopo próprio, chamado no mercado de Marketplace-In:

Dado uma terceira categoria de escopo que só serve para mapeamento DE-PARA do produto entre as áreas, é mais eficiente construir um time para conduzir um Roadmap específico para este escopo:

Neste caso, como muitos contextos similares, o trabalho inicial é enorme, mas após a construção e amadurecimento da estrutura necessária para transformar os dados e entregar o escopo principal, esta equipe estaria ociosa em contrapartida ao escopo de Ecommerce e Marketplace.

Uma solução intermediária seria formar equipe temporária para entregar um Backlog para o Marketplace-In e a reunir quando necessária, seja com membros entre Squads das duas áreas ou apenas de uma.

Um dos problemas de desmobilização do time fixo para um time acionável quando necessário, é que o conhecimento específico do escopo depende de quem trabalhou no time original.

Um aprendizado foi mapear o time “virtual” a partir do original para este capital intelectual impedir a sempre necessidade de um tempo de Onboarding e descoberta durante o acionamento.

As empresas descobriram que não bastam os membros conhecerem as tecnologias, precisam ter profundidade no negócio.

Times de plataformas

Trazendo esse modelo para organizar equipes de entrega da engenharia pura, precisamos entender os Cohorts e jornadas necessárias como esse exemplo do Ecommerce.

Existem dois tipos de plataformas: as funcionais que entregam soluções de negócio diretamente como Gateway de pagamento, Catalogo de produtos e o exemplo de Marketplace In anterior; e as plataformas que entregam a capacidade que os times precisam para entregar os serviços digitais como Dashboard de desenvolvimento, Cluster de mensagerias, engines de CI/CD, entre outras.

Definir um time de plataforma sem entender e mapear os ciclos nas jornadas dos produtos vai causar um prejuízo enorme e um freio na inovação das companhias.

Momento do produto

Um time de plataforma montado antes de entender o que vai entregar, tem a justificativa de “padronizar” a forma de entrega de todas as soluções, isso significa engessar o Lead Time e a validação frequente de hipóteses.

Uma empresa que constrói um produto novo tem uma necessidade e entregar muito mais frequente do que seus produtos já consolidados, abdicar de soluções como Serverless e Low-code fornecidas por provedores de Cloud e SaaS é um acinte. Claro que defenderão com argumentos de segurança e governança para justificar a falta de flexibilidade, por outro lado, é impossível abrir para qualquer solução sem preparar a operação e acionamento em produção como a gestão de incidades.

A entrega e operação guia o formato do time

Na montagem do Product Deck entendemos que existem 3 cenários possíveis:

Time dedicado

No cenário simples de uma startup, todos os perfis são dedicados ao ciclo de vida do produto. Este modelo representa a ideia de um time dedicado para operação em produção, passando por UX, desenvolvedores e gestão, refletindo o tamanho e a agilidade inerentes a esse tipo de negócio.

À medida que a empresa cresce, até mesmo as organizações nativas digitais enfrentam a necessidade de otimizar o compartilhamento de recursos e pessoas. Duplicar infraestrutura e equipes resulta em ineficiências, especialmente para grandes empresas que buscam evoluir digitalmente. Tentar replicar a estrutura de uma startup torna-se um esforço fútil nesse contexto.

Time dedicado com pessoas compartilhadas

Em todos os cenários comuns em grandes empresas, duas grandes jornadas são divididas, operação e entrega. É bastante difícil, ainda mais no Brasil, ter uma estrutura que o N2 e N3 sejam realizados pelo próprio time de produto, ainda mais construir e manter a estrutura que suporta o acionamento.

No mapeamento para o Product Deck, é necessário entender que pessoas são importantes no complemento do produto, quem será acionado e como o resultado é garantido nesse modelo.

Algumas equipes virtuais são fundamentais, exemplo que o Framework entrega é o time virtual de PRE (Product Reliability Engineering, Engenharia de Confiabilidade de Produto), representantes fixos para apoiar o processo e representandos de cada time envolvido com uma Value Stream (exemplo do Marketplace In anterior) organizada como produto acionado em conjunto.

time totalmente virtual

Ao criar uma estrutura totalmente virtual, é fundamental adotar princípios de engenharia universais. Tentar controlar minuciosamente a operação dos times de produto pode resultar em impactos negativos. Em vez disso, é mais eficaz fornecer aos times as ferramentas necessárias para entrega e operação, adaptando-se às necessidades específicas e ao estágio de maturidade de cada equipe. Essa abordagem permite uma maior flexibilidade e eficiência na operação de times virtuais, capacitando-os a alcançar seus objetivos de maneira mais eficaz.

Embora a entrega de um portal de desenvolvimento seja uma prática comum, a abordagem do ProdOps busca alimentar a construção dessa plataforma a partir de uma Value Stream organizada como um produto. Nesse sentido, um time de DevX (Desenvolvimento de Experiência) não precisa ser dedicado com pessoas destacadas e incorporadas em outra estrutura. Basta unificar o Roadmap com uma visão de time dedicado, promovendo uma integração mais eficiente e sinérgica na construção da plataforma, alinhada com a proposta do ProdOps.

O time virtual desempenhará duas funções fundamentais: capturar a ideação com base nas reais necessidades de um time de produto e alimentar a plataforma, fornecendo um direcionamento claro do que precisa ser desenvolvido e entregue. Em resumo, sua atuação se concentrará na coleta de ideias originadas das demandas reais de outros times de produto e na orientação precisa da plataforma, assegurando um desenvolvimento e entrega alinhados com as expectativas e metas estabelecidas.

Um desafio persistente será determinar a quem o time virtual prestará contas ao organizar-se como produto. Nesse contexto, a designação de um Tech Product Manager é crucial para orientar o Roadmap construído. Este profissional desempenhará um papel fundamental na coordenação das atividades do time, facilitando a comunicação eficaz, definindo prioridades e garantindo que as metas e objetivos estejam alinhados com a estratégia geral da organização. A presença de um Tech Product Manager oferece uma liderança centralizada, contribuindo para a eficiência e o sucesso do time virtual ao integrá-lo de maneira coesa dentro da estrutura organizacional.

Dedicação ao Roadmap

O que atrapalha a cultura de produtos digitais não é causada pela estrutura organizacional e o ruído nas comunicações não é sobre como e para quem alguém responde, é para qual Roadmap o profissional precisa ser cobrado a entregar os resultados.

O ProdOps auxilia no estabelecimento correto das atividades e funções a partir de uma visão de produtos para condicionar a entrega do profissional, desta forma, o formato dos times se acomodam.