Migração de projetos para o Project for the web

 Olá pessoal –

Tenho percebido um número cada vez maior de empresas que tem optado pelo Project for the web como solução definitiva de gerenciamento de projetos, em detrimento ao Project Online. Em alguns casos, empresas que gerenciam seus projetos ativamente no Project Online têm feito planos para migrar seu portfolio para o Project for the web – um indicador de que, no médio/longo prazo, essa plataforma ganhará cada vez mais adeptos.

Recentemente apoiei um cliente em um processo de automação via Power Automate para realizar a migração do portfolio de projetos do Project Online para o Project for the web, e gostaria de documentar aqui minhas descobertas e lições aprendidas. O escopo geral do trabalho seria migrar os projetos em andamento do Project Online para o Project for the web (cerca de 350 projetos no total), englobando apenas as informações de nível de projeto, como nome, proprietário, patrocinador e demais atributos – cronogramas/tarefas não seriam migrados.

É importante ressaltar que os mesmos passos também podem ser aplicados por uma organização que esteja realizando o gerenciamento de projetos em qualquer plataforma ou sistema, como Primavera, Project Server, ou mesmo o velho e bom Excel.

..................................................

Para construir o processo de automação, o primeiro passo é exportar os projetos do Project Online (ou de qualquer que seja o sistema) para uma planilha de Excel, como no exemplo abaixo:

A planilha precisa então ser salva em uma biblioteca do SharePoint, para que seja possível obter os registros (linhas) através do Power Automate.

Outro ponto muito importante é mapear os tipos de campo (atributos) utilizados para categorizar os projetos no Project for the web. Como expliquei nesse vídeo, é possível criar campos de diferentes tipos (como Tabela de Pesquisa, Escolha, Texto Livre, etc.), então cada atributo (coluna) da planilha precisará ser tratado de maneira diferente quando da realização do mapeamento e conversão para sua contra-parte no Project for the web.

Uma vez no Power Automate, inicia-se o novo fluxo (disparado manualmente) e uma das ações iniciais deve ser a de listar as linhas presentes em uma tabela (assim como iniciar as variáveis que serão utilizadas para armazenar cada um dos atributos a serem passados como entrada quando do cadastramento do novo projeto):

Em seguida, para cada registro (linha) obtido da planilha Excel, deve-se tratar individualmente cada um dos seus atributos (colunas). Esse tratamento é necessário para que seja possível realizar a conversão adequada do valor do atributo, de modo que a informação possa estar de acordo com os parâmetros de entrada requeridos pelo Dataverse. A título de exemplo, vamos analisar o atributo (coluna) ProjectDirection da planilha – para melhor organizar os meus fluxos, eu gosto bastante de utilizar a ação Scope do Power Automate, pois isso me ajuda a colocar todas as ações de um determinado tópico em uma espécie de container:

O tratamento de dados a ser realizado na coluna ProjectDirection utilizará a ação de controle Switch do Power Automate para converter o texto oriundo da planilha (que é um texto livre) no valor respectivo da lista de escolha do campo de mesmo nome, o quel foi criado no Dataverse:

Nesse caso, ao observar os valores de escolha do campo Project Direction na tabela Projects, será possível identificar o valor que de fato é armazenado pelo sistema para cada uma das opções disponíveis:

Ou seja: quando o usuário escolhe a opção Information Technology na lista suspensa o Power Apps está, de fato, gravando o valor 884.760.000 na tabela. Dessa forma, a ação de controle Switch deverá ser configurada para converter o texto oriundo da planilha no valor específico correspondente, pois é esse o valor que deverá ser passado como parâmetro de entrada quando do cadastramento do projeto via processo de automação:

Uma lógica parecida se aplica quando da necessidade de realizar o tratamento de informações que são oriundas de uma tabela de pesquisa, como é o caso do campo Sponsor do exemplo atual. Nesse cenário, o atributo Sponsor tem como origem a tabela de pesquisa Users, e sendo assim deve-se pesquisar nessa tabela o usuário que corresponde ao endereço de e-mail informado na planilha:

