Arquivo da tag: product owner

0

Um quadro estratégico e tático inter-equipes

|

Em uma consultoria recente os PO’s e analistas me pediram ajuda para organizar um product backlog compartilhado entre 6 equipes especialistas em suites de uma solução digital corporativa – financeiro, contábil, backoffice, etc.

Me baseei em um quadro de features por equipes do framework SAFe, onde temos cada equipe com suas features para o Train, garantindo uma visão tática por equipe x feature que dá suporte para algumas reuniões táticas e escaladas.

A necessidade era baseada em um backlog sendo priorizado por diferentes clientes e pela própria empresa para evolução e manutenção do produto. Queriamos um artefato que os ajudasse a ter uma visão clara transversal estratégica e tática para distribuição e acompanhamento.

Eu já havia ajudado a introduzir há alguns meses Scrum e Scrum of Scrums, que vinham trazendo bons resultados, mas agora os PO’s e analistas precisavam algo mais visual para o backlog nos próximos meses.

Diagramaticamente, reorganizamos os postits utilizados por eles em uma reunião recente de priorização com clientes, quando usaram um quadro de valor x esforço, com cores para 5 diferentes naturezas de ítens.

Simbolizei na imagem a principal diferenciação destacada, pois para cada time temos duas trilhas, uma para projetos (azul) e outra para sustentação (reserva técnica). O quadro visual é apenas para priorização e abstração em uma escala de tempo mensal.

O quadro ficará em um desses cavaletes com rodinhas, a granularidade dos tickets será por conveniência, coisas muito pequenas não serão representadas individualmente e o formato privilegiará selos com marcos, riscos e lembretes.

Cada postits azul representando projetos, no momento apropriado, terão sua própria inception e seu quadro de Release Plan junto ao(s) time(s) envolvidos, ficando aqui registrado apenas seus MVP’s e Releases.

O número de meses/sprints representados no quadro será um ponto de equilíbrio com foco em que o quadro facilite reuniões de estratégia com as equipes, diretoria e clientes. Também será um facilitador na mudança em curso para Agile no que diz respeito a gestão visual transversal, no plano estratégico e tático, compartilhada entre todos os envolvidos e interessados, inclusive stakeholders.

Relato GVDASA

Uma empresa de atuação nacional que vem fazendo sua transformação digital, com total apoio da alta direção, da gestão e equipes ágeis praticando Scrum, Kanban e realizando reuniões transversais seguindo Scrum of Scrums.

A mais de ano, cada equipe, desde a adoção, contando com profissionais que vem se empenhando em serem ágeis, agregar valor, evoluindo a cada ciclo, melhorando suas práticas ágeis através de experimentação x resultados.

“Já queria te dar um primeiro feedback. Recebemos um pedido de priorização de outra área, o item estava em 7º lugar no backlog, marquei um momento para discussão com os envolvidos e direção e utilizamos a técnica de comparação, ou seja o item a ser priorizado é mais importante que o 1º, 2º, 3º e assim sucessivamente. O resultado foi que todos concordaram que a priorização estava correta e deram um feedback positivo a respeito da clareza e transparência das prioridades que estão sendo trabalhadas.”

Vinicius Iager – coordenado de desenvolvimento GVDASA – Gestão educacional integrada, solução completa para a otimização dos processos acadêmicos e administrativos da sua instituição – http://gvdasa.com.br/

logotipo GVDasa

Conclusão

Não só as equipes envolvidas, mas a participação de clientes, líderes e executivos sempre é muito positivo ao se depararem com um quadro de portfólio, programa, ciclo ou Release Plan. Eles veem ali materializado seus objetivos, desejos, sonhos e expectativas.

Muito da alta pressão, “natural” em projetos de TI, é existir diferentes percepções e entendimentos relativos a prioridades e possibilidades. Ao estabelecer um quadro estratégico ou tático, toda a discussão sobre priorização (e mudanças) geram um único entendimento.

Não há regras pétrias de ticketagem (postits) ao iniciar o uso, tanto granularidade quanto diferenciação irão adaptar-se a realidade do tipo de portfólio, programa, ciclo, tecnologia, complexidade, volumes, equipes, pessoas, etc … Dê o primeiro passo, explicite e deixe que as retrospectivas se encarregarão de melhora-lo cada vez mais.

