0

EBM – Evidence Based Management Guide

O modelo de EBM, Evidence Based Management Guide ou gerenciamento baseado em evidências em português, é uma estrutura proposta pela SCRUM.ORG e Ken Schwaber não só para orientação, mas também oferece uma plataforma que gera estatísticas relacionadas a métricas de equipes, produtos e projetos ágeis.

EBM – Evidence Based Management Guide – Como melhorar continuamente os resultados de negócios, medindo o valor e usando o gerenciamento empírico.

O fundamento é que a inspeção frequente dos resultados apóia a melhoria contínua, a tomada de decisão focada em aprendizados, não só para a melhorias da eficiência operacional, mas para melhorar sua capacidade de criar valor para clientes e stakeholders.

A EBM analisa métricas e indicadores em 4 áreas de valor-chave, selecionadas caso-a-caso de acordo com a organização, todas contribuindo para a melhor percepção possíuvel e potencialização dos melhores resultados de forma iterativo-incremental-articulada.

  • Valor corrente – Mede o valor entregue ao cliente ou usuário hoje;
  • Valor Não Realizado – Mede o valor que poderia ser realizado atendendo a todas as necessidades potenciais do cliente ou usuário;
  • Capacidade de Inovar – Mede a capacidade de fornecer um novo recurso que pode atender melhor a necessidade de um cliente ou usuário;
  • “Time to Market” – Mede a capacidade de fornecer rapidamente novas capacidades, serviços ou produtos.

O objetivo é valorizar a transparência, inspeção e adaptação a partir de métricas para esclarecer a capacidade de uma organização e suas práticas de entrega de produtos. Melhoria contínua não é uma opção, é a base do Agile, ciclos consistentes de construção, aprendizado, melhoria.

A provocação é muito oportuna, há métricas de projeto e de produto, no curso de PSPO com o Alexandre Mac Fadden fica claro a percepção de que há métricas mais influenciáveis (cycle e lead time, velocidade) e aquelas menos influenciáveis (receita, acessos, downloads), categóricas.

Vale a pena baixar o manual, ler com atenção e processar as informações com atenção:

https://scrumorg-website-prod.s3.amazonaws.com/drupal/2018-09/EBM_Guide%20September%202018.pdf

0

Benchmark

É mais que analisar a concorrência, é tirar o máximo de proveito dos dados, informações e conhecimentos disponíveis sobre qualquer fonte, física ou virtual, primária ou secundária. No Design Thinking é a Pesquisa Desk, o Gartner oferece uma ideia de quadrante mágico, um eixo de inovação e execução, mas com frequência usamos planilhas comparativas de features, pontos fortes e fracos, valores e recursos necessários.

Ludicamente, é como um arquiteto ou estilistas que busca inspiração nas artes, nas ruas, revistas, hoje em dia a web é ponto de partida para tudo, mas com o cuidado de não se limitar, porque o mundo real desperta outros sentidos e percepções … eles chamam de repertorizar. Benchmark é evitar tentar reinventar a roda.

Se você teve uma ideia, o primeiro passo é pesquisar e ver quem mais a teve, a quanto tempo, quantos produtos semelhantes já estão no mercado, quais seus pontos fortes e fracos, características e estratégia adotada por suas empresas, matriz de funcionalidades, comercialização, …

Significado: “Benchmarking é um processo de comparação de produtos, serviços e práticas empresariais, e é um importante instrumento de gestão das empresas. O benchmarking é realizado através de pesquisas para comparar as ações de cada empresa. Tem o objetivo de melhorar as funções e processos de uma determinada empresa, importante aliado para vencer a concorrência, uma vez que analisa as estratégias e possibilita criar e ter ideias novas em cima do que já é realizado.”

Sempre que já existem opções, como sistema atual, alternativas, concorrentes, é preciso conhecê-los e compará-los, quer seja para não cometer erros conhecidos, como para inspirar-se naquilo que o mercado já confirmou ou rejeitou. Abaixo algumas matrizes comparativas para efeito de ilustração, entretanto benchmark pode vir na forma de um relatório ou fichas descritivas:

0

Shadowing para levantamento de mais informações

É análogo ao conceito de sombra do Design Thinking, é sentar ao lado de alguém, no dia-a-dia de uma equipe e registrar fatos e percepções. Fotografe, grave, filme, peça depoimentos, abstraia roteiros, registre pensamentos, insights, cenários principais e alternativos.

Há uma possibilidade em que terceirizamos esse trabalho, quer por motivos geográficos, volume, velocidade, então um diário pode ser confeccionado e entregue a quem fará o registro, sugerindo as mais diferentes técnicas, para ser preenchido e mantido pela própria pessoa estudada (*) ou por um observador próximo.

