CDIF
Apresentar os principais achados da elaboração da proposta e evidenciar os benefícios com a mesma.
Os resultados da proposta de gestão de riscos (GR) na Coordenação de Distribuição e Faturamento (CDIF) são positivos, onde conseguiu-se construir um mapeamento, de- limitação de escopo, contextos internos e externos e principalmente identificar, analisar, avaliar e elencar opções de tratamento, monitoramento e análise crítica dos riscos en- volvidos no processo de publicação de atos oficiais no Diário Oficial do Distrito Federal (DODF) sob essa coordenação.
Elencou-se 11 riscos envolvidos nas cinco etapas do macroprocesso de publicação, onde as principais categorias de riscos são de conformidade, fiscal e estratégico. Os riscos apontados estão distribuídos em diferentes níveis como baixo, médio e alto.
A possibilidade de implementar um processo de GR ainda durante a publicação de atos oportuniza à tomada de decisões podendo ser mais eficiente e eficácia, ou seja, mini- mizando os riscos e maximizando os benefícios para o cumprimento da missão da CDIF. As principais respostas aos riscos envolvidos no processo de GR foram "evitar"e "mi- tigar"de forma que não se espera a aceitar que os riscos ocorram na publicação de atos oficiais, uma proposta inovadora.
O monitoramento de riscos é realizado durante a publicação de atos oficiais como emissão de alerta semafórica (vermelho, amarelo e verde), além de pop-up que permitem um resumo dos riscos envolvidos, as cores e pop-up sinalizam ao técnico de imediato, o que permite uma ação rápida e objetiva. O monitoramento e a análise crítica acontece na ferramenta desenhada especificamente para a publicação de atos oficiais permitindo ao técnico e gestor a sistematização das informações em formato gráficos (dashboard).
As principais limitações observadas nas aplicações práticas da GR estão relacionadas a abordagem dos autores quanto a utilização de dados quantitativos, onde a avaliação qualitativa das normas ou publicações identificadas não foram consideradas. Os dados utilizados foram avaliados no recorte do tempo e em bases científicas específicas, até dezembro de 2018 e nas bases Web of Science e Scopus, desta forma esses são dinâmicos. Os resultados apresentados são baseados nos achados numéricos e na adoção de percepções dos autores e não das instituições.
Capítulo 6
Proposta de Ferramenta voltada à
Gestão de Riscos
Esse apresenta a proposta de ferramenta voltada à gestão de riscos (GR) para o processo de publicação de atos oficiais no Diário Oficial do Distrito Federal (DODF) sob a coordenação da Coordenação de Distribuição e Faturamento (CDIF) no Governo do Distrito Federal (GDF) elaborado, bem como os seus resultados.
6.1
Método de Desenvolvimento de Ferramenta
Os resultados obtidos do levantamento institucional para identificar possíveis soluções direcionadas a gestão de riscos (GR), como as ferramentas de gestão de riscos (GR) disponíveis comercialmente ou gratuitas evidenciadas no Capítulo 3, bem como a proposta de processo de GR para a publicação de atos oficiais no Diário Oficial do Distrito Federal (DODF) sob coordenação da Coordenação de Distribuição e Faturamento (CDIF) no Capítulo 5, além dos insumos coletados nas reuniões com especialistas e técnicos foram incorporados na elaboração da proposta de ferramenta.
A elaboração da ferramenta partiu da recomendação da International Organization for Standardization (ISO) 31000:2009 e 31000:2018, que recomenda que as organizações desenvolvam e implementem ferramentas conforme seus cenários e situações, além de que melhorias continuas sejam realizadas para integrar o processo de GR na sua organização, na governança, na estratégia, no planejamento, na gestão e que desta forma possam reportar recomendações às políticas, os valores e a cultura [8, 55].
A definição do método de desenvolvimento da ferramenta baseou-se nos métodos ágeis, que dão maior agilidade e dinamicidade no processo de desenvolvimento de sistemas ou software [28] como detalhado no Capítulo 2. A escolha pelo SCRUM deu-se por ser o
mais utilizado entre muito dos métodos e metodologias usados pelas equipes ágeis para gerenciamento de projetos [33], [28].
Na figura 6.1 é possível verificar no framework SCRUM os três artefatos principais: • Backlog do Produto, no qual estão, os requisitos de forma priorizada e expressa em
histórias de usuários;
• Backlog da Sprint, composto pelas tarefas relacionadas as histórias selecionadas para serem desenvolvidas na incremento de software, parte do software funcional e integrada Sprint; e
• Incremento de Software, parte do software funcional e integrada ao Sprint.
A metodologia adotado para desenvolvimento da ferramenta, SCRUM dividi o projeto em sprints ou ciclos de duração igual (geralmente 30 dias) que atende o padrão. No início de um sprint a equipe faz um planejamento de sprint para determinar quais recursos do
backlog do produto serão criados, esse é chamado de backlog da sprint, assim a equipe
trabalha em toda a sprint para construir todos os recursos nela [33] (Figura 6.1).
Figura 6.1: Fluxo de trabalho do SCRUM Fonte: Adaptado de [33, p. 15].
Adotou-se que os eventos dos framework partem do time-boxed, que são definidos como o tempo definido para execução e que se dividem em Planejamento da Sprint (4 a 8 horas),
Sprint(1 a 4 semanas); Reuniões Diárias (Daily Scrum) (15 minutos), Revisão da Sprint
(4 horas), ao final do sprint, o software de trabalho que demonstra para o proprietário do produto e para as partes interessadas na revisão do sprint, Retrospectiva da Sprint (3 horas), a equipe realiza uma retrospectiva para descobrir as lições aprendidas [33].
Para o desenvolvimento da ferramenta utilizou-se noTime Scrum três papéis funda- mentais o Product Owner (PO), que é responsável por especificar os requisitos (histórias de usuários), toma as decisões sobre o projeto e garante o entendimento do Backlog do Pro- duto, o Scrum Master, responsável por garantir a compreensão e uso correto do SCRUM
e o Time de Desenvolvimento, composto por profissionais responsáveis por produzirem o Incremento do Software [33].
A definição do PO, que é o dono do projeto e é responsável por representar o inte- resse de todas as equipes envolvidas no projeto [130, p. 255], no qual se determinou o coordenador da Coordenação de Distribuição e Faturamento (CDIF). As principais res- ponsabilidade estabelecidas para o tal, conforme [33] foram:
• Definir as funcionalidades do produto;
• Decidir a data de liberação e conteúdo de cada liberação; • Responder pela rentabilidade do produto;
• Priorizar as funcionalidades levantadas;
• Ajustar funcionalidades e prioridades a cada Sprint; e • Aceitar ou rejeitar resultados.
A definição do papel do Scrum Master tem o papel de líder facilitador que gerencia os processos, desempenhado por um gerente de projetos, ou um líder técnico, mas pode ser qualquer pessoa, neste caso foi atribuída ao técnico da CDIF, que conforme [33] tem as principais responsabilidades as quais são:
• Esclarecer o andamento do projeto;
• Difundir os valores do SCRUM e suas práticas entre a equipe; • Garantir as reuniões diárias;
• Promover obstáculos eventualmente encontrados; • Proteger a equipe contra interferências internas; • Conduzir os eventos realizados;
• Garantir a produtividade da equipe; e
• Possibilitar uma cooperação estreita entre todos os papéis e funções.
Para o Scrum Team que é o responsável por desenvolver o software e esse organiza a distribuição das tarefas entre seus membros e mostrar os resultados alcançados, neste caso adotou-se um consultor externo. De [131, p. 20] define que o Scrum Team deve ter entre suas principais características as seguintes:
• Ter a liberdade de fazer qualquer coisa dentro das diretrizes do projeto para alcançar os objetivos da Sprint;
• Capacidade de auto organizar as atividades; • Apresentar os resultados do trabalho ao PO; • Proteger a equipe contra interferências internas; e
• Todos trabalham juntos para finalizar a lista de atividades que eles se comprometem a realizar.
Os resultados da aplicação do SCRUM para desenvolvimento da ferramenta para o processo de GR no DODF sob coordenação da CDIF serão os artefatos elaborados, docu- mentação inicial para garantir um desenvolvimento ágil e eficiente permitindo o levanta- mento de requisitos para implementações futuras (Apêndice D, Seção 6.2).