Você está na página 1de 76

FLEKS HYBRID MODEL

MODEL

Criado e mantido por Hélio Rodrigues Costa


Versão 1.0 2020

© 2020 Hélio Rodrigues Costa. oferecido para licença sob Attribution-NonCommercial-NoDerivatives


4.0 Internacional of Creative Commons. Você pode acessar e ler livremente a licença em https://
creativecommons.org/licenses/by-nc-nd/4.0/. Ao utilizar o Guia do Modelo Hibrido FLEKS, você reconhece e
concorda com os termos da licença.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com
FLEKS HYBRID MODEL

ÍNDICE
INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Objetivo do Guia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Reconhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Definição do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Gestão Híbrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Ambiente BRIGHT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Pilares do Modelo FLEKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Valor e suas Medidas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Ciclo de Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Variáveis de Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Mindset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Princípios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Visão Geral do Modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ORGANIZAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
A Identidade Organizacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Sustentabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Estratégia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Objetivos Estratégicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Gestão da Mudança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

VALUE MANAGEMENT OFFICE . . . . . . . . . . . . . . . . . . . . . . . . . 19


Governança . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Gestão de Riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Gestão de Conhecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Definição de OKR (OBJECTIVES AND KEY RESULTS) . . . . . . . . . . . . . . 22
Seleção de Iniciativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Definição de KPI (KEY PERFORMANCE INDICATORS) . . . . . . . . . . . . . . 24
Revisão de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

PRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Análise de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Camada de Gestão de Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Camada de Gestão de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Camada de Gestão de Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

FLUXO DE VALOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
O Fluxo Descendente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
O Fluxo Ascendente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
FLEKS HYBRID MODEL

EVENTOS DA ANÁLISE DE NEGÓCIO . . . . . . . . . . . . . . . . . . . . 35


Análise da Necessidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Ideação da Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Definição de Valor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Desenvolvimento do Business Case . . . . . . . . . . . . . . . . . . . . . . . . . 39

EVENTOS DA GESTÃO DO PORTFÓLIO . . . . . . . . . . . . . . . . . . 41


Planejamento do Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Reunião de Coordenação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Reunião de Revisão do Portfólio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Reunião de Retrospectiva do Portfólio . . . . . . . . . . . . . . . . . . . . . . . 47
Subportfólios e Programas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

EVENTOS DA GESTÃO DE PROJETO . . . . . . . . . . . . . . . . . . . . . 49


Planejamento do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Reunião de Início do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Reunião de Revisão do Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Reunião de Retrospectiva do Projeto . . . . . . . . . . . . . . . . . . . . . . . . 52
Reunião de Encerramento do Projeto . . . . . . . . . . . . . . . . . . . . . . . 52

EVENTOS DA GESTÃO DE PRODUTO . . . . . . . . . . . . . . . . . . . . 53


Planejamento do Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Planejamento do Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Revisão do Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Planejamento da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Reunião da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Revisão da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Retrospectiva da Iteração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

BACKLOG, ESTIMATIVAS E TIMEBOX . . . . . . . . . . . . . . . . . . . . 63


Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Estimativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Timebox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

MONITORAMENTO E CONTROLE . . . . . . . . . . . . . . . . . . . . . . . 66

PAPÉIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Gerente do VMO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Analista de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Gerente de Portfólio, Subportfólio e Programa . . . . . . . . . . . . . . . 71
Gerente de Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Gerente de Produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Equipe de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

NOTAS FINAIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Ferramentas de Suporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Colaboradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
FLEKS HYBRID MODEL

INTRODUÇÃO

OBJETIVO DO GUIA

O objetivo deste guia é explicar o que é o Modelo FLEKS de Gestão Híbrida, como implementá-
lo e ajudar os usuários a manter as melhores práticas de gestão organizacional utilizando
uma abordagem híbrida.

RECONHECIMENTO

O Modelo FLEKS de Gestão Híbrida é baseado em diferentes fontes, tais como padrões,
frameworks, corpos de conhecimento e outros modelos disponíveis na literatura e no
mercado. O modelo foi criado por meio do empirismo e, como será observado ao longo do
guia, alguns nomes originais das fontes citadas acima foram alterados, processos e papéis
adaptados, resultando em uma abordagem diferenciada. O guia está pronto para ser usado e
evoluído por meio de novas experiências dos praticantes. Reconheço também a importância
de todos que, de muitas formas, contribuíram para transformar este guia em realidade.

DEFINIÇÃO DO MODELO

O Modelo FLEKS de Gestão Híbrida é uma abordagem de gestão organizacional, que visa
fornecer suporte a implantação de uma estrutura, processos, técnicas e ferramentas que
permitem uma rápida adaptação às mudanças de mercado e ambiente, criando um fluxo
contínuo e sustentável de valor para seus stakeholders, por meio de iniciativas geridas de
forma híbrida.

INTRODUÇÃO \\ 4
FLEKS HYBRID MODEL

GESTÃO HÍBRIDA

A Gestão Híbrida é uma ampla área de estudo em que


organizações e equipes aplicam processos, técnicas, ferramentas
e práticas de diferentes abordagens preditivas e adaptativas.

A ideia é aproveitar as melhores práticas e criar uma maneira mais adequada de gerir
organizações, portfólios, projetos e produtos. Para efeito desse guia, considera-se uma
abordagem híbrida a que utiliza a combinação de práticas preditivas e adaptativas de forma
simultâneas e não apenas combinações de abordagens puramente preditivas ou adaptativas.

As abordagens preditivas contribuem com processos de gestão mais estruturados e fornecem


algum grau de previsibilidade à organização, enquanto as abordagens adaptativas agregam
leveza e adaptabilidade e tornam a gestão mais enxuta. Utilizadas conjuntamente, podem
produzir um ambiente controlado e adaptável para atingir os objetivos organizacionais.

Desta forma, o uso de abordagens híbridas mostra-se útil para fornecer o equilíbrio certo
e aproveitar o melhor dos dois mundos, sendo possível sua utilização em qualquer tipo de
negócio, tamanho de organização ou indústria, visto que possuem fleksibilidade suficiente
para se adaptar a diferentes contextos e permite que gestores, equipes e outros stakeholders
estejam abertos a mudanças, o que é típico de um ambiente incerto no mundo atual.

INTRODUÇÃO \\ 5
FLEKS HYBRID MODEL

AMBIENTE BRIGHT

Atualmente, as organizações estão inseridas em um ambiente complexo e em constante


mudança. Elas precisam adaptar-se constantemente e rapidamente para sobreviver e ter
sucesso. Em vários contextos, esse ambiente pode ser resumido pelo acrônimo BRIGHT.

l BLURRY (OBSCURO): algo sobre o qual a forma ou formato não está claro.

l RISKY (ARRISCADO): envolve a possibilidade de algo incerto acontecer

l INTERCONNECTED (INTERCONECTADO): conectados ou relacionados entre si.

l GLOBAL: relacionado ao mundo inteiro.

l HI-TECH (TECNOLÓGICO): orientado e dependente de tecnologia avançada ou sofisticada.

l TIMELY (OPORTUNO): acontecendo no melhor momento possível.

Nesse sentido, é difícil definir os limites de algumas organizações, o que elas fazem, onde fazem,
quem são os clientes, seus produtos e limites de operação (BLUR). Existem muitas incertezas que
transformam a tomada de decisão em uma tarefa difícil (RISKY). Organizações e pessoas são cada
vez mais dependentes umas das outras em termos de necessidades e apoio (INTERCONNECTED).
Muitas empresas não são mais locais. É necessário pensar e agir globalmente para prosperar
(GLOBAL). A tecnologia está inevitavelmente presente na vida de pessoas e organizações. Às
vezes, seu uso é o núcleo do próprio negócio (HI-TECH). A gestão do tempo é fundamental para a
sobrevivência, além de estar sempre um passo à frente e antecipar ações (TIMELY).

PILARES DO MODELO FLEKS

INTRODUÇÃO \\ 6
FLEKS HYBRID MODEL

A FLEKSIBILIDADE está no coração do modelo. Em um ambiente BRIGHT, gerentes e


organizações devem entender que quanto mais fleksíveis seus planos e processos, mais
robustos eles se tornam, pois têm mais chances de adaptarem-se às incertezas inerentes
aos negócios, que exigem fleksibilidade e adaptação.

A INTEGRAÇÃO é o segundo pilar no


qual o modelo baseia-se. Nada funciona
A gestão de um produto,
separadamente. Pessoas, processos, recursos.
projeto, programa, portfólio
Tudo deve ser pensado como um único corpo.
ou mesmo uma organização
Este conceito fornece força e senso de unidade.
deve ser feita com uma visão
O terceiro pilar é a COMUNICAÇÃO. A sistêmica e integrada.
comunicação está em toda parte e todos
precisam dela. Encontrar melhores maneiras
de comunicar-se, compartilhar informações, conhecimentos e experiências com as pessoas
certas, no momento certo e no formato certo é a melhor maneira de estabelecer um bom
relacionamento e melhorar a cooperação. Um ambiente seguro em que as pessoas se sintam
livres para se expressar e se comunicar gera transparência e melhora o clima organizacional.

Finalmente, o último pilar são as PESSOAS. Projetos e produtos são feitos por pessoas e para
pessoas. É necessário ter empatia pelas pessoas envolvidas nos processos organizacionais e
clientes para que suas necessidades reais sejam compreendidas e supridas. Gerentes, como
líderes, devem ter um objetivo em mente: transformar a vida de todos para melhor. Para
isso, devem escutar as pessoas atentamente e encontrar maneiras de fazer diferença em
suas vidas.

VALOR E SUAS MEDIDAS

Assim sendo, é altamente recomendável


entender como o valor é definido e
O Modelo FLEKS é direciona-
como medi-lo, que pode ser tanto
do para a criação contínua e
quantitativamente, quanto qualitativamente.
sustentável de valor.

No que se refere à forma quantitativa de


medição, valor é definido como a relação
entre os benefícios e o custo total usado para obter os benefícios, ambos medidos em
unidades financeiras. O custo total pode ser entendido como dinheiro, pessoas, materiais,
equipamentos, instalações e infraestrutura. É consenso que, para o mundo dos negócios,

INTRODUÇÃO \\ 7
FLEKS HYBRID MODEL

quanto mais quantitativos forem os dados, mais fácil será o processo de tomada de decisão.
Se a opção é medir o valor quantitativamente, é possível fazê-lo de maneira absoluta ou
relativa, como pode ser observado pelas fórmulas abaixo.

Também é possível incorporar o grau de incerteza para obter o valor. Nesse caso, é necessário
multiplicar o valor pela probabilidade de materializá-lo.

No entanto, esses dados quantitativos nem sempre estão disponíveis ou não valem o esforço
de serem obtidos. Nesse caso, o Modelo FLEKS sugere o uso da matriz mostrada abaixo à
esquerda. Se alguém quiser incorporar o grau de incerteza à medida qualitativa do valor, é
possível definir a incerteza por meio de cores, conforme a figura abaixo à direita. O quadrado
vermelho significa baixa probabilidade de materializar o valor, o quadrado amarelo significa
probabilidade média e o quadrado verde significa alta probabilidade.

INTRODUÇÃO \\ 8
FLEKS HYBRID MODEL

CICLO DE VALOR

O valor possui um ciclo de gestão, e como tal,


necessita da cooperação de toda a organização
e das equipes para ser adequadamente
tratado. O ciclo é dividido em quatro etapas
diferentes, como mostrado abaixo. É
importante mencionar que este ciclo deve
ser gerido para toda a organização, para
o seu portfólio, um programa, um projeto
um produto ou componentes menores de
incrementos de valor.

l DEFINIR: quando o valor é definido para


um portfólio, programa, projeto, produto
ou qualquer incremento de valor.

l CONSTRUIR: ocorre durante o desenvolvimento do


incremento de valor.

l MEDIR: é a ação de verificar com os stakeholders se o valor definido anteriormente


foi realmente entregue.

l ADAPTAR: é o conjunto de ações necessárias para redirecionar a gestão em caso de


discrepâncias, novas percepções e prioridades em relação à entrega de valor.

O objetivo principal aqui, é sempre manter a criação de valor em mente e sob vigilância, pois
esse é o núcleo do modelo. Existem vários níveis de gestão de valor, seja organizacional,
de portfólio, programa, projeto ou produto. No entanto, independentemente do nível de
gestão que se esteja, gerentes e equipes devem trabalhar juntos e de forma corresponsável,
usando suas distintas capacidades técnicas, contextuais e comportamentais para que juntos
os objetivos sejam atingidos.

VARIÁVEIS DE VALOR

Para criar valor é necessário manipular diversas variáveis. O Modelo FLEKS defende que é
crucial observar e analisar algumas delas. O objetivo principal é criar o maior valor, gerindo
essas variáveis na melhor combinação possível. Gerentes e equipes devem ter em mente
que é muito importante pensar de forma integrada, ou seja, ao alterar os parâmetros de uma

INTRODUÇÃO \\ 9
FLEKS HYBRID MODEL

variável, uma ou mais serão obrigatoriamente alteradas, criando a necessidade de ajustes,


em prol da integração. As variáveis são:

l ESCOPO: o que deve ser feito para criar o


valor.

l TEMPO: a quantidade de tempo


necessária para criar o valor.

l CUSTO: a quantia monetária


necessária para criar o valor.

l QUALIDADE: o padrão de qualidade


necessário que um produto deve ter.

l RISCOS: os riscos identificados


(positivos e negativos) para atingir os
objetivos e criar o valor.

l RECURSOS: pessoas, materiais,


equipamentos, instalações e infraestrutura
necessária para criar o valor.

Como pode ser observado, as seis variáveis orbitam em torno do valor e serão usadas para
planejar como o valor será criado. Em caso de discrepância do planejamento e da realidade
observada, as variáveis devem ser reorganizadas para entregar o valor acordado para os
stakeholders. Esta é uma premissa importante por trás do FLEKS. Durante um processo de
gestão, algumas variáveis podem ser mantidas estáveis por uma questão de planejamento e
controle, mas se algumas delas precisarem ser alteradas para entregar o valor e isso estiver
de acordo com os principais stakeholders, é possível torná-las fleksíveis.

MINDSET

Para aplicar o Modelo FLEKS


adequadamente, é altamente
Um mindset pode ser definido como um
recomendável que toda a
conjunto de pensamentos e crenças que
organização, as equipes e demais
moldam a forma com que uma pessoa
stakeholders tenham seu mindset
ou grupo de pessoas se comporta e toma
firmemente estabelecido, a fim de
decisões em diferentes situações.
criarem um ambiente poderoso
para a criação de valor.

INTRODUÇÃO \\ 10
FLEKS HYBRID MODEL

O mindset correto acolhe desafios, bem como coisas novas e diferentes em nossa vida.
Pessoas com mindset de crescimento aprendem umas com as outras e acreditam que é
necessário muito trabalho para conseguirem o que querem. Além disso, elas reconhecem
falhas e erros como oportunidades para aprenderem e reconhecerem suas fraquezas, mas
estão sempre focadas em transformá-las em pontos fortes.

O Modelo FLEKS defende cinco atitudes e comportamentos para facilitar o desenvolvimento


do mindset desejado: Foco, Customização, Trabalho em Equipe, Aprendizado e Adaptação.

l A organização e as equipes precisam do FOCO para obter melhor desempenho e


fornecer os melhores produtos com uma velocidade sustentável.

l CUSTOMIZAR e simplificar os processos o máximo possível, sem comprometer o


controle desejado.

l TRABALHO EM EQUIPE é a chave para manter as pessoas unidas e comprometidas


com o alcance dos objetivos.

l A organização e as equipes devem APRENDER o máximo possível para melhorar a


qualidade e promover o crescimento.

l Medir e obter feedback é o caminho mais rápido para ADAPTAÇÃO.

PRINCÍPIOS

A gestão, no nível mais fundamental, é uma disciplina que consiste em um conjunto de