(*) Há uma técnica chamada diário, em que pedimos que a própria pessoa registre e mantenha tudo o que acontece durante um certo período de horas ou dia, pois ao ter que registrar provavelmente ele próprio perceberá fatos que lhe passam desapercebido em meio a rotina.

Um super-artigo sobre shadowing em pesquisa é https://www.interaction-design.org/literature/article/shadowing-in-user-research-do-you-see-what-they-see

0

One Page Change Plan

Um canvas com uma abordagem concentrada e singular, que privilegia o debate e planejamento do fluxo de distribuição, implantação e transição, eu não a uso explicitamente, mas são questões comumente trabalhadas quando estamos debatendo a pré-inception para alinhar expectativas e contextualização com stakeholders.

  • A primeira parte resume o que é, o que impacta, como será monitorado e medido;
  • O segundo bloco, intermediário, esclarece quem será impactado e como serão apoiados na mudança;
  • No terceiro bloco, o plano, a mudança e a preparação para que dê certo, além dos próximos passos.

Mais informações podem ser encontradas na página da Lean Change.Org

Uma ferramenta poderosa para um alinhamento antes e depois de um planejamento, uma canvas de amplitude para entendimento do contexto e responsabilidade:

1. Que mudança estaremos fazendo? Qual o nosso objetivo? O que queremos implementar ou mudar?

2. Por que é importante para a organização? Por que estamos fazendo essa mudança? Quais as justificativas ou mesmo benefícios?

3. Qual é e como vamos medir o sucesso? Quais as métricas e indicadores que serão utilizados?

4. Como vamos apresentar o progresso? Quas o plano de comunicação para compartilhar e validar diferentes percepções?

5. Quem são as pessoas, áreas, stakeholders afetados pela mudança? Qual o seu papel?

6. Como nós ajudaremos as pessoas na transição? Além de requisitos de transição, como potencializar, manter o foco?

7. Qual é o nosso plano em alto nível? Preparação? Introdução? Estratégia de Rollout? Retroalimentação?

0

BA Day = GUAN + IIBA

Business Analysis Day (BA Day) é um evento anual realizado pelo Chapter de Porto Alegre do Instituto Internacional de Análise de Negócios (IIBA®), com o objetivo de promover conceitos e práticas de análise e resolução de problemas de negócios mediante palestras e debates realizados por especialistas e membros da comunidade.

IIBA – International Institute of Business Analysis, Chapter Porto Alegre
GUAN – Grupo de Usuários de Análise de Negócios da SUCESU-RS

Este evento contempla uma programação de aproximadamente dez horas de atividades focadas na disseminação do conhecimento e na integração de seus participantes. O BA Day 2012 será no dia 24 de novembro, das 8h às 18h, no auditório do 9º andar da Faculdade de Administração, Contabilidade e Economia (FACE) da PUCRS, situada a Av. Ipiranga, 6681, prédio 50.

Público Alvo : Nesta edição são previstos 130 participantes (capacidade máxima do local), dentre os quais: Analistas de Negócio, Gestores de Negócio, Gerentes de Projeto, Gestores de Processo, Gestores de TI, Consultores de Gestão, Product Owners, entre outros.

Programação : A programação do BA Day 2012 foi concebida para estimular o debate entre seus participantes mediante a apresentação de cases e ideias que desafiarão suas crenças sobre o que é Análise de Negócios. As novas tendências de mercado suportadas pelo IIBA e algumas estratégias empregadas por especialistas e líderes de diferentes organizações serão utilizadas como base para a realização de quatro debates de 30 minutos cada.

O objetivo é fazer com que o participante saia do evento com ideias inovadoras para aplicar em seu ambiente de negócios. A agenda de atividades do BA Day 2012 irá contemplar palestras de 30 e 60 minutos intercaladas com debates e sessões de networking nos intervalos de café e almoço. Serão tratados e debatidos os seguintes temas:

  • Parte I – Passado, presente e futuro da Análise de Negócios
  • Parte II – Perspectivas sobre Análise de Negócios em TI
  • Parte III – Perspectivas sobre Análise de Negócios além da TI
  • Parte IV – Muito além da Análise de Negócios…

Promoção : Os primeiros 25 inscritos pagarão penas R$ 100,00! Essa promoção encerrará no dia 15 de Outubro. Do 50 ao 100 custará R$ 140,00 até o dia 29 de Outubro. Um novo valor será divulgado após 29 de Outubro.

Acesse o site de inscrições, garanta sua vaga, siga o IIBA no Twitter @iibapoa

2

Workshop Requisitos Ágeis

