Lançamento de Fim de Ano

Esta versão entrega um conjunto significativo de melhorias em intake, fluxos de trabalho, governança e controle de dados, projetadas para refletir melhor como PMOs e equipes de projeto operam na prática. O foco está em reduzir o atrito no ponto de solicitação, fortalecer a governança por meio de uma lógica de fluxo de trabalho mais clara, melhorar a colaboração e garantir que os dados de projetos e portfólios permaneçam consistentes, controlados e auditáveis à medida que avançam do intake até a entrega.

Juntas, essas mudanças oferecem aos PMOs mais confiança, mais controle e menos esforço manual ao longo de todo o ciclo de vida do projeto, desde a primeira solicitação até a execução.

Esta versão apresenta uma série de melhorias nos boards de solicitações da comunidade, tornando o intake de projetos e o gerenciamento de solicitações mais rápidos, mais claros e mais alinhados aos fluxos de trabalho reais de PMOs. Seja gerenciando intake de projetos, solicitações de mudança ou fluxos de trabalho de governança, essas atualizações reduzem o atrito na entrada enquanto oferecem aos PMOs mais controle sobre como as solicitações entram no sistema.

Os boards de solicitações da comunidade agora podem ser configurados para ignorar o backlog e enviar novas solicitações diretamente para o fluxo de trabalho.

Anteriormente, todas as solicitações enviadas eram colocadas em um backlog, exigindo que um proprietário ou membro do board as movesse manualmente para o fluxo de trabalho antes que qualquer revisão ou processamento pudesse começar. Para muitos processos de intake, essa etapa de backlog adicionava atrito desnecessário, especialmente quando a primeira coluna do board já representava triagem ou revisão inicial.

Com esta versão, você pode configurar um board de solicitações da comunidade para que novas solicitações sejam criadas diretamente na primeira coluna (mais à esquerda). Isso permite que as solicitações entrem no fluxo de trabalho imediatamente e alinha o board mais de perto com a forma como muitos PMOs realmente operam seus processos de intake e revisão.

Isso é particularmente eficaz para intake de projetos, solicitações de mudança ou fluxos de trabalho de governança onde o backlog atuava puramente como uma área de espera em vez de uma etapa significativa.

Os PMOs agora têm maior controle sobre como os boards de solicitações da comunidade são apresentados aos solicitantes, ajudando a manter a experiência de intake focada e intuitiva.

Usando a configuração Ocultar do Widget da Página Inicial na definição do board, você pode escolher se um board de solicitações da comunidade deve aparecer nos dois principais pontos de descoberta para solicitações de trabalho:

• o widget de solicitações de trabalho da Página Inicial, e

• a lista de boards exibida quando os usuários selecionam Criar → Solicitação de Trabalho.

A opção Ocultar do Widget da Página Inicial oferece controle preciso sobre como as solicitações são exibidas. Isso pode ser usado para ocultar temporariamente um board - por exemplo, enquanto se projeta um processo de intake ou se desativa um fluxo de trabalho antigo. Um board também pode ser intencionalmente ocultado enquanto ainda está em uso ativo, com solicitações feitas apenas por meio de sua URL direta de solicitação de trabalho. Isso é útil quando os envios precisam ser rigidamente controlados ou incorporados em orientações de suporte em vez de serem amplamente descobertos.

Para boards que permanecem visíveis, agora você também pode atribuí-los a categorias. As categorias são exibidas aos solicitantes ao navegar pelos boards de solicitações de trabalho disponíveis e ajudam a guiar os usuários para o caminho de intake correto, como Intake de Projetos, Solicitações de Mudança, Trabalho Operacional ou Revisões de Governança.

Essa combinação de controle de visibilidade e categorização torna muito mais fácil apresentar uma experiência de solicitação limpa e intencional, mesmo em organizações com múltiplos canais de intake.

Os boards de solicitações da comunidade agora podem ser explicitamente configurados com um Tipo de Fluxo de Trabalho, esclarecendo como cada fluxo de trabalho deve ser iniciado e como interage com os projetos. Isso permite que os PMOs projetem processos de intake e governança que se comportem corretamente, seja quando as solicitações são feitas de forma independente ou no contexto de um projeto existente.