habilidades e conhecimentos diferentes que alguém possui e aplica para alcançar objetivos
previamente definidos.

INTRODUÇÃO \\ 11
FLEKS HYBRID MODEL

São fatores essenciais que formam a base


de uma gestão de sucesso. São os meios
De um modo geral, princípios de
pelos quais alguém realmente realiza a
gestão são diretrizes amplas para
gestão, em outras palavras, conclui tarefas
a tomada de decisões gerenciais e
por meio de atividades como planejamento,
comportamentos.
organização e controle de pessoas, além de
recursos financeiros e materiais.

O Modelo FLEKS possui alguns princípios considerados sine qua non (essenciais) para
ajudar o processo de gestão no desafio de liderar pessoas, criar valor e conduzir portfólios,
programas, projetos, produtos e alcançar seus objetivos.

l GESTÃO DE VALOR: a criação de valor é o principal fator de sucesso e deve sempre


ser perseguida.

l GESTÃO PROGRESSIVA: o planejamento, a execução e o controle por etapas ajudam


a obter conhecimento, adaptação e minimizam os riscos.

l INTEGRAÇÃO E EQUILÍBRIO: todos os elementos de valor devem ser integrados e


equilibrados para entregar produtos de acordo com a prioridade e necessidade dos
diversos stakeholders.

l LIDERANÇA SITUACIONAL: os gerentes devem adaptar as ações de liderança de


acordo com o contexto.

l MELHORIA CONTÍNUA: as lições aprendidas devem ser aplicadas para melhorar os


processos de gestão e desenvolvimento de produtos.

l PLANEJAMENTO FLEKSÍVEL: os planos devem ter algum grau de fleksibilidade para


enfrentar incertezas e ajudar na tomada de decisões.

l PAPÉIS E RESPONSABILIDADES: papéis são definidos, toda a equipe conhece suas


responsabilidades e está comprometida com elas.

l COMUNICAÇÃO ABERTA: os canais de comunicação devem estar abertos para


facilitar a troca de informações e a transparência.

INTRODUÇÃO \\ 12
FLEKS HYBRID MODEL

VISÃO GERAL DO MODELO

O Modelo FLEKS compreende quatro grupos distintos para orientar organizações que irão
utilizá-lo. O modelo foi criado para ser o mais fleksível possível, mas assume-se que os
conceitos apresentados neste guia devem ser seguidos para fornecer os melhores resultados
e levar equipes e organizações ao sucesso. Os grupos são: ORGANIZAÇÃO, VMO (Value
Management Office), PRODUÇÃO e PAPÉIS. Cada grupo tem sua parcela de importância e seu
entendimento é fundamental para aqueles que pretendem utilizar o modelo.

l ORGANIZAÇÃO: responsável pela gestão estratégica da organização.

l VALUE MANAGEMENT OFFICE: coordena a criação de valor definida pela organização


que será materializado pelas iniciativas.

l PRODUÇÃO: constituído pela análise de negócio e por diferentes camadas de


gestão que materializam o desenvolvimento de produtos e criam valor aos diversos
stakeholders de uma organização.

l PAPÉIS: conjunto de papéis e suas responsabilidades que proporcionam a criação


de valor para os diversos stakeholders de uma organização.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

INTRODUÇÃO \\ 13
FLEKS HYBRID MODEL

ORGANIZAÇÃO

O Grupo Organização constitui-se de oito elementos que definem a existência da própria


organização dentro da sociedade e do contexto que se encontra. Vale ressaltar que cada
organização pode conter outros elementos dentro desse grupo, caso seja necessário. Estão
citados aqui apenas aqueles considerados fundamentais e serão apresentados a seguir.

A IDENTIDADE ORGANIZACIONAL

Os primeiros quatro elementos formam aquilo que se chama a identidade organizacional:

l PROPÓSITO: representa a sua alma, sua motivação, aquilo que ela se propõe
a fazer para contribuir com a vida das pessoas e da sociedade como um todo e,
desta forma, deveria ser o principal indicador de sucesso de uma organização. O
propósito define os aspectos mais intrínsecos e perenes de uma organização, e tem
como principal característica ser algo que inspire e seja significativo para todos que
dela fazem parte. Um propósito bem definido empodera uma organização para
produzir impactos socioambientais positivos. Um propósito possui três elementos: a
formulação, o compromisso e a ação.

l MISSÃO: corresponde o motivo pela qual uma organização foi criada, sua finalidade;
é a identidade base que permanecerá ao longo do tempo, embora possa existir uma
adaptação ou mesmo uma mudança completa face às mudanças do mercado ou da
própria sociedade.

l VISÃO: define a posição futura, o direcionamento organizacional, onde a empresa quer


estar no futuro. A visão cria uma imagem em que a organização deve manter o foco
para direcionar seus esforços e concretizar sua missão.

ORGANIZAÇÃO \\ 14
FLEKS HYBRID MODEL

l VALORES: é o último elemento da identidade organizacional. Valores são crenças


que orientam a forma de agir e decidir de uma pessoa ou um grupo de pessoas. Os
valores funcionam como um conjunto de regras a serem seguidas conscientemente
para que a missão seja cumprida e a visão seja alcançada.

Os outros quatro elementos do Grupo Organização descrevem, de forma prática, como a


organização pretende materializar sua identidade, ou seja, são elementos mais concretos e
ditarão como os outros grupos serão formados e o que irão fazer.

SUSTENTABILIDADE

Face ao reconhecimento do mercado da importância da sustentabilidade, é fundamental


que a estratégia organizacional esteja alinhada e vinculada a fatores que gerem impactos
sociais, ambientais e econômicos positivos, de forma equilibrada. Adotar uma estratégia
sustentável, alinhada com a materialidade da organização, proporciona uma série de
benefícios e influencia diretamente no processo decisório, tanto no que é relacionado às
mudanças quanto à manutenção do negócio. As organizações, independentemente de seu
propósito e missão, devem identificar quais as melhores estruturas de sustentabilidade (ODS
- Objetivos de Desenvolvimento Sustentável) que podem apoiá-la. No entanto, para que a
sustentabilidade se torne realidade é necessário criar e manter uma cultura organizacional
que seja capaz de valorizar e implementar esse elemento de gestão, bem como escolher as
iniciativas adequadas para concretizar seus objetivos.

ESTRATÉGIA

A estratégia é um meio estruturado que orienta todos os componentes de uma organização a


seguirem em uma mesma direção a fim de que sejam alcançados os objetivos estabelecidos.
É a forma como as decisões de mais alto nível de uma organização são tomadas e define
como os recursos serão alocados ao longo do tempo para se atingir objetivos, cumprir sua
missão e alcançar sua visão. Diversas técnicas e ferramentas podem ajudar na definição
de uma estratégia que vão desde formas mais estruturadas como a Estratégia Diamante,
o Balanced Scored Card, Cinco Forças de Porter, Modelo da Cauda Longa e Oceano Azul.
Modelos mais simples como o OKR (Objectives and Key Results) e o Business Model Canvas
também podem ser adotados. A escolha da forma como a estratégia será definida depende
do contexto da organização. Cabe ressaltar que os modelos podem ser aplicados de forma
combinada para atender às necessidades específicas.

ORGANIZAÇÃO \\ 15
FLEKS HYBRID MODEL

Independentemente da forma como a estratégia será formulada, é importante que se faça


uma avaliação do ambiente que organização se encontra. Uma das formas mais clássicas
de se realizar esta análise é utilizar o modelo SWOT (strenghts, weaknesses, opportunities,
threats). Para a avaliação do ambiente externo deve-se identificar fatores que podem, de
alguma forma, afetar a organização e sua estratégia. Para isso podemos utilizar o acrônimo
PASTEL (políticos, ambientais, sociais, tecnológicos, econômicos e legais). Para a avaliação
do ambiente interno é aconselhável identificar alguns fatores que representam as forças ou
fraquezas da organização, tais como seus processos, capacidades, estrutura, diversidade ou
unicidade de produtos, conhecimentos, maturidade, entre outros.

Após a identificação dos fatores internos e externos é importante que se faça o cruzamento
entre esses fatores para que macroiniciativas e objetivos estratégicos sejam definidos, o que
permite uma avaliação de suas viabilidades e adequação. Este cruzamento pode ser feito
utilizando a imagem abaixo, que possui no centro a identidade da organização, ou seja, é
necessário verificar se essas macroiniciativas e objetivos estratégicos estão alinhados com essa
identidade. É importante destacar que essas macroiniciativas e os objetivos estratégicos estejam
vinculados aos ODS definidos pelo compromisso socioambiental assumido pela organização.

Nesse processo de análise, todas as forças precisam ser cruzadas com as ameaças para
verificar como é possível serem minimizadas. Da mesma forma, todas as forças precisam
ser cruzadas com as oportunidades para descobrir iniciativas para aproveitá-las. No que
se refere às fraquezas, deve-se buscar iniciativas para melhorá-las a fim de minimizar as
ameaças existentes ou aproveitar as oportunidades.

ORGANIZAÇÃO \\ 16
FLEKS HYBRID MODEL

OBJETIVOS ESTRATÉGICOS

Objetivos são pontos futuros no tempo que desejamos alcançar. Muito semelhantes à visão,
trata-se de uma declaração específica e concisa, que direciona as ações de toda a organização
ou de uma equipe. Objetivos estratégicos devem ser claros e inspiradores, motivar pessoas
a alcançá-los ou mesmo superá-los. Desta forma, precisam ser ousados, mas realistas e
mostrar claramente os benefícios ao serem atingidos. Objetivos devem possuir algum
mecanismo de medição e, para tanto, utiliza-se, normalmente o acrônimo SMART (específico,
mensurável, alcançável, relevante e delimitado no tempo) para torná-los mais realistas
e tangíveis. Objetivos estratégicos possuem uma
visão de mais longo alcance, acima de 6 meses,
podendo chegar a vários anos, dependendo
da organização, seu mercado e o contexto
que se encontra. Esses objetivos podem
e devem ser desdobrados em objetivos
de mais curto prazo para que seja
possível realizar um monitoramento
mais eficaz e eventuais adaptações.

Finalmente, é importante ressaltar que


existem diversos outros elementos de
gestão que estão relacionados a um nível
de decisão organizacional. Dependendo
do contexto, existe a necessidade de
integrar setores como Finanças, Tecnologia da
Informação, Logística, Marketing, Recursos Humanos,
Departamento Jurídico ou qualquer outro que faça parte da estrutura da organização. O
Modelo FLEKS não lida com esses aspectos, nem com o de operações de uma organização,
ou seja, de processos internos que fazem com que a organização se mantenha em
funcionamento. O modelo visa apenas mostrar como a parte de Gestão de Portfólio,
Programas, Projetos e Produtos deve ser implementada para viabilizar a criação de valor.

GESTÃO DA MUDANÇA

A Gestão da Mudança pode ser considerada como um conjunto de processos e ferramentas


para gerenciar o lado pessoal da mudança de um estado atual para um novo estado futuro,
de modo que os resultados esperados pela implantação da mudança sejam atingidos.

ORGANIZAÇÃO \\ 17
FLEKS HYBRID MODEL

É possível pensar na Gestão da Mudança em um nível organizacional, de iniciativas e pessoas.


Em um nível organizacional é preciso pensar em como a organização vai planejar e apoiar
iniciativas e pessoas no uso das boas práticas de Gestão da Mudança. No que se refere
às iniciativas é preciso pensar qual mudança será criada, implementá-la e reforçá-la por
meio de feedbacks e adaptações. Finalmente, no nível pessoal é que a mudança realmente
ocorre, pois são as pessoas que fazem uso das práticas, processos, técnicas e ferramentas
e, portanto, precisam incorporar a essência que a mudança vai provocar, ver seu valor e
contribuir para a mudança de status.

Existem vários modelos de implementação de Gestão da Mudança, mas de forma genérica


é preciso definir processos que permitam: (i) identificar a necessidade de mudança; (ii)
descobrir o que precisa mudar; (iii) definir como implementar a mudança; (iv) apoiar a
implantação da mudança; e (v) avaliar resultados obtidos para eventuais adaptações.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

ORGANIZAÇÃO \\ 18
FLEKS HYBRID MODEL

VALUE MANAGEMENT OFFICE

Baseado na identidade
organizacional, na governança
Um VMO é uma estrutura organizacional
corporativa, na estratégia e
estratégica responsável por coordenar e
nos objetivos estratégicos, o
manter um fluxo contínuo de criação e
VMO é responsável por definir
entrega de valor.
processos que otimizem a forma
de se entregar valor para os
stakeholders da organização de
acordo com suas necessidades. Diferentemente de um PMO (Project Management Office)
que tem como foco a otimização de processos, técnicas e ferramentas para a gestão de um
projeto, programa ou portfólio, um VMO, além de realizar essas funções, tem seu foco em
descobrir como a estrutura organizacional e suas iniciativas podem ser otimizadas para a
criação e entrega do valor.

O VMO funciona como um elo entre a organização,


seus stakeholders, que podem ser internos
e externos, e as iniciativas. O vínculo entre
a organização e os stakeholders são as
necessidades de ambas as partes que precisam
ser atendidas de forma adequada. Entre
as iniciativas e a organização, o vínculo
são os resultados obtidos, e entre as
iniciativas e os stakeholders, é o valor
entregue.

O VMO DEVE SER RECONHECIDO


COMO A VOZ DO VALOR DENTRO DE
UMA ORGANIZAÇÃO.

VALUE MANAGEMENT OFFICE \\ 19


FLEKS HYBRID MODEL

Em última instância, o VMO é o responsável pela criação de valor de forma balanceada e


sustentável para a organização e seus stakeholders. Dentre as diversas funções a serem
exercidas por um VMO, o Modelo FLEKS destacou algumas fundamentais que serão listadas
abaixo. No entanto, cada organização pode ter necessidades diferentes e adequar a
estrutura e funções do VMO de acordo com o seu contexto. São elas: governança, gestão
de riscos, gestão de conhecimento, o desdobramento dos objetivos estratégicos em OKRs,
a seleção das iniciativas, a definição de indicadores (KPIs) e a revisão dos resultados obtidos
em períodos pré-definidos para adaptação e realinhamento de ações.

GOVERNANÇA

A governança relacionada às iniciativas de criação de valor pode ser definida como um


conjunto de processos e diretrizes para garantir que:

l todas as iniciativas (portfólios, subportfólio,


programas, projetos e produtos) estejam
alinhadas com os objetivos e a estratégia
organizacional;

l papéis e responsabilidades sejam definidos;

l a criação de valor seja otimizada;

l os recursos necessários estejam disponíveis


para a criação de valor;

l o mindset e os princípios de gestão sejam


aplicados;

l existe uma metodologia de gestão consistente e ao


mesmo tempo fleksível para se ajustar às diferentes necessidades;

l as iniciativas possam se adaptar rapidamente a um novo contexto;

l as pessoas possuem capacidades para realizar suas funções;

l os resultados obtidos são monitorados e controlados; e

l informações estejam disponíveis para os diferentes stakeholders.

Esse tipo de governança, que é derivada da governança corporativa, funciona como um


end-to-end framework que guia todo o processo de criação de valor e auxilia o processo
decisório, integrando diversos aspectos e elementos da estrutura organizacional.

VALUE MANAGEMENT OFFICE \\ 20


FLEKS HYBRID MODEL

GESTÃO DE RISCOS

Junto com a governança, existe a necessidade


de o VMO ter uma visão geral e uma supervisão
Baseado nos objetivos es-
sobre os riscos relativos às iniciativas que serão
tratégicos recebidos da alta
desenvolvidas na organização, para se ter uma
gestão e das iniciativas sele-
real expectativa da probabilidade de sucesso
cionadas, é fundamental que
do portfólio, o que influencia diretamente no
riscos sejam identificados e
processo de seleção das próprias iniciativas.
geridos de forma adequada.
É importante ressaltar que a responsabilidade
da gestão desses riscos nem sempre ficará
sob responsabilidade do VMO, pois este deve ficar focado apenas nos riscos que estiverem
no seu nível de gestão. Riscos específicos das iniciativas devem ser delegados para seus
respectivos gestores.

