Pode-se prevenir riscos em projetos de mídias digitais com planos de projeto detalhados que antecipem todas ações e etapas a realizar. No entanto, estes cuidados nem sempre garantem a proteção necessária em um ambiente de negócios e tecnológico, em permanente transformação. Mesmo projetos bem planejados têm chance de falhar.

De modo geral para fazer frente aos imprevistos a gestão de riscos procura reconhecer e prevenir, de modo sistemático, a ocorrência de eventos que possam influenciar negativamente, ou até inviabilizar, sua realização.

Embora seja um processo muitas vezes evitado, pois ninguém gosta de pensar em insucessos e problemas, ajuda a atenuar as consequências dos erros e incertezas, prevenindo-os, antes que seja preciso corrigi-los.

Em um projeto web, a gestão de riscos começa na elaboração do Termo de Abertura do Projeto, que inclui cláusulas como o que fazer em caso de mudanças de escopo, de atrasos de entregas de produtos, de falta de recursos.

E durante a realização do projeto, a gestão de riscos constitui um acompanhamento crítico que, além de minimizar a probabilidade de ocorrer ameaças e de prever o estabelecimento de responsabilidades para enfrentá-las, permite o registro das situações adversas e como evitá-las em empreendimentos futuros.

Projetos de websites costumam estar sujeitos a riscos como

Mudanças nos apoios políticos da direção da organização, o que enfraquece a relação com os stakeholders e desgasta a imagem do projeto.

Também uma mudança do foco da organização ao longo da realização pode fazer com que o projeto deixe de ser uma ação prioritária, o que prejudica a alocação de recursos.

Mudanças da visão de consenso sobre os objetivos, o que pode levar à conclusão de que o produto do projeto não mais atende às necessidades do negócio e pode mesmo ser interrompido ou esvaziado.

Competição com outros projetos da mesma natureza, que ocorre quando dois departamentos têm iniciativas semelhantes, no mesmo momento.

Dificuldade de obter aprovação dos produtos do projeto pelo dono do produto, ou pelos stakeholders responsáveis, ao final de cada etapa, ou sprint.

Planejamento mal direcionado, não especializado, ou insuficiente. O planejamento mais ou menos detalhado serve de linha-mestra para a tomada de decisões sobre a conceituação, a produção, o lançamento e até a manutenção/evolução do website. Precisa ser explicitado aos profissionais diretamente envolvidos.

Estimativas imprecisas de recursos (tempo, recursos financeiros, ferramentas tecnológicas, suporte técnico, pessoas) que levem à paralisação do projeto.

Aumento ou mudança do escopo do projeto durante a realização, sem revisão dos recursos e tempo suficientes para bancá-los.

Rompimento de contrato com fornecedores devido a especificações inadequadas dos requisitos técnicos.

Saída de um elemento-chave da equipe, que afete todos os processos.

Problemas de relacionamento entre os integrantes da equipe.

Ambiente de trabalho ruim, com fadiga motivacional da equipe, comunicação e colaboração deficientes, que desencadeiam atrasos, erros e resultados insatisfatórios. Pode ocorrer também a falta de comprometimento de colaboradores internos porque o projeto está sendo gerido “por outro departamento”.

Treinamento técnico e gerencial insuficiente da equipe, o que atrapalha ou mesmo inviabiliza a realização das tarefas.

Tarefas mal-distribuídas, algumas pessoas fazem tarefas demais e outras poucas, gerando ciúmes e mal-entendidos.

Erros de design, com soluções inadequadas ao público ou às funcionalidades necessárias do programa.

Atraso na entrega do conteúdo pelo cliente ou departamento responsável, o que gera atrasos, desmobilização da equipe, aumento de chances de retrabalho.

É comum os projetos de websites evoluírem satisfatoriamente até a produção de conteúdo. Muitos atrasos ocorrem na hora de produzir os textos, imagens, vídeos e sons. E normalmente mudanças na estrutura de informações, já homologada, são necessárias.

Conteúdo (textos, imagens, sons, vídeos) criado de maneira insatisfatória ou incompatível com o conceito editorial estabelecido, o que exige mudanças na equipe e atrasos no lançamento.

Problemas de segurança de sistemas, com a fragilidade para invasões de diversas naturezas, tentativas de roubo de informações, ou de introduzir conteúdo impróprio. Se a falta de segurança ameaça os dados dos usuários, afeta também a confiança no programa.

Incompatibilidade entre dispositivos e sistemas.

Dificuldade de configurar o sistema para suportar o acesso simultâneo de milhares de usuários.

Excessiva necessidade de retrabalho, para realizar ajustes a partir dos testes de usuários.

Não-realização de testes de usuários, o que pode comprometer a relação com a interface, gerar problemas de usabilidade, demoras no tempo de download das páginas e imprecisão no envio de dados.

Especificações de produto inadequadas, que não proveem as informações necessárias à consistência do produto.

Rejeição do projeto pela equipe encarregada da atualização, manutenção técnica e suporte ao usuário, o que desencadeia uma reaçãonegativa em cadeia que acaba contaminando o usuário final.

Apesar de riscos genéricos como estes serem comuns, é importante que o os riscos registrados no plano de projeto sejam diretamente relacionados à especificidade de cada situação, cada projeto.

A gestão dos riscos aumenta as chances do produto final ficar dentro das expectativas tanto da organização que publica um site, aplicativo ou plataforma, quanto do cliente que vai visitá-lo/usá-lo.

Como o desenvolvimento de grande número de websites costuma ser relativamente rápido, é comum que gestores façam um gerenciamento de riscos simplificado, que enumera apenas os principais aspectos.

A profundidade do levantamento depende dos investimentos aplicados, dos resultados esperados, e especialmente como dos custos do insucesso.

(Atualizado em 12.8.2010)

 

Referências

Four early warning signs of a project in trouble, de Ty Kiisel (Gantthead, acesso em 12.8.2010)

Register real risk (Projects@Work, acesso em 28.2.2009)

Risk blindness, de Mike Clayton (Shift Happens, acesso em 24.1.2010)

Symptoms & sources (Projects@Work, acesso em 3.12.2009)

Two sides of the same coin: Risk management and ROI in scrum (Gantthead, acesso em 2.11.2008)

Between the lines (Projects@Work, acesso em 23.12.2005)