Ao definir um board, você pode escolher entre três tipos de fluxo de trabalho:

• Fluxo de Trabalho Genérico

  Usado para solicitações que não são inerentemente específicas de projetos, ou onde a solicitação não precisa ser vinculada a um projeto no momento do envio. Exemplos típicos incluem solicitações operacionais, consultas gerais ou ideias em estágio inicial.

  Os fluxos de trabalho genéricos são sempre iniciados fora do contexto do projeto e, quando visíveis, são acessados por meio dos pontos de entrada da Página Inicial ou Criar → Solicitação de Trabalho.

• Fluxo de Trabalho de Projeto

  Usado para fluxos de trabalho que se relacionam diretamente a projetos, como solicitações de intake de projetos, solicitações de mudança ou aprovações em nível de projeto.

  

  Como um board de Fluxo de Trabalho de Projeto pode ser iniciado depende de estar ou não oculto dos principais pontos de descoberta:

  • Se o board não estiver oculto do widget da Página Inicial, as solicitações para este fluxo de trabalho são iniciadas a partir da Página Inicial ou do menu Criar → Solicitação de Trabalho (ou seja, como um ponto de entrada padrão de solicitação de trabalho).

  • Se o board estiver oculto do widget da Página Inicial, o fluxo de trabalho se torna contextual ao projeto e pode ser iniciado a partir de dentro de um projeto. Neste modo, a configuração de Categoria de Projeto controla quais projetos podem iniciar uma solicitação de fluxo de trabalho:

    • Se uma Categoria de Projeto for especificada, apenas os projetos nessa categoria exibirão o fluxo de trabalho no Espaço de Trabalho do Projeto.

    • Se nenhuma categoria for especificada, o fluxo de trabalho estará disponível no Espaço de Trabalho do Projeto para todos os projetos.

    Quando uma solicitação é iniciada a partir de um projeto, quaisquer propriedades de projeto correspondentes são sincronizadas com o card, garantindo que a solicitação herde o contexto relevante do projeto sem reinserção manual.

• Fluxo de Trabalho de Stage Gate

  Usado especificamente para processos de governança vinculados a stage gates. Quando selecionado, o board pode ser associado a um ou mais stage gates, garantindo que aprovações, revisões ou ações de suporte sejam acionadas como parte do ciclo de vida do projeto, em vez de como solicitações independentes.

  Quando uma solicitação é criada a partir de um stage gate, quaisquer propriedades de projeto correspondentes são automaticamente sincronizadas com o card, garantindo que o fluxo de trabalho herde o contexto correto do projeto sem exigir reinserção manual. Isso mantém as aprovações de stage gate estreitamente alinhadas com os dados do projeto que governam e melhora a rastreabilidade nas decisões de governança.

Ao definir o tipo de fluxo de trabalho antecipadamente, os PMOs podem garantir que cada board seja exibido no lugar certo, reduzindo a confusão e mantendo os processos orientados por solicitações estreitamente alinhados com a governança do portfólio.

Esta versão apresenta melhorias na forma como as solicitações de trabalho são criadas e preparadas antes de entrar nos fluxos de trabalho formais. Juntas, essas mudanças suportam uma elaboração mais flexível, melhor colaboração e envios de maior qualidade.

Quando um board de solicitações da comunidade é configurado para ignorar o backlog, os solicitantes agora podem trabalhar em uma solicitação ao longo do tempo em vez de ter que completar tudo de uma vez.

Anteriormente, todos os campos obrigatórios precisavam ser preenchidos antes que uma solicitação pudesse ser salva. Isso frequentemente forçava os usuários a apressar os envios ou abandonar as solicitações completamente se ainda não tivessem todas as informações.

Com esta versão, as solicitações agora podem ser salvas na primeira coluna (normalmente com status de Rascunho) mesmo que os campos obrigatórios ainda não tenham sido preenchidos. Isso permite que os usuários iniciem uma solicitação, salvem-na como rascunho, voltem mais tarde e continuem trabalhando nela à medida que as informações se tornam disponíveis. Os campos obrigatórios só são aplicados quando a solicitação é formalmente enviada para o fluxo de trabalho.

O comportamento é determinado pela estrutura do board:

• A primeira coluna representa solicitações em rascunho ou em andamento.

• A segunda coluna representa o momento em que a solicitação está pronta e entra em revisão formal ou processamento.

Isso oferece aos solicitantes muito mais flexibilidade durante a entrada, melhora a qualidade das submissões e garante que as regras de governança sejam aplicadas no momento certo — quando uma solicitação realmente entra no fluxo de trabalho.

Ao iniciar uma solicitação de trabalho, colaboradores agora podem ser adicionados enquanto a solicitação ainda está em Rascunho. Isso permite que várias pessoas trabalhem juntas para concluir a solicitação antes que ela entre no fluxo de trabalho formal.

Isso é particularmente útil para cenários de entrada onde informações precisam ser coletadas de diferentes funções - por exemplo, combinando detalhes de entrega de um gerente de projeto, contribuição financeira de um analista de PMO, ou contexto técnico de um especialista no assunto - antes que a solicitação esteja pronta para revisão.

Os colaboradores podem editar a solicitação somente enquanto ela permanecer em Rascunho. Assim que a solicitação for submetida ao fluxo de trabalho, o cartão torna-se somente leitura tanto para o solicitante quanto para os colaboradores, garantindo que as informações revisadas e aprovadas permaneçam estáveis à medida que avançam pelas etapas de governança ou entrega.

Esta versão fortalece a relação bidirecional entre quadros e projetos, garantindo que as informações capturadas por meio de fluxos de trabalho permaneçam alinhadas com os dados do projeto aos quais se referem. Seja criando projetos a partir de quadros ou levantando solicitações dentro de projetos, a sincronização agora funciona em ambas as direções para reduzir duplicações e manter os registros consistentes.

Os quadros de pipeline de projetos podem definir colunas ou status específicos que acionam a sincronização entre um cartão e um projeto. Até agora, isso era usado principalmente para criar um novo projeto: quando um cartão era movido para uma coluna configurada, o Fluid criava o projeto e copiava quaisquer propriedades correspondentes do cartão para o novo registro do projeto.

O que há de novo nesta versão é que essas mesmas colunas agora podem ser configuradas para sincronizar propriedades com o projeto já vinculado ao cartão, em vez de criar um novo projeto. Isso significa que quando um cartão está sendo usado para conduzir um fluxo de trabalho em relação a um projeto existente, quaisquer informações adicionais ou atualizadas capturadas no cartão podem ser enviadas de volta ao projeto automaticamente (onde existem propriedades correspondentes). Isso é particularmente valioso para fluxos de trabalho de governança e aprovação, onde os dados do projeto são progressivamente refinados e devem ser refletidos no projeto assim que o fluxo de trabalho atingir um ponto definido.

Além disso, ao configurar uma coluna para sincronizar propriedades com um projeto existente, você também pode controlar como o status do projeto é tratado. Selecionar Não Alterar garante que o status do projeto permaneça exatamente como está, enquanto escolher um status específico permite mover explicitamente o projeto para um novo estado como parte do fluxo de trabalho. Isso oferece aos PMOs controle preciso sobre se uma etapa de governança atualiza apenas os dados do projeto ou também avança o ciclo de vida do projeto.

A sincronização também foi estendida na direção oposta para solicitações iniciadas a partir de um projeto.

Quando uma solicitação é levantada dentro de um projeto - como uma solicitação de mudança ou um fluxo de trabalho relacionado a um stage-gate - as propriedades do projeto agora podem sincronizar de volta ao cartão, desde que existam propriedades correspondentes no quadro. Isso garante que os cartões que conduzem fluxos de trabalho de projetos sempre reflitam o contexto mais recente do projeto, melhorando a rastreabilidade e reduzindo o risco de inconsistências entre os dados do projeto e as solicitações associadas a ele.

Juntos, esses aprimoramentos fornecem aos PMOs uma integração mais estreita entre entrada, fluxos de trabalho de governança e execução de projetos, apoiando melhor qualidade de dados, trilhas de auditoria mais claras e menos esforço manual ao longo do ciclo de vida.

Esta versão fortalece como as decisões impulsionam a progressão do fluxo de trabalho, oferecendo aos PMOs controle mais claro, governança mais robusta e resultados mais previsíveis quando as aprovações são incorporadas aos fluxos de trabalho do quadro.