0

Agile Bi-Modal e o planejamento de projetos

|

O agilista que mais admiro e sigo é o Paulo Caroli, guru da Thoughtworks, referência ágil mundial desde o planejamento até a retrospectiva.

Em 2011 participei de um evento em que ele facilitou uma técnica de Inception para um site de CoP – elevator, objetivos, personas, jornadas, histórias, US mapping com valor x cronologia – sprints e releases.

Anos depois ele lançou a Inception Enxuta, sua técnica Direto ao Ponto surpreende pela habilidade em planejar em nível zero – elevator, objetivos, personas, features, MVPs em ondas (sequenciamento) e canvas.

Genial as duas, extremamente simples, racionais e objetivas ao que se propõem, pessoalmente acabei optando por deixar as duas na minha toolbox, as vezes uso uma, outras vezes a outra.

Fazer certo a coisa certa

Mais importante que a inception, é o trabalho prévio para enquadramento, direcionando ou não business cases, concepção estratégica, bases para que uma inception se beneficie de tudo o que já sabemos – mapas, jornadas, processos, benchmark, mapa de funcionalidades, etc.

Quando iniciamos um projeto do modo 1 como se fosse modo 2, este é o primeiro e maior desperdício, ele se propagará por meses, desconsiderando tudo o que já se sabe apenas para tentar enquadrá-lo como modo 2.

Modo #1 – Projetos com escopo de negócio claros

Participo de dezenas de projetos a cada ano, para os grandes clientes da DBserver, novos produtos tanto quanto evolutivas e pacotes de corretivas. A maioria deles temos um escopo de negócio claro, há variadas alterações durante seu curso, mas um Release Plan claro em sprints e histórias permitem amplitude de conhecimento, registro permanente de mudanças e aprendizado intenso, como por exemplo:

Um sistema de acompanhamento jurídico, com cadastro de escritórios, advogados, causas pró e contra, agenda de datas legais e de trabalho, integração com o TJ e etc. Um projeto executado em alguns meses com uma equipe enxuta, com alterações muito a nível de DoR, pois o briefing e brainstorming durante a Inception, somado ao budget e schedule, proporcionaram um projeto focado e estável em alto nível.

Um sistema de qualidade relacionado a exportação, focado na comunicação de ocorrências por clientes de outros países, gerando registro em uma base de dados, negociação, desde a abertura até o encerramento de cada caso, contando com fotos, relatos e laudos. O briefing, maturidade da equipe, budget e schedule deste também proporcionou um projeto focado e estável em alto nível.

Também soluções corporativas como de serviços adicionais, seguros ou franquias, é claro que há mudanças, mas termos uma ou duas dezenas de sprints desenhadas só trazem senso de pertença, apropriação de conceitos de negócio, principalmente nos dá visão clara de mudanças, impactos, compromisso com entrega, em contextos que valoriza-se o negócio tanto quanto há conhecimento abrangente sobre ele.

Modo #2 – Projetos com escopo de negócio variável

São em bem menor número, na maioria dos casos envolvem eventos prévios de concepção ou mesmo sprint designs, não há uma clara visão da melhor solução ou da melhor forma para executá-las, na maior parte das vezes há um objetivo de entender o primeiro passo, o mínimo produto viável, contando com algumas prints para durante esta trajetória escolher o próximo passo, fruto de construção e validações.

O case mais vivo na minha memória foi em uma solução de atendimento ao cliente com acompanhamento jurídico, de início planejamos alguns sprints, houveram muitas mudanças e aos poucos estabeleceu-se um planejamento de altíssimo nível sem sequer usar de estimativas, apenas conversávamos e a equipe estabelecia com o PO e stakeholders por onde ir e a medida que seguíamos em frente ajustava-se o backlog.

Outro case foi uma solução de apoio a gerentes de contas ou de negócios, onde de início estabeleceu-se a percepção de que não sabíamos para onde seguir e durante algumas semanas foram trabalhadas reuniões de concepção junto a diferentes personas, validando-as em mocks até que a melhor solução ficou estabelecida, completamente diferente da proposta inicial.