GESTÃO DE CONHECIMENTO

A Gestão do Conhecimento é um processo sistematizado e sustentado pela cultura, políticas


e diretrizes de uma organização que visa se apropriar do conhecimento existente (externo e
interno) como diferencial competitivo e criar valor de forma sustentável.

Pode-se identificar dois tipos de conhecimento: o explícito e o tácito. O conhecimento explícito


é aquele que está formalizado em políticas, procedimentos, processos ou lições aprendidas
registradas. Por sua vez, o conhecimento tácito é aquele internalizado nas pessoas, o saber
fazer, o modo de fazer que ainda não está formalizado.

O conhecimento também pode ser considerado como um


valor a ser criado pela organização para seu próprio
benefício. Para tanto, processos de captação, análise,
armazenamento, disseminação e atualização
do conhecimento devem estar em estreito
relacionamento com a gestão de comunicação.

Canais abertos de comunicação e processos enxutos


facilitam bastante o que se chama de conversão
de conhecimento, ou seja, o ato de se identificar um
conhecimento e fazer com que ele chegue da forma

VALUE MANAGEMENT OFFICE \\ 21


FLEKS HYBRID MODEL

mais eficiente possível aos seus principais interessados, de modo a permitir um aprendizado
e aplicação real para que algum valor seja criado.

Dentro desse contexto, o VMO tem fundamental importância sobre o processo, visto que
possui uma visão estratégica das iniciativas e pode fazer a gestão de todo o conhecimento
existente e os novos adquiridos, viabilizando sua disponibilização para as equipes e para a
organização como um todo.

DEFINIÇÃO DE OKR (OBJECTIVES AND KEY RESULTS)

O planejamento estratégico e a visão de longo prazo são necessidades básicas de qualquer


organização. No entanto, em um ambiente BRIGHT, desenvolver estratégias mais fleksíveis às
incertezas e de menor prazo são fundamentais, pois permitem uma adaptação mais rápida,
uma contínua avaliação de resultados e uma gestão dos riscos mais eficiente.

Uma das formas de se fazer isso é implementando


OKRs. De forma sucinta, o método OKR consiste
na definição de objetivos (O) de curto ou
médio prazo (geralmente três meses) e de
resultados chave (KRs) que mostram se o
objetivo foi alcançado. Esses objetivos são
decomposições dos objetivos estratégicos
emanados pela alta administração e
decompostos em objetivos menores e de
mais curto prazo. Os objetivos devem sempre
ser descritos de forma qualitativa ao passo que
os resultados chave devem ser mensuráveis de
forma quantitativa.

Baseado nesses OKRs e nas iniciativas estratégicas, o VMO pode definir iniciativas de mais
curto prazo e realizar a seleção de quais delas farão parte do portfólio para um período
específico. Dessa forma, essas iniciativas poderão ser desenvolvidas e o VMO poderá reavaliar
constantemente se a estratégia está no caminho correto, se os objetivos estratégicos serão
alcançados ou se algo precisa ser ajustado. Uma visão geral de como funciona esse processo
pode ser observado nas figuras abaixo, que mostram como um VMO pode coordenar a
implantação de OKRs, sua avaliação e adaptação diante de novas informações e de cenários
futuros incertos. A primeira figura mostra uma visão geral do processo para um período de
um ano enquanto a segunda apresenta a visão detalhada de um trimestre

VALUE MANAGEMENT OFFICE \\ 22


FLEKS HYBRID MODEL

SELEÇÃO DE INICIATIVAS

Uma das mais importantes funções


do VMO é realizar a seleção das
O Modelo FLEKS preconiza que um
iniciativas que farão parte do
portfólio é um conjunto de iniciativas
portfólio de projetos e produtos
que entrega o maior valor possível
de uma organização. Para tanto, é
com o menor risco para a organização
fundamental a compreensão de que
e seus stakeholders.
um portfólio não é simplesmente um
conjunto de iniciativas.

VALUE MANAGEMENT OFFICE \\ 23


FLEKS HYBRID MODEL

Existem diversas técnicas de seleção de projetos e produtos e cada organização deve


escolher a que mais fizer sentido para seu contexto. No entanto, é de suma importância
observar, não só a prioridade das iniciativas em termos de criação de valor, mas também
as INTERDEPENDÊNCIAS existentes entre elas, os recursos necessários para implementá-las,
restrições, nível de risco das iniciativas e como cada iniciativa contribui para o risco total do
portfólio. Uma boa seleção de iniciativas deve considerar, entre outros:

l Uma efetiva e contínua criação de valor;

l Alinhamento estratégico;

l Viabilidade em termos de recursos;

l Fleksibilidade para adaptação ao cenário;

l Balanceamento entre iniciativas de manutenção e inovação;

l Equilíbrio entre as necessidades dos stakeholders; e

l O tempo necessário e requerido para a entrega de valor.

DEFINIÇÃO DE KPI (KEY PERFORMANCE INDICATORS)

Para medir o desempenho de iniciativas, processos ou de uma organização como um todo


é importante que indicadores efetivos sejam definidos, pois auxiliam o processo decisório
e permitem uma visualização da necessidade de mudança
ou manutenção de procedimentos ou atitudes. Esses
indicadores devem refletir de forma clara e inequívoca
o desempenho das equipes, das iniciativas e dos
resultados acordados que realmente importam.

Podem existir diversos tipos de indicadores e


cada organização deve definir os que forem mais
apropriados. Em função da sua característica
híbrida e da necessidade do que precisa ser
medido, o Modelo FLEKS preconiza dois tipos de
indicadores:

l Indicadores HARD: utilizados para medir desempenhos


técnicos como throughput (produtividade), time to market, custo, tempo gasto para
realizar tarefas, SLA (Service Level Agreement), ROI (Return on Investment), NPS (Net
Promoter Score), quantidade de defeitos, entre outros.

VALUE MANAGEMENT OFFICE \\ 24


FLEKS HYBRID MODEL

l Indicadores SOFT: Utilizados para medir desempenhos comportamentais como nível


de engajamento, aprendizado, capacidade de aprendizagem, nível de satisfação
no trabalho, qualidade e transparência das comunicações, nível de interação,
adaptação, satisfação do cliente, entre outros.

É importante destacar que um KPI não pode


ser confundido com os OKRs . Apesar de
OKRs são dinâmicos, tempo-
serem semelhantes, existem diferenças
rários e utilizados para mudar
importantes que precisam ser estabelecidas.
um status, enquanto os KPIs
A primeira forma de observar a diferença
são fixos e mostram como está
é entender que um KR funciona como uma
a situação presente de uma or-
meta a ser alcançada, uma medida para saber
ganização ou uma iniciativa.
se chegamos ou não a um objetivo futuro,
que foi definido de forma qualitativa, ou se
precisamos de algum ajuste para alcançá-lo.
Por outro lado, um KPI é uma medida estática em um ponto específico no tempo que pode
ser utilizada para saber se vamos ou não chegar a um resultado chave. Destaca-se também
que um OKR pode possuir um ou mais KPIs que ajudam monitorar se estamos ou não no
caminho certo. Uma segunda forma de entender as diferenças é que a partir de um KPI
específico de uma organização OKRs sejam definidos para mudar esta condição.

REVISÃO DE RESULTADOS

Em função da dinâmica do ambiente e eventuais incertezas que podem ter se materializado,


é importante que o VMO esteja apto a tomar decisões que reorientem o caminho em direção
aos objetivos estratégicos.

Esta revisão pode ser realizada com o auxílio dos OKRs e KPIs definidos ou por uma análise de
tendências. Deve-se levar em conta que o mais importante nessa análise é estar preparado
e ter fleksibilidade suficiente para se adaptar a um novo contexto e reorientar as ações, criar
novas iniciativas ou mesmo cancelá-las.

É importante que um VMO tenha em mente que uma iniciativa deve ser interrompida se é
observado que ela não contribui mais para um objetivo, se ela não tem mais condições de
ser realizada ou se o objetivo para qual ela contribuía não é mais necessário ser atingido.

A frequência das revisões deve ficar a critério de cada VMO, mas é recomendado que se
tenha pelo menos uma revisão a cada trimestre, para coordenar e acompanhar os OKRs
definidos e observar discrepâncias dos resultados obtidos com as iniciativas definidas. Essas

VALUE MANAGEMENT OFFICE \\ 25


FLEKS HYBRID MODEL

revisões devem estar em consonância com as revisões realizadas na gestão do portfólio, mas
a diferença é que as revisões do portfólio visam avaliar os resultados de cada iniciativa dentro
de um portfólio definido e a revisão de resultados do VMO visa observar se as iniciativas
existentes devem continuar a existir ou não, em função dos resultados observados ou da
mudança de um contexto.

CONCLUSÃO

Em resumo, um VMO tem uma função preponderante dentro de uma organização moderna e
que busca uma constante e sustentável criação de valor para seus stakeholders. Ele funciona
como um maestro no processo de conduzir essa criação de valor. Para tanto, tem que ser
capaz de visualizar o valor a ser entregue, criar um fluxo, prover condições para que ele possa
ser materializado, realizar um constante acompanhamento do processo para eventuais
adaptações e prover informações atualizadas para a alta gestão e demais stakeholders de
uma organização. De forma genérica, um VMO deve possuir em mente a imagem abaixo,
pois ele será, em última instância, o responsável pela cadeia de valor.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

VALUE MANAGEMENT OFFICE \\ 26


FLEKS HYBRID MODEL

PRODUÇÃO

O Grupo de Produção do Modelo FLEKS compreende seis


elementos para orientar os profissionais que
irão utilizá-lo. Os elementos foram criados
para serem adaptados, de acordo com
a necessidade, mas assume-se que
os conceitos apresentados neste
guia devem ser seguidos para
fornecer os melhores resultados
e levar equipes e organizações ao
sucesso. Os elementos do Grupo
de Produção são: MINDSET,
PRINCÍPIOS, CAMADAS, EVENTOS,
FLUXO DE VALOR e PAPÉIS. Cada
um tem sua parcela de importância
e seu entendimento é fundamental
para aqueles que pretendem utilizar o
modelo. O mindset e os princípios são os
mesmos descritos anteriormente. Os papéis
serão descritos posteriormente. Uma visão geral dos
elementos do Grupo de Produção é apresentada na figura ao lado.

CAMADAS

O Modelo FLEKS define quatro camadas de produção para estabelecer uma distinção entre
papéis e responsabilidades, que são colaborativos e interdependentes. As camadas também
permitem uma melhor compreensão de quais são os principais eventos responsáveis pela

PRODUÇÃO \\ 27
FLEKS HYBRID MODEL

criação de valor. As camadas podem ser observadas na figura abaixo, bem como os eventos
que são realizados dentro de cada camada.

O Modelo FLEKS é capaz de realizar a gestão de portfólios, subportfólios, programas,


projetos e produtos. A camada de Gestão de Portfólio estará sempre presente e atuará na
coordenação das iniciativas. No caso de ocorrência de um subportfólio ou programa, esse
tipo de gestão utilizará os mesmos eventos da camada de Gestão de Portfólio, mas apenas
para as iniciativas dentro de um mesmo subportfólio ou programa.

Todos os projetos utilizarão a Análise de Negócio, as Camadas Gestão de Projeto e Produto.


No caso de a organização realizar iniciativas que são apenas produtos com fluxo contínuo de
entregas (value streamings), poderão ser utilizadas a Análise de Negócio e a Camada Gestão
de Produto, mas, na maioria dos casos, a Camada de Gestão Produto já será suficiente.

ANÁLISE DE NEGÓCIO

Essa camada é responsável pela parte do projeto ou produto relacionada ao negócio e é


responsável pela criação da solução técnica e viabilidade econômica das iniciativas. Assim
que o VMO recebe a demanda por uma iniciativa, a Análise de Negócio busca entender a
necessidade e criar uma solução para supri-la. Em seguida, a Definição de Valor é feita para
que seja claramente definido e acordado o valor a ser entregue por aquela iniciativa. O
próximo passo é formalizar um Business Case com as principais informações necessárias
para iniciar um projeto ou um produto e mantê-lo alinhado aos objetivos do negócio. Em

PRODUÇÃO \\ 28
FLEKS HYBRID MODEL

caso de uma prévia existência de uma solução, esses passos podem ser dispensados. Essa
camada funciona em estreita coordenação com o VMO e as outras camadas de gestão, pois
provê informações importantes para a condução das iniciativas, tais como estimativas de
alto nível.

O(A) Analista de Negócio é responsável por essa atividade, mas não é o(a) único(a) que
executa os eventos planejados para ela. Pelo contrário, ele(a) pode e deve ser aconselhado(a)
por qualquer membro das equipes, especialmente os responsáveis pelas tarefas de gestão
ou especialistas, que podem contribuir com suas habilidades e competências.

CAMADA DE GESTÃO DE PORTFÓLIO

Esta camada é responsável por coordenar o fluxo de entrega de valor das iniciativas definidas
pelo VMO. O objetivo é viabilizar, de forma mais coerente possível, o sequenciamento com
que as iniciativas serão realizadas de acordo com a necessidade, as interdependências e os
recursos disponíveis.

De acordo com os OKRs e as iniciativas definidas pelo VMO, a Gestão de Portfólio realiza um
planejamento para observar como essas iniciativas serão distribuídas ao longo do período
definido de controle, viabilizando a criação do Roadmap do
Portfólio, que poderão ser compostos por subportfólio,
programas, projetos ou produtos. Na sequência, um
Backlog da Iteração do Portfólio é definido para que
todos tenham uma visualização única do que será
feito no período.

Em tempos determinados na reunião de


planejamento e de acordo com a necessidade,
existirá uma Reunião de Coordenação com as
iniciativas que estão sendo desenvolvidas no período.
E ao final, haverá uma Reunião de Revisão do Portfólio,
que visa observar o que realmente foi feito e reajustar o
planejamento. Finalmente, é realizada uma Reunião de Retrospectiva do Portfólio para
melhorar novos ciclos de gestão.

PRODUÇÃO \\ 29
FLEKS HYBRID MODEL

CAMADA DE GESTÃO DE PROJETO

Essa camada é responsável por planejar a execução e controle do projeto, bem como de
seus principais componentes. Com base nas diretrizes fornecidas pela Análise de Negócio,
o principal objetivo é definir o melhor conjunto dos releases que farão parte do Roadmap
do Projeto, o Backlog do Projeto e os Planos que orientarão o desenvolvimento do projeto.
Um release é uma entrega, potencialmente utilizável, e contém um conjunto de incrementos
integrados produzidos por várias iterações. O Modelo FLEKS utiliza a expressão release, mas
dependendo do contexto, pode ser chamado de estágio, fase,
módulo ou outro nome mais adequado à organização.

A definição de releases não é apenas uma questão de


prioridades, mas também do melhor conjunto de
releases e em que ordem devem ser desenvolvidos
para criar o valor do projeto. O(A) Gerente de
Projeto é responsável por essa camada, mas ele(a)
pode ser ajudado(a) pelo(a) Gerente de Produto ou
por especialistas, que podem contribuir com suas
habilidades e competências.

Em caso de dúvida, o(a) Analista de Negócio deve ser


consultado(a), assim como os stakeholders, tais como clientes e usuários finais, até que
todos concordem que o Roadmap do Projeto apresente a melhor maneira de entregar os
produtos e valores acordados. O Roadmap do Projeto deve estar sempre em coordenação
com o programa ou o portfólio que faz parte.