Os fluxos de trabalho há muito suportam a criação automática de decisões quando um cartão atinge uma coluna ou status específico. Nesta versão, essa capacidade é estendida para que o que acontece a seguir seja conduzido diretamente pelo resultado da decisão.

Agora você pode usar expressões para controlar como um cartão se move após uma decisão ser aprovada ou rejeitada. Por exemplo, um cartão pode mover-se automaticamente para uma coluna Aprovado quando aceito, retornar para Revisão Adicional quando rejeitado, ou permanecer na mesma coluna dependendo do resultado. Isso permite que as decisões de governança conduzam ativamente o fluxo de trabalho, em vez de simplesmente registrar uma aprovação de forma isolada.

Esse comportamento é configurado diretamente no nível da coluna no quadro. Ao definir uma coluna, você ativa as Regras de Fluxo de Trabalho de Aprovação, especifica quem são os aprovadores da decisão (usando funções estáticas ou dinâmicas) e, em seguida, define como o cartão deve se mover com base no resultado da decisão.

Isso significa que a lógica de aprovação, a responsabilidade e a progressão do fluxo de trabalho são todas definidas em um único lugar, tornando claro como as decisões de governança se traduzem em próximas etapas concretas no processo.

Para decisões iniciadas como parte de um fluxo de trabalho, os resultados de aprovação agora são definitivos. Uma vez que um aprovador aprova ou rejeita uma decisão, o status não pode ser alterado.

Isso impede que as decisões sejam revertidas após o fato, garantindo uma trilha de governança clara e auditável. Se as circunstâncias mudarem e um resultado diferente for necessário, uma nova decisão deve ser levantada e reatribuída, em vez de editar a original. Esse comportamento se aplica apenas a decisões conduzidas por fluxo de trabalho e não afeta decisões criadas manualmente fora dos fluxos de trabalho.

Para reforçar essa clareza, as decisões conduzidas por fluxo de trabalho foram simplificadas:

• A opção Condicional foi removida.

• O botão de ação agora exibe claramente Enviar, em vez de Salvar.

• Os aprovadores só podem aprovar ou rejeitar a decisão.

Isso remove a ambiguidade nos pontos de decisão e garante que as decisões conduzidas por fluxo de trabalho se comportem de forma consistente, apoiando uma governança mais robusta e uma auditabilidade mais limpa em todos os processos de aprovação.

Esta versão expande significativamente o papel das propriedades personalizadas como um mecanismo central de governança e controle de dados em todo o Fluid. Os PMOs agora têm um controle muito mais refinado sobre quem pode ver e editar dados, como os valores são derivados e restringidos, como os documentos são capturados e governados, e como as definições de propriedades são reutilizadas em quadros, projetos e ambientes.

Juntos, esses aprimoramentos fortalecem a consistência dos dados entre entrada e entrega, reduzem a configuração manual e os erros, e garantem que as informações críticas de projeto e governança sejam capturadas, protegidas e reutilizadas de forma controlada e auditável à medida que o trabalho avança da solicitação para a execução.

Agora você pode definir um modo de visibilidade para cada propriedade personalizada, oferecendo controle preciso sobre quem pode ver uma propriedade e quem pode editá-la.

Para cada propriedade personalizada, você pode escolher um dos seguintes modos de visibilidade:

• Editável por todos os usuários
  A propriedade é visível para todos os usuários e pode ser editada por qualquer pessoa que tenha direitos de edição no item. Por exemplo, em Detalhes do Projeto, um gerente de projeto pode atualizar uma propriedade definida como Editável por todos os usuários.
  Este modo é adequado para informações gerais do projeto que se espera sejam mantidas de forma colaborativa, como notas de entrega ou contexto de alto nível.

• Oculto para usuários não administradores
  A propriedade é visível e editável apenas por administradores de projeto. Usuários não administradores não podem ver a propriedade de forma alguma. Por exemplo, em um projeto, essa propriedade seria visível para um Administrador de Projeto, mas completamente oculta para um Gerente de Projeto que visualiza os Detalhes do Projeto.
  Isso é útil para campos de governança interna, sinalizadores de controle ou dados que devem permanecer estritamente dentro do PMO ou da equipe de administração.

