Pré Game: Cascata, agilidade ou apenas opção para o mundo real?

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:

Pré Game

stakeholders

roi

fronteira

macrovisaofuncionalprovaconceito

meta

Anúncios

Análise de Negócios (ágil ou não), um grande desafio

Neste post vou comentar sobre meu novo desafio, que é uma retomada as origens.

Comecei na carreira como Analista de Requisitos e depois me enveredei mais a Scrum Master. Estou retomando agora com a alcunha de Analista de Negócio.

Bem, como gosto de fazer, vamos imitiar o Jack e ir por partes.

Análise de Negócio, o que é?

Segundo o IIBA é:

“A Análise de Negócios é o conjunto de atividades e  técnicas utilizadas para servir como ligação entre  partes interessadas no intuito de compreender a  estrutura, políticas e operações de uma organização  e para recomendar soluções que permitam que a  organização alcance suas metas”.

(IIBA®, 2009, pg 3)

Esta não é uma tarefa fácil, porém, é muito prazerosa.

Analisar o negócio requer contato direto e aberto com as pessoas. Não pense que o negócio se traduz através de processos descritos ou mapeados, pois não se traduz mesmo. Analisar o negócio não é apenas verificar as interações homens-máquinas que uma pessoa faz ou descobrir tarefas manuais que podem ser automatizadas ou informatizadas.

Muitos confudem isto. Acreditam que por entender o contexto da interação da pessoa com o processo ou descobrir ações manuais que podem ser informatizadas, estão fazendo um grande trabalho de análise. Isto não é. No máximo, é um trabalho de observação, que também é importante mas não deve ser a única ação de um Analista de Negócio.

 Para entender a diferença entre Observação e Analise, vamos ao significado das palavras:

Observação:

 Ato ou efeito de observar, segundo o dicionário

A observação é uma das etapas do método científico. Consiste em perceber, ver e não interpretar. A observação é relatada como foi visualizada, sem que, a princípio, as idéias interpretativas dos observadores sejam tomadas. By Wikipedia.

Observação é comumente descrita como o estudo em que o pesquisador frequenta o local onde o fenômeno ocorre. O observador procura se interar sobre as atividades do grupo estudado, vivendo junto com eles estas experiências afim de averiguar detalhes.

Análise:

Estudo detalhado, decomposição em partes.

Análise (do grego ανάλυσις, transl. análysis, “dissolução”) é o processo de decomposição de uma substância ou tópico complexo em seus diversos elementos constituintes, a fim de se obter uma melhor compreensão sua. By Wikipedia.

Processo lógico que consiste na investigação das estruturas básicas de uma informação.

A Análise é mais profunda do que que a observação, embora a observação faça parte da análise.

Observar as atividades e interagir com as pessoas provem uma base de início para a análise, que tem um intuito da compreensão do todo, compreensão das ações entre as parte e as reações que geram. Uma vez isto acontecido, você aumenta a capacidade de formular soluções e potencializa a comunicação.

Logo, se você não gosta de sair da sua mesa e estar em contato direto com o ambiente a ser estudado, é melhor você não querer (ser) um Analista de Negócio. A imersão no meio ambiente estudado deve ser profunda.

Analisar requer interação e contato com as passoas, logo se relacionar com elas é importante (e importantíssimo na Visão Ágil da Análise, visão que compartilho). Logo, se você não gosta muito de pessoas ou conversar, terá problemas.

 E agora vamos falar do que é Negócio:

Em apertada síntese, podemos dizer que, entende-se por negócio toda e qualquer atividade econômica com o objetivo de gerar lucro.

Etimologicamente, e num sentido mais lato, a palavra negócio deriva do latim, e quer dizer a negação do ócio. Negócio não trata apenas de negócio financeiro ou comercial, mas sim toda a atividade humana que tem efeitos jurídicos. By Wikipedia

Eu gosto muito da origem da palavra Negócio “negação ao ócio”. Logo, Negócio significa atitude ativa. Se você quiser ser (ou é) um Analista de Negócio, este deve ser o seu mantra, seu mandamento número 1:

“Negarás ao ócio”

Para ser um Analista de Negócios, é ideal que você realmente seja ativo, pró ativo, interessado, participativo, dinâmico e mais um monte de palavras que querem dizer “Não fique parado”.

De lambuja, nós teríamos um segundo mandamento (ou dica, não quero ser pretensioso de ditar leis :P).

“Estarás presente”

É meu caro amigo, uma análise adequada não se faz sentado, com o bumbum numa cadeira. Levanta-te, vem para o meio, parafrasenado Jesus.

Como o papai dos Negócios, Peter Drucker define bem, todo Negócio tem um objetivo claro, Criar um Cliente.

Existem outras abordagens para o Objetivo de um Negócio, como gerar Lucro, mas particularmente eu fico com o titio Pete nessa. Um negócio tem por objetivo criar um cliente e satisfazer suas necessidades através de seu ciclo de vida.

” É o cliente que determina o que é um negócio. Apenas o cliente, cuja disposição para pagar por um bem ou serviço converte recursos economicos em riqueza e coisas em bens. Aquilo que o cliente compra e considera de valor nunca é apenas um produto. Tem uma utilidade, i.e., o que o produto ou serviço faz por ele.” By Wikipedia.

Aqui começa o desafio, compreender o Negócio.

 

Para tal, compreender seu Cliente é essencial. Quem é o seu Cliente e quem é o Cliente do Negócio. Isto até parece “A Origem” (Inception) mas é a verdade.

Você, como Analista de Negócio, representa uma Empresa (a sua mesmo ou a em que trabalha) e tem um Cliente. Até aqui tudo OK. Porém, a análise do negócio que você vai realizar tem o seu próprio Cliente.

Buscar este Cliente é um passo importantíssimo para iniciar e manter uma boa análise. A análise Ágil ou Tradicional, valida suas descobertas em ciclos (a ágil em ciclos mais curtos e rápidos) e as descobertas ocorrem de forma iterativa e incremental. Validar quem é o Cliente do Negócio é uma ação que você deve fazer sempre, a cada ciclo. Uma vez que o Cliente se mostrou ser outro, as coisas mudam.

Não trace um plano para analisar o negócio ou achar o seu Cliente. Uma vez um boxeador famoso (que eu esqueci quem é) disse algo assim:

“Todos tem um plano até levar um soco no queixo”.

O análise é um processo de descoberta, formulação de hipoteses, falseamento de hiposteses e ocorre de forma não linear. Logo, não espere ter um plano definido ou ache que a análise vai decorrer sobre a forma de um Diagrama de Atividades ou Fluxogramas.

O produto da análise pode ser demonstrado assim, mas o processo da análise não é desta forma.

A interação com as pessoas torna tudo mais divertido e místico. Pessoas tem dias bons, dias ruins, falam por entrelinhas, e para fazer uma análise legal, é bom o Analista ficar atento a isto.

Eu gosto de realizar práticas e/ou perguntas lúdicas, para entender as entrelinhas. Gosto de conversar com as pessoas em diferentes horários do dia, em dias diferentes o mesmo assunto. Tento fazer isto não ser exaustivo e repetitivo, mas faço isso pra ir colhendo pequenos feedbacks, ora abstraíndo sentimento, ora quero todo o sentimento que as pessoas têm.

Não quero aqui, neste post pelo menos, falar sobre as diferenças entre a Análise de Negócio Ágil e a Tradicional. Existem ótimas referências para isso:

E se um deles disser que eu escrevi merda aqui, acredite neles 😛

Um dia vou escrever algo sobre essas diferenças, quero pensar mais sobre isso, pois, quando comecei a anos atrás e fazia a “Análise Tradicional” e não tinha conhecimento de técnicas e ferramentas que eu tenho hoje, e isto é natural, sempre dei grande importância as pessoas, ao tato e contato, e todos sempre tentavam minimizar o tempo de feedback.

O desafio da Análise de Negócio é imenso, mas muito recompensador.

Pretendo em próximos post falar mais sobre o tal do Analista de Negócio, Requisito, Funcional, Processo ou sei lá o que mais. Alguns dizem que é diferente, outros que é igual.