Antes do início da execução do projeto, o(a) Gerente de Projeto realiza uma Reunião de Início
do Projeto. Durante o projeto são realizadas revisões a cada término de release para que
seja possível realinhar os planos, o roadmap ou mesmo o backlog do projeto. Uma Reunião
de Retrospectiva do Projeto deve ser realizada para que lições aprendidas sejam registradas
e a equipe seja capaz de melhorar desempenhos futuros. Finalmente, o projeto é encerrado
formalmente em uma Reunião de Encerramento.

CAMADA DE GESTÃO DE PRODUTO

Essa camada é responsável pelo desenvolvimento ou adaptação dos produtos do projeto


acordados ou o desenvolvimento contínuo de produtos existentes (value streaming). No caso
de a iniciativa ser um projeto é preciso ter em mente que o escopo está de alguma forma

PRODUÇÃO \\ 30
FLEKS HYBRID MODEL

definido, mas não na sua totalidade, e pode ser adaptado a eventos futuros ao longo do
projeto, por meio de eventuais necessidades ou de uma mudança exigida por um stakeholder.

A pessoa responsável por essa camada é o(a) Gerente de Produto, trabalhando em estreita
colaboração com a Equipe de Desenvolvimento. Com base no Roadmap do Projeto e
em qualquer orientação fornecida pelo(a) Gerente de Projeto, o(a) Gerente de Produto
desenvolve o Backlog do Produto, o Roadmap do Produto, realiza o Planejamento do Release,
define o Backlog do Release e elabora o Roadmap do Release, que define o melhor conjunto
e em qual sequência as iterações irão ocorrer para entregar o valor do Release. O (A) Gerente
de Produto pode ser auxiliado(a) por qualquer membro da
Equipe de Desenvolvimento nessas atividades.

Uma iteração é um período de tempo em que um ou


mais incrementos de valor são criados. No caso de o
escopo desse incremento for um componente mais
adaptativo e exploratório, o objetivo é que esse
incremento possa permitir que os usuários finais
entrem em contato com um produto funcional e
forneçam feedback para melhorar a versão final do
produto.

Em caso de dúvida, o(a) Gerente de Projeto deve ser


consultado(a), bem como os stakeholders, tais como clientes e usuários
finais, até que todos concordem que o Roadmap do Release é a melhor maneira de entregar
o valor proposto para o release. O Roadmap do Release deve estar sempre em coordenação
com o programa ou o portfólio que faz parte.

Em seguida, a Equipe de Desenvolvimento realiza o Planejamento da Iteração, cria o Backlog


da Iteração e realiza a iteração propriamente dita. Ao término de cada iteração, são realizadas
as Reuniões de Revisão e Retrospectiva. Quando todas as iterações de um determinado
release se encerrarem será realizada uma Revisão do Release para realinhamento e
adequação do backlog e planos.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

PRODUÇÃO \\ 31
FLEKS HYBRID MODEL

FLUXO DE VALOR

O MODELO FLEKS É UM PROCESSO DE CRIAÇÃO DE VALOR ITERATIVO,


INCREMENTAL E RECURSIVO.

Iterativo significa que é repetido em intervalos de tempo. Entende-se por incremental


como algo que a cada iteração realizada, um ou mais incrementos de valor são criados.
Uma recursão é um método de resolver um problema em que a solução final depende de
soluções de instâncias menores do mesmo problema, e a cada iteração, dados diferentes são
adicionados para que novos resultados sejam obtidos, até que o processo seja finalizado.

A figura abaixo é um exemplo teórico da construção de um produto. Será exemplificado


apenas do nível da Camada de Produto para baixo, pois é onde os produtos, realmente são
desenvolvidos. O primeiro nível é o roadmap do produto, que contém diversos releases. O
segundo nível representa o roadmap de um release, composto por várias iterações e que se
repete para todos os releases do primeiro nível. O terceiro nível é o roadmap de uma iteração,
composta por vários incrementos e que se repete para todas as iterações do segundo nível.

Um exemplo do fluxo de valor será fornecido para o primeiro release, mas pode ser repetido
recursivamente até o final do último release. O número de iterações e incrementos não é
necessariamente o mesmo para um determinado produto a ser desenvolvido.

As setas para baixo representam o fluxo descendente, que é o início do nível exatamente
abaixo. As setas para cima representam o fluxo ascendente, que é a contribuição em termos
incrementos sendo desenvolvidos por um nível inferior para qualquer componente de um
nível imediatamente superior.

FLUXO DE VALOR \\ 32
FLEKS HYBRID MODEL

O FLUXO DESCENDENTE

A construção do Roadmap do Produto é onde o fluxo descendente começa. O Roadmap


do Produto é composto pela melhor combinação de releases que acrescente o maior valor
possível para esse produto a um menor nível de risco global. Em caso de necessidade, este
roadmap deve ser produzido em coordenação com outros projetos e produtos.

Após a aprovação de início do primeiro release, o Gerente de Produto, prepara o Roadmap


do Release, composto pelo melhor conjunto de iterações que criam o maior valor possível
para esse release a um menor nível de risco global. Em caso de necessidade, o Roadmap do
Release deve ser produzido em coordenação com outros projetos e produtos.

Assim que a primeira iteração é iniciada, a Equipe de Desenvolvimento cria o Roadmap da


Iteração, composto pelo melhor conjunto de incrementos que criam o maior valor possível
para essa iteração a um menor nível de risco global. Em caso de necessidade, o Roadmap da
Iteração deve ser produzido em coordenação com outros projetos e produtos.

Durante o fluxo descendente, o Gerente de Produto e a Equipe de Desenvolvimento têm


a chance de refinar o Backlog do Produto com informações detalhadas relacionadas ao
primeiro release. Esse refinamento é feito por meio de interações com clientes, usuários
finais ou qualquer outro stakeholder. O objetivo principal desse refinamento é ter uma visão
ampla e detalhada dos incrementos do produto, quais valores eles produzem, como serão
desenvolvidos e medidos. No final do fluxo descendente, a equipe possui uma visão macro
de todo o release e a primeira iteração está pronta para ser executada.

FLUXO DE VALOR \\ 33
FLEKS HYBRID MODEL

O FLUXO ASCENDENTE

À medida que os incrementos são desenvolvidos, o Gerente de Produto e a Equipe de


Desenvolvimento controlam a conclusão da primeira iteração. É importante ressaltar
que os incrementos podem ser desenvolvidos em sequência ou em paralelo com outros
incrementos, dependendo do roadmap estabelecido.

Em seguida, inicia-se a segunda iteração de forma análoga até que todas as iterações
previstas para o primeiro release sejam concluídas. É importante ressaltar que as iterações
podem ser desenvolvidas em sequência ou em paralelo com outras iterações, dependendo
do roadmap estabelecido.

Finalmente, após o término do primeiro release, tem início o segundo release de forma
análoga ao anterior, até o fim de todos os releases. É importante ressaltar que os releases
podem ser desenvolvidos em sequência ou em paralelo com outros releases, dependendo
do roadmap estabelecido.

Como se pode observar, o fluxo de valor ocorre de forma iterativa, incremental e recursiva
até que a iniciativa tenha sido concluída. A figura abaixo mostra como um nível inferior
contribui para um nível superior até que o valor da iniciativa seja criado.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

FLUXO DE VALOR \\ 34
FLEKS HYBRID MODEL

EVENTOS DA
ANÁLISE DE NEGÓCIO

O objetivo da Análise de Negócio é auxiliar a organização e, mais especificamente no Modelo


FLEKS, assessorar o VMO no processo decisório de quais iniciativas devem ser encaminhadas
para a execução. A Análise de Negócio funciona como uma interface entre as necessidades
e a criação de valor propriamente dita e garante que exista uma solução técnica viável e que
realmente crie valor aos stakeholders.

Os eventos aqui apresentados podem ser realizados por uma equipe especializada, sob
coordenação de um(a) Analista de Negócio ou pela própria equipe de gestão de um projeto
ou produto.

Existem quatro eventos previstos para a Análise de Negócio, e foram planejados para serem
conduzidos em uma sequência específica. O(A) Analista de Negócios é o(a) responsável por
todos eles. Existem diversas técnicas e ferramentas disponíveis no mercado para a condução
dos eventos. Os modelos apresentados abaixo são meras sugestões e podem ser adequados
de acordo com o contexto. É importante entender que se a organização, em determinada
iniciativa, julgar que um evento seja desnecessário, este pode ser dispensado considerando
que o conhecimento e a informação já estão disponíveis. Em geral, os eventos de Análise de
Negócios podem ser agrupados de acordo com a figura abaixo.

ANÁLISE DA NECESSIDADE

O principal objetivo deste evento é coletar informações sobre o que já é conhecido e porque
a iniciativa é necessária para uma pessoa, um grupo de pessoas ou uma organização, que

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 35


FLEKS HYBRID MODEL

são os stakeholders demandantes da iniciativa, que podem ser internos ou externos à


organização. Existem três tipos de necessidades: uma oportunidade, uma ameaça ou um
problema.

Normalmente, uma oportunidade é identificada para


permitir o retorno de um investimento ou uma proposta
comercial demandada por terceiros. Por sua vez, uma
ameaça é algo observado que pode impactar
negativamente os objetivos dos negócios e,
por isso, uma iniciativa pode ser iniciada para
minimizar ou eliminar a ameaça. Ambos, ameaça
e oportunidade, são eventos futuros e incertos.
Finalmente, um problema é qualquer situação
adversa já materializada e que necessita ser resolvida.

É necessário entender uma necessidade para estar ciente de quatro fatores básicos. As
Causas (causas ou um conjunto de causas que levam à necessidade), os Efeitos (efeitos
esperados decorrentes da necessidade), Stakeholders (aqueles que demandam a
necessidade ou alguém afetado de alguma forma por ela) e os Dados Objetivos (números ou
fatores conhecidos que permitam entender a necessidade).

Por meio de trabalho colaborativo, o(a) Analista de Negócios pode ter uma visão ampla da
necessidade e iniciar o evento seguinte, que é a busca por uma solução. Um exemplo de um
quadro que pode ser utilizado para registrar o que foi observado na Análise da Necessidade
encontra-se disponível no Guia de Canvas do Modelo FLEKS. A figura ilustra esse quadro.

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 36


FLEKS HYBRID MODEL

IDEAÇÃO DA SOLUÇÃO

Após analisar a necessidade, é hora de buscar uma solução para o problema, aproveitar a
oportunidade ou enfrentar a ameaça. A solução pode atacar as causas, os efeitos ou ambos.
Essa solução deve ser acordada entre a equipe e aqueles que solicitaram o projeto.

Vale ressaltar que a decisão tomada deve ser efetiva. Por vezes, não é fácil encontrar a
solução perfeita, mas as pessoas devem ter em mente que a solução obrigatoriamente deve
conter quatro importantes características, representadas pelo acrônimo em inglês FAST,
conforme a figura abaixo:

l FEASIBLE (FACTÍVEL): ser tecnicamente possível de ser desenvolvida.

l ADD (ADICIONAR): deve adicionar valor mensurável para os stakeholders.

l SIMPLE (SIMPLES): ser simples de ser utilizada e mantida durante seu ciclo de vida.

l TIMELY (OPORTUNA): deve estar pronta no tempo adequado para os stakeholders.

Existem diversas técnicas e ferramentas no mercado para se elaborar soluções no contexto


de uma iniciativa, e cada organização ou equipe deve definir a melhor para cada caso. Esta
avaliação pode utilizar desde quadros colaborativos até complexas análises técnicas. Abaixo
estão algumas dicas para serem lembradas durante a ideação de uma solução.

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 37


FLEKS HYBRID MODEL

Durante o processo, podem aparecer diversas alternativas de solução. Para cada uma, tente
identificar algumas características essenciais como o que faz, o que não faz, os benefícios,
pontos fortes e fracos, os desafios a serem enfrentados pela equipe, os recursos, a tecnologia
necessária para a implementação da solução e quais informações consideradas importantes
não são conhecidas. As características identificadas para cada possível solução devem ser
coletadas e apresentadas para os stakeholders demandantes da iniciativa que definirão qual
será a melhor opção. Um exemplo de um quadro que pode ser utilizado para registrar o que
foi observado na Ideação da Solução encontra-se disponível no Guia de Canvas do Modelo
FLEKS. A figura ilustra esse quadro.

DEFINIÇÃO DE VALOR

O propósito de uma iniciativa é a criação e entrega de valor para quem o demanda e permitir
sua validação ao longo do tempo. O evento de Definição de Valor é um passo necessário para
tal e precisa das informações obtidas nos eventos anteriores da Análise de Negócio.

Quando se entende as necessidades, causas, efeitos, as informações objetivas e os principais


stakeholders, bem como a solução, um mapa de valor pode ser construído para mostrar
como este será entregue. Um exemplo de um quadro que pode ser utilizado para registrar o
que foi observado na Definição de Valor encontra-se disponível no Guia de Canvas do Modelo
FLEKS. A figura ilustra esse quadro.

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 38


FLEKS HYBRID MODEL

DESENVOLVIMENTO DO BUSINESS CASE

O Business Case tem a finalidade de capturar o porquê de investir recursos em uma iniciativa
e, pode ser apresentado de várias formas, desde um documento escrito bem estruturado
até um acordo verbal. A lógica de um business case é: sempre que tempo e recursos
forem investidos eles devem atender a uma necessidade de negócio e a criação de valor.
Um Business Case convincente deve conter as características qualitativas e quantitativas
de uma iniciativa proposta. Resumidamente, o Business Case é uma memória da solução
recomendada para a iniciativa, com a motivação e as evidências de suporte à decisão para
seu início. Um Business Case deve estar estruturado de modo a ser:

l ORIENTADO AO NEGÓCIO: relacionado ao impacto do negócio, ao invés de aspectos


técnicos.

l RESPONSÁVEL: acordos para entrega de valor claramente definidos.

l ADAPTADO: customização para atender às características da iniciativa.

l CLARO: conteúdo direto, lógico e fácil de ser entendido.

l MENSURÁVEL: fatores chaves e valores entregues devem ser rastreáveis e


mensuráveis.

O(A) Analista de Negócios é o(a) responsável pelo Business Case, mas pode ser auxiliado por
qualquer especialista da organização. Existem diversos formatos de business case, mas o

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 39


FLEKS HYBRID MODEL

Modelo FLEKS preconiza um conteúdo mínimo:

l Justificativa da necessidade do negócio;

l Objetivos da iniciativa;

l Breve descrição da solução;

l Valor esperado a ser entregue;

l Variáveis de Valor definidos em alto nível;

o Escopo, Tempo, Custos, Recursos, Qualidade e Riscos;

l Principais stakeholders; e

l Premissas e Restrições.

Um exemplo de um quadro que pode ser utilizado para registrar um Business Case encontra-
se disponível no Guia de Canvas do Modelo FLEKS. A figura ilustra esse quadro.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

EVENTOS DA ANÁLISE DE NEGÓCIO \\ 40


FLEKS HYBRID MODEL

EVENTOS DA GESTÃO
DO PORTFÓLIO

No Modelo FLEKS, a Gestão de Portfólio tem como principal função coordenar a execução
do fluxo das iniciativas definidas pelo VMO e prover informações para a tomada de decisão
sobre o status das iniciativas, que podem ser subportfólios dentro da própria organização,
programas, projetos isolados, produtos de desenvolvimento contínuo ou qualquer
combinação deles.

Todo o trabalho de gestão do portfólio será definido pelo período de tempo de controle
definido pelo VMO na sua estratégia de gestão por OKRs. A este período dá-se o nome de
iteração do portfólio que, normalmente, varia entre 1 a 3 meses, dependendo da quantidade
de incertezas ou da necessidade do VMO ou da organização. O objetivo de definir esses
períodos de controle é permitir uma observação mais próxima da efetividade do processo
de criação de valor e viabilizar adaptações no planejamento o mais rapidamente possível.
Dentre as diversas funções que a gestão do portfólio pode realizar encontram-se:

l Planejar, em alto nível, como as variáveis de valor serão gerenciadas no timebox do


portfólio;

l Definir e realizar o desconflito de interdependências;