• Visível, mas somente leitura para usuários não administradores
  A propriedade é visível para todos os usuários, mas apenas administradores de projeto podem editá-la. Por exemplo, um Gerente de Projeto verá a propriedade na página de Detalhes do Projeto, mas não poderá alterá-la, enquanto um Administrador de Projeto pode atualizar o valor.
  Isso é ideal para informações controladas, como resultados de governança, indicadores financeiros ou valores calculados que devem ser transparentes, mas protegidos de edições manuais.

• Visível e somente leitura para todos os usuários
  A propriedade é visível para todos e não pode ser editada por nenhum usuário, incluindo administradores de projeto.
  Este modo é normalmente usado quando uma propriedade é preenchida por um fluxo de trabalho ou processo automatizado. Por exemplo, quando dados de aprovação de projeto são gravados como parte de um fluxo de trabalho de intake ou stage-gate, os valores devem permanecer bloqueados após a aprovação do projeto, garantindo que as decisões de governança capturadas durante o fluxo de trabalho não possam ser alteradas posteriormente.

Esses modos de visibilidade permitem que os PMOs equilibrem transparência e controle, disponibilizando informações-chave onde agregam valor, enquanto protegem dados críticos ou sensíveis de alterações não intencionais.

Esta versão apresenta as Expressões de Lógica Dinâmica, permitindo que os dados já capturados no Fluid conduzam cálculos, decisões e comportamentos de fluxo de trabalho automaticamente.

As Expressões de Lógica Dinâmica são pequenas fórmulas avaliadas em tempo real em relação a projetos, quadros ou quaisquer outras entidades. À medida que os valores mudam, a expressão é automaticamente reavaliada, garantindo que os resultados permaneçam consistentes sem intervenção manual.

Formulários e Captura de Dados mais Inteligentes

Você pode configurar propriedades personalizadas para serem conduzidas por expressões, permitindo que seus valores sejam calculados automaticamente com base em outros dados inseridos no formulário. Isso elimina a necessidade de atualizações manuais e garante que os valores permaneçam consistentes à medida que as entradas mudam.

Você pode consultar a lista completa de expressões e sintaxe suportadas na documentação de Expressões de Lógica Dinâmica.

Por exemplo:

• Um formulário de intake de projeto captura o Custo Estimado e o Percentual de Capitalização

• Um terceiro campo, Valor Capitalizado, é calculado automaticamente usando uma expressão

• À medida que o usuário atualiza qualquer uma das entradas, o valor calculado é atualizado instantaneamente

Decisões Conduzidas por Fluxo de Trabalho e Movimentação de Cards

As Expressões de Lógica Dinâmica podem ser usadas dentro das regras de decisão de fluxo de trabalho para controlar o que acontece com um card quando uma decisão de aprovação vinculada é aprovada ou rejeitada.

Quando um card chega a uma coluna configurada para levantar automaticamente uma decisão de aprovação, você pode definir regras baseadas em expressões que determinam como o card deve se mover após a decisão ser aprovada ou rejeitada. Isso permite que os resultados de aprovação conduzam a progressão do fluxo de trabalho de forma consistente e orientada por dados.

Por exemplo, quando uma decisão é aprovada, uma expressão pode ser avaliada para decidir o próximo passo:

• Encaminhar o card para Revisão Financeira se o orçamento previsto exceder um limite definido

• Mover diretamente para Avaliação de Benefícios para solicitações de menor valor

Quando uma decisão é rejeitada, o card pode ser encaminhado para um status fixo, como Informações Adicionais Necessárias, garantindo que a solicitação retorne ao ponto correto para esclarecimento ou retrabalho.

Essa lógica é definida diretamente na coluna do quadro usando expressões dinâmicas. As expressões avaliam os dados já capturados no card - como o orçamento - para determinar o resultado apropriado automaticamente.

Ao combinar decisões automatizadas com roteamento conduzido por expressões, os fluxos de trabalho podem aplicar regras de governança de forma consistente, reduzir julgamentos manuais e garantir que as solicitações avancem pelas etapas de revisão corretas com base em seu conteúdo real, em vez de um processo único para todos.