Ocorreu nesta noite (09/10) no prédio 50 da PUCRS (FACE) o Workshop de Requisitos Ágeis pelo Grupo de Usuários de Análise de Negócios (GUAN) com o mestre Luiz Cláudio Parzianello, colega nosso do Grupo RBS e a parceria do Filipe Sardi, presidente e diretor de tecnologia do IIBA Porto Alegre Chapter.

O evento contou com patrocínio da Target Thrust no Coffee-Break e teve quórum de mais de quase 40 pessoas, interessadas em maior entendimento das melhores práticas de requisitos em projetos de software, através de dinâmicas de elicitação e análise de requisitos de negócio, usuário, sistema e transição, na compreensão de diversos modelos de User Stories utilizados por equipes ágeis.

  • 19:30-19:45 Café de boas-vindas
  • 19:45-20:00 Abertura (sobre o evento)
  • 20:00-22:00 Workshop de Requisitos (dinâmicas em grupo)
  • 22:00-22:30 Retrospectiva do evento

Iniciou com uma apresentação do evento BA DAY, seguido de breve palestra que buscou explicar os diferentes tipos de requisitos existentes em um projetos de software, debatendo-se a forma como são tratados requisitos em ambientes ágeis, chegando a entrar no conceito de como detalhar a especificação de requisitos com base no modelo de User Stories.

O que é um Requisito?
Requisitos em Projetos de Software
Requisitos de Negócio, Usuário, Produto e Transição
Requisitos Funcionais, Não-Funcionais e Regras de Negócio
Compreendendo as Práticas da Engenharia de Requisitos
O Impacto das Metodologias Ágeis nos Requisitos de Software

Logo em seguida iniciou módulos do workshop em que trabalhamos para identificar objetivos e requisitos, de negócio, usuário e solução para um site de eventos, que suscitou participação e debate até o final, já 22:00 passadas.

Por fim, uma retrospectiva sobre o que se aprendeu, sobre a dinâmica aplicada e uma breve troca de percepções sobre o aprendizado e aplicabilidade daquilo que se aprendeu. Um breve debate sobre desenho de processos, Business Model Canvas e Lean Canvas, entre outras contribuições dos participantes.

Foram recolhidos mais de 35 Kg de alimentos não perecíveis, entregues a mim para a primeira ação com o selo “TecnoTalks – Um Ecossistema Sustentável”, comunidade de profissionais que atuam em empresas do TecnoPUC e que passarão a realizar ações comunitárias junto aos bairros do entorno da PUCRS, em especial, creches e escolinhas do Campo da Tuca e Morro da Cruz.

Leia mais sobre o evento BA DAY em https://jorgekotickaudy.wordpress.com/2012/10/10/ba-day-guan-iiba/

2

Sprint Planning “Visual”

Estava eu conversando com um colega sobre o “como” se desenrola o Planning na equipe dele e percebi que independente da proximidade e alinhamento, para qualquer uma das reuniões ágeis sempre teremos uma infinidade de execuções, cada equipe criará nuances e possibilidades variadas para se sentir bem na sua condução, usando os recursos a sua maneira.

Quadro branco

Por exemplo, eu vejo a reunião de Planning como algo 100% visual, como tudo o mais em nossas timeboxes … característica minha talvez. Tudo o que é dito no transcorrer do planning, vou colocando na parede, no quadro branco. Quando a reunião é em uma sala com pouco quadro, colo folhas brancas nas paredes.

Quadros brancos de 5 por 2 metros é um privilégio e eu teimo em utilizá-los em todo o seu potencial e extenção, mesmo que isto acabe gerando trabalho extra para mim mesmo, pois ao final tenho que reescrever tudo nos postit’s, mas faz com que tudo esteja a vista durante todo o tempo … o que é bom!

Sprint Planning Visual

Começo expondo o calendário de nossa Sprint, normalmente na extrema esquerda, seguido de um espaço para DoD (definitions of done) que irá sendo preenchido no transcorrer da reunião e um espaço para os cálculos de disponibilidade e velocidade, prosseguirei fatiando espacialmente o quadro em espaços para cada User Story, tarefas necessárias e observações.

Quem olha para o quadro, verá nele absolutamente tudo o que foi tratado em seus detalhes, acredito que é útil a todo momento, quando voltamos a algum ítem já discutido ou quando traço uma linha relacionando diferentes ítens ou observações. Também, sempre que temos a mão, colamos o desenho de interface, com as telas ou blocos que construiremos.

Sempre com minha câmera na cintura, pois fotografo todos os nossos eventos e reuniões, ao final, transcrevo para os PostIts, fotografo tudo mais de uma vez e arquivo, não necessariamente nesta ordem.Agora percebi que não tenho fotos gerais de TODO o quadro, mas neste post colei alguns pedaços do quadro para exemplificar, assim espero que tenha ficado claro meu ponto de vista.