Já deixamos claro em vários momentos neste Blog que só trabalhamos com métodos ágeis aqui na Concrete Solutions. Isso porque acreditamos que o processo de desenvolvimento Waterfall é um processo ultrapassado que nunca deveria ter sido aplicado em software. Este processo tem o problema de assumir uma realidade estática na qual pessoas oniscientes preveem o futuro. Ou seja, você acredita que sabe o problema a ser resolvido e a solução para ele antes de começar a criar o seu produto.
Este post tem por objetivo explicar um pouco de como funcionam os times ágeis, destacando a responsabilidade e a importância de cada papel dentro deles.
Antes disso, devemos ressaltar que estamos analisando os times ágeis que funcionam para desenvolvimento de produtos digitais. Cada produto também tem suas peculiaridades e funções específicas que podem interferir nessa estrutura de time. Aqui, nossa intenção é mostrar um time básico, com o qual desenvolvemos a maior parte de nossos produtos.
Também temos alguns conceitos que devemos explicar antes de entrar nos papéis. O trabalho em métodos ágeis é dividido em “sprints”, períodos de tempo pré-definidos, que seguem um “backlog”, lista organizada e priorizada do que tem que ser feito. O backlog é definido na planning, que antecede toda sprint, e revisado ao final dela, no que chamamos de “review”. Diariamente, o time tem reuniões rápidas (de no máximo quinze minutos) chamadas de “dailys”, nas quais os participantes apresentam o que cada um resolveu entre um dia e outro, eliminam as tarefas e assumem novas responsabilidades.
Dito isso, vamos aos papéis:
1. Product Owner (PO) ou Dono do Produto
O PO é o CEO do produto. Ele é o responsável pela definição de qual vai ser o produto, considerando as funcionalidades que ele terá. Ele deve ter uma visão geral de todas as sprints e gerenciar o backlog de acordo com essa visão, priorizando as tarefas. É o product owner quem diz ao time o que ele tem que fazer, e quando.
2. Scrum Master (SM)
O Scrum Master é o “coach” ágil do time. Ele garante que todas as práticas ágeis sejam seguidas, ou seja, garantir que a daily seja realizada, cuidar do tempo do sprint, etc. Também é função do SM proteger o time, garantindo que ele não se comprometa com mais do que pode desenvolver e gerenciando as expectativas dos stakeholders do produto. Também é o scrum master quem resolve problemas de relacionamento entre o time e impedimentos externos que possam atrapalhar o desenvolvimento do produto.
3. User Experience (UX), Designer ou Designer de Experiência de Uso
O UX é quem define a usabilidade do produto. É a ponte entre o desenvolvimento e o usuário final, aquele que vai usar o produto. Ou seja, ao UX cabe decidir o design e o fluxo que as informações devem seguir. É ele quem define quantas telas, o que terá em cada tela, onde fica cada link e etc.
4. Equipe de Desenvolvimento
É quem realmente faz o produto. Pode ser formada por uma ou até sete pessoas, que não têm funções pré-definidas. A equipe é auto gerenciada e auto organizada, ou seja, os próprios membros elegem quem será o responsável por determinada tarefa e cobram a realização dela. Neste ponto, é importante frisar que o time deve ter todos os perfis necessários para a execução do trabalho. Não adianta, por exemplo, ter quatro pessoas para back-end e nenhuma de front-end.
5. Growth Hacker ou Marketing do Produto
Pessoa cedida normalmente pelo marketing da empresa, o growth hacker é responsável por trazer tração para o produto durante a fase de validação. Este papel é responsável por fazer com que as pessoas saibam que o produto existe e engajar essas pessoas para que elas usem durante o desenvolvimento, uma vez que é por meio do feedback dessas pessoas que o time valida hipóteses e segue ou muda de direção. A diferença entre o growth hacker e o marketing tradicional é que o primeiro tem ênfase no uso de ferramentas mais analíticas, uma vez que seu objetivo é validar hipóteses que influenciam no desenvolvimento do produto, e tem orçamento mais limitado. Por isso, desenvolve campanhas focadas em grupos de usuários específicos.
6. Devops
É o responsável por codificar a infraestrutura na qual será montado o produto. Diferente do papel de infraestrutura tradicional, o Devops cria uma documentação viva do ambiente, que pode ser reutilizada.
Antes de terminarmos, é importante observar que todos esses papéis são interligados e parte de um time. Se não tivermos o PO, o time pode desenvolver um produto errado e todo o orçamento será gasto em engenharia. A frase que resume este ponto é “não importa quão bom seja o seu time se você não der algo relevante para ele fazer”. Sem o PO, o time vai desenvolver um monte de códigos desconexos da realidade, que pode não virar um produto efetivamente “entregável”, muito menos um produto de sucesso.
A falta de um scrum master pode comprometer o tempo em que o produto é criado. O time pode pegar mais tarefas do que efetivamente pode executar, e não desenvolver no tempo certo, enquanto os stakeholders podem ter suas expectativas frustradas. Vai faltar cadência no desenvolvimento do produto. Sem o time de desenvolvimento, não tem produto. Sem UX, não temos garantia que o produto vai ser “usável”, ou seja, que o usuário conseguirá utilizar o que você está criando. Sem o Devops, não haverá uma maneira replicável, automática e documentada para criação de ambiente para desenvolvimento, controle de qualidade e produção, enquanto que sem o growth hacker ninguém vai saber que seu produto existe e você não vai conseguir validar suas hipóteses, nem gerar tração e engajamento.
No fim, pode ser até que o produto saia, mas não aquele produto que você gostaria de construir e nem na velocidade que você esperava. Além disso, é bem provável que seu orçamento acabe muito antes do seu produto.
Link: Concrete Solutions