Propriedades personalizadas do tipo Pessoa agora podem ser configuradas com expressões de lookup para controlar quem pode ser selecionado para a propriedade.

Quando uma expressão de lookup é definida, os usuários ainda selecionam manualmente uma pessoa, mas a lista de pessoas disponíveis é automaticamente filtrada pela aplicação com base nos critérios configurados. Isso impede que os usuários selecionem alguém fora das regras definidas, mantendo ainda a escolha final explícita.

No exemplo mostrado abaixo, uma propriedade personalizada de Proprietário de Negócio foi criada como uma propriedade de Pessoa e configurada com um filtro de lookup:

• O Campo de Lookup especifica qual propriedade no registro do usuário deve ser avaliada (por exemplo, Linha de Negócio).

• O Valor de Lookup usa uma expressão que referencia outra propriedade no item, neste exemplo a Linha de Negócio do projeto.

• Como resultado, apenas usuários cuja Linha de Negócio corresponda à Linha de Negócio do projeto estarão disponíveis para seleção ao preencher o campo Proprietário de Negócio.

Isso significa que os usuários não podem atribuir acidentalmente alguém fora do escopo organizacional relevante, mantendo ainda o controle sobre a seleção final.

Essa abordagem é particularmente útil para aplicar regras de propriedade, orientar a seleção de aprovadores e garantir uma atribuição consistente de funções em projetos e fluxos de trabalho.

As propriedades personalizadas agora suportam um novo tipo Documento, permitindo que documentos sejam capturados como dados estruturados do projeto em vez de anexos gerais.

Ao criar uma propriedade personalizada - seja para projetos, quadros, cronogramas, tarefas, impactos ou outras entidades - você agora pode definir a propriedade como tipo Documento. Os usuários podem fazer upload de um ou mais documentos diretamente nessa propriedade, deixando claro por que o documento existe e ao que ele se refere.

Quando um documento é carregado via uma propriedade de Documento:

• o documento é exibido diretamente no valor da propriedade, e

• também é adicionado ao local de documento apropriado para a entidade:

  • a seção Documentos para espaços de trabalho de projetos, ou

  • a seção Anexos para itens como cards, tarefas agendadas ou impactos.

Isso garante que os documentos sejam tanto contextualmente visíveis quanto centralmente acessíveis.

A aplicação pode ser configurada para bloquear documentos introduzidos como parte de um fluxo de trabalho, independentemente de como foram adicionados ao card.

Isso se aplica a:

• documentos carregados via uma propriedade personalizada de Documento, e

• documentos carregados diretamente na seção de Anexos do card.

Quando um card avança por um fluxo de trabalho e os documentos são sincronizados com um projeto, esses documentos são copiados para a seção Documentos do espaço de trabalho do projeto. Assim que a sincronização ocorre e o bloqueio de documentos está habilitado, os documentos ficam totalmente bloqueados no projeto.

Documentos bloqueados:

• não podem ser excluídos, inclusive por Administradores de Projeto, e

• não podem ser editados ou substituídos.

Observe que, enquanto o card permanece no fluxo de trabalho, os proprietários e membros do quadro podem continuar a adicionar ou remover documentos conforme necessário. No entanto, assim que o fluxo de trabalho chega ao ponto em que os documentos são sincronizados com o projeto, esses documentos são preservados como parte do registro formal do projeto.

Isso garante que os documentos aprovados ou enviados por meio de fluxos de trabalho de governança, como business cases, aprovações ou evidências de conformidade, permaneçam imutáveis uma vez que façam parte do projeto, proporcionando forte auditabilidade e protegendo a integridade das decisões de governança.

As propriedades personalizadas agora podem ser reutilizadas com mais facilidade entre quadros e projetos, sem duplicar configurações inteiras. Você pode copiar propriedades diretamente de outro quadro, ou exportá-las e importá-las usando um arquivo JSON — com controle total sobre quais propriedades são aplicadas e como são mescladas.

Na página Configurações do Quadro ou na página Gerenciar Propriedades Personalizadas para projetos, agora você pode:

• Copiar propriedades personalizadas de outro quadro
  Selecione um quadro existente do qual deseja copiar as propriedades. Após a seleção, a lista de propriedades disponíveis para cópia é exibida, permitindo que você desmarque as propriedades que não deseja incluir. Isso fornece controle preciso sobre quais definições de propriedade são copiadas para o quadro ou projeto de destino. Em seguida, decida se deseja:

  • Substituir todas as propriedades existentes no destino pelas selecionadas, ou

  • Mesclar as propriedades, adicionando apenas as que ainda não existem e mantendo as definições existentes inalteradas.

• Exportar propriedades personalizadas para um arquivo JSON
  Exporte definições de propriedades personalizadas como um arquivo JSON para que possam ser reutilizadas em outros lugares. Isso é normalmente usado para manter as propriedades de quadros e projetos alinhadas, reutilizar definições de propriedades sem duplicar quadros inteiros e mover configurações com segurança entre ambientes, como promover alterações de um ambiente de sandbox para produção.

• Importar propriedades personalizadas de um arquivo JSON
  Carregue um arquivo JSON exportado anteriormente e revise a lista de propriedades contidas nele. Antes de aplicar a importação, você pode selecionar ou desmarcar propriedades individuais e escolher se deseja substituir ou mesclar as propriedades com as existentes.

Em todos os casos, as propriedades copiadas ou importadas mantêm sua estrutura, tipo de dado e configuração, permitindo uma captura de dados consistente entre quadros e projetos, ao mesmo tempo que reduz a configuração manual e o risco de desalinhamento.

Esta versão introduz novas capacidades que oferecem aos PMOs maior controle sobre como os stage gates se comportam ao longo do ciclo de vida do projeto. Em conjunto, essas melhorias permitem que a governança seja mais rigorosa onde necessário e mais flexível onde apropriado, garantindo que os projetos sejam governados de forma consistente, ao mesmo tempo que refletem as condições reais de entrega e as regras do portfólio.

Esta versão fortalece a governança em nível de fase ao permitir que a progressão de fase do projeto seja explicitamente controlada pela conclusão do stage gate.

Quando uma metodologia é aplicada a um projeto e as fases são definidas com gates associados, agora você pode impor uma regra que impede o projeto de avançar para a próxima fase até que todos os gates da fase atual sejam concluídos. Essa configuração é aplicada no nível da aplicação e é configurada pelo Administrador do Projeto, garantindo um comportamento consistente em todos os projetos que utilizam metodologias governadas.

O comportamento foi projetado para ser prático e não disruptivo:

• Se um projeto tentar avançar, mas um ou mais gates ainda estiverem pendentes, o projeto permanece na fase mais antiga com gates incompletos.

• Quando os gates estão concluídos, o projeto pode progredir naturalmente para a próxima fase de acordo com suas datas planejadas.

• Se um projeto ultrapassou sua data de término ou nenhuma fase válida se aplica, a fase atual é removida adequadamente.

Isso garante que os pontos de verificação de governança controlem genuinamente o fluxo de entrega, reduzindo o risco de mudanças de fase prematuras enquanto mantém um modelo de progressão sensato para projetos ativos.

Os stage gates agora podem ser exibidos ou ocultados condicionalmente usando expressões baseadas em propriedades do projeto.

Isso significa que os PMOs podem definir regras que determinam se um gate é aplicável a um projeto. Por exemplo, um gate pode ser visível apenas para projetos acima de um determinado limite de orçamento, para tipos específicos de projetos, ou para iniciativas dentro de um portfólio ou área de negócios específica.

No exemplo acima, o gate de Aprovação Arquitetural será exigido apenas para projetos onde o impacto da mudança seja Alto ou Médio.

Ao usar expressões vinculadas aos dados do projeto, os frameworks de governança podem ser tornados mais adaptativos sem duplicar metodologias ou criar gates desnecessários para projetos onde eles não se aplicam. Isso ajuda a reduzir o ruído nos fluxos de trabalho de entrega, garantindo que o nível correto de governança seja aplicado aos projetos certos.

Observe que as expressões de stage gate são orientadas por funcionalidades. A instância da aplicação deve ser configurada para habilitar essa capacidade antes que as expressões possam ser definidas e usadas nos stage gates.

