Eu estive envolvido em marketing por quase toda a minha vida. Antes de começar a promover canais do YouTube na One2, eu gerenciava o departamento de atendimento ao cliente na agência PROMO. Inovações sempre me atraíram, então me deparar com a metodologia Scrum era uma questão de tempo.
Meu caminho para a gestão de projetos
Na agência de publicidade, eu me tornei o líder de um departamento composto por gerentes de conta. Não havia um sistema de gestão de projetos. Não cumpríamos nossos deveres contratuais a tempo e realizávamos trabalhos de qualidade inferior. Assim, eu me tornei um solucionador de problemas para lidar com o feedback negativo dos clientes. Era um beco sem saída: ao falhar em prevenir um problema, eu gerenciava suas consequências.
Comecei a procurar um conjunto de ferramentas para lidar com a situação. Naquela época, eu não estava ciente de Agile ou Scrum, muito menos das formas de utilizar a metodologia Scrum em equipes não-IT.
Eu me tornei um solucionador de problemas para lidar com feedback negativo dos clientes.
Como escolhemos a metodologia de gestão de projetos
A princípio, olhamos para o Kanban. É particularmente bom para problemas de fluxo, como correções de bugs ou processamento de aplicações em um call center. Mas para introduzir o Kanban, você precisa de uma equipe altamente motivada e bem organizada. Não era o nosso caso.
Também consideramos o Waterfall. É bom para equipes de TI porque uma sequência clara de etapas requer menos códigos, e você está em ascensão. O mesmo projeto em Scrum parecerá completamente diferente:
uma coisa que funciona —>ajuste —>otimização
A confiabilidade do Waterfall esconde sua desvantagem – um alto risco de interromper prazos. As empresas querem obter resultados o mais rápido possível, em vez de esperar um ano inteiro para se convencer de que a estratégia escolhida não funciona. O Scrum não está livre desse “problema”.
Quais ferramentas Scrum se adequarão a uma agência de marketing
O Scrum oferece muitas ferramentas para aumentar a motivação:
- Quadros Scrum. Os quadros Scrum mostram os status das tarefas e podem guiá-lo a pontos problemáticos (por exemplo, muitas tarefas estão na fase de discussão com os clientes). Disponibilizamos os quadros Scrum para nossos clientes para que eles pudessem acompanhar o status das tarefas. Isso aliviou profundamente nossos gerentes de conta do carga.
- reuniões diárias. Todos os membros da equipe se revezam para apresentar os resultados do dia anterior, fazer uma promessa para o dia atual e compartilhar problemas. Devido a essas reuniões diárias, você pode entender o que está acontecendo na empresa e encontrar maneiras de tornar o trabalho mais eficiente.
- planejamento. Isso torna o processo de trabalho transparente para o gerente e para o cliente. Convidamos clientes específicos e decidimos juntos quais tarefas definir para os próximos sprints.
- retrospectiva. Podemos entender os erros que cometemos e as maneiras de corrigi-los (por exemplo, como aumentar o número de tarefas simultâneas em andamento sem comprometer a qualidade).
- demostração do produto. Ela apresenta o progresso da equipe ao longo do sprint. Cada membro da equipe mostra sua parte do produto. A demonstração do produto possibilita realizar modificações rapidamente, melhorar o produto e não perder tempo com apresentações precoces do produto finalizado.
Meu trabalho consistia principalmente em analisar feedback negativo dos clientes. Após a introdução do Scrum, começamos a perguntar as opiniões dos clientes para entender se a direção do nosso movimento estava correta. Atualizamos o índice de suporte ao consumidor (NPS).
Quais são as desvantagens do Scrum para equipes não-IT?
O Scrum tem três principais desvantagens:
- Os processos de negócios se tornam mais caros. Introduzimos a posição de Product Owner, uma vez que nenhum membro da equipe conseguiria lidar com um papel tão importante. Esse especialista é caro. Nem o Product Owner nem o Scrum Master criam valor diretamente; eles estão além da equipe, e essencialmente pertencem à categoria das despesas gerais.
- Não há um serviço conveniente de gestão de projetos no Scrum para equipes não-IT. Nós costumávamos utilizar o Jira, mas sua configuração muitas vezes requer a contratação de um especialista.
- A terminologia de TI no Scrum não é adaptada para empresas não-IT. Para empresas de TI, existem diretrizes detalhadas que descrevem as maneiras de fazer o Scrum funcionar. Elas explicam a terminologia: incremento é um produto funcional, demonstração é mostrar como o produto funciona. No nosso caso, não estava claro como a redação de conteúdo afetava a operação do produto. E o que é um incremento em SEO? Se escrevemos um texto e o publicamos no site – é um produto funcional? Levou mais de três meses para adaptar a terminologia de TI para nossas necessidades.
Como falhamos em introduzir o Scrum
Começamos a introduzir o Scrum unindo equipes. E imediatamente cometemos dois erros.
Erro nº 1. Incluímos especialistas em publicidade contextual e SEO em uma mesma equipe. A lógica é a seguinte: eles todos atraem tráfego para os sites dos clientes e aumentam vendas, o que significa que estão bem juntos. A equipe é unida em torno de um cliente.
Como resolvemos o problema: após algum tempo, dividimos os especialistas por valores e produtos. Alguns clientes receberam vários gerentes de conta e equipes ao mesmo tempo.
O que entendemos: uma equipe deve estar unida em torno de um objetivo de negócio. Tal equipe é autossuficiente e capaz de criar valor para o cliente por si só.
Erro nº 2. Não conseguimos definir de imediato quem deveria atuar como Scrum Master e Product Owner.
Como resolvemos o problema: suplementamos a posição de contador de grupo existente com a função de Scrum Master. Antes disso, ele era responsável pela produtividade da equipe e pela entrega ininterrupta de valor ao cliente. Contratamos uma pessoa separada para ser o Product Owner.
Eu frequentemente encontro dois erros em empresas que também introduzem o Scrum:
- As equipes são combinadas em torno de uma função. Um departamento é apenas renomeado para equipe. O problema é que, se um cliente precisa de um site, a equipe deve ter um programador, designer e gerente. Nenhum departamento de marketing composto por gerentes de marca criará um site.
- As empresas têm medo de destruir a estrutura existente. O seguinte exemplo foi real. Um gerente de conta lidava com vários projetos, cada um dos quais era apoiado por diferentes especialistas em SEO. Os projetos eram distribuídos dependendo da carga de trabalho dos especialistas em SEO. Suponha que um especialista tenha obtido 10 projetos para trabalhar com diferentes prioridades. As prioridades são definidas pelo gerente de projeto, e essa empresa tinha vários. No melhor dos casos, o especialista em SEO cumpria a tarefa mais compreensível; no pior, a tarefa do gerente de conta que mais gritava.
Unir-se em “equipes corretas” é um processo doloroso.
Por que precisamos de um Scrum Master?
A Toyota tem um caso interessante para exemplificar o papel do Scrum Master. Na fábrica, alguns trabalhadores foram designados para ajudar um engenheiro mecânico a otimizar o trabalho. O engenheiro mecânico era pago por hora, o que era suficiente, assim o desempenho tinha que ser aumentado e os custos reduzidos. Foi percebido que o engenheiro mecânico procurava a chave de fenda certa – então um aprendiz foi designado para fornecer-lhe chaves. A intenção era facilitar ainda mais o processo: estênceis para ferramentas foram pintados no chão, e o aprendiz os organizou pela manhã antes do trabalho.
Então, um bom Scrum Master garante 80% do sucesso na introdução do Scrum. Se você não tem uma pessoa que pode assumir esse papel, encontre alguém que esteja interessado em trabalhar nesse campo. Como último recurso, procure um Scrum Master em empresas de TI.
O Scrum Master tem as seguintes funções não óbvias:
- Sentir onde a equipe está se saindo mal, onde é possível acelerar e onde é melhor desacelerar. É como um escudo contra prazos pressionadores e caos.
- Ser responsável pelo senso de segurança da equipe. Isso inclui proteção contra um cliente que quer “fazer tudo para ontem”. Por exemplo, encontramos tal problema: os gerentes de conta estavam compilando relatórios para clientes por muito tempo. A instigação do Scrum Master, nós configuramos relatórios automatizados gerados em tempo real. Agora o cliente não precisa esperar o final do mês para entender como as coisas estão indo. Todas as partes estão satisfeitas.
- Aumentar o nível da equipe para usar o Scrum por escolha voluntária.
- Comunicação um-a-um com cada membro da equipe. Sobre os problemas e dificuldades do funcionário. Deste modo, os especialistas juniores alcançam o nível médio mais rapidamente, e os especialistas médios crescem para seniores. A rotatividade de funcionários diminuirá.
Por que precisamos de um Product Owner?
Não entendemos imediatamente quem deveria se tornar o Product Owner e de que ele/ela seria responsável. Chegamos à conclusão de que o Product Owner é um especialista técnico que possui um bom conhecimento do produto e capaz de elaborar contextos e estratégias de SEO, transmitindo-as ao cliente. Em outras palavras, este é um estrategista que diz o que precisa ser feito.
O que nosso Product Owner faz?
- forma backlogs;
- remove e define prioridades das tarefas;
- ajusta estratégias com base nos dados obtidos da equipe;
- é responsável perante os clientes pelos resultados.
A maneira como introduzimos o Scrum em uma empresa não-IT
Os especialistas costumavam trabalhar separadamente: redatores e editores, construtores de links e analistas de SEO. Enquanto introduzíamos o Scrum, os misturamos uns com os outros. Cada equipe também tem um gerente de conta que entrega valor aos clientes.
As equipes foram formadas para cada uma das três áreas de SEO:
- gerenciando a massa de links
- criando conteúdo
- reforma de site.
O trabalho foi dividido em sprints que fundamentam o planejamento mensal. Durante o planejamento, tentamos reduzir o risco de não alcançar resultado ao final do mês.
Experimentamos com a duração dos sprints. Quando começamos a introduzir o Scrum, os sprints eram semanais. Um sprint semanal possibilita rapidamente rodar um processo e perceber onde você está errado, ensinar funcionários e entender como tudo funciona.
Conselho chave para a duração dos sprints do Scrum em marketing: selecione um prazo que seja suficiente para fazer algo útil.
Os sprints são assim:
planejamento —>reuniões diárias —>demo —>retrospectiva.
Redirecionamos parte das equipes para ter sprints de duas semanas. Tenha em mente que quanto mais longo o sprint, mais você arrisca perder prazos.
Usamos as seguintes ferramentas em nosso trabalho:
- planejamento em poker. A técnica torna possível avaliar a complexidade e a abrangência das tarefas que precisarão ser abordadas enquanto o produto é criado. Todos os membros da equipe estão envolvidos no planejamento em poker. Usando cartas, eles avaliam as tarefas e tomam decisões coletivas;
- analogia de programação em par baseada em programação extrema. Várias pessoas trabalham em uma tarefa no mesmo local de trabalho. É um exemplo demonstrativo da regra – “Duas cabeças pensam melhor que uma”. Usamos isso em momentos críticos;
- Ciclos HADI. Eles são algoritmos para verificar hipóteses controversas que ajudam a ganhar a confiança do cliente. Leia mais sobre os ciclos HADI abaixo.
O que são ciclos HADI e como usá-los?
O que é? Um ciclo HADI é um algoritmo para verificar uma hipótese que se apresenta da seguinte forma:
hipótese —> verificação —> resultado —> conclusões.
Ciclos HADI são semelhantes ao loop Lean Startup:
construir —> medir —> aprender
Como funciona?
Você gera hipóteses cuja viabilidade é questionada. Se uma tarefa é compreensível e necessária, não faz sentido processá-la em um ciclo HADI. Após verificar a hipótese, você determina se funcionou ou não, e até que grau de eficiência. Se funcionou, você a lança em um sprint, se não, apenas a descarta.
Como é?
Por exemplo, há uma hipótese: “Se eu fizer linkagem nos produtos, isso resultará em um crescimento triplo do tráfego”. Você verifica a hipótese em um produto, criando links manualmente dentro do site. Se a hipótese funcionar, você dá uma tarefa para os programadores: “Forneça linkagem em todo o site”.
Qual é a vantagem dos ciclos HADI?
Pode parecer ao cliente que sua nova solução não terá um bom desempenho. Em resposta, você mostra o exemplo real baseado em um elemento.
Documente suas hipóteses, mesmo que não tenham funcionado. No próximo sprint, você pode testar outra. Além disso, certifique-se de que seus experimentos não causem um conflito de interesses (por exemplo, para que hipóteses relacionadas à mesma página da web não sejam testadas simultaneamente). Caso contrário, não ficará claro qual hipótese teve sucesso.
7 dicas para introduzir o Scrum se você não é uma empresa de TI
- Comece pela formação. Leia literatura especializada, visite sessões de treinamento.
- Determine quem é seu stakeholder (parte interessada). E então trabalhe para entregar valor ao cliente e ao stakeholder.
- Sprints devem permanecer inalterados. Não tenha medo de mudar o restante das coisas.
- Não redirecione toda a equipe para o Scrum, apenas porque “é legal”. Por exemplo, nossos redatores trabalham com Kanban porque os textos não têm prioridades – eles precisam ser feitos o mais rápido possível.
- Determine o tamanho ideal da sua equipe. De acordo com minha experiência, são cinco a sete pessoas em empresas não-IT.
- Organize uma área de trabalho isolada para cada equipe. Se você tem um escritório em espaço aberto, adicione quadros Scrum offline.
- Lidere a implementação do Scrum. Se a gestão não entende o propósito de uma nova metodologia, nada será feito.