l Alocar recursos;

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 41


FLEKS HYBRID MODEL

l Gerir riscos do portfólio;

l Conduzir reuniões de coordenação das diversas iniciativas;

l Controlar o fluxo de informações;

l Prover dados para os tomadores de decisão em um nível gerencial superior;

l Repriorizar o fluxo de iniciativas em função da necessidade;

l Assessorar o VMO na escolha das iniciativas, em função da quantidade e do tipo de


iniciativas que já existirem em um portfólio já em execução; e

l Facilitar as iniciativas sob sua coordenação.

Quando se pensa em um conjunto de iniciativas que precisam ser escaladas, é preciso


entender o motivo que leva uma organização a realizar este tipo de atividade. Basicamente,
isso acontece por dois motivos: (i) uma equipe não consegue realizar todo um escopo e precisa
desmembrar em duas ou mais iniciativas; (ii) existem iniciativas diferentes que precisam ser
coordenadas por um nível superior de gestão para que se possa ter mais chance de alcançar
seu objetivo de forma conjunta.

Para que isso possa acontecer, os eventos da Camada de Gestão de Portfólio do Modelo
FLEKS foram definidos e podem ser observados na figura abaixo e é importante ressaltar que
todos esses eventos devem ser realizados de forma análoga para um subportfólio e para um
programa, mas apenas diferenciando a escala de gestão.

PLANEJAMENTO DO PORTFÓLIO

O objetivo dessa reunião é definir quais iniciativas ou partes delas serão executadas na
Iteração do Portfólio definido pelo VMO. Essa escolha depende de vários fatores tais como a
duração estimada de cada iniciativa, os recursos disponíveis, capacidade das equipes, grau de
interdependência entre elas, riscos existentes, objetivos a serem atingidos, o valor ou valores
que se pretende criar no período, dentre outros. É importante ressaltar que no Modelo FLEKS
o que se pretende na escolha desse portfólio não é apenas uma priorização e sim definir o
melhor conjunto que maximize o valor e minimize o risco global.

Em uma reunião de Planejamento de Portfólio, que será conduzida pelo(a) próprio(a) Gerente
do Portfólio e sua equipe, poderão fazer parte os gerentes de qualquer iniciativa de interesse

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 42


FLEKS HYBRID MODEL

ou representantes destes, visto que a troca de informações é fundamental para a tomada de


decisão. Vale ressaltar que, em alguns casos, nesse momento os papéis ainda podem não
terem sido definidos e cabe a(o) Gerente de Portfólio assessorar na definição de quem serão
os eventuais responsáveis pelas iniciativas.

As entradas fundamentais para esse tipo de reunião são os valores que o VMO deseja criar
no período, as iniciativas candidatas que já passaram pelo processo de seleção que formam
o Backlog do Portfólio, os stakeholders e suas expectativas, recursos disponíveis, capacidade
das equipes, entre outras tais como restrições e premissas. Ao final da reunião, algumas
perguntas precisam ser respondidas e um conjunto de artefatos mínimo deve ser produzido,
mas dependendo da necessidade e da organização, outras perguntas e artefatos podem ser
necessários.

l Que iniciativas ou partes delas devem fazer parte da iteração do portfólio?

l Que valores serão entregues ao final da iteração?

l Que objetivos devem ser alcançados?

l Como o desempenho das iniciativas e das equipes será observado?

l Qual a estimativa em alto nível das variáveis de valor a serem geridas no período?

l Existem interdependências ou dependências lógicas que precisam ser respeitadas?

l Qual a sequência de execução tornará o fluxo de criação de valor mais otimizado


possível?

l Com que frequência os gerentes e equipes devem se reunir para a coordenação dos
trabalhos que estão sendo realizados?

Em relação aos artefatos, os principais são: as iniciativas ou as partes delas que serão
executadas no período, formando o Backlog da Iteração do Portfólio e o Roadmap da Iteração
do Portfólio. As iniciativas que não forem selecionadas para a Iteração do Portfólio, devem
permanecer no Backlog do Portfólio para serem avaliadas no planejamento de uma futura
iteração. Um artefato não obrigatório, mas desejável, dependendo do tamanho do portfólio,
seria um Plano da Iteração do Portfólio.

O Roadmap da Iteração do Portfólio pode ser construído de várias formas diferentes,


dependendo das condicionantes listadas anteriormente, mas de forma geral ele terá as
características da imagem abaixo, em que se observa a divisão do período em meses e
semanas (S1, S2, S3, S4), bem como as estimativas de em quais períodos serão executadas as
iniciativas.

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 43


FLEKS HYBRID MODEL

Cada iniciativa deve ser detalhada de acordo com as informações disponíveis no momento
em que o Roadmap da Iteração do Portfólio está sendo desenvolvido. Idealmente, as
informações necessárias para cada iniciativa são relativas a estimativas de alto nível das
variáveis de valor e dos valores esperados a serem criados por elas. Na maioria dos casos
essas informações são fornecidas pela Análise de Negócio e devem ser elaboradas com o
auxílio de especialistas ou baseadas em dados históricos. Por vezes, isso não é possível e
as informações devem ser coletadas à medida que as iniciativas evoluem, especialmente
quando se tratar de iniciativas mais exploratórias ou com elevado grau de incerteza.

Essas informações são fundamentais para o(a) Gerente de Portfólio obter previsibilidade
e controle sobre o portfólio. O Roadmap da Iteração do Portfólio com as informações
detalhadas funciona como uma linha de base para qualquer stakeholder. Um resumo das
principais entradas e artefatos que podem ser criados nesse evento estão apresentados na
figura abaixo.

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 44


FLEKS HYBRID MODEL

Um aspecto importante a ser considerado nessa reunião é a frequência com que os


responsáveis pelas iniciativas devem se reunir durante a Iteração do Portfólio para a
coordenação das atividades. A princípio, essas reuniões devem ocorrer semanalmente,
e com duração de uma hora, mas isso não é algo obrigatório e dependerá de fatores
como a complexidade das iniciativas, grau de incerteza e a necessidade de atualização das
informações por parte dos stakeholders do portfólio. Mais detalhes sobre esse evento serão
explicados a seguir. É importante ressaltar que tanto a frequência e a duração podem ser
alteradas em diferentes iterações do portfólio.

REUNIÃO DE COORDENAÇÃO

Conforme explicado anteriormente, essa


Reunião de Coordenação deve ter sua
Com o início da execução dos duração e frequência definida na Reunião
trabalhos, é necessário que as de Planejamento do Portfólio. Ela ocorre
equipes coordenem seus tra- sob coordenação do Gerente do Portfólio
balhos durante a Iteração do e os participantes desse evento dependem
Portfólio e realizem adapta- da necessidade das informações a serem
ções em seus planejamentos, trocadas, mas em princípio, todos os
em caso de necessidade. gerentes de subportfólios, programas,
projetos e produtos que tiverem
envolvimento com a Iteração do Portfólio
devem participar, visto que podem contribuir com informações importantes, especialmente
no que se refere a interdependências.

As Reuniões de Coordenação são usadas pelas equipes para obter informações sobre como
está o andamento das iniciativas e para ajustar o trabalho entre duas reuniões consecutivas. O
objetivo principal é observar se as equipes estão no caminho certo para completar o Backlog
da Iteração do Portfólio, entregar os valores acordados e atingir os objetivos pretendidos.

A estrutura das reuniões pode mudar de acordo com a necessidade da organização e a


Gestão do Portfólio. Elas podem variar de um formato definido para um evento mais aberto
baseado em discussão. Cada representante de uma iniciativa tem a oportunidade de falar e
explicar seu ponto de vista sobre a Iteração do Portfólio.

Nesse sentido, os participantes podem informar o que fizeram no período entre uma
reunião e outra, o que pretendem fazer no próximo período, discrepâncias observadas,
levantar impedimentos, riscos, problemas com os stakeholders ou qualquer coisa que esteja
prejudicando seu trabalho.

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 45


FLEKS HYBRID MODEL

Durante a reunião, os representantes das iniciativas têm a chance de reprogramar o curso


de ação e reorganizar suas atividades de acordo com as informações coletadas. No entanto,
as soluções para certos problemas identificados devem ser resolvidas a qualquer momento
diferente ao da reunião. Tipicamente, ao final dessa reunião os participantes precisam saber:

l O que deve ser realizado até a próxima Reunião de Coordenação;

l Ajustes necessários nos seus backlogs individuais;

l Ajustes nos seus roadmaps individuais;

l Que riscos precisam ser geridos com maior atenção; e

l Impedimentos que precisam ser eliminados.

REUNIÃO DE REVISÃO DO PORTFÓLIO

Após concluir a Iteração do Portfólio, o(a) Gerente do Portfólio


se reúne com os representantes das inciativas e o Gerente
do VMO, bem como outros stakeholders necessários, tais
como clientes que receberão os produtos desenvolvidos
no período. O objetivo principal é observar o que foi
concluído com sucesso, permitir o ajuste do Backlog
do Portfólio e das iniciativas, bem como auxiliar o
planejamento da próxima Iteração do Portfólio.

Os representantes das iniciativas apresentam o que foi realizado,


o que foi aceito pelos stakeholders em suas iniciativas individuais e eventuais discrepâncias.
Outras informações importantes que podem ser fornecidas, referem-se às discrepâncias das
variáveis de valor, tais como custos, recursos, riscos ocorridos, entre outras. Dificuldades
observadas e lições aprendidas também podem ser divulgadas para os participantes.

Vale ressaltar que essa é uma reunião de coordenação interna do portfólio e não se refere a
uma reunião de inspeção de produtos, suas funcionalidades e se atendem ou não a critérios
de aceitação, pois isso já deve ter ocorrido nas reuniões de revisão das iniciativas ocorridas
anteriormente a essa reunião.

Ao final da reunião, o Gerente do VMO, do Portfólio e os demais participantes devem ter as


informações necessárias e a capacidade para dar continuidade ao processo de entrega de
valor em um novo ciclo de planejamento.

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 46


FLEKS HYBRID MODEL

REUNIÃO DE RETROSPECTIVA DO PORTFÓLIO

Após a Reunião de Revisão do Portfólio e antes da próxima reunião de Planejamento do


Portfólio, o(a) Gerente do Portfólio se reúne com os representantes das iniciativas que fizeram
parte da Iteração do Portfólio para discutir os pontos altos e baixos da iteração recentemente
concluída, a fim de melhorar o desempenho futuro. Alguns dos assuntos que podem ser
discutidos durante a reunião estão listados abaixo, mas não estão limitados aos exibidos:

l Se os pilares, princípios de gestão e o mindset foram aplicados;

l Lições aprendidas;

l Como ocorreu a interação entre as pessoas;

l Fluxo de comunicação;

l O que deve ser mudado ou mantido;

l Como implementar melhorias; e

l Compromissos a serem assumidos em uma próxima iteração.

Acima de tudo, apesar da informalidade da reunião, o evento é uma chance de promover


o trabalho em equipe e planejar como obter um desempenho melhor. Um exemplo de um
quadro que pode ser utilizado para registrar o que foi discutido na Reunião de Retrospectiva
encontra-se disponível no Guia de Canvas do Modelo FLEKS. A figura abaixo ilustra esse
quadro.

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 47


FLEKS HYBRID MODEL

SUBPORTFÓLIOS E PROGRAMAS

Os eventos previstos para a Gestão do Portfólio devem ser replicados de forma análoga para
subportfólios e programas que tenham alguma iniciativa prevista para o timebox da Iteração
do Portfólio. Seus gestores devem adaptar os nomes dos eventos e artefatos gerados para as
suas respectivas iniciativas e realizar as coordenações previstas com o Gerente de Portfólio
ou de outras iniciativas que, eventualmente, possam ter alguma relação com as suas.

Dessa forma, uma Reunião de Planejamento do Portfólio passa a se chamar Reunião


de Planejamento do Subportfólio ou do Programa e assim sucessivamente para todos os
eventos. Os artefatos como backlogs, roadmaps e planos também devem ser renomeados.

Estas iniciativas devem realizar um planejamento para que todos os eventos referentes às
suas gestões estejam em coordenação com os do portfólio e as informações necessárias
estejam disponíveis para os eventos previstos pela Gestão do Portfólio.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

EVENTOS DA GESTÃO DO PORTFÓLIO \\ 48


FLEKS HYBRID MODEL

EVENTOS DA GESTÃO
DE PROJETO

Existem cinco eventos nessa camada de gestão. Como nos eventos apresentados
anteriormente, existem várias técnicas e ferramentas disponíveis no mercado para a
realização dos eventos. Os modelos apresentados abaixo são apenas sugestões e podem ser
personalizados pela equipe do projeto. Os eventos estão resumidos na figura abaixo.

PLANEJAMENTO DO PROJETO

O principal objetivo do Planejamento do Projeto é ter uma ideia ampla de como as atividades
acontecerão durante o projeto e como poderão ser monitoradas e controladas. Com base nas
informações criadas pela Análise de Negócio e disponíveis no Business Case, o(a) Gerente de
Projeto, assistido(a) pelo(a) Gerente de Produto ou por qualquer especialista considerado
necessário, define o Backlog do Projeto e o Roadmap do Projeto, que é representado pelo melhor
conjunto de releases que, a princípio, irão compor o produto definido pela Análise de Negócio.

Ao final dessa reunião, o(a) Gerente de Projeto


precisa ter definido como as variáveis de valor
É importante ressaltar
serão gerenciadas ao longo do projeto e se
que ao final desse
existem tolerâncias para cada uma delas nos
evento a Equipe de
diferentes releases. Isso incluirá o planejamento,
Desenvolvimento deve
execução e controle destas variáveis, em um nível
estar definida.
suficiente para prover controle e previsibilidade,
mas não em detalhes.

EVENTOS DA GESTÃO DE PROJETO \\ 49


FLEKS HYBRID MODEL

Além disso, é importante ressaltar que qualquer outro plano considerado necessário para a
gestão do projeto deve ser desenvolvido. Alguns desses planos adicionais estão relacionados
aos Stakeholders, às Comunicações, às Aquisições e à Gestão de Mudanças, mas não se
limitam a eles. Atenção especial deve ser dada aos stakeholders envolvidos em cada release e
como a equipe irá gerenciá-los. Sendo assim, o(a) Gerente de Projeto pode tirar proveito das
ferramentas e técnicas tradicionais, como EAP, cronogramas, registros de risco, ou quaisquer
outras consideradas necessárias. É preciso lembrar que estas práticas representam a parte
preditiva do modelo e visam criar a previsibilidade necessária aos diversos stakeholders.

Esses artefatos serão a base para que o(a) Gerente de Produto e a Equipe de Desenvolvimento
possam criar o Backlog do Produto e o Roadmap do Produto, que permitirão guiar o
desenvolvimento dos produtos previstos no projeto. Um resumo das entradas e artefatos
desse evento podem ser encontrados na figura abaixo, mas não se limitam a eles.

Existem muitas maneiras de se definir roadmaps e eles dependem de uma variedade de


fatores, como o tipo de projeto, recursos disponíveis, interdependências, capacidade e
disponibilidade da equipe, entre outros, mas de forma geral apresenta os grandes releases
do projeto e o período estimado de execução. Um projeto pode ter tempos iguais para a
conclusão de releases ou diferentes e eles podem ocorrer em sequência ou mesmo com
algum grau de paralelismo, dependendo das características do projeto. É importante
ressaltar que esse planejamento do Roadmap do Projeto precisa estar coordenado com a
execução do Roadmap do Portfólio ou do Programa em que o projeto fizer parte, caso não
seja um projeto isolado. A figura abaixo apresenta o exemplo de dois tipos de roadmaps com
duração total de três meses dividido em semanas (S1, S2, S3, S4).

EVENTOS DA GESTÃO DE PROJETO \\ 50


FLEKS HYBRID MODEL

Dessa forma, é possível verificar quais releases poderão ser concluídos totalmente ou
parcialmente dentro da uma Iteração do Portfólio.