Uma vez encontrado o usuário correspondente na tabela Users, é necessário registrar o seu ID interno para que este possa ser utilizado pelo processo de automação quando do cadastramento do projeto (note que o que deve ser passado como parâmetro é o ID do usuário, e não seu nome ou endereço de e-mail):

Após realizar o tratamento e o mapeamento dos campos conforme necessário, é chegado o momento de enfim criar o projeto no Dataverse. Porém (e parece sempre haver um porém!)... ao utilizar a ação adicionar uma linha do Power Automate e apontar para a tabela Projects, seremos apresentados a uma lista de campos obrigatórios que devem ser preenchidos para a criação de um novo projeto no Project for the web. Entre eles:

• Calendar Id
• Contracting Unit (Organizational Units)
• Schedule mode
• Work hour template (Work template)

Eu não fazia ideia de que era preciso ter posse dessas informações para criar um novo projeto no Project for the web via Power Automate 😕. Como não sabia os parâmetros para cada uma dessas informações, fiz o seguinte:

• Criei um novo fluxo no Power Automate, disparado quando da criação de um novo projeto

• Adicionei uma ação qualquer (por exemplo, iniciar uma nova variável), pois todo fluxo deve possuir pelo menos uma ação após seu disparo

Com isso, bastou criar manualmente um novo projeto no Project for the web para que esse fluxo auxiliar fosse disparado. Uma vez executado, foi possível colher os resultados do fluxo, os quais contemplam as informações que precisávamos para finalizar o processo de automação original:

De posse dos dados faltantes, basta regressar ao fluxo original para configurar os parâmetros:

Assim, quando tudo estiver pronto, basta iniciar o fluxo de maneira manual para que todos os projetos da planilha sejam devidamente cadastrados no Project for the web, respeitando e mantendo seus respectivos atributos:

...............................................

Confesso que essa não é, definitivamente, uma tarefa simples e corriqueira. Porém, foi muito gratificamente poder cadastrar todos esses 350 projetos de maneira automática – além de todo o aprendizado gerado a partir dessa necessidade.

Espero que esse post tenha sido útil de alguma forma. Até o próximo 😉.

Integração entre o Project Online e Azure DevOps

 Olá pessoal –

Há um certo tempo eu e meu amigo André Xavier entregamos uma palestra no evento Global Microsoft 365 Developer Bootcamp, e mesmo passados quase 3 anos do evento ainda hoje tenho desenvolvido soluções, através do Power Automate, que permitam a integração e a troca de informações entre o Project Online e o Azure DevOps.

Pretendo retomar esse assunto aqui no blog para compartilhar, com um pouco mais de detalhes, as lições aprendidas que venho coletando ao longo desse tempo a respeito da integração entre essas duas plataformas.

É tudo uma questão de processos

Antes de qualquer coisa, se você pretende iniciar um projeto que tenha como objetivo integrar essas duas plataformas, foque inteiramente no processo. Conversar e obter a maior quantidade possível de informações com os principais interessados na integração é fundamental para que, tecnicamente, a solução seja desenvolvida com sucesso. Procure entender aspectos como:

• Quais times serão beneficiados (ou afetados) com a sincronização? É importante entender quem são os principais interessados pelo processo de integração, e como eles serão beneficiados/afetados. Não é incomum que, dentro de uma organização, diferentes times utilizem o Azure DevOps de diferentes maneiras, de modo que tentar criar um processo de integração único se torne complexo e problemático. Caso você tenha que suportar diferentes times, com diferentes metodologias e processos, talvez o melhor caminho seja construir uma integração individual para cada um dos times.
• Qual o caminho a ser percorrido pelos dados? É preciso determinar se as informações serão coletadas no Azure DevOps para então alimentar o Project Online, ou se o caminho a ser percorrido será no sentido contrário. Ou, caso o processo desejado seja ainda mais complexo, pode ser que exista a necessidade de comunicação em duas vias, onde os dois sistemas trocarão informações entre si.
• Quais informações serão coletadas e processadas na automação? O Azure DevOps permite que as equipes estruturem seu trabalho utilizando os mais variados componentes, como Bugs, Epics, Features, User Story e Tasks. Procure entender como esses componentes estão estruturados na sua organização (ou no seu cliente), e quais deles participarão de fato da integração. Além disso, para cada um dos componentes que eventualmente tenham de fazer parte do processo de integração, entenda quais atributos devem ser sincronizados (Trabalho Real/Restante, datas de Início e/ou Término, etc).
• Qual será a periodicidade de sincronização? Lembre-se que, para editar um projeto no Project Online, é preciso efetuar o seu check-out... nesse contexto, um processo de sincronização que esteja configurado para ser executado muitas vezes ao longo do dia pode se tornar um pesadelo para os gerentes de projeto, uma vez que seus projetos podem ficar indisponíveis em diferentes momentos do dia, em decorrência do processo de automação. Uma recomendação é estabelecer uma periodicidade semanal (programada para acontecer no final de semana).