[]s e até a próxima.

Domain Game – Uma dinâmica para todos

Desenvolver um produto requer muita comunicação. Os desafios de se transferir conhecimento são grandes. Bem como o desafio de se ter um bom ambiente onde desenvolvedores, testers e outros papéis técnicos consigam se comunicar com eficácia e eficiência com aqueles que dominam o negócio acerca do produto.

Foi tendo este desafio em mente que criei o “Domain Game”.

O Domain Game é um Agile game que visa auxiliar a ardua tarefa de disseminação de conhecimento, de uma forma simples e divertida.

O Domain Game se baseia no Domain Drive Design onde, através do Domain Model e a Ubiquitous Language podem ser geradas perguntas que são apresentadas ao Time de desenvolvimento. Vamos explicar a dinâmica.

O Product Owner junto do Domain Expert, Analista de Negócios e Clientes geram uma série de perguntas em torno de Domain Model do produto, exemplo:

Digamos que estamos tratando do desenvolvimento de um software de Nota Fiscal Eletrônica, podemos formular algumas questões:

  • O que significa NFe?
  • Para que serve uma Nota Fiscal?
  • O que siginifica DANF?
  • O que siginifica ICMS?
  • O que signifca ISS?
  • Qual a diferença entre tributo, imposto e taxa?
  • É correto afimar que existem mais tributos que impostos?
  • Quando é emitida uma Nota Fiscal Eletrônica?

Uma vez geradas estas perguntas, podemos reunir todos envolvidos possíveis numa sala.

Product Owner, Analistas de Negócio, Domain Expert e Cliente irão fazer o papel do “Caixa”. Tanto o Caixa quanto cada membro do Time começam o jogo com uma quantidade de bombons, semelhante ao “stack” do Poker.

O Caixa irá realizar uma pergunta para um membro do Time por vez. Se o membro do Time acertar a pergunta, ele recebe um bombom do Caixa. Se ele errar a resposta, ele dá um bombom para o caixa.

O jogo pode ficar ainda mais interessante. Caso o Caixa realize uma pergunta a um membro do Time, e este dar uma resposta e outro membro do Time achar que aquela não foi a resposta correta e quiser responder a pergunta do Caixa, ele pode desafiar a resposta do membro anterior. Aí, a quantidade de bombons envolvidas na aposta aumenta.

 

 

 

 

 

 

 

 

 

Quem acertar, leva os bombons envolvidos na disputa. Se ambos errarem o Caixa leva tudo.

O jogo não tem uma busca por vencedor. O ideal é que se estipule um Time Box para se jogar. Ao final do tempo, uma boa dica é juntar os bombons e repartir entre todos, com todo mundo que estiver por perto, pelo caminho e etc.

Ao final do jogo, podemos fazer um Retrospectiva para avaliar como o Domain Model  está absorvido pelo Time. Nesta Retrospectiva podemos verificar tais pontos:

  • Entendimento sobre o Domínio: O Time teve muitas duvidas quanto as perguntas realizadas?
  • Entendimento sobre a lingaguem do Domínio: O Time compreende os jargões e metáforas?
  • Ambiente saudável: O jogo foi jogado de forma descontraída e alegre? Houve pressão?

O Domain Game não tem regras especifícas. Ele tem diretriz. Você pode adaptá-lo para jogar em pares, grupos, usar tabuleiros. Busque apenas criar um bom ambiente e através dele, fortalecer o entendimento do Domínio.

O Domain Game é um jogo integrativo. Visa aproximar o Cliente e especialistas do Negócio ao Time de desenvolvimento, gerando uma interação mais amigável e sustentável.

Eu já utilizei o jogo em Domínio muito complexos e com várias pessoas envolvidas e os resultados foram bons. Geralmente o aplico no início do desenvolvimento do produto ou de um novo módulo, para podermos validar nosso entendimento.

Eu apresentei o Domain Game em uma Talk no Agile Brazil 2011.

Aqui estão os slides da apresentação.

Utilize também e compartilhe os resultados.