Criar fluxo automatizado para registro de recebimento em pedidos de imersão

[gabrielbdornas]

Devemos registrar o recebimento de pedidos de imersão em formulário conforme #83.

Atividades

• Criar fluxo automate web para resposta via e-mail.
• Criar texto para agradecer envio.
• Melhorar texto explicando formulário.
• Publicar base em formato aberto.
• Informar, no corpo do e-mail de resposta, a classificação obtida na ordem de prioridades.

[gabrielbdornas]

@YanVieira1905:

• Fluxo para registro de recebimento dos pedidos de imersão, primeira versão, já foi criado. Compartilhei ele com você no Automate Web. Recebeu?

• Também gostaria de seu auxílio para validar o texto atual de agradecimento:

A equipe Automatiza.MG agradece pelo envio de sua solicitação. Você receberá uma confirmação de recebimento no e-mail informado. Neste, também informaremos como seu pedido foi classificado dentro de nossos critérios de priorização de demandas. Caso não receba esta mensagem, favor nos acionar no email [email protected].

• Assim como o texto inicial do formulário (quando tivermos nosso domínio podemos incluir algo para mais informações no texto):

Este formulário visa captar solicitações de imersão para projetos de automatização. Nele você nos contará um pouquinho sobre o processo que deseja automatizar.

Caso não tenha entendido algum campo, fique com alguma dúvida durante o preenchimento ou se sinta mais confortável preenchendo com alguém de nossa equipe, favor entrar em contato pelo e-mail [email protected]. Ficaremos felizes em agendar um pequeno horário para te auxiliar.

Favor não incluir nenhuma informação sensível nos campos do formulário pois os dados aqui coletado serão automaticamente disponibilizados em formato aberto.

Solicito validação de toda equipe @dcd-github-admin!

Obs.: A intenção é incluir no corpo do e-mail de resposta a classificação que o pedido recebeu, mas ainda não consegui fazer isso no Automate Web, por isso estou chamando o feito até o momento de primeira versão.

[Andrelamor]

@gabrielbdornas:

• no texto de confirmação do formulário, não seria "Caso não receba o email" em vez de "Caso não receba esta mensagem..."?
• no texto inicial, talvez "ficaremos felizes em agendar um horário para auxiliar" soe mais amistoso que "pequeno horário", já que sabemos de antemão que meia horinha resolveria, certo?
• na parte das informações sensíveis, isso não pode inibir o preenchimento? O conceito de infos sensíveis pode variar, e quem sabe limitar a divulgação aos campos/colunas 'não-sensíveis', seria viável? De qualquer maneira, sugiro colocar um texto apontando para o link/parte do site onde as informações estariam disponíveis, bem sucinto mesmo, tipo "Consulte aqui os pedidos de imersão recebidos e a sua ordem de priorização", daí a pessoa já veria o que de fato está publicado

[Andrelamor]

@gabrielbdornas para o caso de respondente marcar evento único/passivo: vc acha que é gastar muito trocar a restrição do campo 'frequência" de numérica para que venha um pouco mais detalhe (strings)? Nesse caso em particular, não tem como ter ideia da ocorrência, pois não vai ter periodicidade, a não ser que isso tenha sido descrito antes

e para o caso de ser eventual, ou por provocação, mas não tiver periodicidade certa, nem for único/passivo, compensa fazer uma categoria nova 'eventual'?

[gabrielbdornas]

@gabrielbdornas:

• no texto de confirmação do formulário, não seria "Caso não receba o email" em vez de "Caso não receba esta mensagem..."?
• no texto inicial, talvez "ficaremos felizes em agendar um horário para auxiliar" soe mais amistoso que "pequeno horário", já que sabemos de antemão que meia horinha resolveria, certo?
• na parte das informações sensíveis, isso não pode inibir o preenchimento? O conceito de infos sensíveis pode variar, e quem sabe limitar a divulgação aos campos/colunas 'não-sensíveis', seria viável? De qualquer maneira, sugiro colocar um texto apontando para o link/parte do site onde as informações estariam disponíveis, bem sucinto mesmo, tipo "Consulte aqui os pedidos de imersão recebidos e a sua ordem de priorização", daí a pessoa já veria o que de fato está publicado

