Oi pessoal.
Este post tem que ter uma menção honrosa ao Eduardo D’avo, que me pediu pra pensar num método sobre Pré Game.
Vou contextualiza-los:
Trabalho numa grande (e muito legal e feliz) consultoria. Nós atuamos em muitos projetos e nem sempre nossos clientes conhecem Agile. Ou mesmo os que conhecem optam, por vezes, em não trabalhar desta forma e esse é o mundo real. Como todos aqui somos profissionais, e provavelmente não compramos as casas na praia que queremos ou viajamos pra todos lugares que desejamos, nós não negamos fogo a projetos “não ágeis”.
Sem duvida, não deixamos de explicar os benefícios do filosofia Agile (junte Lean aqui, ok) e de trabalhar com essa mentalidade, mas muitas vezes o cliente não abre mão da aceitação formal de fases, mantém o conhecimento em silos, deseja estimativa para saber prazo e custo e as outras maravilhas que todos conhecem. Então, nós aqui na Empresa fazemos um Pré Game.
O Pré Game consiste, no nosso caso, num curto espaço de tempo antes do início do desenvolvimento em si (das iterações) aonde averiguamos o contexto do Negócio (Projeto ou Produto) especulamos sobre seus objetivos, sua forma de gerar Valor e a quem ele gera valor. Também fazemos uma análise sobre as principais necessidades dos clientes e começamos a especular sobre as principais funcionalidades. Quando o caso é projeto, muitas vezes o Cliente já tem uma documentação preparada e tem seus Domain Experts.
Neste caso, literalmente sugamos o conhecimento junto ao Domain Expert, criamos conexões com os usuários e fazemos um reconhecimento da documentação existente. A questão é, Por que fazemos isso a invés de começar logo a desenvolver?
A resposta: Estamos no mundo Real!
Se pegarmos a documentação já existente, toma-la como correta e definitiva e começarmos a desenvolver, alguém aqui arrisca o resultado? Sim, o resultado será MERDA. Não por falta de qualidade ou incompetência. Sabemos o resultado de conhecimento de negócio colocado em papel, como forma de comunicação. Dá merda.
Outro ponto também: muitas vezes o cliente documenta o DESEJO e não o REQUISITO. E o pior: REQUISITO sem conhecimento do domínio do NEGÓCIO é como sexo sem órgão genital. O Pré Game, no nosso caso, serve também para criar a ponte entre o Cliente e o Time, fazer a contextualização sobre o Domínio do Negócio, unir as pessoas e criar o elo indivisível entre aqueles que querem entregar valor.
No nosso Pré Game, começamos a entender o que é desejo, o que é requisito e junto do Cliente buscamos o MPV (minimo produto viável) e criar o Plano de Release. É normal o cliente pedir tudo sem saber do valor sobre o que ele está pedindo. E ele acha que tem que pedir tudo pois provavelmente já teve experiências tristes e frustadas em outras consultorias, aonde coisas de valor pra ele, quando ele não especificou logo no começo do projeto e foi pedir depois, foi tratada como “change request” e foi um transtorno pra ser feito.
O nosso Pré Game serve como meta-game para educar o cliente, sem ele pedir está educação. E sem duvida nosso Pré Game também serve para outra coisa, que gera polêmica: ESTIMATIVAS. No nosso Pré Game, muitas vezes listamos as principais funcionalidades, as entendemos e estudamos sua complexidade técnica e em muitos casos, fazemos POCs.
E geramos uma potencial estimativa para ser feito o MVP. Ao longo do nosso processo de Pré Game, o cliente vai sentido que ele não precisa conhecer ou dominar todo o escopo. Explicamos o que realmente é uma estimativa e como vamos trata-la ao longo do projeto. Porém, por mais bonito que seja o discurso Ágil, e muitos sabem o quanto eu advoco por ele, muitas vezes os clientes não querem isso. Eles querem estimativa e prazo. Nossa artimanha para tentar ir quebrando esse medo e necessidade deles é o Pré Game.
Lá se vão 1 ano e 2 meses que estou aqui. Lá se vão 5 projetos que atuei diretamente e outros N > 10 e < 20 Pré Games feitos em propostas que não vingaram ou estão para vingar e o resultado tem sido muito bom. 2 casos recentes foram muito interessantes:
1 – Um cliente começou um projeto conosco mas por questões políticas internas deles, foram obrigados a parar.
Eles não poderiam fazer o projeto conosco por questões de contrato com outros parceiros e tal. Mas assim que isso se resolveu, eles nos escolheram não só pra terminar o projeto quanto começar um outro grande projeto.
O diferencial: O mote como fizemos o Pré Game e a concepção do MPV deles.
2 – Outro cliente que teve no seu Pré Game grandes descobertas de valor, graças a estudo de mercado e falseamento de hipóteses.
Ao fim do Pré Game, toda uma cadeia de valor foi estudada, grandes e inovadoras funcionalidades foram testadas em POC e hoje o produto ta no ar já dando o ROI esperado. E vem mais Releases dele…
Seria muito fácil para nós, negarmos fazer um projeto por sentir que o cliente não “deseja” Agile. Porém seria, IMHO, muito infantil da atitude de um profissional. Nosso Pré Game é um Meta Game de ensino de Agile. Sim, nós fornecemos estimativas e prazos, mas damos a estes o valor que eles merecem. Nada mais do que chutes ao vento cujo toda iteração iremos avaliar.
O ouro do nosso Pré Game é: O aprendizado junto ao cliente sobre o negócio e seu valor, gerando a integração entre stakeholders e Time, ao mesmo tempo que fornecemos o aprendizado em Agile, criando um elo de confiança.
No nosso Pré Game, sempre buscamos integrar o máximo possível de membros do Time junto aos stakeholders. Abaixo, seguem imagens do método de nosso Pré Game, de um material que gerei graças ao pedido do Edu.
Eu soltei ele pra Comunidade pois quero coletar feedback:
agilementoring 