Quando a configuração da aplicação para impedir a progressão para a próxima fase até que todos os gates da fase atual sejam concluídos está habilitada, um controle adicional é agora aplicado dentro da mesma fase.

Neste modo, um projeto não pode concluir um gate de saída de uma fase a menos que todos os gates de entrada dessa fase já tenham sido concluídos. Isso garante que os projetos não possam ignorar as aprovações de entrada obrigatórias e avançar diretamente para as decisões de saída da fase.

Esse comportamento reforça o sequenciamento correto da governança, garantindo que:

• as verificações e aprovações de entrada sejam concluídas antes que as decisões de saída sejam tomadas, e

• a conclusão da fase reflita um caminho de governança totalmente compatível, não apenas uma aprovação final.

Juntamente com o bloqueio de progressão de fase e a visibilidade condicional de gates, isso fornece aos PMOs um framework de stage gate robusto e consistente que impõe a governança na ordem correta, ao mesmo tempo que permite flexibilidade onde as regras são intencionalmente relaxadas.

Esta versão expande as notificações para melhorar a visibilidade nos fluxos de trabalho e nos eventos do ciclo de vida do projeto, garantindo que as partes interessadas sejam mantidas informadas sem precisar monitorar ativamente quadros ou painéis.

Várias novas notificações foram introduzidas para melhorar a transparência nos fluxos de intake, solicitações e decisões.

Quando uma decisão é encaminhada para um Workhub, o proprietário do Workhub é agora notificado, garantindo que as solicitações de aprovação enviadas às equipes sejam claramente atribuídas e tratadas.

Os solicitantes também são notificados sempre que o status de sua solicitação de trabalho muda, mantendo-os informados à medida que sua solicitação avança pelas etapas de revisão, aprovação ou rejeição.

Além disso, quando uma solicitação de intake é aprovada e um espaço de trabalho do projeto é criado, uma notificação é enviada tanto ao Solicitante quanto ao Gerente de Projeto. Isso confirma que o processo de intake está concluído e sinaliza claramente que o projeto está pronto para prosseguir, fechando o ciclo entre solicitação, aprovação e iniciação do projeto.

Novas notificações também foram adicionadas para melhorar a visibilidade em torno de mudanças importantes no projeto.

Os Gerentes de Projeto agora são notificados quando:

• o status do projeto muda, e

• a atribuição do Gerente de Projeto Principal é atualizada.

Essas notificações garantem que os GPs permaneçam alinhados com atualizações importantes de propriedade e ciclo de vida, reduzindo o risco de mudanças perdidas e melhorando a consciência do dia a dia.

Esta versão introduz flexibilidade adicional na forma como os campos do projeto são bloqueados e gerenciados, ajudando os PMOs a equilibrar o controle de governança com as necessidades de entrega do dia a dia.

Os projetos já podem ser configurados para bloquear campos específicos de modo que apenas os Administradores do Projeto possam atualizá-los. Um desses campos é o campo GP Principal, que frequentemente é rigidamente governado em ambientes regulamentados ou controlados por portfólio.

Uma nova opção Permitir Edições do PM Principal foi adicionada para funcionar em conjunto com essa configuração de bloqueio de campos. Isso permite que as organizações decidam se:

• todos os campos bloqueados devem permanecer restritos apenas aos Administradores de Projeto, ou

• o campo PM Principal permanece editável, mesmo quando outros campos do projeto estão bloqueados.

Isso oferece aos PMOs um controle mais refinado sobre o gerenciamento de propriedade - por exemplo, permitindo que as transferências de PM ocorram de forma tranquila sem exigir intervenção administrativa, enquanto mantém outros campos sensíveis do projeto protegidos.

A funcionalidade de edição em massa para quadros foi aprimorada para permitir que o Solicitante seja definido ou atualizado em vários cartões de solicitação de trabalho de uma só vez.

Isso é particularmente útil em cenários onde as solicitações foram enviadas em nome de outras pessoas, importadas em massa ou requerem correção após o envio.

Para atualizar solicitantes em massa, exporte o arquivo de edição em massa do quadro, preencha a coluna RequestedBy com o valor apropriado para cada cartão e faça o upload do arquivo de volta no Fluid.