Fui Agile Coach por vários meses em uma aceleradora, a cada sexta-feira planejávamos os próximos passos para algumas semanas, sendo que na sexta seguinte tudo poderia mudar. Lean Startup na veia, permanentemente checando ideias, pressupostos, validando, programando algo, validando, tudo de novo, validando, … Várias startups, com nenhuma tínhamos planos maiores que algumas semanas em Kanban.

A seguir minha reinterpretação sobre a TI Bi-Modal do Gartner, ambos os modos ágeis:

1

NÃO entregar valor NÃO é opção em uma sprint

|

A cada dia em um projeto SCRUM é preciso relembrar Pareto (80 x 20), bem como buscar inspiração na técnica de caminho crítico. Desde o release plan, product backlog e sprint backlog, daily e pós-daily, review e retrô, o discurso de valor é legal, mas só vale se entregarmos valor.

Quando cito Pareto em projetos, tem o estratégico pela necessidade do cliente e usuários, o tático na complexidade e capacidade, tem o operacional de cada dia, a nível de tecnologia, requisitos, funcionalidades, regras, … temos então nossa rede mental e caminho crítico.

Pareto: A regra dos 80/20 ou Lei dos poucos vitais para muitos triviais, afirma que aproximadamente 80% dos efeitos vêm de 20% das causas. Um dos ícone do Lean, a lenda Joseph Moses Juran, sugeriu este princípio e o nomeou em homenagem a Vilfredo Pareto e seus estudos.

Áreas de Convergência/Divergência: O caminho crítico é uma sequencia de atividades que representa o caminho mais longo de um projeto. Área de Convergência é quando várias atividades devem concluir para outra iniciar, Área de Divergência é quando uma é pré-requisito de várias.

Assim como um bom gerente de projetos, uma equipe ágil lida diariamente com a possibilidade de tomada de decisões relacionadas a riscos, rede, fragmentação, inclusão e exclusão de atividades, paralelismo e sequenciamento, recursos essenciais para auto-organização e sucesso.

Em uma liberdade poética, trago uma rede e seu caminho crítico propostas pela UniversoProjeto para discutir conceitos de caminho crítico, não representa a estratégia de histórias e tarefas em uma sprint mas é didática quanto a caminho crítico e áreas de convergência e divergência:

Em Agile, cada história possui sua rede no sprint, gerando um desafio tático diário ao time, como na abstração que montei logo abaixo … a entrega do mínimo valor (vitais) de qualquer história não pode ser comprometida em função de entregas triviais de outras histórias:

Diariamente, a cada novo fonte, objeto, classe ou método é preciso perceber o caminho crítico e lembrar de evitar triviais antes de vitais, valorizando eliminar gargalos e garantir entregas antecipadas, parciais, essa é a nossa missão: Entregar valor!

As vezes usamos de dissonância cognitiva para justificar o porque não vai ser possível, esquecendo de se utilizar de uma visão holística, onde o todo é composto de partes … equipes ágeis de alta performance esforçam-se em entendê-las e tomam decisões para garantir entregas e valor.

Acredite, adaptar-se não é resignar-se a inevitabilidade das mudanças, é diariamente mitigar, contornar, fracionar, eliminar ou reduzir áreas de convergências e divergência, focar na essência, de forma que a adaptação não seja a negação do valor, mas a confirmação dele.

Cada SPRINT é um pacto por valor a ser entregue

Planejado na inception e materializado no product backlog, a sprint backlog é um pacto gerado pelo time entorno do mix de domínio, conhecimento, expertises e percepções de todos, levando em condição valor, prioridade, complexidade, riscos e oportunidades.

A cada Daily e pós-Daily, nossa missão é repactuar o sucesso de nossas entregas, mitigando riscos, sempre focados no mínimo entregável de valor suficiente, sempre investindo no vital e questionando o trivial, justificando assim o porque do método ágil que praticamos.

Na medida que o sprint avança, a responsabilidade e necessidade de planos de ação e responsabilidade na aplicação de árvores de decisões vais tornando-se cada vez mais premente. No 1° dia, 2° e 3° temos mais opções, a partir do 4° e do 7° temos menor margem para manobras.