@Andrelamor, gostei de todas as sugestões. Já, inclusive, realizei as revisões no formulário.

[gabrielbdornas]

@gabrielbdornas para o caso de respondente marcar evento único/passivo: vc acha que é gastar muito trocar a restrição do campo 'frequência" de numérica para que venha um pouco mais detalhe (strings)? Nesse caso em particular, não tem como ter ideia da ocorrência, pois não vai ter periodicidade, a não ser que isso tenha sido descrito antes

e para o caso de ser eventual, ou por provocação, mas não tiver periodicidade certa, nem for único/passivo, compensa fazer uma categoria nova 'eventual'?

@Andrelamor, gosto das sugestões. Incluo @YanVieira1905 para aprovação e posterior modificação do form.

[Andrelamor]

Devemos registrar o recebimento de pedidos de imersão em formulário conforme #83.

Atividades

• Criar fluxo automate web para resposta via e-mail.
• Criar texto para agradecer envio.
• Melhorar texto explicando formulário.
• Publicar base em formato aberto.
• Informar, no corpo do e-mail de resposta, a classificação obtida na ordem de prioridades.

@gabrielbdornas agora o exercício é aplicar o fluxo automate Web para o formulário criado no tally em #83 ?

[Andrelamor]

Tentei ontem e antes de ontem copiar as fórmulas do algoritmo da planilha do sharepoint na planilha-teste do meu google drive, mas sem sucesso.

A questão é como montar um fluxo em que as respostas da planilha gerada do tally forms sejam aplicadas ao algoritmo e depois plote/embede o resultado da lista de priorizações em alguma parte do site, certo, @gabrielbdornas ? Se vc já não tiver acertado isso, gostaria de fazer junto, o que acha?

[gabrielbdornas]

Tentei ontem e antes de ontem copiar as fórmulas do algoritmo da planilha do sharepoint na planilha-teste do meu google drive, mas sem sucesso.

A questão é como montar um fluxo em que as respostas da planilha gerada do tally forms sejam aplicadas ao algoritmo e depois plote/embede o resultado da lista de priorizações em alguma parte do site, certo, @gabrielbdornas ? Se vc já não tiver acertado isso, gostaria de fazer junto, o que acha?

@Andrelamor, ótimo. Comecei um primeiro teste ontem (14/03/2024), mas não finalizei. Primeiro estava entendendo como @YanVieira1905 montou cada parte do cálculo.

Minha estratégia inicial seria refazer as fórmulas feitas no Excel no Google Sheet. Esta primeira etapa seria apenas para entender totalmente o cálculo e ter uma base de comparação com um processo automatizado futuro.
Depois partiria para automatizar o processo utilizando python (utilizando pandas). O macrofluxo pensado inicialmente será:

• Configurar Tally para enviar um e-mail para [email protected] sempre que um novo form for preenchido (Já funcionando, inclusive).
• Utilizar Power Automate Web (trigger novo e-mail recebido) para acionar um GitHub actions para realizar os cálculos.
• Este mesmo actions atualiza os dados no site.

[gabrielbdornas]

@YanVieira1905 e @dcd-github-admin, estou pensando se vale a pena calcularmos o score somente após uma conferência nossa, manual, das informações preenchidas no formulário. Isso evitaria cálculo para situações como essa:

A ideia é, ao sermos notificados do novo pedido, analisarmos as informações preenchidas. Caso o preenchimento seja coerente marcamos uma flag (pensar aonde) autorizando o fluxo do cálculo. Caso o preenchimento esteja estranho, entramos em contato com o demandando para entender melhor. O que acha?

Neste cenário, o usuário receberá um primeiro e-mail falando que o pedido foi recebido e que em até x dias ele receberá uma primeira resposta.

O que acham?

[Andrelamor]

