O modelo unFIX: O sucessor do Team Topologies?
Olá!
Nos últimos anos, um livro que me influenciou grandemente foi o Team Topologies (TT), no qual eu resumi aqui. Desde que eu li esse livro, mal podia esperar o que a comunidade de tecnologia ia dizer sobre ele e os trabalhos derivados dessas mesmas ideias. Hoje eu gostaria de comentar sobre uma dessas ideias derivadas que achei bastante promissora.
O modelo unFIX é uma criação do Jurgen Appelo em cima das ideias do TT.
Basicamente, a ideia é ser uma espécie de modelo padrão na estruturação de times (independente do segmento de atuação da empresa), porém, obviamente que o foco aqui será sobre times de tecnologia.
Um exemplo de como que ficaria uma equipe unFIX se resume a seguinte estrutura:
Calma que eu sei que pode parecer confuso, mas acompanha aqui comigo que no final do texto você vai saber o que cada termo significa.
Principles
O modelo tem como base os seguintes princípios:
It Depends — Everything is Optional: Como cada contexto é um contexto, o modelo se torna mais uma pattern library de como estruturar times do que um modelo fixo. Portanto, nenhuma estrutura proposta é obrigatória.
Try: Cheap, Safe, and Fast — Don’t Fail: Não existem falhas, apenas aprendizado validado, portanto, criar uma ambiente seguro e barato para falhas é essencial.
Experience Beats Product and Service: O foco tem que estar na experiência, seja do consumidor ou do developer, tudo isso é muito melhor do construir um produto simplesmente por construir. Portanto, foco em produto sem pensar em experiência é uma sub-otimização.
Where Is the Customer? Everywhere: Todo o modelo é pensado para atender os clientes, seja internos ou externos. Um detalhe importante, no entanto: O unFIX não elabora nenhuma recomendação sobre processos internos, somente no design organizacional. Não espere um sucessor do Scrum, por exemplo.
Balance High Cohesion with Low Coupling: Nem todo mundo precisa saber do Big Picture e está tudo bem. Através de uma estrutura descentralizada com fronteiras explícitas entre times e ciclos de feedbacks e troca de conhecimentos entre Crews, Forums e Turfs (mais detalhes sobre esses termos mais adiante), a organização toda cresce e aprende sem precisar de alguém centralizando o conhecimento.
Increase Simplicity, Embrace Variety: As coisas precisam ser o mais simples possíveis, sem esquecer da variabildade. Afinal, é possível ser simples para todos, mas é impossível que a mesma resposta atenda todos os times.
Manage the System, Lead the People: O modelo é pensado para que liderança não seja um cargo e sim um papel a ser realizado pelas pessoas que foram empoderadas pelo design organizacional. Gerenciando os sistemas em que as pessoas estão envolvidas, as pessoas farão a parte delas.
Base Types
O termo usado para equipe nesse modelo é Crew. O ponto interessante é que há uma razão. Esse termo em inglês não tem a carga que termos como Squad e Team possuem (um amarrado ao Scrum, outro a metáforas esportivas, respectivamente).
Para se começar a montar o design dos times, é necessário definir qual será o tipo da Base que se irá usar, pois é literalmente a forma como todo o resto irá funcionar. Para tal, temos os seguintes tipos: Fully Integrated Base, Strongly Aligned, Loosely Aligned ou Fully Segregated. A grosso modo, imagine que essa tipificação é uma espécie de espectro que varia de totalmente acoplado a totalmente segregado.
Abaixo eu comento brevemente sobre cada um dos tipos:
Fully Integrated Base: É uma estrutura de um Produto só. Absolutamente todos os times trabalham diretamente na entrega de valor de uma única coisa. Apesar de haverem quebras entre times por especialidade (back-end e front-end, por exemplo), no final tudo é um produto só mesmo.
Strongly Aligned: É um tipo de estrutura na qual os produtos e serviços possuem várias dependências entre si. Como exemplo consigo pensar em uma estrutura de um banco, por exemplo. Serviços como empréstimos, cartões e demais produtos financeiros sempre acabam dependendo de alguns sistemas específicos, como conta e saldo. Apesar disso, alguns produtos não possuem essa dependência e conseguem ser ofertados separadamente. Graficamente, temos:
Loosely Aligned: Tipo de operação em que os produtos tem poucas dependências entre si. Um exemplo é uma consultoria especializada em mobile que possuem times dedicados para Android e iOS para clientes diferentes mas que não interagem entre si, porém, compartilham interações com alguns times internos, como gestão de projetos ou algo similar. Um exemplo disso seria o seguinte:
Fully Segregated: Modelo no qual as iniciativas não tem nada em comum e operam praticamente de forma independente. Um exemplo fornecido pelo Jurgen é uma espécie de incubadora de startups, que possuem em seu portfólio várias ideias diferentes de negócios que não possuem correlação entre si.
Crews
Independente da Base, os tipos de time (Crew) se resumem aos seguintes:
Governance: É o time que cuida da estratégia, direcionamento e resolução de conflitos. Em caso de conflitos de prioridades ou algo similar, é essa e somente essa equipe que desempata. Esse conceito não existe no TT.
Value stream: É o equivalente aos times Stream-Aligned descritos no TT. Ou seja, times de entrega de valor contínuo sem prazo para acabar. Basicamente, equipes de Produto.
Facilitation: Esse time pode fazer o que é necessário para se conseguir uma determinada conquista macro na estrutura dos times. Pode ser um time multiplicador de Arquitetura, DevOps, Cyber Security ou qualquer outro assunto. É equivalente ao Enabling Team do TT.
Capability: Time que possui conhecimento especializado que não possui motivo para ser espalhado em vários times, seja por custo ou simplesmente porque é difícil contratar profissionais. Um exemplo é um time com conhecimento em C que dá manutenção nas bibliotecas de criptografia internas. É o equivalente ao Complicated Sub-System Team do TT.
Experience: É um time que tem como missão cuidar da jornada do usuário como um todo. Ele atua junto com os times de Value Stream, quase como se fosse um time de Facilitation focado em experiência. Lembrando que o foco é na experiência geral e não somente ter um ótimo local em uma determinada Crew.
Platform: Time que cuida da estrutura macro da plataforma de tecnologia, podendo ou não ser divido por área (também chamado de Guildas ou Chapters), como Back-end ou Front-end. São os Platform Teams do TT. Mais detalhes sobre times dessa natureza aqui.
Partnership: Time que cuida especificamente da gestão de terceiros. Apesar de parecer um pouco inútil, é um tipo de conhecimento que também pode ser centralizado para facilitar o gerenciamento de iniciativas dessa natureza. Lembrando que o intuito do unFIX é ser um framework para qualquer tipo de empresa e não somente empresas de tecnologia.
Roles
Gostaria de esmiuçar mais alguns termos relacionados aos papéis passíveis de serem desempenhados:
Turf: É uma área mantida e cuidada por um grupo de pessoas. Ela possui fronteiras explicitas e em termos de tamanho, o ideal é que ela não seja nem grande e nem pequena demais justamente para manter a carga cognitiva sobre controle (outro conceito explorado no TT).
Forums: Um agrupamento de pessoas que discutem um determinado tópico. Também chamado de Chapter ou Guilda em alguns lugares. O ponto relevante aqui é que o trabalho derivado das discussões é feito nas Crews e não nos Forums em si. Além disso, um Forum não tem um Manager.
Chief: É um papel de gestão, que fica na Governance Crew. Pode gerir pessoas de uma ou mais Crews. Não reporta para ninguém em uma Base além de outro Chief. A grande diferença aqui é que o modelo propõe que não exista Middle Managers, todo o trabalho de contratar, promover e reter é feito pelos Chiefs. A ideia geral proposta é ter o mínimo possível de gestores.
Captain: É um papel de embaixador, no qual é o representante da Crew em um Forum ou em interações com outras Crews. O modelo propõe que em times com um bom histórico de resultados o Captain pode ser escolhido pelo próprio time ao invés de um Chief. Seria um novo termo para Champion e Squad/Team Leader. Lembrando que esse papel é obrigatoriamente relacionado a uma Crew. Não existem Captains fora das Crews, pois ai eles seriam um papel que só faz gestão de pessoas que estão em vários times (ou seja, um Middle Manager).
Chair: Basicamente é o representante oficial de um Forum. Apesar de haver uma recomendação de ser uma pessoa com um perfil mais senior para conduzir os trabalhos, a mesma recomendação de se manter os Managers fora dessa dinâmica se aplica aqui, ou seja, não é recomendado que Chiefs sejam Chairs.
De resto, o modelo propõe as mesmas restrições do TT (e alinhadas com o Status Quo da Agilidade, digamos assim): Times pequenos (entre 3–7 pessoas), independente do tipo da Crew. Além disso, é um modelo que se posiciona como um antídoto para o crescimento acelerado desgovernado de algumas empresas, portanto, ao atingir 200–300 pessoas no quadro de funcionários é o momento ideal para se implementar essas ideias, antes que tudo saia do controle.
Espero que com essas explicações fornecidas os desenhos tenham ficado mais claros agora.
Caso você queira entender melhor indo direto na fonte, recomendo essa talk do próprio Jurgen que ela explica o modelo de uma outra forma e também esse site sobre o assunto.
Até a próxima!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