Estudo de caso: Em um cenário adverso, no segundo dia foi discutido opções e assumidos certos riscos, no quarto dia já é preciso concentrar esforços e no sétimo dia muitas vezes temos que tomar decisões difíceis, mas responsáveis frente ao compromisso de entrega de valor.

Para ser mais claro, quando falamos no sprint planning sobre compromisso com a excelência combinada, características funcionais otimizadas, regras, automações, camadas, etc, isto NÃO pode ser mais importante que a entrega, validação com o cliente, fluxo e cadência.

Se decisões tiverem que ser tomadas, ok, vamos depois discutir o porque foi preciso, vamos aprender com elas, vamos nos esforçar por melhorar nos próximos sprints, vamos incluir a discussão sobre o resgate e refatoramento do gap entre o que foi previsto versus o que foi feito.

Falando em valor e sprints, cuidado com o que promete, pois és responsável por quem cativas e NÃO entregar o máximo de valor a cada sprint NÃO é opção! O desafio e a solução todos terem este princípio em mente, sem stress, mas antenados ao máximo de entregas de valor.

Nossa linguagem ubiqua foca em valor para o cliente, se você mesmo assim não abre mão de atrasos por excelência técnica, em detrimento de valor antecipado, validação e aprendizado – PDCL – Desculpa, mas talvez seja uma linguagem ambigua e não ubiqua.

Se leu até aqui, tenho certeza que vai curtir ler esse outro, garantcho:  https://jorgeaudy.com/2014/11/04/divida-tecnica-um-mal-necessario-mas-nao-e-um-carma/

0

A equação CAPEX += OPEX é essencial para bons gestores e equipes

|

Quer na vida, empresa, futebol, política, é preciso entender o valor de trabalhar com equilíbrio entre metas de curto, médio e longo prazos, desdobramentos, ganhos e perdas. O brasileiro trata CAPEX e OPEX em suas empresas da mesma forma que gerencia times de futebol ou política, muitas vezes imediatista, oportunista, pró-geração de factóides.

Não entendam o tom de meus posts como acusatórios, são situações que nos circundam em diferentes graus, o que precisamos as vezes é um balde de água gelada para se propôr a debater com mais realismo as consequências de atos nossos (conscientes ou inconscientes). A equação certa é CAPEX += OPEX, significa CAPEX = CAPEX + OPEX.

CAPEX (expenditure) ~ despesas ou investimentos em bens de capital; despesas de capital; aquisições.

OPEX (operational expenditure) refere-se às despesas operacionais, recorrentes, continuadas.

CAPEX é investimento, aquisição, projeto, mas cada tomada de decisão ali pode aumentar ou diminuir sua OPEX, custo recorrente de operação que muitos geram como a maldição da múmia. Um projeto mal feito, imediatista, enrolada em retalhos, terá que ser mantido com doses maciças de recursos super-dimensionados por anos para fazer frente a tudo o que não foi feito em alguns meses mal geridos de projeto.

Sempre cito paradigma e risco da Teoria da Agência, pois ‘empresa’ não existe, existem CEO, VP’s, diretores, gerentes, profissionais, as vezes inconscientemente com foco em objetivos pessoais ou zona de conforto. Projetos precisam ter no radar uma visão de longo prazo, evitando acordos onde todos se beneficiam, menos a empresa.

Reflexão: Estudos sobre Linha de Produto de SW demonstram um custo inicial para a absorção e qualificação, sendo mais oneroso começar a fazer diferente do que fazer mais do mesmo, até um breakeven, quando então passamos a obter os resultados melhores desejados, cumulativamente, cada vez mais – Vale para muitas técnicas e tecnologias!

lps_figura1

CAPEX e OPEX – ESTUDOS DE CASOS HIPOTÉTICOS

Um projeto de software construído sob muita pressão pode gerar elogios, bonificações e promoções pelo CAPEX, mas com práticas inconsequentes afetando sua OPEX. Um projeto construído com muita pressa, pode ganhar elogios, mesmo com tecnologia inadequada, desde que atenda a necessidade. Tem até casos em que não se documenta de forma mínima, não se automatiza o mínimo, nem qualidade ou valor necessários.

