# NUPP

Princípios Quase Universais de Projetos

[image]

Esta é uma versão descarregável do manual online (https://omimo.org/pt/modules/nupp/), gerada em 2026‑07‑02. Consulte o site para versões mais recentes.

O NUPP vem do OMIMO (https://omimo.org/pt/), uma família de módulos abertos e minimalistas.

Este manual pode ser utilizado e distribuído livremente sob a licença Creative Commons Attribution 4.0 International.

O OMIMO é cofinanciado pela União Europeia. As opiniões e pontos de vista expressos são, no entanto, apenas do OMIMO e não refletem necessariamente os da União Europeia ou da EPOS VZW. Nem a União Europeia nem a entidade que concede o financiamento podem ser responsabilizadas por eles.

Traduzido por: Edi Venturin


## Introdução

NUPP (em inglês Nearly Universal Principles of Projects) é uma coleção de princípios quase universais, a serem seguidos em todos os projetos para maximizar seu sucesso, independentemente das metodologias e abordagens utilizadas.

Qualquer recurso ou método disponível para executar projetos depende de algum desses princípios quase universais (NUPs, ou Nearly Universal Principles). Porém, é preciso ter em mente que:

  - Nem sempre todos os NUPs são levados em conta, embora seja útil para os profissionais de gerenciamento considerálos como um todo e não separadamente.
  - Os princípios por trás desses recursos ou métodos não são geralmente claros o suficiente, e a maioria dos profissionais de gerenciamento de projetos está tão focada em detalhes práticos que se esquece dos princípios e adota práticas não consistentes com esses princípios.

NUPP é compatível com todos os principais métodos, sistemas, recursos e frameworks, como PRINCE2^(®), Guia PMBOK^(®), P3.express, PM², DSDM^(®), XP e Scrum. Embora possa não ser compatível com algumas interpretações desses sistemas, NUPP procura encorajar os profissionais a reconsiderar suas interpretações.

NUPP é uma coleção dos seguintes princípios quase universais (NUPs):

  - NUP1 — Preferir resultados e a verdade a grupos ou afiliações
  - NUP2 — Preservar e otimizar energia e recursos
  - NUP3 — Ser sempre proativo
  - NUP4 — Lembrar que uma corrente é tão forte quanto seu elo mais fraco
  - NUP5 — Não fazer nada sem um propósito claro
  - NUP6 — Usar elementos repetíveis


## NUP1 Preferir resultados e a verdade a grupos ou afiliações

[image]

Todos nós temos uma tendência natural de pertencer a grupos, o que muitas vezes transcende sua forma geral, cria afiliações fortes e pode causar problemas. Com isso, perdemos muito mais do que ganhamos por causa dessas afiliações. Podemos nos tornar especialistas mais profissionais e eficientes se não limitarmos nossa identidade e preferências a determinados grupos.


### Exemplo: Ágil vs Waterfall

Numa época em que a regra geral era usar abordagens preditivas no desenvolvimento de software, um grupo de entusiastas teve a coragem de experimentar abordagens adaptativas e chamou essa abordagem de “Agile” (Ágil). Foi uma ótima iniciativa para não limitar as escolhas ao que parecia ser necessário à época. Ainda há muitas pessoas entusiasmadas e orientadas para resultados na comunidade Ágil, mas infelizmente, existem também algumas pessoas nesta comunidade que transformam a abordagem Ágil em um culto e consideram todos aqueles que estão de fora como inimigos. Isso causa problemas diversos, incluindo:

  - Isso impede que aprendam com pessoas fora do seu grupo
  - Desencoraja pessoas de fora a aprender com eles
  - Torna a afiliação ao grupo mais importante do que seu real propósito, o que por sua vez impede muitos de seus membros de compreender o verdadeiro significado de Agilidade

Esses problemas podem ser mitigados, ou até eliminados, utilizando-se “Ágil” apenas como rótulo quse se refere à abordagem de desenvolvimento, e não a uma comunidade com membros; e tendo-se pessoas que se consideram criadores, solucionadores de problemas e líderes, e que veem Agilidade simplesmente como uma ferramenta facilitadora, e não como sua identidade.

Não há uma guerra Ágil-Waterfall para verdadeiros profissionais.


### Exemplo: PRINCE2^(®) vs Guia PMBOK^(®)

Há muitos profissionais na comunidade que se associam ao PRINCE2^(®) ou ao Guia PMBOK^(®) (geralmente devido à sua localização geográfica) sem estar familiarizado com o outro. Todos podemos ter nossas preferências por determinados recursos, mas não devemos vêlos como parte de nossa identidade. Mais importante ainda, devemos nos familiarizar com o máximo de recursos possível para ampliar nossa perspectiva e opções.

O verdadeiro profissional está aberto a todas as idéias, buscando por elas, aprendendo sobre elas e utilizando-as como e quando necessário, sem afiliar-se a nenhuma.


### Exemplo: Aprendizado contínuo

Afiliações satisfazem um indivíduo devido ao sentimento de pertencimento que geram, mas não o impulsionam a aprender, e às vezes, até o desencorajam de aprender por medo de perdê-las. Quando você é livre, um especialista sem afiliações, é necessário preencher as lacunas com aprendizado: com o aprendizado contínuo.

Aquilo em que acreditamos hoje não representa a verdade. É apenas a nossa melhor compreensão até o momento, que deve ser aprimorada à medida que evoluímos. Há algo errado se as nossas ideias forem exatamente as mesmas de alguns anos atrás. E isso também se aplica aos NUPP: se você voltar após alguns anos e encontrar exatamente a mesma coisa, deve ficar desconfiado.


### Exemplo: Abertura e Diálogo

Ao discordar de alguém, certifique-se de direcionar sua objeção à idéia e não à pessoa. Isso ajuda a evitar muitas tensões. Da mesma forma, quando alguém discordar de você ou falar algo negativo a seu respeito, tente não interpretar como uma guerra contra você, mas sim como uma discussão de idéias e mantenha-se aberto a isso. Não ouça para responder, ouça para entender; e trabalhe com a outra pessoa para aprimorar a idéia.

Algumas pessoas podem intencionalmente focar em você em vez da idéia; nesse caso, você deve ajudá-las a se concentrar na idéia em vez de em você antes de prosseguir e tentar manter essa postura ao longo da conversa.


## NUP2 Preservar e otimizar energia e recursos

[image]

Recursos são limitados. Os recursos disponíveis para um projeto são limitados, assim como a energia mental que você possui para tomar boas decisões. Você deve preservar e otimizar esse recurso para si mesmo e para o projeto, e ajudar os outros membros da equipe a fazerem o mesmo.


### Exemplo: A regra 80/20

Uma grande parte dos possíveis benefícios da gestão de projetos pode ser alcançada com um pequeno esforço. Na maioria dos casos, visar 100% dos benefícios possíveis é muito caro e injustificável. É preciso considerar essa regra em tudo o que se faz e incentivar os outros a fazerem o mesmo.


### Exemplo: Fadiga de decisão

Nós usamos uma única fonte de energia mental para tomar todos os tipos de decisões, bem como para expressar força de vontade. Se você esgota essa fonte tomando decisões desnecessárias ou pouco importantes, terá menos energia para as decisões importantes, o que pode levar a resultados ruins. Essa é uma das razões pelas quais você deve evitar o microgerenciamento (o princípio de “gerenciar por exceção” do PRINCE2^(®)).

Conflitos relacionados a idéias podem ser úteis, mas aqueles que envolvem pessoas geralmente são prejudiciais ao projeto, e uma das consequências é que esgota a energia mental dos membros da equipe. Se você perceber esse tipo de conflito, faça o possível para identificar a causa raiz e resolvê-la.


### Exemplo: Cuide de si mesmo!

As decisões que você toma e a força de vontade que você expressa consomem sua fonte de energia mental. Por outro lado, essa fonte é preenchida com energia quando você dorme e se alimenta adequadamente. Portanto, você deve cuidar bem de si mesmo: certifique-se de ter sono suficiente e descanso, e coma bem. Se você tiver hábitos prejudiciais ou problemas com o sono, não precisa lidar com isso sozinho; existem muitos especialistas que podem ajudá-lo a resolver tais problemas. A atividade física também pode ajudar nessa fonte de energia, embora os estudos ainda não sejam conclusivos sobre esse assunto.

Tente incentivar os membros da equipe a fazerem o mesmo que você. Primeiro, certifique-se de que eles trabalhem em um ritmo sustentável e sem muitas horas extras. Em seguida, se tiver escolha, tente oferecer alimentos energéticos e saudáveis, lanches e bebidas durante o horário de trabalho.


### Exemplo: Equilíbrio vida profissional-pessoal

Muitos de nós amamos o que fazemos, mas isso ainda não é tudo o que precisamos ter na vida. Da mesma forma que você otimiza seu trabalho, você deve planejar e implementar idéias em sua vida pessoal, de maneira que a tornem alegre e feliz. Quando você está mais feliz, também pode ser mais bem-sucedido no trabalho. Se puder, tente incentivar os membros da sua equipe a fazerem o mesmo.


### Exemplo: Motivação

Motivação é um conceito complexo. Existem recursos interessantes e úteis sobre o assunto, assim como muitos que não tem base científica. No entanto, é importante aprender sobre isso e utilizá-la de maneira contínua, pois aumenta a energia mental da equipe e a possibilidade de alcançar melhores resultados para o projeto.

A motivação pode ser tão simples como fazer com que as pessoas saibam que você reconheceu o bom trabalho delas com um sorriso gentil ou um simples “obrigado”. No entanto, é preciso ter cuidado, pois muitas das formas comuns de motivação têm um efeito negativo, como recompensas monetárias pequenas.


### Exemplo: Colaboração e trabalho em equipe

Pessoas que estão colaborando têm o poder de criar resultados melhores, mas ainda mais importante, os seres humanos são seres sociais e gostam de fazer parte de um grupo. Se você conseguir eliminar os aspectos negativos do trabalho em equipe e criar um ambiente agradável, os membros da equipe ficarão mais felizes no projeto.

No entanto, devemos estar atentos às diferenças entre os indivíduos: alguns precisam de mais calma, concentração e solidão do que outros; em geral, o equilíbrio é necessário.


### Exemplo: Cultura de espírito de equipe

Existe uma tendência de diferentes partes interessadas criarem ou considerarem subgrupos e causarem tensões com outros grupos; por exemplo, pessoas focadas nos aspectos comerciais do projeto vs. pessoas que estão criando o produto. Essa tensão consome muita energia de ambos os lados, e é uma das razões pelas quais devemos tentar construir criar uma cultura baseada no espírito de equipe, onde todos trabalham juntos para um mesmo objetivo.


### Exemplo: A sabedoria das massas

Quando um grande número de pessoas diversas se reúne e trabalha em um ambiente facilitado, há o potencial de obter muito bons resultados, idéias e soluções, que podem ser até melhores do que aquelas provenientes de especialistas individuais.

Se você tiver essa opção, pode utilizá-la regularmente para pedir aos membros da equipe que o ajudem a resolver problemas difíceis no projeto. Além da possibilidade de obter bons resultados, isso também permite que os membros da equipe saibam que suas opiniões são valorizadas e que desempenham um papel importante no projeto, o que por sua vez, aumenta seu nível de energia. A Atividade E02 do P3.express é um exemplo de uso da sabedoria das massas em projetos.


### Exemplo: Chefe Facilitador de Projetos

Se você é um gerente de projetos, a maioria das coisas que você faz possui uma natureza de facilitação (ou pelo menos deveriam ter). Por outro lado, você pode eventualmente perceber que os membros da equipe tiveram experiências ruins com gerentes de projetos no passado, e que essas experiências estão impactando o relacionamento deles com você: uma parte da energia deles é gasta analisando seu comportamento em busca de possíveis ameaças, em vez de confiar em você. Nesse caso, você pode alterar seu título de gerente de projetos para Chefe Facilitador de Projetos. Afinal, é isso que você realmente faz no projeto.


## NUP3 Ser sempre proativo

[image]

Temos uma tendência natural de sermos reativos. Isso pode nos ajudar a preservar energia lidando com questões sem importância, ou pode nos dar melhores resultados quando estamos lidando com algo em que somos completamente incompetentes. Essas situações são diferentes dos nossos projetos, e aqui podemos obter melhores resultados sendo proativos.


### Exemplo: Planejamento

Se você precisa ir para um local novo e está atrasado, pode começar a dirigir imediatamente para “economizar tempo” e lidar com possíveis problemas conforme surgem. A abordagem proativa é reservar um tempo no início para configurar seu sistema de navegação e obter a rota mais rápida com base no trânsito, possíveis acidentes e bloqueios, e então começar a dirigir; isso significa gastar tempo antes da execução para evitar problemas mais tarde, e assim economizar tempo no final.

Ao contrário do que algumas pessoas pensam sobre projetos Ágeis, o planejamento é sempre necessário. Trata-se apenas do tipo e do nível de detalhes dos planos. Planejar antes de executar é uma abordagem proativa.

Lembre-se da citação: “Dê-me seis horas para cortar uma árvore e eu passarei as primeiras quatro afiando o machado”.

Em um projeto preditivo, você pode gastar 4 horas afiando o machado, porque tem certeza de que vai cortar uma árvore. Em um projeto Ágil, você não tem certeza se vai cortar uma árvore, juntar galhos quebrados, colher grama, extrair carvão ou qualquer outra coisa. No entanto, você ainda precisa estar preparado de forma geral para todas essas situações (saber onde fica a loja de ferragens mais próxima) e ter uma preparação específica (afiar o machado) quando for se concentrar em uma solução específica; isso é planejamento.


### Exemplo: Planejando o planejamento

Planejar a maneira como vamos executar o projeto é uma abordagem proativa. Essa proatividade pode até ser estendida ao planejar a forma como iremos planejar a execução; esse é o conceito de plano de gerenciamento do Guia PMBOK^(®), estratégias de gerenciamento do PRINCE2^(®) e abordagens do DSDM^(®).


### Exemplo: Planejamento contínuo

A realidade raramente corresponde ao que planejamos, e está tudo bem - mas precisamos adaptar continuamente nossos planos para garantir que eles permaneçam realistas e práticos. Devemos fazê-lo assim que a adaptação for necessária, e não quando nos depararmos com problemas. Essa é uma abordagem proativa.


### Exemplo: Gerenciamento de riscos

Todo o conceito de gerenciamento de riscos é baseado na proatividade: ao enfrentar eventos incertos, em vez de esperar para ver o que acontece e reagir a eles, pensamos em possibilidades e impactos, consideramos respostas e provavelmente fazemos algo a respeito antes que aconteça.

Observe que o que fazemos em projetos é sério; às vezes, trata-se da vida das pessoas.


### Exemplo: Definir papéis e responsabilidades

É possível deixar os membros da equipe do projeto trabalharem sem papéis e responsabilidades claras, e mais cedo ou mais tarde uma forma de papéis e responsabilidades surgirá, mas isso é custoso demais e pode não funcionar bem no final das contas. A abordagem proativa é defini-los cedo e adaptá-los conforme necessário. Isso facilita o trabalho para todos, e eles podem se concentrar em produzir algo, em vez de decidir quem faz o quê.

O número e a variedade de papéis depende do tipo e do tamanho do projeto; pode ser uma definição simples como a do Scrum, algo moderado como o do P3.express, ou algo abrangente como os do DSDM^(®) e PRINCE2^(®). No entanto, não se esqueça de que as descrições de papéis nesses métodos são apenas sobre atividades de gestão, e você sempre precisa adicionar também descrições de papéis para aspectos técnicos.


### Exemplo: Opções disponíveis

Deve-se encerrar o projeto prematuramente ou continuar com ele?

Raramente existem apenas duas opções, mesmo que a pergunta sugira isso. Você precisa adotar uma abordagem proativa e considerar todas as suas opções antes de tomar uma decisão. Talvez você possa redefinir o escopo do projeto; talvez você possa pausá-lo até que algo mais fique claro; ou talvez você possa alterar a abordagem do projeto (por exemplo, terceirização), etc.


### Exemplo: Pensamento crítico

Todos nós temos muitos viéses que nos ajudam a sobreviver, por um lado, e nos enganam levando a tomar decisões ruins, por outro. Quando se trata de tomar decisões importantes sobre o projeto, é melhor pausar por um momento e considerar todos os viéses que podem impactar nossa decisão antes que eles causem problemas.

Como referência, você pode usar a lista de viéses cognitivos disponível na Wikipedia.

Existem até mesmo estruturas de tomada de decisão que você pode utilizar para tomar decisões melhores. No início, pode ser uma distração e até mesmo irritante usá-las, mas logo você se acostuma e tira proveito delas sem muito esforço consciente.


### Exemplo: Transparência

Não gostamos de atrasos no projeto ou de enfrentar qualquer outro tipo de problema, mas isso não significa que devemos escondê-los. Você deve ser transparente e informar os envolvidos, pois alguns deles podem ser capazes de ajudar, e além disso, saberão dos problemas e suas consequências mais cedo ou mais tarde, e alguns podem até exigir ações antecipadas de sua parte (por exemplo, aceitar a consequência negativa).


### Exemplo: Comunicar-se de forma eficaz

Pode haver muitos casos em que você envia relatórios para as partes interessadas e elas não lhe dão nenhum feedback. Você pode acreditar que está tudo bem só porque não há feedback negativo, embora isso possa não ser verdade. Você precisa ser proativo e verificar se eles realmente utilizaram o relatório e se ele cumpriu o propósito, utilizando as informações recebidas para ajustar seu método de comunicação; caso contrário, esse problema oculto pode causar sérios problemas mas tarde, quando for difícil de corrigir.


### Exemplo: Assumir a responsabilidade

É fácil culpar os outros por resultados insatisfatórios. Por exemplo, você pode querer que sua organização lhe dê plena autoridade para mudar tudo no projeto e fazê-lo perfeitamente, mas eles não o fazem e, como consequência, o projeto falha. Isso não é uma abordagem proativa.

A abordagem proativa é assumir a responsabilidade e fazer tudo o que estiver ao seu alcance dentro das restrições. Você não pode esperar que a organização confie plenamente em você e lhe dê tudo na esperança de obter bons resultados, especialmente quando eles já viram tantos projetos fracassados. O que você precisa fazer é realizar uma pequena melhoria dentro das restrições estabelecidas, usar isso para conquistar um pouco de confiança, alguns recursos adicionais e um pouco mais de tolerância às restrições, e então utilizar isso para uma melhoria um pouco maior, e assim por diante, até atingir o objetivo ideal.


## NUP4 Lembrar que uma corrente é tão forte quanto seu elo mais fraco

[image]

Existem vários domínios em projetos, e todos precisam de atenção; devemos ter uma perspectiva holística do projeto. Prestar atenção a um domínio aparentemente importante (por exemplo, o tempo) não é suficiente, pois todos os domínios interagem e não funcionam corretamente a menos que todos recebam a devida atenção.


### Exemplo: Tudo se resume ao prazo!

Digamos que você esteja construindo algo para os Jogos Olímpicos. Isso tem um prazo muito rigoroso, o que torna a gestão do tempo muito importante. Certo, mas será que é só isso? E se a qualidade for tão baixa que seja necessário refazer o trabalho depois de um tempo? Isso afetaria o prazo. Portanto, é uma questão de tempo e qualidade. Talvez você tenha um jardim chique listado na definição original do projeto, mas você sabe que se não houver tempo suficiente, pode pular essa parte e apenas cobri-lo com grama, contanto que tenha considerado essa possibilidade a tempo e esteja preparado para isso. Portanto, a gestão do escopo também é importante. Agora temos o escopo, o tempo e a qualidade no centro de nossa atenção.

Você já ouviu falar daquele famoso exemplo em que o presidente Kennedy encontra um zelador na NASA e pergunta o que ele faz, e ele responde: “Estou ajudando a colocar um homem na lua”? Ter esse tipo de pessoa no projeto não ajuda a cumprir o prazo?

À medida que você avança, percebe que cada domínio do projeto contribui para a gestão do tempo, e você não pode cumprir o prazo com um nível aceitável de certeza, a menos que preste atenção em todos os domínios.


### Exemplo: Escolher a dedo

Quando as pessoas se deparam com uma variedade de métodos, às vezes começam a escolher a dedo (cherry picking) e criar uma mistura de tudo que parece interessante de diferentes sistemas. Isso geralmente não funciona, pois os elementos não funcionam isoladamente e precisam ser compatíveis entre si. Qualquer adição ou mudança em um sistema deve ser feita a partir de um ponto de vista holístico.

É por isso que às vezes vemos elementos contraditórios em diferentes métodos; algo funciona bem em um sistema, enquanto seu oposto funciona bem em outro sistema. Esse elemento não é certo nem errado por si só.

A abordagem mais segura é selecionar uma metodologia para o projeto, adaptá-la, e em seguida adicionar novos elementos com cautela, levando em consideração a consistência de todos o sistema.


### Exemplo: Abordagem Anti-Processo

Uma das melhores coisas que os métodos ágeis fizeram foi chamar a atenção para os aspectos humanos. O Manifesto Ágil dá mais valor aos indivíduos e às interações em comparação aos processos e ferramentas, embora essa comparação possa não ser justa. Quase todos os métodos afirmam que os aspectos humanos são importantes, e a verdadeira diferença com os métodos ágeis é que os aspectos humanos são uma parte integrada de seus processos, e não apenas uma simples sugestão. Portanto, não se trata de uma competição entre aspectos humanos e processos, mas sim da forma como os aspectos humanos são vistos no sistema.

Não há dúvida de que algumas pessoas tentam substituir os aspectos humanos por processos mais sofisticados, mas isso é apenas um mau uso. Até mesmo o oposto existe: pessoas tentando substituir processos por aspectos humanos, o que também não funciona bem.


### Exemplo: Estes são todos os domínios que você precisa

Ao pensar nos domínios, é importante ter cuidado para não deixar nenhum deles de fora. Mas quais são eles? Se você consultar os recursos fundamentais, receberá respostas diferentes; no entanto, nenhum deles é a verdade absoluta.

Os temas do PRINCE2^(®) são domínios, mas esses são apenas os domínios que desempenham um papel fundamental na metodologia. Os outros domínios são apenas implícitos.

O Guia PMBOK^(®) não é uma metodologia e pode formulá-los de forma muito melhor com as dez áreas de conhecimento. No entanto, essas são interpretações de todos os domínios com base na perspectiva do Guia PMBOK^(®) sobre o projeto, e não em uma perspectiva neutra (não que haja necessariamente uma perspectiva neutra). Por exemplo, os aspectos humanos não recebem muita atenção no Guia PMBOK^(®).

Uma boa fonte de informação sobre domínios é o ICB (IPMA). No entanto, não se trata dos domínios em si, mas das competências que são exigidas no projeto. Não há uma correspondência direta entre as competências e os domínios, mas isso ajuda muito na identificação deles.

Não existe uma lista de domínios nos NUPP, principalmente porque é um meta-sistema e não um sistema, e também porque a categorização dos domínios depende do tipo de projeto e seu ambiente; por exemplo, um projeto de construção de rotina pode exigir uma perspectiva diferente de um projeto de pesquisa criativa.


## NUP5 Não fazer nada sem um propósito claro

[image]

Você não deve fazer nada a menos que tenha um propósito claro. Imagine dois mundos paralelos onde tudo é igual, exceto pela coisa que você está considerando fazer: quão diferentes seriam esses mundos? A diferença vale o esforço de fazer aquela coisa?

Se você não tem um propósito claro em mente e está fazendo algo apenas porque todo mundo está fazendo, ou porque todos dizem que é importante fazer, então

  - pode ser que não haja um benefício real no seu caso e, portanto, você pode não ganhar nada com isso; ou
  - pode ser ainda que haja benefícios potenciais no seu caso, mas como você não tem o propósito em mente, sua maneira de fazer pode não ajudar a perceber esses benefícios.


### Exemplo: Portfólios e programas

Se você estiver envolvido na seleção e em iniciar projetos, certifique-se de focar nos benefícios e nos problemas que precisam ser resolvidos, em não no produto que irá concretizar essas coisas. O exemplo clássico é o fabricante de elevadores que costumava receber reclamações sobre a velocidade de seus elevadores e, por isso, realizava vários projetos para aumentar a velocidade, sem muito sucesso. Isso continuou até que decidiram focar no problema (o tédio ou desconforto das pessoas) em vez da solução “natural” (elevadores mais rápidos). O resultado foi que adicionaram espelhos aos elevadores, solucionando o problema de forma simples e econômica.

Lembre-se de que a gestão de projetos é principalmente sobre fazer as coisas corretamente, enquanto a gestão de portfólio trata de fazer as coisas certas. Não importa o quão bem você conduza seus projetos; não funcionará bem se você estiver fazendo os projetos errados. Tudo se resume a ter um propósito.


### Exemplo: Projeto como um todo

A flexibilidade do produto varia entre projetos. Em alguns projetos de desenvolvimento de TI, o produto é completamente flexível e sua forma final depende do feedback gerado pelos incrementos do produto ao longo do projeto, o que requer uma abordagem adaptativa (Ágil). Isso é, em termos práticos, uma combinação das camadas de portfólio, programa e projeto, exigindo atenção máxima ao objetivo final. É uma boa idéia documentar o propósito e tê-lo acessível; essa é uma das finalidades da “visão do produto”, como é utilizada em alguns projetos Scrum. A atenção ao valor de negócio em projetos Ágeis é a maneira de garantir o alinhamento com o propósito.

Em outros tipos de projeto, onde o produto é relativamente fixo e existem outros mecanismos para garantir que o produto identificado satisfaça o propósito, é possível que os membros da equipe do projeto desviem uma grande parte de sua atenção do propósito para o produto (daí o princípio de “foco nos produtos” do PRINCE2^(®)), mas é necessário pelo menos uma atenção mínima ao propósito para garantir que o que está sendo construído irá satisfazer o propósito, o que pode ser feito comparando os benefícios previstos com os benefícios esperados (daí o princípio de “justificação contínua do negócio” e o tema business case do PRINCE2^(®)).

Quando um projeto é realizado para um cliente externo, o cliente terá seu próprio propósito para o projeto, e sua empresa terá um propósito diferente. É importante compreender e utilizar ambos para obter sucesso real.


### Exemplo: Monitoramento do projeto

Concentrar-se no objetivo final é necessário, mas pode ser muito abstrato para muitos dos usos diários. Por isso, é necessário estabelecer uma hierarquia de indicadores para torná-lo mais prático. Primeiro, são definidas a justificativa e os benefícios do projeto com base no objetivo final, e então são estabelecidas metas explícitas e implícitas para as variáveis do projeto (por exemplo, tempo, custo e qualidade) a fim de satisfazer a justificativa, que por sua vez satisfará o objetivo final. Esses são propósitos de nível inferior que são úteis para muitas de nossas tarefas diárias.

Quando se trata de monitoramento, o monitoramento de nível inferior do projeto será feito usando o nível mais baixo de variáveis, pois pode não ser possível rastrear o objetivo final. Nesse caso, você ainda deve ter os propósitos em mente: qual é o propósito do monitoramento?

Uma resposta normal e aceitável é verificar se estamos no caminho certo e, caso contrário, desencadear uma determinada reação que nos traga de volta ao caminho certo ou ajustar as metas e ver se ainda é possível satisfazer o objetivo final. Nossas medições devem, portanto, ser capazes de ajudar nesse propósito de nível inferior, e as medições apropriadas são previsões para as variáveis na conclusão; por exemplo, quando seríamos capazes de concluir o projeto? Quanto dinheiro precisaríamos para concluí-lo?

Todas as outras medições, como os valores planejados e reais até o momento, são apenas valores intermediários necessários para calcular as previsões, não os valores finais usados para fins gerenciais.


### Exemplo: Documentos

A despeito da abordagem de desenvolvimento utilizada no projeto, planejamento é sempre necessário. A questão importante é o nível de detalhe em cada tipo de plano. Se não houver detalhamento suficiente no plano, ele não poderá contribuir o suficiente e a execução do projeto será baseada em decisões ad hoc em vez de decisões integradas e holísticas. Por outro lado, muitas pessoas tentam ser cautelosas e adicionam muitos detalhes ao plano, o que torna difícil de preparar e manter, além de rígido demais para as incertezas do projeto. Como resultado, o plano se torna irreal e inútil.

A melhor maneira de decidir sobre o nível de detalhe é ter um propósito em mente para cada elemento do plano. Por exemplo, se você está considerando a adição de recursos ao plano, você deve ter um propósito para isso: Como você pretende utilizá-los? Como isso ajudará o projeto? Quanto esforço será necessário? E vale a pena?

Às vezes, trata-se de decidir se você deseja ter um determinado elemento em seus planos e, às vezes, da maneira como você deseja planejar ou preparar algo. Seja um business case, um termo de abertura do projeto ou um relatório: você ainda deve se perguntar por que está preparando aquele documento e como ele pode ajudar o projeto.

Procurar um “modelo” é o oposto de fazer algo com base em um propósito.


### Exemplo: Relatório de Status

É comum ter relatórios de status muito longos em muitos projetos. Com base neste NUP, devemos nos perguntar qual é o propósito do relatório e como podemos alcançá-lo, independentemente do que a maioria das outras pessoas possa estar fazendo.

Isso pode levar, em muitos casos, à preparação de relatórios simples de uma página que os interessados realmente leiam e entendam, em vez de relatórios longos. Isso é prestar atenção ao propósito.

No entanto, se você preparar relatórios de uma página, algumas pessoas podem se opor a você e pensar que você não tem um sistema de monitoramento “adequado” em vigor. Na prática, isso cria um segundo propósito para você (além do primeiro propósito, que é ajudar os interessados a entender o status do projeto), e para satisfazê-lo, você pode simplesmente criar um segundo tipo de relatório que é muito longo. No entanto, você não misturará isso com o primeiro relatório, porque esses dois propósitos não são os mesmos.


### Exemplo: Business case e Project Charter (Termo de Abertura do Projeto)

Preparar documentos como um business case e um termo de abertura do projeto geralmente é considerado tarefa chata, sem frutos e burocrática para a maioria das pessoas, embora esses documentos tenham propósitos válidos que se aplicam à maioria dos projetos. Se você tentar encontrar um “modelo” e preenchê-lo, o trabalho será em vão. Em vez disso, você pode verificar o verdadeiro propósito desses documentos, ver se e como eles podem ser úteis ao seu projeto e, em seguida, preparar o documento da maneira que preferir, apenas para satisfazer esses propósitos: esse será o documento adequado.

Enquanto você estiver pensando na forma como pode preparar os documentos para atender aos seus propósitos, pode ser que você não pense em todos os cenários e acabe deixando passar algo. Para evitar isso, você pode verificar quais recursos, como PRINCE2^(®), Guia PMBOK^(®), P3.express e DSDM^(®) sugerem e, em seguida, avaliar essas sugestões com base nos propósitos.


### Exemplo: Pós-projeto

Embora o projeto tenha um propósito específico, e possamos considerar esse propósito ao longo do projeto, a realização desse propósito é avaliada principalmente com base em previsões feitas durante o projeto. No entanto, não devemos esquecer disso quando o projeto estiver concluído. É importante verificar a realização dos objetivos após o término do projeto porque

  - podemos ver como os objetivos finais são alcançados e aprender com isso para projetos futuros, e
  - às vezes os objetivos são alcançados apenas quando realizamos algumas tarefas adicionais após a conclusão do projeto, e entender a necessidade dessas tarefas extras requer monitoramento.

O monitoramento pós-projeto é uma etapa necessária para ser orientado por um propósito. É principalmente responsabilidade de sistemas de gestão de programas e portfólio, e como a maioria das empresas não possui essas camadas de gerenciamento, essa etapa geralmente é negligenciada. É por isso que métodos como o P3.express e o DSDM^(®) adicionam essa etapa às suas metodologias de gerenciamento de projetos.


### Exemplo: Simplicidade

O mundo é complexo e caótico, mas nossos modelos são aproximações abstratas que refletem partes do mundo e, portanto, podem ser simples. Por outro lado, sistemas simples geralmente funcionam melhor, porque podemos nos concentrar na idéia principal.

Muitos de nós tentam obter melhores resultados adicionando complexidade aos nossos sistemas, esperando que isso corresponda à complexidade do mundo, mesmo que na prática isso torne o sistema difícil de lidar e geralmente nos impeça de cumprir o propósito.


### Exemplo: Customização

Um software para streaming de música tem uma condição muito diferente daquele que será usado em equipamentos de um hospital ou em um avião onde vidas podem depender dele, ou de um software que será usado em um satélite onde espera-se que funcione por muitos anos sem falhas, e todos eles são diferentes da construção de uma casa de veraneio, um posto de combate a incêndios ou uma planta de processamento.

Ao ter os propósitos em mente, você entenderá melhor como adaptar os sistemas e artefatos para diferentes projetos.


## NUP6 Usar elementos repetíveis

[image]

Uma abordagem improvisada ao projeto demanda muita energia e recursos, além de correr o risco de deixar passar alguns dos elementos necessários. A melhor maneira de simplificar o que deve ser feito é utilizar elementos repetíveis e, de preferência, realizá-los em ciclos repetíveis.


### Exemplo: Checklists de qualidade

Um checklist é um exemplo simples de um elemento potencialmente repetível que muitas pessoas usam em suas vidas pessoais e profissionais. Tome como exemplo os critérios de qualidade de uma entrega:

  - Primeiramente, você pode criar um checklist com todos os critérios, que é uma forma de planejamento.
  - O que o NUP6 recomenda é tentar generalizá-la: existem outros produtos semelhantes no projeto? Nesse caso, prepare um checklist de qualidade geral para essa categoria de produtos e use-o para todos. Se houver algumas variações, mantenha a lista genérica e adicione alguns itens extras para os produtos individuais. Agora você tem checklists repetíveis.
  - Depois de preparar checklists genéricos para vários tipos de produtos, você pode encontrar elementos que se repetem entre eles, o que sugere uma categoria “pai” virtual para eles. Nesse caso, em vez de repetir os itens para todas esses checklists genéricos, você pode extraí-los e colocá-los em um checklist “pai”. No final, você provavelmente terá um único checklist genérico para todo o projeto. A “definição de pronto” (DoD) do Scrum é um exemplo de uso de checklists em nível de projeto para qualidade (possível, entre outras coisas). Ao fazer isso, cada produto pertencerá a uma hierarquia de categorias e deverá atender aos itens que constam nos checklists de todas as categorias de sua cadeia.

Ao fazer isso, um item no checklist pai se tornará repetível para todas os produtos abaixo dele, o que economiza tempo e energia no planejamento e na execução.

Mais importante ainda, uma vez que você faça isso para um projeto, você pode adaptá-lo e usá-lo para todos os projetos semelhantes no futuro, o que é uma forma repetível de planejamento para múltiplos projetos.


### Exemplo: Processos e fluxos de trabalho

Alguns produtos ou serviços, ou metas vinculadas a eles, exigem etapas específicas que podem se tornar padronizadas e repetíveis. Por exemplo, se os produtos ou serviços precisam ser projetados individualmente e aprovados, você pode preparar um fluxo de trabalho simples que deixe claras todas as etapas, pessoas envolvidas e durações aproximadas, evitando muitas dificuldades. No entanto, é preciso ter cuidado para não tornar os fluxos de trabalho e processos muito complicados ou excessivamente documentados, pois isso terá uma consequência negativa. Todas as pessoas envolvidas no projeto devem enxergar os fluxos de trabalho e processos como algo que apoia o trabalho delas e torna tudo mais fácil, em vez de como uma documentação burocrática que bloqueia o trabalho real.

Projetos ágeis possuem elementos repetíveis em sua abordagem de desenvolvimento iterativo, onde determinadas atividades de desenvolvimento são repetidas para cada funcionalidade; por exemplo, a rotina diária comum no XP (eXtreme Programming): formar duplas, escolher um item, desenhá-lo em um quadro branco, construir scripts de teste e código, integrar o código, etc.

Além dos fluxos de trabalho repetíveis que podem ser utilizados para atividades técnicas, também é possível ter elementos repetíveis para as atividades de gerenciamento de projetos. Os processos no Guia PMBOK^(®), PRINCE2^(®) e DSDM^(®), as atividades no P3.express e os eventos no Scrum são exemplos desse conceito.


### Exemplo: Ciclos

Ter elementos repetíveis para gerenciar um projeto é útil. Isso pode ser ainda mais facilitado ao colocá-los em ciclos repetíveis. Esses ciclos simplificam significativamente as atividades diárias das pessoas envolvidas no gerenciamento e liderança do projeto. Ciclos de grupos de processos no Guia PMBOK^(®), quando utilizados em projetos com várias fases, sequências no PRINCE2^(®), ciclos diários, semanais e mensais no P3.express, iterações e “timeboxes” no DSDM^(®) e Sprints no Scrum são todos exemplos desse conceito.

Ciclos mais curtos são mais fáceis de entender e usar do que ciclos mais longos; por exemplo, os Sprints no Scrum em contraste com as fases de acordo com o Guia PMBOK^(®). No entanto, ciclos muito curtos podem não ser suficientes para dar suporte a certos tipos de projetos, e a solução pode ser o uso de múltiplos ciclos, como o uso de ciclos curtos de “timeboxes” juntamente com ciclos mais longos de iteração no DSDM^(®), ou o uso de ciclos diários, semanais e mensais no P3.express.


### Exemplo: Métodos

Utilizar uma metodologia ou um framework para conduzir um projeto é outro uso de elementos repetíveis. Isso pode ser um sistema existente, como PRINCE2^(®), P3.express, DSDM^(®) ou Scrum, ou um que você mesmo tenha personalizado ou desenvolvido. No entanto, normalmente é melhor começar com um dos métodos existentes e adaptá-lo às suas necessidades do que criá-lo do zero.

Qualquer elemento repetível é abstrato e precisa ser personalizado para se adaptar ao mundo real. No entanto, há um espectro de abstração e necessidade de personalização: checklists de qualidade pequenos e relativamente concretos estão em uma ponta do espectro, com menor abstração e necessidade de adaptação, enquanto as metodologias estão na outra ponta, com maior necessidade de adaptação. Você sempre deve levar em consideração a necessidade de personalização, caso contrário, o elemento repetível não atenderá adequadamente às suas necessidades.