@gabrielbdornas acho que pode calcular e vai dar erro de qq forma (a não ser que o erro de um caso interrompa o fluxo de cálculo automático dos subsequentes).
Sobre programar o email automático dando expectativa de retorno, creio que tem que atentar para o ranking, que é móvel, à medida que outras respostas forem chegando e o algoritmo for recalculando as posições... assim, em x dias mais y a posição no ranking já pode ter mudado!
Para a curadoria, digamos que vamos combinar de checar periodicamente as respostas que chegaram, toda semana, e debater rapidamente numa planning review, daí separamos as respostas com campos fora do padrão para entender melhor a situação que o demandante tenta expressar.
Eu não faria muita expectativa sobre a verossimilhança das infos preenchidas - em que pese o esmero em captá-las com o mais alto grau de exatidão possível! Apostaria que a maior fração das respostas de número de ocorrências e tempo (minutos) será estimada bem por alto, quando não for ignorada tal qual no exemplo acima. Nas imersões até agora, as medidas sempre passaram pela lupa da nossa equipe.
Bom, por fim, vai ter sempre o trade-off necessidade X viabilidade, desafio constante para decisão de quanto tempo seria dedicado pra cada respondente que tiver sua demanda priorizada!

[gabrielbdornas]

@gabrielbdornas acho que pode calcular e vai dar erro de qq forma (a não ser que o erro de um caso interrompa o fluxo de cálculo automático dos subsequentes).

@Andrelamor, não entendi bem este ponto. Poderia explicar melhor. Você acha pode ser calculado quando o formulário chegar, fazemos a curadoria e se for o caso o cálculo será refeito?

Sobre programar o email automático dando expectativa de retorno, creio que tem que atentar para o ranking, que é móvel, à medida que outras respostas forem chegando e o algoritmo for recalculando as posições... assim, em x dias mais y a posição no ranking já pode ter mudado!

Concordo com tudo. O texto do e-mail tem que deixar claro que a priorização pode mudar a todo momento. Outra coisa que tem que ficar claro é o peso final ser dado pela Diretoria, independente do resultado do cálculo. O resultado servirá para nortear nossas decisões e não martelo final de decisão. O que significa dizer que pedidos classificados com o menor score podem ser selecionados a depender da vontade do gestor, no caso @YanVieira1905.

Eu não faria muita expectativa sobre a verossimilhança das infos preenchidas - em que pese o esmero em captá-las com o mais alto grau de exatidão possível! Apostaria que a maior fração das respostas de número de ocorrências e tempo (minutos) será estimada bem por alto, quando não for ignorada tal qual no exemplo acima. Nas imersões até agora, as medidas sempre passaram pela lupa da nossa equipe.

Concordo e não vejo problema em termos respostas apenas estimadas para tempo e volumetria dos processos.

@YanVieira1905 e @augustacora, solicito opinião de vocês sobre o assunto.

[Andrelamor]

em conversa com @gabrielbdornas

• expectativa de tempo de retorno não pode faltar (20 dias?)
• maneiras de se realizar a curadoria (quanto tempo para entrar em retorno com respostas inválidas)
• formulário recebido; email automático com 30 dias para resposta (texto automático informa que respostas incoerentes demorarão mais para retorno e estarão sujeitas a revisões); cálculo não será automático após primeiro envio; análise dos 3 campos principais (ocorrência; minutos gastos por ocorrência; volume financeiro); se estiver coerente, flag da resposta ok, cálculo feito; se não estiver coerente, flag para cálculo não ser feito (e-mail resolve? ou precisa reunião para colocar informação real); após informação real, algoritmo roda e a resposta vai

[gabrielbdornas]

@dcd-github-admin, fiz um teste na planilha onde as respostas estão sendo salvas. Modifiquei, nesta planilha, um valor. Esta atualização não se reflete, como eu esperava, nas informações de resposta gravadas na aba submissions. Acho que incluirmos manualmente na planilha valores após o processo de curadoria muito ruim. Penso nesta planilha como fonte canônica das respostas e não algo que poderá ser modificada por qualquer pessoa.

[augustacora]

@gabrielbdornas acho que pode calcular e vai dar erro de qq forma (a não ser que o erro de um caso interrompa o fluxo de cálculo automático dos subsequentes).

@Andrelamor, não entendi bem este ponto. Poderia explicar melhor. Você acha pode ser calculado quando o formulário chegar, fazemos a curadoria e se for o caso o cálculo será refeito?