Há uma infinidade de histórias hipotéticas, ardilosas ou inconscientes, envolvendo ingenuidade, miopia, interesses, medo de argumentar, zelo pela estabilidade, falta de comunicação, não saber ouvir, vício em protagonismo individual e suas benesses no modelo de gestão 1.0 onde fazer exatamente o que mandam gera recompensas.

Bons indicadores são alto custo de manutenção, dimensionamento absurdo de equipes de sustentação, delay entre identificação de corretivas e evolutivas até a execução e entrega delas, quando ajustes simples exigem desproporcional esforço, novos projetos comprometidos em um ciclo viciosos de legados e deficiências coisas do passado.

Em muitos casos as empresas sequer fazem esta ilação CAPEX += OPEX, como se uma nada tivesse a ver com a outra … mas estes impasses não sobrevivem a um bom estudo de cadeia de valor. Rasgar dinheiro até é possível em tempos de bonança, mas na crise eles estarão tão imersos em soluções mal construídas que sua OPEX irá cobrar o preço.

593861c6-2213-457e-aece-17e588847be7

É fácil ser perdulário e inconsequente durante a bonança, complicado é olhar para trás e perceber que milhões desperdiçados no passado estão fazendo falta. Na hora do aperto é possível reduzir a CAPEX, reduzir sua capacidade em evoluir, mas impossível reduzir uma OPEX contaminada sem comprometer a operação, o cliente e sua imagem.

Há algo tão ruim quanto o alto custo evitável de OPEX, é quando CAPEX gera novas CAPEX, quando a cada par de anos temos que reconstruir soluções mal feitas, que acaba virando uma colcha de retalhos e exige reconstrução. Um projeto que não atende a real necessidade, um produto mal feito que não pôde ser escalado ou evoluído.

Planejamento ágil, sinérgico, ciclos iterativo-incrementais-articulados, em camadas, com boas práticas de engenharia de software, testes automatizados, devops, com equipes auto-organizadas pesando cada decisão quanto ao ponto de equilíbrio entre qualidade e valor para o negócio, geram também valor no médio e longo prazos às partes.

Nosso trabalho encarece ou mitiga a equação CAPEX += OPEX, cada decisão tomada durante um projeto irá tender a uma OPEX mais alta ou mais baixa. As decisões em um projeto com CAPEX bem dimensionada e racional pode levar a uma OPEX recorrente como no cenário #1, #2, #3 ou #4 … isto pode ser uma escolha consciente ou inconsciente.

A pergunta é: Nossas decisões estão economizando tempo ou custo ou mesmo escopo e gerando uma OPEX #1? A brincadeira que faço em meus cursos é: quem ligaria para o diretor presidente da empresa e argumentaria caso isso tornasse-se explícito? Na maior parte das vezes, líderes diriam que não tinha a menor ideia que nossas decisões levavam a tamanho impacto … afinal, no Lean, GEMBA tem direitos e deveres, a responsabilidade de argumentar, advertir sobre a OPEX, por incrível que pareça, também é nossa.

O tom deste post é provocativo, precisamos compreender o oportunismo na Teoria da Agência, o mimetismo na Teoria Institucional, sócio-técnica, trilogia de Juran, capacidade absortiva, contingencial, GC no modelo SECI e de exploitation x exploration, acredito muito em entender Teorias da psicologia e sociologia que tanto nos envolvem e citam, dá uma olhada no eBook “sobre os ombros de gigantes“.

0

TTalks – Keep Calm and Trust Your Product Owner

|

Hoje rolou o quinto dia de evento TecnoTalks 2017, os três primeiros foram três abordagens sobre planejamento de carreira, networking, meninas na TI e uma oficina, o quarto foi sobre o papel de Scrum Master e o quinto hoje foi o papel de Product Owner.

Nenhum dos cinco possui uma receita de bolo, mas todos os cinco contaram com muita gente boa, com muitos debatedores e participantes com muita experiência no assunto da rodada. As técnicas e formato a cada dia foi diferente e mesmo quando igual, melhorado ou tentamos melhorar …

