Habilite a Autonomia dos Desenvolvedores com Refining
Há pouco mais de três meses, Malu, nossa product manager e eu palestramos em um grande evento chamado TDC. Na semana seguinte eu dei uma aula no Gama Academy na formação de Product Manager. O ponto que mais chamou a atenção das pessoas foi um movimento que está em curso na Creditas: habilitar os próprios desenvolvedores a assumirem tarefas táticas de produto e processos.
Todos ficam abismados de como podemos dar autonomia ao time técnico e não ter grandes problemas com isso. Acabamos indo por esse caminho por conta de uma grande mudança organizacional que realizamos em fevereiro.
CONTEXTO
Antes de fevereiro essa era nossa estrutura de times.
Nosso time tinha um tamanho médio e o ponto era, precisávamos crescer, principalmente para conseguir entregar produto em todas as áreas da empresa.
Atualmente nossa estrutura está dessa forma.
É notável que além de aumentar o número de software engineers, também nasceram novos times ao redor da nossa operação. Tudo isso por conta da evolução do nosso modelo de negócio: estamos saindo do estágio de growth entrando em scale.
Em apenas 3 meses, saímos de 3 times de produtos para significantes 8 times! Não tínhamos pessoas de produto para todos os times, e mesmo que corrêssemos para aumentar o nosso time de apoio (QA, PM, Agile Coach e Arquitetura) sabemos que esses papéis demoram um pouco mais para amadurecer independente do contexto.
Mas nem tudo foi um mar de rosas. No começo batemos muito a cabeça, pois não é simplesmente agrupá-los e esperar que mágica aconteça.
Ahh e só para lembrar, temos muitas vagas em aberto.
Então a saída foi exatamente posicionar esses papéis que apoiam os software engineers como mentores/coaches, pois a nossa intenção em fragmentar a estrutura era também transformar os desenvolvedores em especialistas no negócio, fazendo com que tecnologia e business passassem a trabalhar em conjunto.
DIFICULDADES
Nosso negócio é muito complexo, pois nossa operação é similar a de um banco. Tivemos um puta desafio inicial que foi balancear o curto e o longo prazo.
SHORT TERM X LONG TERM
A operação tem a nobre missão de fazer a empresa crescer mês a mês, e produto + tech de criar uma vantagem competitiva a cada 3 meses no mínimo. Se você foca a tecnologia em resolver problemas atuais e pontuais, dificilmente você irá inovar e criar um modelo que escale e tenha longevidade.
Nesse ponto, entendemos de fato a importância de interseccionar dois papéis de apoio: arquitetura e produto.
O arquiteto, nesse contexto, é de suma importância para garantir que tudo que está sendo construído vai se encaixar perfeitamente no que já existe, mesmo que o primeiro release seja super simples. E produto é essencial para garantir que esse mesmo release esteja de fato possibilitando que a estratégia da empresa seja seguida. Isso acontece através da priorização dos problemas que vamos trabalhar. Outra responsabilidade de produto, é garantir que as entregas resolvam não só problemas atuais, mas que levem a empresa a um novo patamar.
No nosso contexto, produto é mais dono dos problemas e objetivos que das soluções, é aí que os desenvolvedores começam a ganhar plenos poderes e responsabilidades.
Depois de alguns tropeços, superamos a fase do curto vs longo com muitos aprendizados e partimos para uma nova etapa: fazer com que as ideias, objetivos e problemas virassem incrementos de produto.
PROCESSO, PROCESSO E MAIS PROCESSOS
Em um time completo e já formado, teríamos pelo menos um product manager para cada 4 times, mas no nosso cenário recente, em que tínhamos apenas uma product manager e 8 times, seria humanamente impossível que ela sozinha conseguisse mapear os temas/épicos, refinar os itens e escrever as user stories de todos os times.
Foi nesse ponto que dois outros papéis de apoio subiram ao palco: QA e o Agile Coach (que vos escreve ao som de Rashid, Mano Brown e Max de Castro). Seguindo os 5 itens descritos no agile manifesto testing, começamos a reforçar o entendimento do time a respeito dos entregáveis.
Um conceito que adotamos foi o FDD (Feature Driven Development), que foca planejamento na camada de funcionalidades do produto. A partir dessa camada, encontramos os temas e as user stories.
Outro conceito que tornou-se muito importante para nós foi o refining, que é uma prática usada para deixar as user stories ready. Segundo o guia do Scrum, deixar user stories ready significa deixar um item pronto para o desenvolvimento, seguindo alguns critérios de qualidade exigidos pelo time técnico na escrita da história.
Esse framework, segue o conceito de feature injection, que basicamente consiste em destacar e fixar qual o valor que a entrega vai gerar em algumas dimensões:
- Empresa
- Operação
- Usuário
- Tecnologia
Usamos um formulário que é preenchido no momento que uma funcionalidade começa a ser discutida pelo time. A ideia futura é fazer com que esse formulário seja preenchido a cada step que avançamos no nosso fluxo de produção. Inclusive depois da entrega, preenchendo a métrica de que justifica o sucesso da entrega.
Depois usamos uma ferramentinha que chamamos de story tree.
É muito simples! No topo fica a funcionalidade e no centro o usuário mais interessado nela. O usuário pode ser uma pessoa ou sistema.
A grande sacada dessa ferramenta é responder as seguintes perguntas:
COMO EU RESOLVO A FUNCIONALIDADE X PARA O USUÁRIO Y? QUAIS SÃO OS OBJETIVOS DELE AO UTILIZAR ESSA FUNCIONALIDADE?
Ao responder essas simples questões, as user stories acabam nascendo uma após a outra.
Após o preenchimento do story tree, a nossa product manager entra em cena mais uma vez. Ela ajuda o time a entender quais itens são must havee quais são could have, algo semelhante ao que o MVF (Minimal Viable Feature) propõe.
Na sequência, vem a parte mais sinistra da brincadeira: a escrita da user story. Para isso, usamos outra ferramenta chamada 7 dimensões do produto (ou 7D para os íntimos), que no nosso caso se transformou em 6 dimensões (6D).
O formulário ajudou a entender a motivação da funcionalidade e mapear o principal interessado na entrega e, consequentemente, também foi vital para as descobrir as user stories. Como o nosso processo é sequencial, o domínio sobre a resolução vai sendo incrementado passo a passo, lembrando o conceito de divisão e conquista. Nesse ponto o time já começa a visualizar possíveis regras de negócio, problemas técnicos, esforço e conhecimento específico da experiência do usuário.
Para fazer o 6D, reunimos o time todo em volta de uma parede com post its. É interessante que pelo menos na primeira vez seja feito dessa forma, pois é uma atividade que incentiva a colaboração.
No cabeçalho, escrevemos o nome da user story, da funcionalidade e qual o problema que estamos resolvendo com elas. Na linha debaixo, colocamos as 6 colunas na sequência conforme a imagem acima.
- Ator — usuário principal (ator pode ser um sistema);
- Interface — interface que irá possibilitar o uso;
- Ação — verbos que o usuário pode executar;
- Dados — informação que ele irá inputar;
- Regras de Negócio — validações;
- Qualidade — requisitos não funcionais
O segredo aqui está em responder uma sequência de perguntas:
1ª Qual é o ator que irá utilizar a user story X da funcionalidade Y que resolve o problema W?
2ª Quais são as ações que o ator A pode executar na user story X da funcionalidade Y que resolve o problema W?
3ª Quando o ator A estiver executando a ação B na user story X da funcionalidade Y que resolve o problema W, quais são os dados que ele vai inserir?
4ª Quando o ator A estiver executando a ação B inserindo o dado H na user story X da funcionalidade Y que resolve o problema W, quais são as validações que devemos realizar?
5ª Quando o ator A estiver utilizando a user story X da funcionalidade Y que resolve o problema W, quais são os requisitos não funcionais que devemos nos preocupar?
6ª Qual será a interface que irá permitir o ator A utilizar a user story X da funcionalidade Y que resolve o problema W?
Ao terminar de responder essas 6 perguntas (as 6 dimensões do produto), no melhor dos mundos, nós vamos ter a user story pronta:
USE CASE
Eu como analista de crédito quero cadastrar o meu perfil para poder ter acesso às ferramentas de aprovação de crédito.
CRITÉRIO DE ACEITAÇÃO
O nome do analista é obrigatório
O nome do analista tem que conter nome e sobrenome
Todo evento deve ser registrado no log do sistema
Caso o time levante dúvidas a respeito das ações, dados e regras, o próprio time vai atrás dos stakeholders para eliminar as dúvidas e deixar a user story ready para entrar no sprint. E nesse caso, tanto o Agile Coach como a QA tem autoridade total para bloquear a entrada de itens não ready no sprint.
A nossa QA entra no sprint para automatizar os testes de aceitação junto com os desenvolvedores. Dessa forma, eliminamos a obrigação da product manager de validar o comportamento da solução, restando a ela apenas a validação das regras de negócio. Isso torna a nossa cadeia de valor mais fluida e habilita não só o poder do time, mas também a responsabilidade do mesmo sobre a entrega.
CONCLUSÃO
Sabemos que os desenvolvedores, além de serem os software engineers, tem também um perfil altamente criativo e pensante, então não queremos que eles sejam apenas digitadores!
Nesse caso, para habilitar a autonomia do time de desenvolvimento, utilizamos um processo bem fluido e simples de ser executado. No começo, ele pode até diminuir a velocidade de entrega, mas, a longo prazo, acreditamos que teremos pessoas com um perfil técnico porém especializado em uma área de negócio da empresa. Isso nos dará não só um ritmo sustentável, mas também entregas mais assertivas. Na nossa opinião, essas são as verdadeiras entregas de valor, pois resolvem os problemas de todos na empresa.
Ainda temos alguns problemas que aos poucos estamos resolvendo. Nosso time de produto está crescendo e acreditamos que os desenvolvedores vão ajudar e muito a contextualizar os novos product managers.
O texto, apesar de longo, foi bem resumido. Se você quiser saber mais em detalhes como funciona o nosso processo, entre em contato que podemos bater um papo.
Um abraço e até o próximo post.
Tem interesse em trabalhar conosco? Nós estamos sempre procurando por pessoas apaixonadas por tecnologia para fazer parte da nossa tripulação! Você pode conferir nossas vagas aqui.
