Concrete Logo
Hamburger button

A formação de times ágeis

  • Blog
  • 4 de Dezembro de 2017
Share

Atualmente, um dos grandes desafios em grandes empresas é aprender a desenhar a melhor estrutura possível para a área de TI e Digital. Afinal, muito provavelmente é a sua área com mais mudanças ao longo do tempo, pois tudo que é digital está em constante movimento. Má notícia: o desafio vai continuar aí, porque não existe uma fórmula pronta para esse desenho e muito provavelmente ele vai mudar em muito pouco tempo.

Uma estrutura possível e bastante comum é aquela na qual existe uma clara divisão entre os departamentos e suas responsabilidades:

Combina com waterfall, né? E considerando tudo o que já sabemos sobre essa metodologia, o resultado final é que muitas vezes o produto em desenvolvimento entra no mercado depois de muito tempo e sem sucesso algum.

É claro que surgiram outros modelos de desenvolvimento depois do waterfall, mas basicamente todos eles mostram uma “receita de bolo” com fases ou tarefas a serem executadas em determinado momento do processo. Até que chegamos ao Ágil, com metodologias que se adaptam a novos fatores durante o desenvolvimento do projeto ao invés das tentativas de analisar previamente tudo o que pode ou não acontecer no decorrer do desenvolvimento.

Com agilidade, trabalhamos com constantes feedbacks, o que permite adaptar rapidamente eventuais mudanças nos requisitos e proporciona entregas constantes de partes operacionais do software. As metodologias ágeis vieram trazer uma abordagem mais iterativa e incremental de desenvolvimento de software, e colocam produtos em produção em ciclos mais curtos, regulares ao longo do tempo, que chamamos basicamente de Sprint.

Esse ciclo envolve as etapas de descoberta, na qual se aprende sobre o cliente em seu ambiente natural; de desenho, que é a fase efetivamente de projeto, de desenvolvimento e de testes. Mais ou menos assim:

                                                                                                Fonte: SIEO (2013)

Com isso, a forma de se olhar os projetos também mudou, assim como a maneira de montar times, estruturar departamentos e, por consequência, empresas. O mercado passou a entender que para entregar produtos relevantes neste contexto era necessário ter no time todos os perfis adequados para aquela entrega, ou seja, um caráter multidisciplinar.

Talvez o diagrama mais famoso de estrutura ágil é o do Spotify, usado por quase todas as empresas que já estão em um determinado nível de adoção de digital.

Fonte: KNIBERG (2012)

O modelo é formado por tribes, squads, chapter e guilds. A menor unidade deles é o Squad, times menores responsáveis por determinada funcionalidade de ponta a ponta. Cada um desses times tem todos os perfis necessários para executar determinada tarefa relacionada ao produto.

Fonte: EVANGALIST (2016)

Com todos os perfis necessários, os squads têm a autonomia para tomar as melhores decisões sobre a funcionalidade pela qual é responsável. Cada vez mais os times de desenvolvimento de produtos digitais têm se especializado em diversos papéis. Aqui na Concrete esse time básico é formado por:

  • Product Owner (PO) ou Dono do Produto: responsável pela definição de produto, de acordo com suas funcionalidades. Deve ter uma visão geral de todas as sprints e gerenciar o backlog, priorizando as tarefas. O Product Owner é quem diz ao time o que ele tem que fazer e quando. Basicamente, o PO é o “Chief Executive Officer” (CEO) do produto.
  • Scrum Master (SM): garante que todas as práticas ágeis sejam seguidas. O SM protege o time para que ele não se comprometa com mais do que pode desenvolver e gerencia as expectativas dos stakeholders, além de resolver problemas de relacionamento entre o time e impedimentos externos que possam atrapalhar o desenvolvimento. O scrum master é o “coach” ágil do time.
  • User Experience (UX), Designer ou Designer de Experiência de Uso: age como ponte entre o desenvolvimento e o usuário final, cabendo decidir o design e o fluxo que as informações devem seguir. Define também quantas telas, o que terá em cada tela, lugares de cada link e etc. O UX é quem define a usabilidade do produto.
  • Equipe de Desenvolvimento: pode ter de uma a sete pessoas, que não têm funções pré-definidas. A equipe é autogerenciada e auto-organizada, isto é, seus membros elegem o responsável por cada tarefa e cobram sua realização. O time deve apresentar todos os perfis necessários para a execução do trabalho e é a responsável pelo desenvolvimento do produto.
  • DevOps: responsável por codificar a infraestrutura na qual será montado o produto. O DevOps cria uma documentação viva do ambiente, que pode ser reutilizada.