O evento desta noite “Keep Calm and Trust Your Product Owner” discutiu no mesmo formato de ontem, pequenos grupos propuseram temas que desejavam discutir, clusterizamos (agrupamos sugestões semelhantes) e os clusters que tiveram mais votos foram o próprio papel e outros papéis alinhados a negócio, seguido de questões pertinentes a definição, prioridade e mudanças … valor.

20170210_002509

A primeira parte gravada em Face Live focou no que é o papel do Product Owner e o quanto outros papéis acima ou abaixo de sua alçada foram se compondo com o passar do tempo, como Chief PO, Business Owner, Analista de Negócios, entre outras siglas e funções.

O que mais se destacou no meio da discussão é o quanto diferentes contextos nos permitem defender uma abordagem, mas não que seja o melhor em qualquer contexto, há muitas diferenças que geram reflexos na melhor opção de perfil e atuação do PO, time e papeis adjacentes.

Continuação, porque minha bateria acabou, neste momento mais focados na abordagem de business, de tomada de decisão, responsabilidade na definição, mudança, negociação, para entrega de valor a cada sprint, release, até o final do projeto. Iterativo-incremental-articulado!

Novamente a discussão não era para achar uma receita de bolo ou solução mágica, mas compartilhar vivências e debater ideias, experiências e convicções, de forma que cada um dos participantes pudessem levar um mix de informações e oportunidades, acoplando a sua realidade conforme aderência e possibilidades.

Continuação parte II, porque me atrapalhei e encerrei o vídeo, mas a Andrea Balle percebeu e começou a compartilhar na sua timeline, ainda no tópico valor para o negócio, adaptação a mudanças necessárias, ROI, …

 

Ao final da noite registramos com uma foto oficial, alguns já tinham saído, mas a maioria marcou presença na foto de fechamento:

20170209_213728p

Link compartilhado pelo Parzianello – 7-skills-to-be-a-great-product-owner

Link compartilhado pelo Motta – PO-x-BA-x-analista-de-sistemas

0

Evento GUAN de 18/07 vai ter BDDWarriors

|

No dia 18/07/2016, uma segunda-feira as 19:00 na FACE da PUCRS, a previsão do tempo prevê frio do lado de fora e o GUAN promete calor do lado de dentro, contando com palestras e o game BDDWarriors.

Um evento voltado ao aprendizado experiencial e prático, onde eu vou falar de metodologias e técnicas, o Abílio mostrará um passo-a-passo do valor de BDD, desde a escrita até o código de testes gerado, a Ana Hermann aplicará o jogo BDDWarriors usando seus baralhos e tabuleiros novinhos em folha.

A abertura será com a Mayra falando sobre a técnica de modelagem e planejamento de MVP chamada Direto ao Ponto, tendo desde o início o Cesar Coutinho e Carlos Giovani do GUAN e IIBA na batuta … quem for vai curtir e aproveitar:

13620162_10201889117545642_1516575296644280194_n

http://www.sucesurs.org.br/evento/toolkit-do-analista-de-negocios-com-jorge-audy-e-convidadas

Teremos o sorteio de duas inscrições para a palestra sobre Data Science puxado pelo Felipe Cabral lá no Nós Coworking – http://www.eventick.com.br/data-science

Untitled

1

BA DAY – Turno da Tarde

|

Se voce não leu o post sobre o turno da manhã, sugiro fazê-lo antes de ler o turno da tarde [clique aqui], o almoço foi no prédio 40, no Panorama.

14:00 – Suzandeise Thomé, consultora da Interdual, com a palestra “Fazer Análise de Negócios somente dentro da TI é tarde demais!”. Uma abordagem interessante em que temos uma analise de negócios micro e outra macro.

Citou como pressuposto que temos sempre um demandante e um fornecedor, mas há uma questão histórica onde existe uma grande falta de alinhamento de expectativas entre o fornecedor (TI) e o demandante (cliente) – “Golfinho e ser humano, dois seres inteligentes, mas que não falam a mesma lingua”, uma forma divertida para ilustrar uma comunicação ineficiente.

