Impacto do Retrabalho na Cadeia de Valor e Recomendações Finais

Conforme exibido na Figura 4.11, que ilustra o ciclo da ordem de serviço, cada vez que erros são encontrados nas avaliações solicitadas via demanda, ou durante o processo de homologação pelo cliente, a OS é retornada à fábrica, devendo ser corrigida em até 48 horas, segundo o contrato, gerando um retrabalho para a equipe e refletindo em atrasos nos projetos.

Após realizada a correção das não conformidades apontadas, a fábrica reentrega a OS, e o líder de projeto abre uma demanda para que a equipe que realizará a reavaliação verifique se os erros foram corrigidos na aplicação. Porém, esta demanda, ao ser aberta, vai para o final da fila do setor responsável e fica aguardando atendimento. Quando este ciclo ocorre mais de uma vez, como é o caso evidenciado na Figura 4.10, onde a maioria das OSs da CGSI passam por até 2 ciclos de testes, o atraso da OS excede facilmente mais de uma semana.

Esse tipo de atraso em cada OS de um mesmo projeto faz com que o projeto inteiro atrase. Com base nestes resultados, a gerência de riscos se faz necessária para que a CGSI consiga gerenciar os riscos dos projetos de software atacando a causa raiz dos problemas, ou seja, identificando, tratando e planejando ações de resposta a estes riscos a fim de mitigá-los, diminuindo o percentual de não conformidades encontradas e sucessivamente o de atraso.

Ou seja, todo o ciclo de retrabalho poderia ser minimizado, caso os riscos fossem geridos durante o processo de desenvolvimento do software. A Árvore de Falhas identificou inconformidades em todos os tipos de avaliação e identificou que algumas OSs passaram até por mais de 4 ciclos de testes, o que deixaria inviável qualquer prazo acordado com o cliente.

Figura 4.11: Ciclo da Ordem de Serviço. Fonte: Elaboração própria.

A Tabela 4.2, evidencia o atraso das OSs referentes aos sistemas solicitados por cada diretoria do INEP. Os prazos executados em média das OSs de cada diretoria equivalem a mais que o dobro da média em dias do que foi previsto, independente do tipo da OS.

Pode-se verificar que as diretorias DEED, DGP e DAEB juntas demandam mais de 70% dos serviços de TI. Coincidentemente, nestas diretorias estão vinculados os projetos dos censos da educação básica e superior e vários exames e avaliações, tais como: ENEM, ENCCEJA, SAEB, CENSOS, PROVINHA BRASIL, dentre outros.

Tabela 4.2: Cluster de prazo estimado x executado por diretoria. Fonte: Elaboração própria

cluster 1 2 3 4 5 6

Tamanho 27,5% (257) 25,8%(241) 21,1%(197) 10,6%(99) 8,7%(81) 6,3%(58)

Diretoria DEED DGP DAEB DAES DTDIE DIRED

Prazo estimado 7,41 6,17 7,76 6,6 5,94 7,28

Prazo executado 15,54 12,64 18,86 15,11 12,81 20,41

a cadeia de valor. Por conseguinte, afeta as áreas de negócio, pois atrasa a chegada do software nos ambientes de homologação e produção.

Há necessidade de uma adoção da gestão de riscos nos projetos de TI que reflita todas as áreas do processo de desenvolvimento de software para minimizar os percentuais de inconformidades encontrados e exibidos na Figura 4.10. A elaboração da metodologia de gestão de riscos para a CGSI visa auxiliar os líderes de projetos de software a realizarem de forma padronizada a gestão de riscos em seus projetos, e os guiará, informando como poderá ser realizado em conjunto com o Scrum.

Com base no diagnóstico da situação atual baseado na análise da taxa de atrasos das OSs e nas causas raízes das inconformidades encontradas durante a aferição da qualidade, foi possível verificar que a maioria atrasa por inconformidades encontradas durante a execução dos testes, o que gera um retrabalho devido a correção de erros e defeitos, atrasando sua entrega. Tais inconformidades são oriundas de riscos que poderiam ser mitigados caso houvesse uma gestão de riscos durante o processo de desenvolvimento de software. Com base nesta situação, a próxima seção deste trabalho, apresentará a proposta de metodologia de gestão de riscos que explica como poderá ser realizado o processo da gestão de riscos dentro das fases do Scrum e quais ferramentas podem ser utilizadas.

Capítulo 5

Proposta de Metodologia de Gestão

de Riscos da CGSI

5.1 Contextualização

A metodologia de gestão de riscos proposta neste trabalho se trata de uma integração da gestão de riscos tradicional ao processo ágil de desenvolvimento de software utilizado nesta coordenação. Esta iniciativa está alinhada com o PDTI (2016-2019), em seu objetivo estratégico 7: ‘Aprimorar a gestão de projetos’ e metas a seguir:

• Meta 3 - ‘Aumentar a efetividade das ações de governança de TI’.

• Meta 6 - ‘Aumentar as ações de modelagem, definição de processos e metodologias’. A metodologia proposta é um conjunto de conceitos, processos, papéis, técnicas e ferra- mentas que tem por finalidade nortear a atuação dos envolvidos na condução da gestão de riscos em projetos de desenvolvimento ágil de software. Esta metodologia é compatível

com a INC no _{1, de 10 de maio de 2016, publicada pela CGU e pelo MP, que dispõe}

sobre controles internos, gestão de riscos e governança no âmbito do Poder Executivo

Federal. A INC CGU/MP no _{01/2016 tornou obrigatória aos órgãos e entidades do Poder}

Executivo Federal a adoção de medidas para a sistematização de práticas relacionadas à gestão de riscos, aos controles internos e à governança. A metodologia proposta também é compatível com as normas técnicas NBR ISO/IEC 31000:2009, 31010:2012 e NBR ISO /TR 31004:2015 que discorrem sobre a gestão de riscos, técnicas e ferramentas para a sua adoção e implementação da gestão de riscos, respectivamente [1], [2], [3]. Leva ainda em consideração, os padrões já adotados internamente, tais como:

• Framework Scrum (framework adotado para desenvolvimento dos sistemas) • MGDS (Metodologia Geral de Sistemas de Informação) e

• MGP (Metodologia de Gestão de Projetos).

Todos fornecem elementos para a descrição da metodologia proposta para a CGSI. Porém as definições trazidas na INC CGU/MP n 01/2016, são soberanas em relação a qualquer definição assumida internamente que não esteja alinhada a ela. Esta metodologia poderá ainda ser apoiada por software computacional, porém é independente de qualquer ferramenta.