REUNIÃO DE INÍCIO DO PROJETO

Após concluir o Planejamento do Projeto, o(a) Gerente de Projeto deve se reunir com o(a)
Gerente de Produto e a Equipe de Desenvolvimento para apresentar o Business Case do
Projeto, caso exista, e explicar o planejamento.

No final da reunião, a equipe tem uma visão clara do produto, as principais diretrizes, a
estrutura da equipe do projeto, o comprometimento da equipe e um canal de comunicação
aberto é estabelecido para criar o ambiente interativo e cooperativo necessário para alcançar
os objetivos do projeto e entregar o valor definido. É altamente recomendável, durante esta
reunião, revisar os pilares, o mindset e os princípios do Modelo FLEKS.

REUNIÃO DE REVISÃO DO PROJETO

Ao término de cada release e/ou no término da Iteração do Portfólio a que o projeto pertence,
o(a) Gerente de Projeto deve se reunir com o(a) Gerente de Produto para avaliar discrepâncias em
relação ao planejado para o período. Com base nas informações obtidas na Reunião de Revisão
do Release, que acontece anteriormente a esse evento, é avaliada a necessidade de atualizar o
Backlog do Projeto e do Produto, bem como planos, reavaliar a gestão das variáveis de valor e
reorientar o trabalho a ser realizado no próximo release ou na próxima Iteração do Portfólio.

Esse eventual replanejamento deve estar de acordo com as relações de interdependências


com outras iniciativas, caso existam. As informações coletadas nessa reunião são importantes
insumos para as Reuniões de Coordenação e de Revisão do Portfólio a que o projeto faz parte.

EVENTOS DA GESTÃO DE PROJETO \\ 51


FLEKS HYBRID MODEL

REUNIÃO DE RETROSPECTIVA DO PROJETO

Após o término de todos os releases, o(a) Gerente do Projeto realiza uma reunião com o(a)
Gerente de Produto e a Equipe de Desenvolvimento para discutir os pontos altos e baixos
do projeto recentemente concluído, a fim de melhorar o desempenho futuro. Alguns dos
assuntos que podem ser discutidos durante a reunião estão listados abaixo, mas não estão
limitados aos exibidos:

l Se os pilares, princípios de gestão e o mindset foram aplicados;

l Lições aprendidas;

l Como ocorreu a interação entre as pessoas;

l Fluxo de comunicação;

l O que deve ser mudado ou mantido;

l Como implementar melhorias; e

l Compromissos a serem assumidos em um próximo projeto.

Acima de tudo, apesar da informalidade da reunião, o evento é uma chance de promover


o trabalho em equipe e planejar como obter um desempenho melhor. Um exemplo de um
quadro que pode ser utilizado para registrar o que foi discutido na Reunião de Retrospectiva
encontra-se disponível no Guia de Canvas do Modelo FLEKS.

REUNIÃO DE ENCERRAMENTO DO PROJETO

Um projeto termina quando seus objetivos são atingidos, quando não podem mais ser
alcançados ou quando a justificativa do negócio não existe mais. Independentemente do
motivo, no final do projeto, o(a) Gerente de Projetos realiza uma reunião, juntamente com
o(a) Gerente de Produto, a Equipe de Desenvolvimento e os demandantes do projeto para
encerrar o projeto e formalizar sua conclusão. Outros stakeholders da organização, tais
como o(a) Gerente do Programa, do Portfólio, Analista de Negócio ou qualquer outro julgado
necessário podem participar da reunião.

O objetivo principal é discutir se as metas do projeto foram atingidas, se o valor foi de fato
criado, aspectos positivos e negativos, lições aprendidas ou qualquer outra informação que
possa melhorar o conhecimento da equipe e da organização para projetos futuros.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

EVENTOS DA GESTÃO DE PROJETO \\ 52


FLEKS HYBRID MODEL

EVENTOS DA GESTÃO
DE PRODUTO

A primeira coisa que é preciso entender da Camada de Gestão de Produto é que ela
pode fazer parte de um projeto ou ser apenas utilizada para o desenvolvimento de novas
funcionalidades de um produto existente que está em constante evolução e necessita de
uma criação contínua de valor (value streaming). A diferença fundamental entre a gestão
de um projeto e de um produto é que o projeto terá um fim e um produto não há um prazo
específico para término.

A Camada de Gestão de Produto é onde os produtos realmente se tornam uma realidade


e os valores previstos são criados. Isso é feito por meio de um fluxo de iteração contínuo.
Basicamente, uma iteração é um evento com tempo determinado em que um incremento
potencialmente utilizável é desenvolvido e entregue. Uma iteração possui características
específicas:

l Possui um ou mais valores a serem entregues que devem ser o foco da equipe;

l Deve ser planejada, executada e controlada de acordo com as variáveis de valor;

l Todas as variáveis de valor podem ser fleksibilizadas, dependendo do contexto;

l Pode ser cancelada se o valor não puder ser entregue ou se tornar obsoleto; e

l É o ambiente perfeito para descobrir e aprender sobre o produto e evoluir a forma


de trabalho.

Além da iteração propriamente dita, existem sete eventos previstos para serem realizados,
e eles são exibidos de acordo com a figura abaixo. Os três primeiros eventos são de
responsabilidade do(a) Gerente de Produto e os demais da Equipe de Desenvolvimento.

EVENTOS DA GESTÃO DE PRODUTO \\ 53


FLEKS HYBRID MODEL

PLANEJAMENTO DO PRODUTO

O principal objetivo do Planejamento do Produto é ter uma ideia ampla de como as atividades
acontecerão durante o projeto ou o período previsto para o desenvolvimento do produto,
bem como definir a forma como as variáveis de valor poderão ser monitoradas e controladas.

Baseado nas informações criadas pela Análise de Negócio e/ou nos artefatos da Gestão
de Projetos, o(a) Gerente de Produto, assistido(a) pela Equipe de Desenvolvimento ou por
qualquer especialista considerado necessário, define o Backlog do Produto e o Roadmap do
Produto, que é representado pelo melhor conjunto de releases que, a princípio, irão compor o
produto definido pela Análise de Negócio. Em alguns casos, é possível o desenvolvimento de
planos que auxiliem a gestão do produto. Analogamente ao projeto, o(a) Gerente de Produto
terá informações básicas sobre as variáveis de valor a serem geridas durante o período de
execução. Um resumo das entradas e artefatos desse evento podem ser encontrados na
figura abaixo, mas não se limitam a eles.

Vale ressaltar que, em alguns casos, pode existir


O grau de detalhamento uma semelhança entre esses artefatos e os
desse planejamento deve gerados pela Gestão de Projetos, mas o(a) Gerente
ser o mais enxuto possível de Produto e a Equipe de Desenvolvimento devem
e conter apenas o necessá- manter nesses artefatos apenas aquilo que se
rio para uma execução e refere ao produto em si e não ao projeto como um
controle seguros durante a todo. Destaca-se também que se for o caso de não
iniciativa. se estar realizando um projeto e sim a gestão de
um produto, estes artefatos precisam ser criados.

EVENTOS DA GESTÃO DE PRODUTO \\ 54


FLEKS HYBRID MODEL

PLANEJAMENTO DO RELEASE

Para iniciar um release é necessário detalhar e refinar o escopo ou os itens do backlog


ou qualquer outra informação necessária para gerenciá-lo e fornecer mais informações à
Equipe de Desenvolvimento. Esse refinamento é conduzido pelo(a) Gerente de Produto,
auxiliado pela própria Equipe de Desenvolvimento, por meio de interações com o(a) Gerente
de Projeto, demandantes do projeto, clientes, usuários finais ou qualquer stakeholder
considerado necessário.

Com base no Roadmap do Produto e no Backlog do Produto, o(a) Gerente de Produto define
o Backlog do Release, o Roadmap do Release e confirma o valor a ser entregue pelo Release,
que orientará todas as ações realizadas durante a execução dos trabalhos. Assim como o
Roadmap do Projeto, o Roadmap do Release não é apenas uma questão de prioridades, mas
o melhor conjunto de iterações necessárias para maximizar a criação de valor e minimizar o
risco global.

Existem muitas maneiras de se definir roadmaps


e eles dependem de uma variedade de
fatores, como o tipo de iniciativa, recursos
disponíveis, interdependências, capacidade
e disponibilidade da equipe, entre outros,
mas de forma geral apresenta as iterações
do release e o período estimado de
execução. Uma iteração, dentro de um
mesmo release, deve ter duração idêntica,
mas dependendo do contexto e das
características dos produtos a serem criados
isso pode ser fleksibilizado em acordo com os
stakeholders capazes de tomar essa decisão. A
duração das iterações também é definida neste evento
e, por padrão, pode durar não menos que 1 semana e não mais que 4 semanas, mas estes
não são valores fixos. Esses limites podem ser alterados e são definidos pela Equipe de
Desenvolvimento e pelo(a) Gerente de Produto dependendo das características do que
será produzido e informações disponíveis para a equipe. Fatores como o tipo de entrega,
complexidade, riscos e capacidade da equipe podem auxiliar na definição da duração da
iteração.

As iterações podem ocorrer em sequência ou mesmo com algum grau de paralelismo,


dependendo do contexto, das interdependências, grau de complexidade e da Equipe de
Desenvolvimento. É importante ressaltar que esse planejamento do Roadmap do Release

EVENTOS DA GESTÃO DE PRODUTO \\ 55


FLEKS HYBRID MODEL

precisa estar coordenado com a execução do Roadmap do Portfólio ou do Programa em que


o projeto fizer parte, caso não seja um projeto isolado ou mesmo um produto fazendo parte
da Iteração do Portfólio. A figura abaixo apresenta o exemplo de dois tipos de roadmaps com
duração total de três meses dividido em semanas (S1, S2, S3, S4).

O(A) Gerente de Produto também define como as variáveis de valor serão gerenciadas ao
longo do Release considerando eventuais tolerâncias fornecidas pelo(a) Gerente de Projeto
para o Release. Um resumo das entradas e artefatos desse evento podem ser encontrados
na figura abaixo, mas não se limitam a eles.

EVENTOS DA GESTÃO DE PRODUTO \\ 56


FLEKS HYBRID MODEL

REVISÃO DO RELEASE

Ao término de cada release e/ou no término da Iteração do Portfólio a que a iniciativa


pertence, o(a) Gerente de Projeto deve se reunir com o(a) Gerente de Produto e a Equipe
de Desenvolvimento, bem como o solicitante do projeto ou qualquer outro stakeholder
considerado necessário para apresentar o incremento do produto resultante do release.

O(A) Gerente de Projeto pode apresentar e discutir como as variáveis de valor foram
gerenciadas e as discrepâncias observadas. O(A) Gerente de Produto apresenta o que foi
e o que não foi feito, fornecendo qualquer explicação sobre os problemas e dificuldades
enfrentadas pela equipe durante o release.

A Equipe de Desenvolvimento é responsável por demonstrar os incrementos produzidos,


bem como validar os critérios de aceitação, integração e valor entregue. Em caso de se tratar
de uma entrega exploratória, o incremento produzido pelo release deve estar pronto para
ser usado em um ambiente real, para que o feedback dos stakeholders possa ser coletado
com o objetivo de melhorar o trabalho futuro e aumentar o conhecimento. Em se tratando de
uma entrega mais preditiva, não necessariamente precisa estar funcional, mas é importante
que os solicitantes/clientes tenham condição de avaliar os critérios de aceitação e perceber
que o release acrescenta valor ao projeto ou ao produto.

Ao final da reunião, toda a equipe e os stakeholders discutem ajustes nos backlogs, nos
roadmaps e nos planos. Deve ser observado, também, qual é considerado o melhor curso de
ação para o próximo release em função da reavaliação do contexto ao final do release, das
necessidades e do ciclo de valor. Além disso, a aceitação do incremento deve ser formalizada.
Essa também é uma oportunidade de coletar lições aprendidas para melhorar releases
futuros. Esse evento é de vital importância para coletar informações que servirão para a
Revisão do Projeto e do Portfólio.

PLANEJAMENTO DA ITERAÇÃO

Este é o evento em que a Equipe de Desenvolvimento define quais partes do Produto e, mais
especificamente, do Backlog do Release farão parte da iteração, compondo o Backlog da
Iteração. Além disso, a Equipe de Desenvolvimento pode, se desejar e for necessário, definir
o Roadmap da Iteração, bem como o(s) incremento(s) do produto que serão produzidos.

EVENTOS DA GESTÃO DE PRODUTO \\ 57


FLEKS HYBRID MODEL

A definição de quais itens do backlog que farão


O Backlog da Iteração é parte da iteração é uma questão da capacidade
a melhor combinação de da Equipe de Desenvolvimento, da duração da
entregas que cria o maior iteração e do nível de incerteza que a equipe
valor possível da iteração pode perceber.
com o menor risco global.
A Equipe de Desenvolvimento deve ter em mente
as informações fornecidas pelo(a) Gerente de
Produto referente às variáveis de valor, a estimativa das entregas a serem produzidas, suas
interdependências e as tolerâncias da iteração, se aplicável.

Após a definição do Backlog da Iteração, a Equipe de Desenvolvimento define quem será


responsável por cada entrega, se for o caso.

Os membros da Equipe de Desenvolvimento são os


principais responsáveis por estimar qualquer item do
Backlog e podem ajudar o(a) Gerente de Projetos
com o Planejamento da Gestão de Projetos e o(a)
Gerente de Produto em seus planejamentos.
Isso é fundamental para o planejamento e
controle total do projeto, uma vez que a equipe
de Desenvolvimento é a responsável pelo
desenvolvimento dos produtos e ninguém é mais
adequado do que ela para essa tarefa. O(A) Gerente
de Produto e também o(a) Gerente de Projeto devem
participar da reunião de Planejamento de Iteração, já que
podem contribuir com informações, bem como ajudar com suas experiências de gestão e
liderança. O(A) Gerente de Projeto reúne todos os impedimentos e riscos levantados pela
Equipe de Desenvolvimento e será o responsável por lidar com eles, trabalhando como
facilitador. Em caso de não se tratar de um projeto, mas da gestão de um produto, o(a)
próprio(a) Gerente de Produto realizará essa função.

Outra decisão importante desse evento é o tempo e a frequência com que a equipe irá
realizar a Reunião da Iteração. Por padrão, esse é um evento diário com duração máxima
de 15 minutos, realizado no mesmo local e horário. Mas, a Equipe de Desenvolvimento
pode decidir mudar isso para uma reunião em dias alternados ou mesmo semanalmente.
A Equipe de Desenvolvimento também pode alterar a duração da reunião. A decisão
pode ser em função da complexidade e do nível de incerteza da iteração. Quanto maior a
complexidade e o risco, mais frequente deve ser a Reunião da Iteração, para que a Equipe
de Desenvolvimento tenha a chance de se atualizar e se adaptar. A duração pode ser uma

EVENTOS DA GESTÃO DE PRODUTO \\ 58


FLEKS HYBRID MODEL

função de outras variáveis, tais como tamanho da equipe e duração da iteração. Esta decisão,
teoricamente, deve ser válida para toda a iteração, mas a equipe pode decidir alterar isso, em
função de necessidades não percebidas durante a Reunião de Planejamento da Iteração.

A Equipe de Desenvolvimento deve ter uma definição clara de como os produtos que serão
desenvolvidos na iteração serão medidos em termos de critérios de aceitação para ajudá-los
durante toda a iteração e melhorar as chances de se ter o produto aceito.

Às vezes, durante uma iteração, é necessário realizar alguns experimentos (spikes) para testar
um conceito, uma nova forma de fazer algo ou mesmo uma tecnologia. Assim, a Equipe de
Desenvolvimento pode previamente definir isso no Planejamento da Iteração, caso já tenham
conhecimento. É importante mencionar que experimentos podem surgir durante a iteração.

A identificação de restrições e premissas também é importante e deve ser tratada por


