Os papéis em um time ágil

Se você está começando em um time ou empresa ágil, é comum ficar confuso sobre os papéis e responsabilidades de cada um do time.

Neste artigo, o objetivo é explorar de forma rápida e resumida os papéis mais comuns em um time ágil e as responsabilidades de cada um. Note que os papéis estão sempre muito ligados e pode haver interseções entre eles dependendo da estrutura da empresa. Importante comentar que estes papéis e responsabilidades variam muito de empresa para empresa, mas tentei sintetizar aqui o que percebo que é mais comum. 

PO/PM: O Product Owner ou Product Manager, como vamos explorar muito nesse blog (inclusive, as diferenças entre eles), é o responsável por definir e traduzir a estratégia do produto em features e por trazer a visão dos usuários para a squad. No dia-a-dia, costuma ser responsável pelo roadmap do produto, gestão de backlog, escrita de histórias de usuário, gestão de métricas, KPIs, OKR e demais indicadores de produto, alinhamento com stakeholders. O PO também tem como parte de suas atividades o contato com usuários do produto, que pode se dar através de entrevistas, visitas, ligações telefônicas, testes de usabilidade ou qualquer outro recurso que permita entender mais sobre os usuários e sobre o uso do produto. Muitas vezes, essas atividades acontecem em parceria com os designers, como explicaremos mais à frente. 

Agile Master / Scrum Master: Agile Master / Scrum Master são os guardiões dos processos. São parceiros na busca por mais eficiência e eficácia nos processos do time. Além de conduzir e agendar as cerimônias, os AMs/SMs contribuem para a melhoria contínua da equipe. A diferença básica entre eles é que os Scrum Masters, como o nome sugere, são para equipes que utilizam Scrum. Para as demais metodologias ágeis, ou mesmo para deixar sua atuação mais abrangente, muitas empresas tem adotado o termo Agile Master. Essa pessoa contribui para disseminar boas práticas e a garantir que o time todo entenda os princípios e o mindset ágil, e também ajuda a remover impedimentos que possam estar impactando no andamento das atividades do time.

Designer (UX):  User Experience Designers são responsáveis, como o nome sugere, por pensar em toda a experiência de uso do produto. Na prática, eles entendem minuciosamente as necessidades e os problemas que estamos tentando resolver, e tentam transformar isso em um fluxo palpável e simplificado, que permita que o usuário consiga realizar o que deseja de forma simples e autônoma. Os UXs, junto com o PO, são responsáveis por trazer o máximo de informações possíveis sobre os usuários, portanto conduzem pesquisas com os mesmos para entender motivações, dores e necessidades. Um entregável comum dos UX designers são protótipos, wireframes e fluxos, prevendo cenários de sucesso e erro e detalhes sobre cada tipo de interação possível.

Designer (UI): Diferente do que muitos pensam, o papel do UI Designer vai muito além de “dar cor” e “vida” aos fluxos e wireframes desenhados pelo UX. Ele também é responsável por definir padrões de interface, avaliar o uso de componentes nativos de cada sistema operacional, garantir consistência visual, tipografia e questões de acessibilidade. Geralmente, seu entregável é um layout em alta fidelidade, com especificações claras de posicionamento, espaçamento, cor e tipografia, de forma que possam ser facilmente implementadas pelos desenvolvedores.

Uma observação sobre os designers: Muitas empresas, especialmente Startups, tem deixado de diferenciá-los por especialidade, e tem utilizado o cargo de Product Designer, que, neste caso é responsável tanto pelas atividades de UX (user experience) quanto UI (user interface).

QA: QA significa Quality Assurance, e como o nome diz, é responsável pela qualidade do produto. O QA é normalmente o responsável por testar tudo o que foi desenvolvido, antes da entrega acontecer em produção. No geral, o QA participa de todo o processo de produto, para assim ter uma clara visão dos pontos de sucesso e erro e conseguir construir o que chamamos de cenários de teste. Um ponto importante é que, apesar do QA ter essa responsabilidade, é importante que todos os envolvidos no processo de desenvolvimento de produto sejam co-responsáveis pelos testes e pela qualidade do produto, principalmente PO e Devs. 

Devs (Desenvolvedores): Como o nome diz, desenvolvedores são responsáveis pelo desenvolvimento do produto, traduzindo o layout e as necessidades de negócio em código. Eles são responsáveis pela construção do código, da arquitetura e das funcionalidades do produto. Os desenvolvedores, no geral, são divididos entre Backend e Frontend. Explicando de forma simplificada (perdoem-me, desenvolvedores) os backends constroem as partes do código que não são claramente visíveis para os usuários, como serviços, APIs, conexões com banco de dados e etc. Já os desenvolvedores Frontend (que podem ser web ou mobile) constroem o que é visível aos usuários – telas, botões, interações. Eles são essenciais nas discussões de fluxo, layout e regras de negócio, para que consigam apontar possíveis limitações técnicas e impactos de performance. No dia-a-dia, além do desenvolvimento, normalmente também são responsáveis pela monitoria dos serviços, saúde das aplicações e pela qualidade do produto. 

Há diversos outros papéis que podem fazer parte de uma squad, como: Marketing de produtos, Analytics expert, DevOsp, DBA (Banco de Dados) e etc, mas poderemos explorar esses papéis em outra oportunidade.

Mais importante do que delimitar fronteiras é, de fato, trabalhar como um time. Os times multidisciplinares fazem tanto sucesso justamente por conseguirem extrair o melhor de cada papel, mas não funcionam sem colaboração e confiança.

Ficou alguma dúvida? Deixe seu comentário, vamos conversar!

Nos próximos posts, vamos explorar um pouco mais cada papel e também sugestões de como extrair o melhor de cada um, em um ambiente ágil.