Ela escreveu o livro “TI para Negócios 2: Como aumentar o retorno do seu investimento em tecnologia e gerar lucro“, com provocações em que aponta a necessidade de um novo paradigma em que o cliente assuma a sua real responsabilidade e a inutilidade de tentar repassar ela toda a TI como é feito.

  • A responsabilidade é do demandante
  • Ele é que deve explicar a necessidade
  • Ele deve exigir “agilidade” da TI
  • Não esperar receber análise gratuita durante a etapa de proposta
  • Deve montar um business case
  • Deve ter em sua equipe o analista de negócios
  • O valor da AN é o resultado final atingido com sucesso

Mais que isto, entrando no mérito da questão, é tarefa deste analista de negócio conhecer e escrever as regras do negócio, descrever os requisitos e gerenciar os seus projetos, assim como montar os seus business cases. Pode chamar ou não o profissional que o faz de analista de negócios, mas a responsabilidade é sua.

Traduziu “Start At The End, with SMART requirements” de Willen Dijkgraaf.

A seguir um vídeo da Suzandeise Thomé, para quem não foi conhecê-la:

14:40 – Rodolfo Canonico e Thais Dalcin, consultores de gestão do Grupo RBS, apresentaram o case “Análise de Negócios na Consultoria de Gestão do Grupo RBS”. O case apresentado é do grupo de consultores montado pelo VP de Gestão e Pessoas Deli Matsuo para atender os diferentes veículos e empresas do grupo, fórmula de sucesso que ele trouxe do Google.

Os dez consultores que compõe o time, utilizam-se de análise de negócios e técnicas ágeis para apurar o entendimento e coach junto aos gestores e suas equipes, a cada projeto, usando todo tipo de conceitos e habilidades:

  • Lean StartUp
  • Teste de hipóteses
  • Pilotos
  • Linguagem Ubiqua
  • Prototipação
  • Business Cases
  • Análise de risco
  • Análise de viabilidade

Aproveito para incrementar o link da palestra proferida pela Thais junto com o Parzianello no Agile Brasil e no GUMA Agile Day – Implantando a Cultura Ágil em Larga Escala no Grupo RBS

15:20 as 16:00 houve um debate interativo dos palestrantes com o público.

16:30 – Sergio Schaumloeffel, do PGQP – Programa Gaúcho da Qualidade e Produtividade, palestrou “Entendendo a Busca da Excelência em Gestão” que citou uma boa frase: “O futuro tem um péssimo hábito, ele chega de repente!”, querendo dizer que devemos sempre estarmos aprendendo e preparados.

Eu posso dizer que fiquei impressionado com as proporções do PGQP, a convergência com muito do que falamos sobre boas práticas ágeis e da absoluto domínio e desenvoltura demonstrados pelo Sergio, que era da Stihl e que atualmente atua como consultor. Nota 10!

  • 10 Mil organizações com termo de adesão
  • 15 Mil agentes multiplicadores
  • 1,3 Mil pessoas envolvidas
  • +600 organizações premiadas
  • 100 entidades na liderança
  • 300 Mil pessoas capacitadas

As empresas vivem em um ecossistema, sob um contexto econômico, social, tecnológico e ambiental, sob o estigma da incerteza, onde recomenda-se buscar apoio em alguns principios:

  • Horizonte de aprendizado contínuo
  • Organizações são sistemas vivos
  • Redes dinãmicas e abertas
  • Qualidade das relações
  • Sustentabilidade
  • Ecossistema
  • Excelência

17:10 – Luiz C. Parzianello, presidente do IIBA Chapter Porto Alegre, palestrou sobre a análise de negócios na melhoria contínua e gestão das mudanças organizacionais, sobre a percepção sobre a inter-relação entre as diferentes áreas de conhecimento da Análise de Negócios.

Palestra brilhante sobre o que é, sobre o presente e o futuro da análise de negócios, com links diretos para as demais palestras do dia, encerrando com um debate geral sobre o tema.

A seguir alguns links de palestras e o blog do Parzianello:

17:50 as 18:30 houve um debate interativo dos palestrantes com o público.

18:30-19:00 Encerramento