Crie campos personalizados

Uma vez que o roadmap do processo de sincronização tenha sido definido, o passo seguinte será criar os campos (colunas) personalizados para capturar os principais atributos que irão permitir a comunicação entre as duas plataformas – campos a serem criados tanto no Project Online quanto no Azure DevOps. A princípio, você deve pensar nos seguintes campos/colunas:

É claro que podem haver outros campos/colunas personalizadas que tenham de ser criadas nas plataformas, a depender de quais informações seja necessário coletar.

No azure devops, crie uma consulta robusta e confiável

Caso a necessidade da sua organização (cliente) seja a de sincronizar informações do Azure DevOps para o Project Online (trata-se da grande maioria dos casos), então você deve criar uma consulta extremamente robusta e confiável (no Azure DevOps).

Para melhor esclarecer o parágrafo anterior, é preciso entender que o processo de automação que é iniciado a partir do Azure DevOps precisa ser baseado em uma consulta – uma das primeiras ações do Power Automate é obter os resultados de uma consulta específica criada no ADO. Nesse sentido, ao configurar a consulta, é preciso garantir que seus parâmetros estejam muito bem definidos, afim de que apenas os dados necessário sejam submetidos à sincronização.

Uma consulta robusta e confiável também deve incluir parâmetros de governança e conformidade, evitando que dados contraditórios sejam trazidos ao processamento. Alguns exemplos:

• Caso a sua organização (cliente) tenha a intenção de processar apenas o componente Tasks, configure a sua consulta para filtrar especificamente este item, deixando todos os demais de fora.
• De modo geral, no Azure DevOps os usuários não tem a obrigatoriedade de preencher certas informações – como datas de início e término. Ao tentar sincronizar datas não preenchidas (em branco) com o Project Online o processo de automação gerará erros, e dessa forma é preciso configurar a consulta para que ela exclua do processamento tarefas que não possuam todas as informações a serem sincronizadas.
• Da mesma maneira, o Azure DevOps permite que inconsistências sejam inseridas no âmbito de um componente – por exemplo, um usuário pode inserir uma data de término anterior à data de início. Como o Project Online jamais aceitará que uma tarefa tenha sua data de término definida para antes do seu início, é preciso configurar a consulta para excluir esse tipo de inconsistência.

Lembre-se de que é preciso rever os requisitos de negócio de maneira bem detalhada e meticulosa, para que seja possível identificar os possíveis erros que podem evetualmente acontecer no momento da sincronização, garantindo que eles sejam tratados pela consulta.

Tratamento de erros

Esteja preparado para aplicar o devido tratamento de erros ao processo de automação. Alguns dos erros mais comuns são:

• Projetos em estado de check-out no momento da execução da automação
• Tarefas (ou componentes) que fazem parte do processo de automação e que tenham sido eventualmente excluídas do cronograma (ou do board do Azure DevOps)
• Tarefas com caracteres especiais nos seus nomes (! $ # * & ’ @ etc.)

...............................................

Bem, por hoje era isso. O objetivo era realmente trazer algo mais genérico a respeito do processo de automação, seus eventuais problemas e desafios – e não algo técnico que fosse descrever detalhadamente como estruturar toda a integração.

Se você ainda precisa de alguma ajuda fazer a sincronização funcionar aí na sua empresa, é só entrar em contato 😉.