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

Analista de Negócios, Analista de Requisitos, Analista de Processos. Preciso ir a uma Analista

Olá caros amigos, tudo certo?

Você vai ter uma overdose da palavra “Análise”, mas siga firme que terá êxito em ler o Post.

Como prometido há algum tempo, hoje vou falar sobre esta miscelânia de papéis que existem na TI referente a Análise.

Esta variedade de papéis costuma fundir a cabeça das recrutadoras do RH nas empresas, costuma causar crise de identidade nos profissionais e mais ainda, costuma causar problemas no projeto se o profissional não souber corretamente qual é o seu papel e o que se espera dele.

Mas afinal, será que Analista de Negócios, Analista de Processos e Analista de Requisitos não é tudo a mesma coisa?

A resposta: Não. Não é tudo a mesma coisa não.

Apesar de ser muito comum o desentendimento sobre cada papel e alguém acabar fazendo os três papéis (ou fazer apenas um e achar que está fazendo todos) no dia-a-dia, cada tipo de análise é sim uma coisa diferente.

Como gosto de fazer, vamos por parte e destrinchar cada um destes papéis:

Primeiro, vamos saber o que é um Analista:

a.na.lis.ta1 adj m+f (gr analystés) Que analisa. s m+f 1 Pessoa que analisa ou é versada em análises. 2 Pessoa cujo ofício é fazer análises das propriedades químicas, físicas ou de outra espécie de uma substância ou produto.

a.na.lis.ta2 adj m+f (lat annale+ista) Relativo ou pertencente a anais ou a quem os escreve. s m+f Pessoa que escreve anais.

O Analista é uma pessoa que tem por carateristícas, a vontade de observar, compreender e descrever a dinâmica de algum produto, processo ou modo de execução. É fundamental para quem exerce este papel ter uma dicção para poder se comunicar de forma clara, ter domínio da escrita, sendo simples na sua forma de descrever porém coeso e acertivo. Um Analista também deve ter em si uma curiosidade natural para sempre procurar saber mais sobre as coisas, como elas se iniciam, como se processam e como passam a diante.

Vamor ver o que é “Negócios”:

By Wikipedia:

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

Processos:

By Wikipedia:

Processo deriva do latim procedere, verbo que indica a ação de avançar, ir para frente (pro+cedere)) e é um conjunto sequencial e particular de ações com objetivo comum. Pode ter os mais variados propósitos: criar, inventar, projetar, transformar, produzir, controlar, manter e usar produtos ou sistemas.

Em gerenciamento de processos (também apelidado BPM), o processo de negócio é uma sequência de tarefas (ou atividades) que ao serem executadas transformam insumos em um resultado com valor agregado.

Requisitos:

By Wikipedia:

No âmbito da engenharia, um Requisito consiste da definição documentada de uma propriedade ou comportamento que um produto ou serviço particular deve atender.

O duro trabalho do Analista

Em outras palavras, o Negócio é algo “maior”. Está diretamente ligado as maneiras que a Empresa irá operar para conseguir gerar Lucro.

O Negócio alinha-se com a estratégia da Empresa e leva em consideração objetivos a serem alcançados e os meios que devem ser satisfetios para serem atingidos. A análise do Negócio percorre toda a estrutura da Empresa.

Esta análise é a que vejo menos ser feita nos Projetos de Software. Geralmente o que acontece, é que alguém realiza análise de Processo, ou seja, realiza análise de Gatilhos e Estados iniciais de uma área ou interação de uma área, análise suas ações e suas execuções e por fim análisa as saídas que esta área oferece para suas interações.

Este é o papel do Analista de Processo: analisar os processos que as áreas das Empresas realizam e geram para atingir uma Meta de Negócio.

Basicamente, todo processo tem um Gatilho ou um Estado Inicial. O processo tem sua execução e gera insumos que podem ser gatilhos para outros processos ou estados finais com respostas.

