Escolar Documentos
Profissional Documentos
Cultura Documentos
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
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
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 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.
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
l BLURRY (OBSCURO): algo sobre o qual a forma ou formato não está claro.
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).
INTRODUÇÃO \\ 6
FLEKS HYBRID MODEL
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.
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 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
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
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.
PRINCÍPIOS
INTRODUÇÃO \\ 11
FLEKS HYBRID MODEL
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.
INTRODUÇÃO \\ 12
FLEKS HYBRID MODEL
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.
INTRODUÇÃO \\ 13
FLEKS HYBRID MODEL
ORGANIZAÇÃO
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.
ORGANIZAÇÃO \\ 14
FLEKS HYBRID MODEL
SUSTENTABILIDADE
ESTRATÉGIA
ORGANIZAÇÃO \\ 15
FLEKS HYBRID MODEL
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.
GESTÃO DA MUDANÇA
ORGANIZAÇÃO \\ 17
FLEKS HYBRID MODEL
ORGANIZAÇÃO \\ 18
FLEKS HYBRID MODEL
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.
GOVERNANÇA
GESTÃO DE RISCOS
GESTÃO DE CONHECIMENTO
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.
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
SELEÇÃO DE INICIATIVAS
l Alinhamento estratégico;
REVISÃO DE RESULTADOS
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
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.
PRODUÇÃO
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.
ANÁLISE DE NEGÓCIO
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.
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.
PRODUÇÃO \\ 29
FLEKS HYBRID MODEL
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.
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.
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.
PRODUÇÃO \\ 31
FLEKS HYBRID MODEL
FLUXO DE VALOR
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
FLUXO DE VALOR \\ 33
FLEKS HYBRID MODEL
O FLUXO ASCENDENTE
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.
FLUXO DE VALOR \\ 34
FLEKS HYBRID MODEL
EVENTOS DA
ANÁLISE DE NEGÓCIO
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
É 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.
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 SIMPLE (SIMPLES): ser simples de ser utilizada e mantida durante seu ciclo de vida.
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.
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:
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
l Objetivos da iniciativa;
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.
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 Alocar recursos;
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
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 Qual a estimativa em alto nível das variáveis de valor a serem geridas no período?
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.
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.
REUNIÃO DE COORDENAÇÃO
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.
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.
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.
l Lições aprendidas;
l Fluxo de comunicação;
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.
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.
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.
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.
Dessa forma, é possível verificar quais releases poderão ser concluídos totalmente ou
parcialmente dentro da uma Iteração do Portfólio.
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.
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.
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 Lições aprendidas;
l Fluxo de comunicação;
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.
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.
l Possui um ou mais valores a serem entregues que devem ser o foco da equipe;
l Pode ser cancelada se o valor não puder ser entregue ou se tornar obsoleto; e
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.
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.
PLANEJAMENTO DO RELEASE
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.
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.
REVISÃO 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.
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.
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
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.
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.
REVISÃO DA ITERAÇÃO
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.
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
l Fluxo de comunicação;
BACKLOG
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.
É 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
TIMEBOX
EVENTO TIMEBOX
MONITORAMENTO E CONTROLE
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 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.
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.
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 Servir como mentor para outros papéis dentro da estrutura de criação de valor;
l Prover informações sobre o fluxo de criação de valor para a alta gestão e demais
stakeholders;
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 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
PAPÉIS \\ 70
FLEKS HYBRID MODEL
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 Definir tolerâncias em relação às variáveis de valor das iniciativas sob sua coordenação;
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:
PAPÉIS \\ 72
FLEKS HYBRID MODEL
GERENTE DE PRODUTO
PAPÉIS \\ 73
FLEKS HYBRID MODEL
EQUIPE DE DESENVOLVIMENTO
PAPÉIS \\ 74
FLEKS HYBRID MODEL
PAPÉIS \\ 75
FLEKS HYBRID MODEL
NOTAS FINAIS
FERRAMENTAS DE SUPORTE
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.
NOTAS FINAIS \\ 76