Sobre programar o email automático dando expectativa de retorno, creio que tem que atentar para o ranking, que é móvel, à medida que outras respostas forem chegando e o algoritmo for recalculando as posições... assim, em x dias mais y a posição no ranking já pode ter mudado!

Concordo com tudo. O texto do e-mail tem que deixar claro que a priorização pode mudar a todo momento. Outra coisa que tem que ficar claro é o peso final ser dado pela Diretoria, independente do resultado do cálculo. O resultado servirá para nortear nossas decisões e não martelo final de decisão. O que significa dizer que pedidos classificados com o menor score podem ser selecionados a depender da vontade do gestor, no caso @YanVieira1905.

Eu não faria muita expectativa sobre a verossimilhança das infos preenchidas - em que pese o esmero em captá-las com o mais alto grau de exatidão possível! Apostaria que a maior fração das respostas de número de ocorrências e tempo (minutos) será estimada bem por alto, quando não for ignorada tal qual no exemplo acima. Nas imersões até agora, as medidas sempre passaram pela lupa da nossa equipe.

Concordo e não vejo problema em termos respostas apenas estimadas para tempo e volumetria dos processos.

@YanVieira1905 e @augustacora, solicito opinião de vocês sobre o assunto.

Concordo sobre as respostas estimadas no formulário. Mas acho que, uma vez que a imersão seja confirmada, nas nossas métricas posteriores (pra cálculo de tempo economizado, por exemplo) os valores devem ser mais exatos. Fica até mais fácil saber isso certinho quando já estivermos em contato com o órgão em questão.

[gabrielbdornas]

Concordo sobre as respostas estimadas no formulário. Mas acho que, uma vez que a imersão seja confirmada, nas nossas métricas posteriores (pra cálculo de tempo economizado, por exemplo) os valores devem ser mais exatos. Fica até mais fácil saber isso certinho quando já estivermos em contato com o órgão em questão.

Nossa @augustacora, acho que isso faz todo sentido. Então podemos criar um fluxo para cadastro de novos valores caso os preenchidos não estejam consistentes e um fluxo para cadastro final levantado durante o processo de apoio (imersão).

[gabrielbdornas]

@dcd-github-admin, cálculo para priorização de pedidos de apoios finalizados e consolidados neste arquivo .csv. Falta pensar o fluxo para iniciar o fluxo após informarmos que a avaliação inicial está OK. Para teste localmente é necessário criar um arquivo .env na raiz do repositório clonado com o valor PEDIDOS_APOIO_URL configurado. Por gentileza, entre em contato para envio desta informação.

[gabrielbdornas]

Reunião agendada para 15/04/2024 para discussões sobre os pedidos de apoio.

[YanVieira1905]

@gabrielbdornas, acha que consegue publicar a base com aqueles órgãos que já reunimos e com os projetos que estão em andamento? Se quiser, podemos conversar sobre o layout.

[gabrielbdornas]

@gabrielbdornas, acha que consegue publicar a base com aqueles órgãos que já reunimos e com os projetos que estão em andamento? Se quiser, podemos conversar sobre o layout.

Consigo, sim, mas precisamos definir o layout antes. Na verdade, penso que deveríamos pensar no fluxo completo antes de fazer a publicação. Poderíamos criar uma agenda para isso. Este é aquele próximo desafio que você havia me perguntando. Para após a API do SEI.

[YanVieira1905]

@gabrielbdornas, acha que consegue publicar a base com aqueles órgãos que já reunimos e com os projetos que estão em andamento? Se quiser, podemos conversar sobre o layout.

Consigo, sim, mas precisamos definir o layout antes. Na verdade, penso que deveríamos pensar no fluxo completo antes de fazer a publicação. Poderíamos criar uma agenda para isso. Este é aquele próximo desafio que você havia me perguntando. Para após a API do SEI.

Combinado. Vamos priorizar a API do SEI. Irei voltar esse issue para o ToDo.

[gabrielbdornas]

@YanVieira1905, voltei ele p Backlog, já que o ToDo seria uma indicação de que devemos fazer.