Entenda que o papel do Analista de Processo não é menor do que o Papel do Analista de Negócio, eles apenas estão em esferas diferentes.

Geralmente, uma Empresa já tem suas Metas definidas e buscam através de Projetos ou Produtos conseguir atingi-las. Poucas Empresas eu realmente vi estarem abertas para Análise de seu Negócio para aferir o que realmente um Projeto ou Produto pode fazer por ela.

Isto toma tempo, pode revelar algumas coisas interessantes e até indesejadas, dada a burocrácia e hierarquias da Empresas atuais. Mas posso dizer que o resultado de uma Análise de Negócio é algo realmente muito interessante e bom.

Analisar o Negócio está diretamente ligado em entender todo o ambiente aonde a Empresa se posiciona: O seu Mercado de atuação, sua posição neste mercado, seu histórico, seus concorrentes e etc..

Uma vez tendo a diretriz de negócio madura, pode-se iniciar a análise dos Processos que a Empresa realiza para atingir seus objetivos.

Não quero fazer alusão a Waterfall e mostrar uma sequência obrigatória, mas realmente fica mais fácil analisar o processo tendo uma diretriz de negócio definida, talvez estas duas análises não possam correr em paralelo.

Analisar o Processo requer uma imersão e um acompanhamento próximo no dia-a-dia da Empresa. Não que a Análise de Negócio não requira isto, mas a Análise de Processo se diferencia pelo grau de imersão e proximidade junto as áreas da Empresa, o dia-a-dia mesmo.

Analisar o Processo vai de encontro a entender os “mini objetivos” que as áreas da Empresa tem, analisar a interação entre elas e ver o quão isto se alinha ao objetivo da Empresa.

Os processos buscam satisfazer alguns requisitos e eles mesmo são compostos de algumas regras. Aqui entra o chapéu do Analista de Requisitos.

A Análise de Negócio gera Requisitos de Negócios a serem satisfeitos. A Análise de Requisitos trabalha diretamente para entende-los e ver suas partes na execuções dos processos. Compreender aonde cada requisito é requerido, processado e satisfeito.

Está no trabalho do Analista de Requisitos ser capaz de descrever e validar os requisitos da solução que foram iniciados na Análise do Negócio.

Não quero aqui gerar links profundos entre uma Engenharia de Requisitos, falar em tipos de documentos, técnicas, linguagens de modelagem com o conceito geral da Análise de Requisitos. Que seja livre de quem estiver exercendo este papel escolher as melhores ferramentas para atingir seus objetivos segundo sua realidade.

Mas, basicamente, temos uma “Cebola” com três camadas que demonstram a atuação de cada papel:

A Cebola da Análise

Dentro de um Processo Ágil, estas fase podem (e devem??) ser sobrepostas, o que faz com que a pessoa que irá realizar este trabalho assuma os chapéus de cada Analista em diferentes momentos ao longo do Projeto.

Este dinamismo da troca do chapéu ajuda a causar o desentendimento de cada papel em específico.

Segundo o IIBA, todo este processo de análise pode estar contido no papel do Analista de Negócios. Eu particularmente discordo um pouco, por achar que quem é capaz de fazer isso ou é o Super Homem ou é Louco e também por ver objetivos e características mais específicos para cada perfil de Analista.

Conheço grandes Analista de Requisitos que não têm muito o perfil de estar com uma Junta Diretora de uma Empresa e ser capaz de abstrair os obejtivos de Negócio e ser capaz de compreender a complexidade do Mercado, porém é extremamente habilidoso no mapeamento, modelagem e descrição dos requisitos.

Talvez seja uma questão de experiência, talvez seja uma questão de aprendizado, mas acho que cada Analista tem sim seu perfil mais adequado.

E você, discorda? Concorda? Acredita que todos estes papéis são sim uma coisa única em tempos diferentes? Ou que esses papéis são realmente diferentes mas possíveis de ser feito por uma única pessoa?

Expresse sua opinião.

[]s.