Recentemente, li o livro Shape Up, mais uma grande obra do Ryan Singer, co-founder do Basecamp Inc, empresa também criadora dos livros best-sellers Getting Real e Rework.
É um livro extremamente polêmico, mas necessário, que rediscute o Scrum e a forma que gerimos produto como um todo, trazendo uma visão inovadora de trabalhar sem possuir um backlog fixo de produto. Já parou para pensar nisso?
Olhando de forma bem superficial em cima do Scrum e do Shape Up, enquanto o primeiro é um modelo para desenvolvimento de projetos baseado em Sprints, o segundo é para focar em lidar com incertezas do que precisa ser construído, realizar apostas e realizar o desenvolvimento do produto.
Ainda em cima de uma visão pragmática, o Scrum trabalha com sprints que vão de 1 a 3 semanas geralmente, enquanto um ciclo do Shape Up dura 6 semanas.
Embora eu não seja um grande fã do Scrum, ele traz muitos artefatos e cerimônias que tem um grande valor para a gestão de produtos e projetos. Um grande desafio que eu vejo no Scrum é conseguir manter uma qualidade de entrega, pesquisas, entrevistas, product discoveries, enquanto fatia o desenvolvimento de forma eficiente e colaborativa. Por mais Dual track que a gente busque ser, é sempre um grande desafio conseguir realizar pesquisas, entrevistas, envolver diferentes stakeholders, documentar tudo, fatiar tudo, desenhar fluxos e telas, e ainda não deixar engenharia morrer de fome.
O Shape Up me surpreende nesse sentido, por incluir dentro do seu processo a etapa de Shape e Bet. Deixa eu explicar um pouco mais como ele funciona.
No modelo proposto por Ryan Singer, a etapa de Shape tem quatro etapas: Definir limites, Esboçar os elementos, Abordar os riscos e Escrever o pitch. Nela, você analisa a direção que a empresa está focando, onde eu vejo que podemos inserir KPIs e OKRs como drivers. Um ponto importante nesse processo, é avaliar o peso do problema, ou seja, a importância do problema que queremos resolver, pois ele vai nos indicar o quanto queremos investir em tempo (ou talvez outras medidas) para resolver esse problema.
Essa definição em tempo, vai nos ajudar a definir um limite para que a relação entre solução x problema seja positiva (ou seja, não investir 6 semanas em um problema de baixa criticidade). O processo do Shape Up define um limite curto de semanas (2 semanas) para projetos pequenos, e um limite alto de semanas (6 semanas) para projetos grandes.
Um ponto que eu torci um nariz em cima do Shape Up, é que o mesmo aponta no livro que a etapa de Shape é primariamente um trabalho de Design, e que a pessoa deveria ganhar habilidades técnicas e de negócio para realizar melhor o trabalho, no máximo adicionando uma ou duas pessoas no processo. Para mim, isso vai contra todo o processo dos últimos anos, de integrar diferentes departamentos em pesquisas, discussões e discoveries. Assim como eu não gostaria de ver uma pessoa de produto estimando e definindo conhecimento técnico, não vejo que Design deveria ser o departamento a fazer isso sozinho. A defesa dele para isso é bem feita e "joga para torcida", dizendo que conceito por trás do Shape é um design de interação visto da perspectiva do usuário. Ele define o que o recurso faz, como funciona e onde se encaixa nos fluxos existentes. Eu não posso negar que isso tudo seja importante e necessário, ainda mais com a visão incrível de Designers, mas cadê a análise do que é factível? E sobre as prioridades e expectativas do negócio?
Um outro ponto de aprendizado em cima do Shape Up diz respeito ao Dual Track, que, como você que já leu artigos que vem do Basecamp deve saber, eles sempre dão nomes diferentes às coisas que você já conhece com nomes famosos. Nesse caso, ele chama de Two Tracks :)
Enquanto você tem Builders produzindo o que foi modelado ("shapeado") no último ciclo, você tem Shapers modelando o que será produzido ("buildado") no próximo ciclo. Isso já é muito parecido com o modelo de Product Discovery, trabalhando em dual-track com o Product Delivery. Então, nessa etapa de Shape, levantamos as ideias para resolver o problema apostado, esboçando as soluções (para mim um retrocesso para quem já atua com os frameworks OST ou Impact Mapping), passando para a fase de riscos e incertezas técnicas (que no fim nada mais é do que um risco)(que é chamado lá fora como "Rabbit hole", que podemos traduzir para buracos de coelho)(sim, usei dois parênteses nessa frase, ops 3). A última etapa do shape é a que eu mais gostei do processo, que consiste em Escrever o Pitch. Deixa eu falar um pouco mais sobre ela.
O foco do Pitch é vender a ideia do que foi modelado na etapa de Shape, para o restante do time (que vale dizer que, até o momento, é blindado de saber o que está sendo projetado pelos "shapers"). Essa apresentação traz os seguintes elementos:
- Problema - A ideia bruta, um caso de uso ou algo que vimos que nos motiva a trabalhar nisso
- Limitação - Quanto tempo queremos gastar e como isso restringe a solução
- Solução - Os principais elementos que criamos, apresentados de uma forma que seja fácil para as pessoas entenderem imediatamente
- Buracos de coelho - Detalhes sobre a solução que vale a pena mencionar para evitar problemas
- Não-vão - Qualquer coisa especificamente excluída do conceito: funcionalidade ou casos de uso que intencionalmente não cobrimos para atender à limitação de tempo ou tornar o problema tratável
No livro, ele explica cada elemento desse com muito mais detalhes, inclusive mostrando exemplos reais do próprio Basecamp.
Eu gostei desse modelo, pois é mais um tipo de documentação que podemos trazer para produto. Geralmente, não vejo muitas "apresentações" de produto após o discovery, no máximo um item novo no Upstream, que só será comunicado quando for para "hand-off" (isso quando não é um pequeno squad). Comunicar o processo de Discovery, com os aprendizados, esboços e riscos mapeados, geram maior confiança no time como um todo, e torna um processo valioso mais transparente, tanto aos olhos dos stakeholders, quanto dos shareholders.
Por fim, entendo que o Shape Up realmente tem uma grande aposta da Basecamp, que sempre traz conceitos inovadores, revolucionários e provocadores. Vejo que, muitos dos elementos citados no livro, já fazem parte do dia-a-dia de Product Managers e Designers principalmente, porém, com outros nomes, e talvez encaixado a outros elementos.
Um processo natural de organizar um Backlog de ideias dá lugar a filosofia de só trabalhar com ideias já modeladas e transformadas em Pitch, Dual track entre Discovery e Delivery dá lugar a two tracks de Shape e Build, definição de Product OKRs e de um Theme-based Roadmap dá lugar a uma Tabela de Apostas, Sprints dão lugar a Cycles, e assim vai.
Eu, particularmente, me senti desafiado de conhecer melhor o modelo e experimentar com meu time. Até para que eu possa reafirmar as opiniões desse artigo, ou até mesmo voltar atrás rever meu comentário. Um dos pontos que gostei e gostaria de implementar na equipe semana que vem, se possível, é o Cool Down, etapa de 2 semanas que acontece paralela a etapa de Aposta, ou seja, enquanto Product Managers estão definindo suas próximas apostas, Designers e Engenheiros estão fazendo o que quiserem, sejam relaxando, projetos paralelos da empresa, se reunindo para melhorar algo, aprendendo algo novo, atuando em débito técnico, matando itens dos OKRs do departamento, realmente qualquer coisa.
E você, já conhecia o Shape Up? Concorda com a minha análise ou tem uma visão diferente?
Me conta :)