alguém. Pode ser a própria Equipe de Desenvolvimento ou o(a) Gerente de Projeto ou
Produto, dependendo do caso. Uma atenção especial deve ser dada às premissas, uma vez
que são eventos incertos assumidos como verdade e se não se concretizarem, o valor da
iteração pode ser comprometido.

As melhorias definidas em iterações anteriores e os pontos de atenção são os itens finais a


serem listados nesta reunião. Eles são importantes para alertar a Equipe de Desenvolvimento
sobre alguns dos aspectos especiais a serem lembrados durante a iteração. Algumas equipes
consideram desnecessário formalizar o Planejamento de Iteração, mas outras podem querer
organizar as informações em um quadro como o exibido abaixo que se encontra disponível
no Guia de Canvas do Modelo FLEKS.

EVENTOS DA GESTÃO DE PRODUTO \\ 59


FLEKS HYBRID MODEL

REUNIÃO DA ITERAÇÃO

A Reunião de Iteração é usada pela Equipe de Desenvolvimento para obter informações sobre
como está o andamento do processo de criação de valor e para ajustar o trabalho entre duas
reuniões consecutivas. O objetivo principal é observar se a equipe está no caminho certo
para completar o Backlog da Iteração e entregar seu valor. A reunião é um bom momento
para colocar em prática o mindset (foco, customização, trabalho em equipe, aprendizado e
adaptação) e descobrir a melhor maneira de trabalhar em equipe e alcançar objetivos.

A estrutura da reunião pode mudar de acordo com a equipe e a iniciativa. Elas podem
variar de um formato definido para um evento mais aberto baseado em discussão. Cada
membro da Equipe de Desenvolvimento tem a oportunidade de falar e explicar seu ponto
de vista sobre a iteração. É importante destacar que a reunião é elaborada e conduzida pela
Equipe de Desenvolvimento, mas os Gerentes de Projeto e de
Produto devem comparecer à reunião para ajudar a
Equipe de Desenvolvimento e também para tomar
nota de qualquer solicitação ou tomar conhecimento
de qualquer necessidade que a equipe considere
necessária para ajudá-los em seu trabalho diário.
Nesse sentido, a Equipe de Desenvolvimento pode
levantar impedimentos, riscos, problemas com os
Stakeholders ou qualquer coisa que possa alterar o
trabalho da equipe.

Durante a reunião, a Equipe de Desenvolvimento tem


a chance de reprogramar o curso de ação e reorganizar
de acordo com as informações coletadas. No entanto, as soluções para certos problemas
identificados devem ser resolvidas a qualquer momento diferente ao da reunião.

É importante dizer que, independentemente da frequência e duração da Reunião de Iteração,


a Equipe de Desenvolvimento pode decidir se reunir a qualquer momento que julgue
necessário durante toda a iteração para falar sobre algum problema, desafios e questões
pendentes que precisam resolver juntos, bem como trocar informações importantes.

REVISÃO DA ITERAÇÃO

Após concluir a iteração, a Equipe de Desenvolvimento e os Gerentes de Projeto e Produto


se reúnem e convidam o solicitante da iniciativa ou qualquer outro stakeholder considerado

EVENTOS DA GESTÃO DE PRODUTO \\ 60


FLEKS HYBRID MODEL

necessário para apresentar o incremento do produto resultante da iteração. A presença de


Gerentes de Programas, de Portfólio e Analistas de Negócio não é obrigatória, mas pode se
fazer necessária, em algumas circunstâncias.

A reunião é coordenada pelo(a) Gerente de Produto, que apresenta o que foi e o que não foi
feito, fornecendo qualquer explicação sobre os problemas e dificuldades enfrentados pela
equipe durante a iteração. Às vezes, é importante discutir como as variáveis de valor foram
gerenciadas e as discrepâncias observadas.

A Equipe de Desenvolvimento é responsável por demonstrar as funcionalidades das entregas


desenvolvidas, bem como validar os critérios de aceitação, integração e valor entregue. No caso
de uma iteração possuir um caráter exploratório, o incremento produzido pela iteração deve
estar pronto para ser usado em um ambiente real, para que o feedback dos stakeholders possa
ser coletado com o objetivo de melhorar o trabalho futuro e aumentar o conhecimento. Em se
tratando de uma entrega mais preditiva, não necessariamente precisa estar funcional, mas é
importante que os solicitantes/clientes tenham condição de avaliar os critérios de aceitação e
perceber que o que foi desenvolvido acrescenta valor ao projeto ou ao produto.

Ao final da reunião, toda a equipe e os stakeholders discutem ajustes para o Produto e/ou o
Backlog do Release e o que é considerado o melhor curso de ação para a próxima Iteração ou
Release. Além disso, a aceitação do incremento deve ser formalizada.

RETROSPECTIVA DA ITERAÇÃO

Após a Revisão da Iteração e antes da próxima reunião de Planejamento da Iteração, a Equipe


de Desenvolvimento, os Gerentes de Projeto e de Produto se reúnem para discutir os pontos
altos e baixos da iteração concluída, a fim de melhorar o desempenho futuro. Alguns dos
assuntos que podem ser discutidos durante a reunião estão listados abaixo, mas não estão
limitados aos exibidos:

l Discrepâncias no Planejamento da Iteração e fatos, bem como suas razões;

l Se os princípios de gestão e o mindset foram aplicados ou não;

l Lições aprendidas com produtos e processos;

l Se a equipe está trabalhando de forma efetiva;

l Fluxo de comunicação;

l Frequência e duração dos eventos;

l Gestão de variáveis de valor;

EVENTOS DA GESTÃO DE PRODUTO \\ 61


FLEKS HYBRID MODEL

l O que deve ser mudado ou mantido;

l Compromissos a serem assumidos; e

l Solicitações da Equipe de Desenvolvimento para a próxima iteração.

Acima de tudo, apesar da informalidade da reunião, o evento é uma chance de promover


o trabalho em equipe e planejar como a equipe pode ter um desempenho melhor do que
antes. Um exemplo de um quadro que pode ser utilizado para registrar o que foi discutido na
Reunião de Retrospectiva encontra-se disponível no Guia de Canvas do Modelo FLEKS.

A Retrospectiva da Iteração é facilitada pelo(a) Gerente de Projeto e conduzida pelo Gerente


de Produto e pela Equipe de Desenvolvimento. No caso de gestão de produto, apenas o(a)
Gerente de Produto a Equipe de Desenvolvimento farão parte da reunião.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

EVENTOS DA GESTÃO DE PRODUTO \\ 62


FLEKS HYBRID MODEL

BACKLOG, ESTIMATIVAS E TIMEBOX

BACKLOG

UM BACKLOG É UM CONJUNTO DE ITENS, CONTINUAMENTE ATUALIZADOS,


QUE PRECISAM SER PRODUZIDOS EM UMA INICIATIVA.

Geralmente é organizado começando com o item de maior valor até o item de menor valor,
mas o mais importante da criação de um backlog é observar qual o melhor conjunto de itens
de backlog que entregam o maior valor possível com o menor risco global, considerando as
variáveis de valor.

No Modelo FLEKS podem existir diversos backlogs, dependendo do nível de gestão que se
observa. Por exemplo, existe o Backlog do Portfólio, da Iteração do Portfólio, do Programa, do
Projeto, do Produto, do Release e da Iteração. Com exceção feita ao Backlog da Iteração, que é
de responsabilidade da Equipe de Desenvolvimento, todos os outros são de responsabilidade
exclusiva dos seus respectivos gerentes e somente eles possuem autoridade para realizar
modificações.

Uma vez definido um backlog, este não deve ser alterado, a não ser que após alguma
reunião, revisão de iteração do projeto ou produto, de release ou de iteração do portfólio seja
observado que isto se faz necessário para o bem da iniciativa e atendimento às necessidades
dos stakeholders. Os respectivos gerentes responsáveis pelos backlogs se encarregarão de
realizar os ajustes necessários.

BACKLOG, ESTIMATIVAS E TIMEBOX \\ 63


FLEKS HYBRID MODEL

Um refinamento é o ato de reunir


detalhes sobre os itens do backlog até
Durante o planejamento e
que um nível abaixo de gestão ou a
execução das iniciativas, os res-
Equipe de Desenvolvimento esteja certa
ponsáveis pelos backlogs e suas
que o trabalho a ser feito em seguida
equipes trabalham juntos para re-
possa ser realizado. No caso específico
alizar o processo de refinamento.
da Equipe de Desenvolvimento, o(a)
Gerente de Produto e a própria equipe
realizam esse refinamento por meio de
interações com os diversos stakeholders, a fim de obter detalhes, compreender melhor os
produtos, identificar critérios de aceitação, melhorar as estimativas e perceber o valor a ser
criado. O refinamento é uma atividade contínua e deve exigir não mais que 10% do esforço
do tempo de uma iteração.

É importante destacar que o responsável por um backlog deve realizar esse refinamento
durante a execução de uma iteração ou release e se preparar para uma ou duas iterações
seguintes. Dessa forma, ao se realizar o planejamento seguinte, os itens de backlog já
possuirão melhor condição de serem analisados e melhores decisões podem ser tomadas.
Esta lógica funciona para o refinamento do Backlog da Iteração do Portfólio, de um Programa,
do Projeto, do Release e da própria iteração.

ESTIMATIVAS

As estimativas em qualquer iniciativa são sempre um ponto sensível. As abordagens


preditivas tendem a aplicar medidas quantitativas de tempo, custos, riscos, qualidade e
outros parâmetros para criar planos e ganhar previsibilidade. Por outro lado, as abordagens
adaptativas defendem que as estimativas são sempre incertas, especialmente em um
ambiente empírico. Portanto, a tendência é de se aplicar medidas qualitativas para planos de
iterações. Ambas as medidas são válidas, mas é importante ter em mente que elas não são
exclusivas e podem ser usadas em combinação, para o bem da iniciativa.

Durante a Análise de Negócio, o planejamento do portfólio, de um subportfólio, de um


programa e de um projeto, as estimativas são geralmente quantitativas e definidas por
analogia com iniciativas semelhantes ou estimativas de especialistas. O objetivo aqui é ter
uma visão ampla das variáveis de valor que serão gerenciadas durante a iniciativa. Além disso,
prover informações preditivas para os diversos stakeholders da organização, pois acabam por
se tornar a linha de base para o monitoramento e controle de desempenho em diversos níveis,
desde o desenvolvimento do produto até o VMO e a organização como um todo.

BACKLOG, ESTIMATIVAS E TIMEBOX \\ 64


FLEKS HYBRID MODEL

No entanto, se as estimativas forem


realizadas de forma qualitativa, estas
Na Camada de Gestão de Produ- devem, sempre que possível, ter como
to, estimativas quantitativas ou referência as estimativas quantitativas
qualitativas podem ser utilizadas, estabelecidas como parâmetro de
dependendo se o produto a ser de- gestão, especialmente as relativas a
senvolvido tem um caráter mais tempo e custos. Essas medidas realizadas
preditivo ou mais exploratório. pela Equipe de Desenvolvimento
são fundamentais para que se possa
efetuar os planejamentos das próximas
iterações, pois faz-se necessário observar a capacidade real de uma equipe realizar um
conjunto de itens constantes de um backlog em relação ao que se pretendia no momento
inicial de uma iteração.

TIMEBOX

Um Timebox é um período de tempo no qual uma atividade é realizada e visa gerar um ou


mais artefatos ou incrementos de valor. Em virtude da grande diversidade de eventos e da
característica híbrida do modelo, alguns eventos não possuem timebox definido e alguns
outros são apenas um parâmetro inicial de planejamento, visto que as equipes devem definir
seus timeboxes em função do contexto, capacidade da equipe, complexidade e grau de
incerteza existente nas iniciativas. A tabela abaixo apresenta algumas sugestões:

EVENTO TIMEBOX

Todos da Análise Negócio Sem timebox definido


Reuniões de Planejamento 2 horas para cada semana de iteração
Reuniões de Coordenação 1 hora
Reuniões de Revisão e Retrospectiva* 1 hora para cada semana de iteração
Reunião de Início e Encerramento de Projeto 2 horas
Reunião da Iteração** 15 minutos
Iteração*** 1 a 4 semanas
* A Reunião de Retrospectiva do Projeto não segue essa regra e pode durar no máximo 4 horas.
* A Reunião de Revisão do Release não segue essa regra e pode durar no máximo 4 horas.
** Pode variar de acordo com o planejamento da equipe.
*** Pode variar de acordo com a necessidade do produto a ser desenvolvido.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

BACKLOG, ESTIMATIVAS E TIMEBOX \\ 65


FLEKS HYBRID MODEL

MONITORAMENTO E CONTROLE

Diferentes tipos de informações são requeridos


por diversos stakeholders. Os níveis superiores
A organização deve ter
de gestão, bem como clientes, geralmente
controle sobre o progresso
precisam de uma visão ampla, estimativas
das iniciativas em direção
de mais longo prazo, se os objetivos estão no
a seus objetivos em todos
caminho de serem atingidos e se os valores serão
os níveis de gestão.
entregues. Por outro lado, níveis mais baixos de
gestão demandam informações mais detalhadas.

Por meio de reuniões formais ou informais, os stakeholders podem obter as informações


necessárias para acompanharem o desempenho e fazer ajustes. Para tornar isso possível,
todos devem garantir que a comunicação seja aberta e esteja disponível a qualquer momento,
permitindo que o progresso seja monitorado.

Esse fluxo de comunicação começa no nível estratégico da organização, passa pelo VMO, é
incorporado pela Gestão de Portfólio, de Projetos e Produtos. Diretrizes de alto nível são
fornecidas pela organização e o VMO transforma em ações de governança e direciona as
informações para iniciativas específicas. Indicadores estratégicos são estabelecidos.

Na Camada de Gestão de Portfólio, os planos começam a ser criados e diretrizes mais


específicas são estabelecidas. Indicadores intermediários são definidos para que um controle
mais eficaz possa ser estabelecido.

Na Camada de Gestão de Projetos, gestores também criam planos e indicadores, mas estão
interessados em como as variáveis de valor estão sendo gerenciadas de uma forma mais
detalhada e se os planos estão sendo implementados ou não, eventuais discrepâncias,
motivos, tendências e estimativas futuras, para que as ações de controle possam ser
planejadas.

MONITORAMENTO E CONTROLE \\ 66
FLEKS HYBRID MODEL

Por sua vez, Gerentes de Produto e a Equipe de Desenvolvimento estão mais interessados
em verificar se estão executando suas tarefas para entregar os produtos certos, no momento
certo, com a qualidade esperada.

À medida que as iterações ocorrem e os produtos são produzidos, o(a) Gerente de Projeto,
de Produto e a Equipe de Desenvolvimento devem controlar as variáveis de valor (escopo,
tempo, custo, qualidade, riscos e recursos) e o progresso das iniciativas é informado aos níveis
superiores de gestão, tais como um programa ou o portfólio, para que decisões possam ser
tomadas, caso essas decisões ultrapassem o nível de competência das camadas mais baixas
de gestão. Solicitações também são frequentemente enviadas a níveis mais elevados visando
facilitar a execução dos trabalhos.

Decisões podem ser relativas à fleksibilização de qualquer das variáveis de valor, visto que,
conforme explicado anteriormente, todas podem ser fleksibilizadas em função da entrega de
valor, que é a prioridade do Modelo FLEKS. A imagem abaixo ilustra o fluxo de comunicação
que permite o monitoramento e controle da gestão das iniciativas organizacionais.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

MONITORAMENTO E CONTROLE \\ 67
FLEKS HYBRID MODEL

PAPÉIS