É importante deixar claro neste contexto que estamos falando de um time, e não várias pessoas fazendo trabalhos separados. O fluxo e as decisões do que e como será feito são decididos em conjunto. E como os squads se dividem? No Spotify, cada um é responsável por uma funcionalidade, como o player, o destaque, listas e etc. Aqui na Concrete, como somos uma consultoria, os times são definidos de acordo com as funcionalidades do produto desenvolvido ou por cliente, dependendo do tamanho de ambos.

Outro conceito importante delineado pelo Spotify é o das tribes, que são coleções de squads com uma mesma área de negócio. Pode existir, por exemplo, uma tribe focada em mobile. O conceito de chapter, que também é implementado por nós na Concrete, foi criado para garantir a existência de alinhamentos técnicos. São pessoas que trabalham com o mesmo domínio conceitual, como por exemplo, o designer. É comum existir nível hierárquico, no qual as pessoas envolvidas naquele chapter respondem a um chapter leader.

Fonte: EVANGALIST (2016)

Finalmente, Guild são pessoas com interesses compartilhados e que se juntam para trocar conhecimentos e práticas, como automação de testes, guild de tecnologias web, entre outras.

Fonte: EVANGALIST (2016)

O conceito de desenho de time do Spotify começou a ser utilizado por muitas empresas ao redor do mundo, em todo ou em partes, e é referência na formação das estruturas das empresas que estão investindo no processo de transformação. Entretanto, mais do que a divisão entre squads, chapters e guilds, é ideal que os times sejam pequenos e se comuniquem entre si, sejam responsáveis por seus trabalhos e tomem decisões rápidas, além de comemorar pequenas vitórias.

Também é importante que esses times não sejam estruturas políticas, respondam do início ao fim pela feature que são responsáveis e foquem nas coisas que realmente importem, entregando releases de produtos várias vezes ao dia. Com isso, surgem estruturas menos hierárquicas e cada vez mais matriciais.

Hierarquia é mais forte na parte de produtos

Fonte:  GONÇALVES  (2017)

Hierarquia é mais forte na abordagem de Chapter

Fonte:  GONÇALVES  (2017)

As estruturas acima são exemplos de como se montar times e hierarquias mais voltadas ao negócio. Enquanto no primeiro temos uma estrutura bem focada no produto, com um head de produto acima de todo o time, no segundo temos uma estrutura ortogonal, na qual os times ficam abaixo (ou ao lado) dos gerentes de chapters ou capítulos. Essa abordagem é mais comum em empresas que têm como diferencial competitivo a excelência técnica, nas quais é mais efetivo ter “chefes” dando um direcionamento e feedbacks técnicos para melhoria daquele chapter específico.

Então, qual é a melhor estrutura hierárquica?

Aquela que funciona para cada empresa. Respeitando alguns conceitos, diversas variações são possíveis para termos times ágeis com foco em produto. O importante é entender como a sua empresa funciona, como ela pretende lidar com a transformação digital e quais os objetivos e o perfil dos times considerando sempre o construir, medir e aprender. E importante: não se esqueça que muito provavelmente a sua estrutura vai mudar!

Ficou alguma dúvida ou tem alguma observação? Aproveite os campos abaixo!

Até a próxima.

Quer saber mais sobre como os times da Concrete funcionam? Entre em contato.