Nenhuma iniciativa de negócio é executada apenas por uma pessoa. A prática e a experiência
demonstraram a eficiência do trabalho em equipe para alcançar um objetivo comum.
Sendo assim, o Modelo FLEKS define alguns papéis que são considerados fundamentais
para a sua implantação. O modelo não preconiza papéis e responsabilidades para o grupo
organizacional, visto que existem diversas possibilidades e configurações. No entanto,
os outros papéis e suas responsabilidades estão definidos. É importante ressaltar que,
dependendo do tamanho da organização, alguns papéis podem ser acumulados e uma
mesma pessoa pode exercer o mesmo papel em várias iniciativas simultâneas.

l GERENTE DO VMO: responsável pela gestão do valor dentro de uma organização.

l ANALISTA DE NEGÓCIO: responsável pela conexão entre o negócio e as iniciativas.

l GERENTE DE PORTFÓLIO: responsável pela coordenação de todas as iniciativas


dentro do portfólio organizacional.

l GERENTE DE PROGRAMA: responsável pela coordenação de todas as iniciativas


dentro de um programa organizacional.

l GERENTE DE PROJETO: responsável pelo planejamento e controle do projeto.

l GERENTE DE PRODUTO: responsável pela gestão do desenvolvimento do produto.

l EQUIPE DE DESENVOLVIMENTO: responsável pela construção dos produtos.

PAPÉIS \\ 68
FLEKS HYBRID MODEL

GERENTE DO VMO

O(A) Gerente do VMO que pode ser assessorado(a) por outras pessoas, dependendo
do tamanho e da complexidade de gestão existente na organização, tem como funções
principais, mas não limitadas a essas:

l Garantir o alinhamento estratégico das iniciativas;

l Garantir que o mindset e os princípios de gestão estejam sendo aplicados nas


iniciativas;

l Maximizar a relação valor x riscos do conjunto de iniciativas a serem desenvolvidas;

l Definir processos enxutos e fleksíveis para a condução de suas atividades e das


iniciativas;

l Subdividir os objetivos estratégicos em OKRs;

l Definir e aplicar modelos de seleção de iniciativas;

l Definir quais iniciativas farão parte do portfólio em coordenação com a análise de


negócio;

l Maximizar o fluxo de criação de valor;

l Prover recursos para as iniciativas;

l Definir metodologias, modelos e ferramentas de gestão adequadas para as práticas


híbridas;

l Servir como mentor para outros papéis dentro da estrutura de criação de valor;

l Definir indicadores (KPIs) para monitorar o desempenho das equipes e iniciativas;

l Acompanhar o fluxo de criação de valor em períodos determinados;

l Prover informações sobre o fluxo de criação de valor para a alta gestão e demais
stakeholders;

l Promover a descentralização e autogestão, de acordo com a maturidade e


competência das equipes;

l Realizar a Gestão de Conhecimento dentro do âmbito das iniciativas de criação de


valor; e

l Realizar a Gestão de Risco em alto nível e escalar os riscos para um nível


organizacional, quando necessário.

PAPÉIS \\ 69
FLEKS HYBRID MODEL

ANALISTA DE NEGÓCIO

O(A) Analista de Negócio tem como principal função garantir que as iniciativas criarão o
valor pretendido pelo VMO e os demais stakeholders, tais como clientes e usuários finais.
No Modelo FLEKS esse papel pode ser exercido por uma pessoa específica ou mesmo pelo(a)
Gerente de Projeto ou de Produto, dependendo da complexidade ou tamanho da iniciativa.
Um(a) Analista de Negócio pode exercer esse papel para várias iniciativas simultâneas. Suas
principais funções, mas não limitadas a essas são:

l Coordenar e facilitar todos os eventos relativos à Análise de Negócios;

l Interagir com demandantes de iniciativas, clientes e usuários finais para entender as


suas reais necessidades e prover uma solução viável para todos os stakeholders;

l Identificar requisitos funcionais, não funcionais e entregas de alto nível para as


iniciativas;

l Definir, junto com especialistas, a melhor solução para a necessidade dos


stakeholders;

l Assessorar o VMO e gerentes das iniciativas no que se refere à viabilidade técnica e


financeira;

l Estimar, junto com especialistas, as variáveis de valor necessárias para realizar a


iniciativa;

l Definir critérios de sucesso da iniciativa;

l Realizar um gap analysis entre as necessidades de implementação da solução e a


realidade da organização e das equipes;

l Elaborar o Business Case da iniciativa, quando aplicável, e garantir que ele esteja
válido durante toda a execução da iniciativa, promovendo modificações, quando
necessário; e

l Coordenar com Gerentes de Projeto e Produto que as iniciativas irão entregar o


valor acordado com os diversos stakeholders.

PAPÉIS \\ 70
FLEKS HYBRID MODEL

GERENTE DE PORTFÓLIO, SUBPORTFÓLIO E PROGRAMA

O(A) Gerente de Portfólio, de Subportfólio e de Programa pode ser assessorado(a) por outras
pessoas, dependendo do tamanho e da complexidade de gestão existente na organização. É
importante ressaltar que, em caso de ocorrência de um subportfólio e/ou programa, as funções
são idênticas, mas adequadas ao subportfólio ou ao programa. A diferença fundamental é que,
no caso de subportfólios ou programas, eles serão coordenados pelo(a) Gerente de Portfólio.
Estes papéis possuem suas principais funções listadas abaixo, mas não limitadas a elas:

l Coordenar e facilitar todos os eventos realizados na camada de gestão sob sua


coordenação;

l Sugerir os(as) Gerentes de Projeto e Produto a serem designados para as iniciativas


sob sua coordenação;

l Manter atualizadas as informações relativas ao andamento das iniciativas sob sua


coordenação;

l Prover informações para o VMO, a organização e outros stakeholders sobre a


desempenho das iniciativas sob sua coordenação;

l Garantir recursos para as iniciativas, em coordenação com o VMO e a organização;

l Negociar com stakeholders externos à organização, quando necessário;

l Obter e manter o envolvimento dos stakeholders relacionados às iniciativas sob sua


coordenação;

l Fornecer diretrizes e autorizações de alto nível para as iniciativas sob sua


coordenação;

l Definir tolerâncias em relação às variáveis de valor das iniciativas sob sua coordenação;

l Aprovar a fleksibilização sobre a gestão das variáveis de valor identificadas pelas


iniciativas;

l Monitorar e controlar o progresso das iniciativas sob sua coordenação;

l Liderar toda a equipe sob sua coordenação em direção ao objetivos definidos;

l Criar e promover comunicação aberta e transparência;

l Garantir que o mindset e os princípios de gestão sejam aplicados durante as iniciativas;

l Remover impedimentos fora da competência dos(as) gerentes das iniciativas sob


sua coordenação; e

l Gerenciar os riscos que estejam fora da competência dos(as) gerentes das iniciativas
sob sua coordenação.

PAPÉIS \\ 71
FLEKS HYBRID MODEL

GERENTE DE PROJETO

O(A) Gerente de Projeto é responsável por planejar e controlar o projeto diariamente dentro
dos parâmetros definidos pela gerência superior e/ou pelo(a) Analista de Negócio. Ele ou
ela não deve ser visto como uma “figura de autoridade” pelo(a) Gerente de Produto e pela
Equipe de Desenvolvimento, mas como um líder participando da mesma equipe. As principais
responsabilidades do(a) Gerente de Projeto são:

l Garantir que o projeto esteja alinhado com o Business Case;

l Garantir que práticas e processos preditivos e adaptativos estejam ajustados ao


projeto;

l Assessorar e treinar o(a) Gerente de Produto e a Equipe de Desenvolvimento nas


práticas e processos preditivos e adaptativos;

l Participar dos eventos de outras camadas de gestão, quando necessário;

l Coordenar e facilitar todos os eventos na camada de Gestão de Projetos;

l Facilitar eventos na camada de Gestão de Produtos;

l Criar os artefatos da camada de Gestão de Projetos e adaptá-los durante o projeto;

l Obter aprovação para os artefatos criados na Camada de Gestão de Projetos,


quando necessário;

l Solicitar recursos para o projeto;

l Negociar com fornecedores internos e externos, quando necessário;

l Obter e manter o envolvimento dos stakeholders do projeto;

l Fornecer diretrizes e autorizações para o(a) Gerente de Produto e a Equipe de


Desenvolvimento;

l Definir tolerâncias relacionadas às variáveis de valor;

l Solicitar fleksibilização para as variáveis de valor, quando necessário;

l Aprovar fleksibilização relacionadas às variáveis de valor geradas pelo(a) Gerente de


Produto e pela Equipe de Desenvolvimento;

l Monitorar e controlar o progresso do projeto;

l Coordenar eventos do projeto com outros(as) Gerentes de Projeto, Programa e


Portfólio, quando necessário;

l Gerenciar as variáveis de valor ao longo do projeto;

l Reunir informações e preparar relatórios do projeto, quando solicitado;

PAPÉIS \\ 72
FLEKS HYBRID MODEL

l Manter os documentos e registros do projeto atualizados;

l Criar e promover comunicação aberta e transparência;

l Garantir que os pilares, o mindset e os princípios de gestão sejam aplicados durante


o projeto;

l Remover os impedimentos levantados pelo(a) Gerente de Produto e pela Equipe de


Desenvolvimento;

l Gerenciar os riscos do projeto;

l Escalar riscos fora de sua competência;

l Escalar questões e impedimentos fora de sua competência;

l Garantir que todos os eventos no nível de Gestão de Produtos ocorram e que os


tempos de duração sejam cumpridos. Participar e facilitar todos os eventos da
camada de Gestão de Produtos; e

l Auxiliar o(a) Gerente de Produto a resolver conflitos.

GERENTE DE PRODUTO

O(A) Gerente de Produto é a pessoa responsável por coordenar o desenvolvimento do


produto e entregar o valor proposto pela iniciativa. Ele ou ela entende como os produtos
devem ser criados para atender às necessidades da organização e do solicitante da iniciativa.
Vale ressaltar que no Modelo FLEKS, o(a) Gerente de Produto pode trabalhar em coordenação
com um projeto ou isoladamente, no caso de um value streaming. Dotado(a) de habilidades
gerenciais e de liderança, ele ou ela também pode trabalhar como líder técnico, mas isso não
é obrigatório. As principais responsabilidades do(a) Gerente de Produto são:

l Coordenar a seleção e a atribuição da Equipe de Desenvolvimento;

l Elicitar requisitos junto aos stakeholders da iniciativa;

l Participar dos eventos de outras camadas de gestão, quando necessário;

l Maximizar o trabalho realizado pela Equipe de Desenvolvimento;

l Criar e promover a comunicação aberta e transparência;

l Criar os artefatos da camada de Gestão de Produto e adaptá-los durante a iniciativa;

l Obter aprovação para os artefatos criados na Camada da Gestão de Produto,


quando necessário;

l Solicitar recursos para a iniciativa;

PAPÉIS \\ 73
FLEKS HYBRID MODEL

l Garantir a aplicação dos pilares, do mindset e dos princípios de gestão;

l Gerenciar as variáveis de valor durante a execução do desenvolvimento dos


produtos;

l Solicitar fleksibilização das variáveis de valor, quando necessário;

l Coordenar sessões de refinamento e garantir que itens do Backlog estejam


suficientemente detalhados para serem selecionados para uma iteração;

l Participar de todas as reuniões de iteração e aconselhar sobre tomada de decisão,


quando necessário;

l Ajudar a Equipe de Desenvolvimento a resolver conflitos;

l Garantir que a Equipe de Desenvolvimento se concentre no trabalho a ser realizado;

l Garantir que a Equipe de Desenvolvimento esteja trabalhando apenas no escopo de


cada iteração;

l Fornecer aos níveis superiores de gestão as informações necessárias sobre as


atividades em andamento de cada iteração, quando solicitado; e

l Assessorar outros níveis de gestão sobre assuntos técnicos, se necessário.

EQUIPE DE DESENVOLVIMENTO

A Equipe de Desenvolvimento é responsável por planejar, executar e controlar todas as


atividades consideradas necessárias para criar os produtos e fornecer cada valor da iteração.
Não há um tamanho específico para equipes no Modelo FLEKS em virtude da diversidade
de projetos que se pode realizar em uma abordagem híbrida. Normalmente, em partes do
escopo mais adaptativa preconiza-se equipes pequenas (até 10 pessoas), mas isto não é uma
regra fixa, e dependerá do tipo do trabalho a ser realizado.

Espera-se que a Equipe de Desenvolvimento seja auto-organizada, tenha competência e


maturidade suficiente para decidir como transformar os Itens do Backlog em incrementos
valiosos. No entanto, isso nem sempre acontece em algumas organizações. Nesse caso, a
equipe pode ser aconselhada e liderada pelo(a) Gerente de Produto ou mesmo pelo(a)
Gerente de Projeto, uma vez que ele ou ela é responsável por aconselhar e treinar a equipe
sobre práticas e processos preditivos e adaptativos.

Dentro de uma Equipe de Desenvolvimento, não há hierarquia e, independentemente das


habilidades e conhecimentos individuais, é importante ter em mente que ela deve trabalhar

PAPÉIS \\ 74
FLEKS HYBRID MODEL

em equipe, pois é, em grande parte, responsável pelo sucesso da iteração. As principais


responsabilidades da Equipe de Desenvolvimento, mas não limitadas a elas são:

l Realizar todas as atividades planejadas para os eventos da Iteração;

l Criar todos os artefatos relativos aos eventos sob sua responsabilidade;

l Participar dos eventos de outras camadas de gestão, quando solicitado;

l Criar e promover a comunicação aberta e a transparência;

l Garantir que os pilares, o mindset e os princípios de gestão sejam aplicados;

l Participar de sessões de refinamento e garantir que os Itens do Backlog com maior


prioridade sejam suficientemente detalhados para serem selecionados para uma
iteração;

l Fornecer aos gerentes as informações necessárias sobre as atividades em


andamento de cada iteração, quando solicitado;

l Assessorar os gerentes em assuntos técnicos;

l Estimar os Itens do Backlog em relação a variáveis de valor;

l Solicitar fleksibilização das variáveis de valor para os Gerentes de Produto e/ou


Projeto;

l Escalar riscos fora da competência da Equipe de Desenvolvimento; e

l Identificar impedimentos ou qualquer coisa que possa prejudicar o trabalho.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

PAPÉIS \\ 75
FLEKS HYBRID MODEL

NOTAS FINAIS

FERRAMENTAS DE SUPORTE

Existem muitas ferramentas disponíveis no mercado para apoiar os eventos e cada


organização pode criar suas próprias ferramentas. No entanto, o Modelo FLEKS possui um
kit de ferramentas para facilitar sua implementação e está disponível para download gratuito
em www.fleksmodel.com.

COLABORADORES

É muito difícil construir algo sozinho. Suas lógicas e verdades podem não ser absolutas.
Produtos valiosos emergem da iteração entre pessoas e ideias que levam à evolução e
melhoria dos resultados. Durante a criação do Modelo FLEKS, várias pessoas contribuíram de
alguma forma ou forneceram recomendações valiosas para aperfeiçoar o modelo. Reconheço
que, sem a ajuda deles, o Modelo FLEKS não teria a mesma qualidade e aplicabilidade.

Andre Barcaui, Bianca Luongo, Carla Krieger, Carlos Alexandre Espanha, Carlos Magno da Silva
Xavier, Christina Barbosa, Cristiane de Lima, Déborah Zavistanavicius Zapata, Diego Borges
Sechin, Elisabete Saman, Érico Vinicius do Lago Afonso, Fabio Cruz, Gino Terentim, Gutenberg
Silveira, João Sarmento, Júlio César Cardoso Tavares, Luiz Guilherme Carvalho, Norberto
Almeida, Márcio Fructuoso, Maurini Brito, Roberto Pons, Rogerio Prado Manso, Rosiana da
Silva Bertolazi, Sueli Marquet, Vitor Massari e todos aqueles que, ao longo de minha carreira,
me ensinaram a fazer a boa gestão.

CLIQUE AQUI PARA VISITAR NOSSO WEBSITE


www.fleksmodel.com

NOTAS FINAIS \\ 76

Você também pode gostar