1 INTRODUÇÃO

O início dos projetos de software está diretamente relacionado a alguma necessidade do negócio, de origem corretiva, adaptativa, de extensão de recursos ou de inovação (PRESSMAN, 2008). A maioria dos projetos de desenvolvimento de software enfrenta grandes riscos que podem ocorrer durante todo o processo de desenvolvimento. Tao (2008) aponta que muitos desses projetos tentam aumentar a capacidade atual do software para alcançar algo que não foi feito antes, mas que esse avanço não pode ser obtido sem correr riscos. Nesse sentido, os riscos devem ser diminuídos para que seja alcançado o sucesso de um projeto, considerando que o mercado exige cada vez mais softwares atualizados e desenvolvidos o mais rápido possível (TAO, 2008).

O ambiente de desenvolvimento de softwares é marcado por um elevado grau de exposição a riscos mercadológicos, financeiros e técnicos (DEY; KINCH; OGUNLANA, 2007). Embora os métodos tradicionais de gerenciamento de projetos procurem dar conta dos riscos do projeto, não há nenhum projeto de pesquisa ou um modelo específico para o gerenciamento de risco de software (JUN-GUANG; ZHEN-CHAO, 2010). Nesse contexto, Boehm e Demarco (1997) definem que o objetivo do gerenciamento de riscos é minimizar os riscos presentes em atividades técnicas, minimizar os riscos de retrabalho e o uso excessivo de recursos destinados a correções de desvios ou mesmo de atrasos e cancelamentos.

O risco técnico consiste em variáveis que podem designar o sucesso do projeto. Ele pode definir a probabilidade de que eventos indesejados aconteçam em projetos de desenvolvimento de software. Os danos causados por esses eventos podem resultar em má qualidade do software, aumento dos custos, falha e/ou conclusão atrasada das atividades (TAO, 2008).

Com a finalidade de identificar elementos associados ao risco técnico presente em projetos de desenvolvimento de software, este artigo busca responder à seguinte questão de pesquisa: como o gerenciamento de riscos técnicos pode contribuir na conclusão projetos em um ambiente de desenvolvimento de softwares? Para responder a essa questão, foram utilizados como unidade de análise projetos de desenvolvimento de software de uma empresa brasileira de Tecnologia da Informação.

Assim, na seção seguinte, será apresentada a revisão de literatura sobre projetos de desenvolvimento de software e gerenciamento de riscos e de riscos técnicos em projetos de desenvolvimento de software. Posteriormente, serão abordados os procedimentos metodológicos e apresentados os resultados. Por fim, serão discutidas as limitações desta pesquisa e indicações para estudos futuros.

2 REFERENCIAL TEÓRICO

2.1 Projetos de desenvolvimento de software

A definição de projetos foi, ao longo dos tempos, sendo aprimorada com o propósito de estabelecer um entendimento único e comum nas organizações que atuam com esse tipo de empreendimento (RABECHINI; CARVALHO, 1999). Pode-se perceber que os conceitos em relação a tempo e à unicidade estão presentes nas definições de certos autores, como Shenhar e Dvir (2010), Kerzner (2009), Turner (2009) e PMI (2013), o que não significa, contudo, que a temporalidade não se traduza em empreendimentos de curta duração, pois projetos podem durar semanas, meses ou anos.

Neste artigo, o conceito de projeto utilizado relaciona-se ao esforço temporário para criar um produto ou serviço. Um projeto possui início e fim definidos, sendo este estabelecido quando o objetivo é alcançado ou cancelado, além de requerer empenho financeiro, materiais e recursos humanos.

Em relação ao gerenciamento de projetos de desenvolvimento de software, o processo de gestão, de acordo com Xiaosong et al. (2009), está dividido em quatro estágios (Figura 1):

• identificação − pesquisa, listagem e caracterização dos elementos de risco

• análise − priorização dos riscos identificados por meio de critérios estabelecidos

• planejamento − seleção e implementação das opções de tratamento de risco

• gerenciamento − implantação, monitoramento por relatórios e revisão das ações de gestão dos riscos em relação aos objetivos do projeto.

Figura 1
Os quatro estágios do gerenciamento de projetos de desenvolvimento de software.
adaptado de Xiaosong et al. (2009, p. 1).

A engenharia de software deve ser capaz de produzir modelos destinados à melhoria de processos como meio de aumentar a probabilidade de sucesso na execução de projetos (PRESSMAN, 2008). Projetos de software apresentam altas taxas de desvios de prazo e custos, variáveis que, muitas vezes, são ignoradas pelos profissionais desenvolvedores de software. Assim, a necessidade do uso de metodologias orientadas ao processo de gerenciamento de projetos aumenta dentro das organizações, a fim de, conforme Dey, Kinch e Ogunlana (2007), assegurar a definição e o cumprimento de metas, custos, prazos e qualidade do software produzido.

Projetos de desenvolvimento de software fornecem informações para o apoio às operações, para a análise de gestão e para a tomada de decisões dentro de uma organização. No entanto, além dos desafios de gerenciamento de escopo e qualidade, projetos de software demandam grande esforço no gerenciamento de tempo e custo. Tais aspectos remetem à modelagem de risco de mercado, riscos financeiros e riscos técnicos (DEY; KINCH; OGUNLANA, 2007).

Ao discutir aspectos associados a projetos de softwares, Tao (2008) aponta que o risco pode ser descrito em termos de eventos que podem influenciar o sucesso do projeto. O risco relaciona-se à probabilidade de eventos indesejados que, caso aconteçam, tendem a gerar atrasos na programação da entrega, erros nas estimativas de recursos etc.

Alguns gestores de projetos de desenvolvimento de software afirmam que empregam técnicas de gerenciamento em seus projetos, mas há evidências de que não efetuam o gerenciamento de riscos de forma sistemática. Muitas vezes, esses gestores desconhecem os riscos técnicos e raramente lidam com os riscos financeiros e de mercado − fatores cruciais para obter sucesso no desenvolvimento de software (DEY; KINCH; OGUNLANA, 2007).

Os riscos técnicos estão diretamente ligados ao sucesso do projeto e não devem ser negligenciados. Assim, é de grande importância a adoção e o emprego de processos de gerenciamento eficazes, levando em conta as características do processo de desenvolvimento de softwares, como meio de minimizar possíveis perdas e/ou maximizar ganhos nos empreendimentos ligados à indústria de software.

2.2 Gerenciamento de riscos em projetos

O gerenciamento de riscos do projeto tem como objetivo aumentar a probabilidade e o impacto dos eventos positivos e diminuir a probabilidade e o impacto dos eventos adversos ao projeto (PMI, 2013). Os riscos do projeto são entendidos como eventos ou condições incertas que, se ocorrerem, terão efeitos positivos ou negativos sobre ao menos um objetivo do projeto, como tempo, custo, escopo ou qualidade.

Em relação aos pontos negativos, Carvalho e Rabechini (2009) apontam que a maioria das organizações possui a tendência de focar apenas aspectos negativos, devido à experiência dos profissionais, que possuem mais facilidade para identificar potenciais falhas e problemas do que para procurar oportunidades. Em suma, caso algum evento incerto ocorra, poderá haver um impacto indesejável no custo, no cronograma ou no desempenho do projeto.

Fatores como práticas de gerenciamento deficiente, inexistência de métodos ou sistemas de gerenciamento integrados, falhas na comunicação, implantação de vários projetos simultaneamente, dependência de participantes externos e falta de qualificação das equipes de projeto são apontados como causas de riscos que, se devidamente corrigidas e melhor planejadas, podem ser contornadas. Assim, os riscos devem ser controlados e monitorados a fim de garantir que os objetivos sejam cumpridos por meio da diminuição dos impactos negativos (ameaças) e do aumento dos positivos (oportunidades).

Os riscos são inerentes a qualquer projeto. Nesse sentido, o gerenciamento de riscos vem se tornando cada vez mais importante nas organizações. Koontz e O´Donnel (1982) definem que gerenciar consiste em executar tarefas e atividades para atingir determinado propósito com o mínimo de desvios, o que deve ser feito por meio do uso sistemático do planejamento e do controle. Assim, todas as etapas e ações no âmbito de um projeto, desde sua iniciação até a fase de finalização, remetem de uma forma ou de outra ao gerenciamento de riscos.

2.3 Riscos em projetos de desenvolvimento de software

Existem vários riscos associados ao desenvolvimento de um produto de software, mas poucas são as estratégias e ações definidas para evitá-los ou tratá-los. Talvez este seja o motivo pelo qual os riscos de software sejam discutidos em termos de custos, cronograma e consequências técnicas (TAO, 2008). O risco consiste em variáveis que podem designar o sucesso do projeto, de modo que seu o gerenciamento é uma ferramenta fundamental.

A baixa qualidade na definição dos objetivos do projeto, a falta de detalhamento de suas atividades, os erros de estimativa e a alocação ineficiente dos recursos empregados são fatores de risco que podem impactar diretamente a entrega do projeto. Com a finalidade de apoiar a identificação do risco, Fontoura, Price e Hill (2004) apresentam os riscos inseridos no contexto de gerenciamento de projetos identificados por seu tipo de ocorrência, conforme demonstrado no Quadro 1, exposto a seguir.

Quadro 1
Identificação de risco.

Fontoura, Price e Hill (2004, p. 5).

Esses fatores acontecem devido à falta de conhecimento do risco da atividade, gerando uma incerteza tecnológica no projeto, que, de acordo com Shenhar e Dvir (2010), é universal e subjetiva − isso porque depende do conhecimento tecnológico que existe ou que é acessível. Nesse sentido, o risco técnico em software é compreendido como uma medida de probabilidade e severidade dos efeitos adversos essenciais ao processo de desenvolvimento de software que não suprem os requisitos planejados e as funções específicas (CHITTISTER e HAIMES, 1993; ZMUD, 1980). Com o objetivo de focar os melhores esforços nos riscos certos, Pritchard (2001) definiu a identificação dos riscos em cinco categorias, expostas no Quadro 2.

Quadro 2
Fontes de risco por categoria.

Pritchard (2001).

Na tentativa de minimizar os impactos negativos dos riscos técnicos em projetos de desenvolvimento de software, Boehm (1990) recomenda que os gerentes evitem situações como: (i) orçamento e cronogramas fora da realidade, (ii) desmotivação da equipe e (iii) funções incorretas do software. Em se tratando de cronogramas, é possível mencionar como principal fator de impacto o risco técnico, que, relacionado a erros nas estimativas das atividades, pode causar atraso na data de entrega e/ou cancelamento do projeto. A definição da estimativa de duração de cada atividade e, por conseguinte, de duração total do projeto depende de informações do escopo de trabalho das atividades, do cronograma, do tipo de recurso necessário, da quantidade de recursos e do calendário de disponibilidade de recursos.

Para um profissional qualificado, tais estimativas podem ser estimadas por meio de diferentes técnicas. De acordo com Jiang e Klein (1999), a mais comum é por meio do método matemático de probabilidade subjetiva, em que não são necessários muitos dados para estabelecer determinado valor.

3 METODOLOGIA

O uso de uma estratégia apropriada de pesquisa permite alcançar conclusões sobre determinado assunto baseadas em evidências (MARTINS; THEÓPHILO, 2009). De acordo com Vergara (2013), a taxonomia dos critérios de avaliação de pesquisas é proposta em relação aos fins e aos meios da pesquisa. Para este estudo, foram adotados os seguintes critérios:

• em relação aos fins − uso de pesquisa descritiva com o propósito de analisar o índice de projetos cancelados ou com data de entrega adiada em relação à planejada, antes e após o uso mais efetivo de gerenciamento de riscos técnicos em projetos de desenvolvimento de projetos de software (SANTOS, 1999; YIN, 2010)

• em relação aos meios − uso de pesquisa de natureza qualiquantitativa, incluindo um estudo com análise documental e processo de observação envolvendo 827 projetos de desenvolvimento de software, entre os anos de 2005 e 2012 em uma empresa do segmento da Tecnologia da Informação. A análise e a interpretação dos dados coletados podem variar em função do delineamento da pesquisa científica, permitindo, assim, tratar os dados da pesquisa de forma qualitativa e quantitativa ao mesmo tempo (CHIZZOTTI, 1998; SANTOS FILHO; GAMBOA, 2000).

3.2 Levantamento, coleta e análise dos dados

A questão de pesquisa descrita neste trabalho é abordada por meio da identificação de fatores de risco técnico na área de desenvolvimento de software da empresa objeto de estudo, conforme procedimento explicitado a seguir. Para a fase de levantado de dados, inicialmente foram identificados os dados primários e secundários de projetos por meio de análise de documentos da base histórica dos projetos. Na sequência, foram coletados dados de projetos concluídos dentro do prazo planejado e de projetos cancelados ou com desvio de prazo em relação à data de entrega planejada − desvios esses associados à incidência de riscos técnicos, ocorridos durante os anos de 2005 a 2008.

A validação dos resultados foi realizada por meio do teste de hipótese não paramétrico de Mann-Whitney. Efetuaram-se, assim, uma análise comparativa entre o período de 2005 a 2008, quando não havia nenhuma medida de gerenciamento de riscos técnicos, e uma análise do período de 2009 a 2012, quando foram implementadas práticas de gerenciamento desses riscos.

Segundo Guimarães e Cabral (1997), quando se possui uma amostra pequena, com tamanho menor que 30 elementos, a variável aleatória não tende a seguir uma distribuição normal de probabilidades, sendo prudente a utilização de um teste de hipóteses não paramétrico. Dessa forma, como as amostras deste estudo são pequenas e não são emparelhadas, utilizou-se, portanto, o teste de Mann-Witney.

Devore (2000) define que o teste de Mann-Whitney foi desenvolvido primeiramente por F. Wilcoxon em 1945, para comparar tendências centrais de duas amostras independentes de tamanhos iguais. Snedecor e Cochran (1980) apontam que o único pressuposto exigido para a aplicação do teste de Mann-Whitney é que as duas amostras sejam independentes e aleatórias e que as variáveis em análise sejam numéricas ou ordinais (os pressupostos para a aplicabilidade do teste t-Student, por exemplo, são mais exigentes: as populações de onde as amostras provêm têm distribuição normal; as amostras são independentes e aleatórias; e as populações têm uma variância comum).

Snedecor e Cochran (1980) apresentam a lógica do teste como a mesma lógica utilizada no teste t: calcula-se certa estatística de teste e obtém-se o p-valor a partir da distribuição amostral dessa estatística sob H0. A diferença é que, em vez de construir essa estatística com dados originais, eles são previamente convertidos em postos (ordenações). Snedecor e Cochran (1980) definem que a vantagem é que, com isso, as suposições de normalidade e homogeneidade das variâncias não são necessárias, permitindo mais generalidade aos resultados. Outra vantagem apresentada por Guimarães e Cabral (1997) acerca da utilização do teste de Mann-Whitney é que ele pode ser aplicado em uma variável que seja originalmente ordinal, enquanto que o teste t exige uma escala contínua.

3.3 Caracterização da empresa em estudo

A empresa abordada nesta pesquisa é uma companhia líder no mercado de desenvolvimento de softwares para Contact Center. Iniciou suas atividades no Brasil no estado de São Paulo, no ano de 1999. A partir de 2000, começou a expansão de seus negócios com a criação de novos serviços nas áreas de finanças, telecomunicações, seguros, tecnologia e indústrias, alcançando como resultado o status de uma empresa de Contact Center com a prestação de serviços em múltiplas plataformas e tecnologias.

Alguns dados importantes sobre a atuação da empresa no Brasil no ano de 2010 são: atuação em mais de 15 países; desde o ano 2000, a empresa multiplicou por três o número de funcionários, passando de 40.324 para 152.000; mais de 500 clientes de diversos setores em todo o mundo; terceira maior empresa de Contact Center do mundo; em 2012, a receita da empresa apresentou um crescimento de 1.663 bilhões de euros.

3.4 Hipóteses e variáveis

De acordo com Machado (2002), o processo de gerenciamento de riscos em projetos é muito pouco praticado em empresas de desenvolvimento de softwares. Segundo Jones (2000), a falta ou o uso ineficiente de um processo de gerenciamento é também considerado uma das principais causas de fracasso em projetos de software.

Além desse fator, existem as estimativas de prazo e de custo das atividades, que são associados à categoria de riscos técnicos. Tais fatores são importantes para caracterizar o sucesso ou a falha do projeto. Nesse sentido, a análise desses fatores, que consiste na principal contribuição deste trabalho, testa os resultados da seguinte hipótese:

H1: A melhora na gestão do risco técnico tem impacto positivo na redução da taxa de projetos com desvio de prazo em relação à data planejada.

H2: A melhora na gestão do risco técnico tem impacto positivo na redução da taxa de projetos cancelados.

Onde:

risco técnico − medido pelo emprego de técnicas com o objetivo de minimizar os impactos negativos em projetos de desenvolvimento de software (BOEHM, 1990);

taxa de projetos com desvio de prazo − índice dos projetos com desvios de prazo no período da pesquisa (PRITCHARD, 2001);

taxa de projetos cancelados − índice dos projetos cancelados no período da pesquisa (PRITCHARD, 2001).

4 RESULTADOS OBTIDOS

4.1 Problemas enfrentados pela empresa

O crescimento da área de desenvolvimento de softwares da empresa ocorreu de forma rápida e abrupta, devido ao aumento da sua carteira de clientes e, consequentemente, de seus projetos de desenvolvimento de software. Nessa mesma velocidade de crescimento, o índice de projetos cancelados ou com data de entrega alterados em relação à data previamente planejada também aumentou.

Durante o ano de 2005, o índice de projetos cancelados ou com data de entrega alterada em relação à data planejada foi de 40,48%. A empresa teve um total de 109 projetos. Desse total, 45 projetos foram cancelados ou tiveram sua data de entrega alterada e 64 projetos foram entregues dentro do prazo planejado.

Com o objetivo de identificar os principais fatores associados ao gerenciamento de riscos técnicos responsáveis pelo índice de projetos cancelados ou projetos com a data de entrega alterada em relação à data previamente planejada, foi realizada uma análise documental pelo gerente de projetos da empresa em estudo. Além da análise documental, o gerente de projetos, por meio da utilização do processo de observação, procurou identificar as possíveis falhas relacionadas ao gerenciamento dos riscos técnicos dos projetos.

O gerente de projetos é responsável por toda a carteira de projetos de desenvolvimento de softwareda empresa analisada, participando na tomada de decisões desde a fase de planejamento até o acompanhamento pós-implantação. Em síntese, após efetuar a análise documental e a observação das técnicas de gerenciamento dos riscos técnicos, o gerente identificou que o processo de crescimento da área de desenvolvimento de softwares se processou em meio aos seguintes fatores:

• ausência de processos estruturados nas áreas de gerenciamento de projetos e de gerenciamento de riscos técnicos em projetos

• carência de recursos humanos qualificados e uso de soluções paliativas, como alocação de pessoal com baixo nível de qualificação técnica e em projetos

• emprego de estimativas ad hoc, sem uso efetivo de metodologias para levantamento de requisitos e obtenção de estimativas confiáveis de duração e custo das atividades

• falta de utilização de metodologia de apoio na prática de desenvolvimento de softwares

• inexistência de uma base histórica de projetos concluídos, de modo que novos projetos passavam pelos mesmos problemas enfrentados em projetos anteriores.

4.2 Análise e procedimentos de gerenciamento de riscos técnicos adotados

Com base nos possíveis fatores responsáveis pelo alto índice de atraso e cancelamento dos projetos em relação ao planejado, o gerente de projeto resolveu adotar um conjunto de práticas de gerenciamento de riscos técnicos com o objetivo de diminuir o índice de projetos cancelados ou com desvios de prazo em relação ao planejado e, por conseguinte, aumentar o índice de projetos entregues dentro do prazo previamente planejado.

Dentre os fatores de riscos técnicos apontados por Jiang e Klein (1999), que, tratados e gerenciados, podem garantir que o projeto seja entregue de maneira bem-sucedida, estão a falta de conhecimento necessário da tecnologia e/ou de competências da equipe. Para suprir tal necessidade, o gestor adotou a prática de contratação de mão de obra especializada com maior nível profissional e maior conhecimento técnico.

Resumidamente, os seguintes fatores associados às práticas de gerenciamento de riscos técnicos foram adotados pelo gerente de projetos a fim de melhorar o índice de projetos bem-sucedidos em relação ao cumprimento de prazo:

• aumento do controle e monitoramento das atividades dos projetos de desenvolvimento de software relacionadas aos riscos técnicos

• contratação de mão de obra com maior nível de experiência profissional e técnica

• adoção de boas práticas para o processo de desenvolvimento de softwares

• criação e utilização de uma base histórica de projetos como apoio às estimativas de projetos futuros.

Para a elaboração deste estudo, foram utilizados projetos de desenvolvimento de software realizados durante o período de janeiro de 2005 e dezembro de 2012. Procurou-se analisar o índice de projetos cancelados ou com desvios de prazo em relação à data de entrega planejada e identificar os fatores de riscos técnicos que impactavam diretamente o índice de projetos entregues dentro do prazo planejado.

Para a elaboração deste estudo, foram utilizados projetos de desenvolvimento de software realizados durante o período de janeiro de 2005 e dezembro de 2012. Procurou-se analisar o índice de projetos cancelados ou com desvios de prazo em relação à data de entrega planejada e identificar os fatores de riscos técnicos que impactavam diretamente o índice de projetos entregues dentro do prazo planejado.

Durante o período entre janeiro de 2005 e dezembro de 2008, a empresa foco deste estudo não adotava de forma efetiva práticas ou metodologias de gerenciamento de riscos técnicos em sua área de desenvolvimento de softwares, de modo que a quantidade de projetos atrasados e cancelados era similar à quantidade de projetos entregues na data planejada. O número dos projetos entregues dentro do prazo inicial estipulado no plano de projeto, sem a incidência de algum imprevisto previamente analisado e contido no escopo, era de 58,72%; já o índice de projetos atrasados/cancelados era de 41,28% no ano de 2005. No ano de 2006, o índice foi de 60,19% para os projetos entregues no prazo e de 39,81% para os projetos atrasados ou cancelados. Por fim, em 2008, os índices ficaram em 60,19% e 39,81%, respectivamente, para projetos entregues no prazo e para projetos com desvios de prazo ou cancelados. A Figura 2, exposta a seguir, apresenta a quantidade total de projetos com desvio de prazo ou cancelados e de projetos que tiveram sua data de entrega planejada cumprida, durante o período analisado neste artigo.

Figura 2
Taxa de projetos entregues no prazo e projetos cancelados ou com desvio de prazo em relação ao planejado.
elaborado pelos autores.

O sucesso no desenvolvimento de softwares está estritamente associado à qualidade, à funcionalidade e à oportunidade (DEY; KINCH; OGUNLANA, 2007). De acordo com Tao (2008), ele não pode ser alcançado sem o tratamento dos riscos, principalmente dos riscos técnicos que se relacionam a desvios nos prazos e/ou ao cancelamento de projetos.

Diante desse cenário e com o objetivo de aumentar o índice de projetos entregues dentro do prazo planejado, a partir do ano de 2009, a área de desenvolvimento de software da empresa passou a utilizar práticas de gerenciamento de riscos técnicos para minimizar os impactos causados pelos projetos cancelados ou entregues fora do prazo acordado. Foram adotadas, então, técnicas de gerenciamento de riscos técnicos no processo de desenvolvimento dos projetos de software. A alocação de recursos em atividades passou a respeitar fatores de riscos técnicos, como a criticidade do projeto e o nível de maturidade profissional. Novas técnicas para a estimativa de atividades passaram a ser utilizadas, incluindo, por exemplo, a adoção de uma base histórica de projetos para auxiliar nas estimativas das atividades.

Com base nos fatores utilizados para identificar o índice de projetos cancelados ou com data de entrega adiada em relação à planejada, elaborou-se o Quadro 3, que demonstra, para cada fator responsável pelo índice, o cenário da empresa entre os anos de 2005 e 2008 e as medidas tomadas a partir de 2009 para diminuir o índice de atraso e cancelamento dos projetos da empresa em relação ao planejado.

Quadro 3
Fatores de risco técnico na área de desenvolvimento de software da empresa em estudo.

elaborado pelos autores com base em Dey, Kinch e Ogunlana (2007), Jun-guang e Zhen-chao (2010), Jones (2000) e Tao (2008).

Fatores	Cenário até 2008	Cenário a partir de 2009
Emprego de pessoal qualificado	Recursos com pouca experiência e vivência no ambiente de desenvolvimento de softwares e alocados em projetos respeitando apenas a disponibilidade de cada um. De acordo com Dey, Kinch e Ogunlana (2007), o emprego de recursos específicos e com grande conhecimento profissional e técnico possui influência direta no aumento da qualidade da entrega dos projetos de desenvolvimento de software.	Contratação de recursos com maior experiência profissional e alocação de recursos em projetos de acordo com o nível de criticidade do projeto em relação ao nível de maturidade profissional do recurso.
Adoção de técnicas de gerenciamento de projetos	Pouca utilização das práticas de gerenciamento dos riscos técnicos pelo gestor de projetos. Dey, Kinch e Ogunlana (2007) e Jun-guang e Zhen-chao (2010) apontam que os métodos tradicionais de gerenciamento de projetos procuram dar conta dos riscos do projeto. Este cenário é asseverado por Dey, Kinch e Ogunlana (2007), que apontam a falta do uso de técnicas de gerenciamento em projetos de desenvolvimento de software.	Gestor dedicado aos projetos de desenvolvimento de software, aumentando a utilização das técnicas de gerenciamento dos projetos, por meio do controle e monitoramento efetivo das atividades em relação aos riscos técnicos.
Construção de base histórica de projetos	As lições aprendidas e as estimativas de projetos não eram armazenadas. Jones (2000) aponta que falhas nas estimativas das atividades quanto ao custo e ao prazo têm relação direta com a taxa de sucesso de projetos de desenvolvimento de softwares.	Armazenamento de estimativas e características de projetos em uma base histórica para apoio a novos projetos.
Uso de técnicas para a estimativa de atividades	Estimativas baseadas na opinião do profissional alocado no projeto, levando em consideração o tempo que ele mesmo supostamente gastaria para executar a tarefa. A superestimação das atividades e de recursos é apontada por Tao (2008) como um dos fatores de riscos técnicos causadores dos desvios dos projetos (prazo e custo) em relação às estimativas planejadas.	Utilização de base histórica para apoio à estimativa de atividades e uso de boas práticas de desenvolvimento de software.

A quantidade e o percentual de projetos entregues no prazo planejado e a quantidade de projetos cancelados ou com desvio de prazo em relação ao planejado são demonstrados na Tabela 1. O período de 2005 é marcado pela falta de utilização das técnicas de gerenciamento de riscos técnicos. Já o período de 2009 a 2012 se caracteriza pela utilização de técnicas de gerenciamento de riscos técnicos pela área de desenvolvimentos de softwares.

Tabela 1
Quantidade e percentual de projetos entregues dentro do prazo planejado, cancelados ou com desvio de prazo entre os períodos de 2005-2008 e 2009-2012.

elaborado pelos autores.

Projetos	Quantidade		Percentual
	Antes	Depois	Antes	Depois
	2005-2008	2009-2012	2005-2008	2009-2012
Entregue no prazo (n1)	250	271	59,52%	66,58%
Entregue com desvio (n2)	170	136	40,48%	33,42%
Total	420	407	100%	100%

Com relação aos dados da Tabela 1, pode-se identificar que a quantidade de projetos entregues no prazo planejado no período de 2009 a 2012, após a empresa adotar técnicas de gerenciamento de riscos técnicos, aumentou considerável em relação ao período de 2005 a 2008, quando a empresa não adotava nenhum tipo de técnica. Com base nesse resultado, a hipótese H1 − A melhora na gestão do risco técnico tem impacto positivo na redução da taxa de projetos com desvio de prazo em relação à data planejada − não pode ser rejeitada, pois a política de redução de riscos operacionais promoveu um aumento significativo dos projetos entregues no prazo, variando de 59,52%, no período de 2005 a 2008, para 66,58%, no período de 2009 a 2012.

Quanto aos projetos cancelados, entre o período de 2005 a 2008, a média de projetos atrasados ou cancelados era de 40,48%. No período de 2009 a 2012, esse índice foi reduzido para 33,42%. Assim, a H2 − A melhora na gestão do risco técnico tem impacto positivo na redução da taxa de projetos cancelados − não pode ser rejeitada, pois os resultados apontam um nível de significância de 5% do teste de Mann-Witney.

O teste de Mann-Witney foi realizado com dados de duas amostras de uma mesma distribuição, uma antes e outra após o uso de técnicas de gerenciamento de riscos técnicos em projetos de desenvolvimento de software, levando em consideração a relação de um conjunto de hipóteses.

5 CONCLUSÕES

O presente trabalho procurou avaliar como o gerenciamento de riscos técnicos pode contribuir para a conclusão de projetos de desenvolvimento de software por meio de um estudo de caso de uma empresa brasileira do ramo de Tecnologia de Informação. Para isso, foram avaliados o índice de projetos entregues dentro do prazo planejado e o índice de projetos cancelados ou com desvio de prazo em relação ao planejado entre os anos de 2005 a 2012.

Durante os anos de 2005 a 2008, a empresa não adotava nenhum tipo de técnica ou gerenciamento dos riscos técnicos dos projetos de desenvolvimento de software. Como consequência, possuindo, como consequência, um número elevado de projetos cancelados ou com desvio de prazo em relação ao planejado. A partir de 2009, a empresa passou a utilizar práticas de gerenciamento de riscos técnicos com o objetivo de minimizar os impactos causados pelos projetos cancelados ou entregues fora do prazo acordado.

A organização passou, assim, a adotar fatores associados às práticas de gerenciamento de riscos técnicos, como o aumento do controle e monitoramento das atividades dos projetos, a contratação de mão de obra com maior nível de experiência profissional e técnica, o uso de boas práticas no processo de desenvolvimento de software e a utilização de uma base histórica de projetos como apoio às estimativas de projetos futuros. A esse respeito, a literatura especializada aponta que o baixo uso de práticas de gerenciamento de riscos técnicos é um fator de risco que deve ser tratado pela empresa, assim como a falta de conhecimento dos gestores da área da Tecnologia da Informação. Quanto maior for o gap de conhecimento do gestor em relação ao contexto de desenvolvimento de softwares e maiores forem os fatores de riscos técnicos, maior será o risco de ocorrer o desvio do prazo de entrega em relação ao planejado e, às vezes, levar ao cancelamento do projeto.

O emprego das técnicas de gerenciamento de riscos técnicos apresentados neste estudo contribuiu para a redução do índice de projetos cancelados ou com desvio de prazo em relação à data de entrega planejada. Tais práticas vão ao encontro da necessidade de garantir o atendimento de requisitos exigidos pelo cliente, dentro de padrões aceitáveis de custo e de prazo (GUSMÃO; MOURA, 2002).

Este trabalho não teve como objetivo avaliar as competências em gerenciamento de projetos utilizadas pelos gestores nem identificar o nível de maturidade profissional utilizado como recurso em projetos de desenvolvimento de software da empresa foco deste estudo. Nesse sentido, como sugestão para trabalhos futuros, destaca-se a realização de pesquisas para identificar outros fatores de riscos técnicos relacionados diretamente ao índice de projetos cancelados ou entregues fora do prazo planejado. Isso permitiria identificar as práticas de gerenciamento de riscos técnicos corretivos em busca da maior eficiência no índice de projetos entregues dentro do prazo planejado.

REFERÊNCIAS

BOEHM, B. Software risk management: principles and practices. IEEE Software, v. 8, p. 32-41, 1990.

BOEHM, B.; DEMARCO, T. Software risk management. IEEE Software, n. 3, p. 17-19, 1997.

CARVALHO, M. M.; RABECHINI, R., Jr. Construindo competências para gerenciar projetos. 2. ed. São Paulo: Atlas, 2009.

CHITTISTER, C.; HAIMES, Y. Risk associated with software development: a holistic framework for assessment and management. Systems, Man and Cybernetics, IEEE Transactions on, v. 23, n. 3, p. 710-723, 1993.

CHIZZOTTI, A. Pesquisa em ciências humanas e sociais. 3. ed. São Paulo: Cortez, 1991.

DEVORE, J. Probability and Statistics for Engineering and the Sciences. 9. ed. Australia: Duxbury, 2000.

DEY, P.K.; KINCH, J.; OGUNLANA, S.O. Managing risk in software development projects: a case study. Industrial Management and Data Systems, v. 107, n. 2, p. 284-303, 2007.

GUIMARÃES, R. C.; CABRAL, J. A. S. Estatística. 2. ed. Portugal: McGraw-Hill, 1997.

GUSMÃO, C.; MOURA, H. P. Gerência de risco em processos de qualidade de software: uma análise comparativa. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DE SOFTWARE, 3., 2002, Brasília. Anais... Brasília, 2002.

JIANG, J. J.; KLEIN, G. Risks to different aspects of system success. Information & Management, v. 36, n. 5, p. 263-272, 1999.

JONES, C. Patterns of software systems failure and success. 1. ed. Boston: International Thomson Computer Press, 2000.

JUN-GUANG, Z.; ZHEN-CHAO, X. Notice of Retraction Method study of software project risk management. In: Computer Application and System Modeling (ICCASM), 2010 International Conference on. IEEE, 2010. p. V8-9-V8-12.

KERZNER, H. Project management: A systems approach to planning, scheduling and controlling. 10. ed. Nova York: John Wiley and Sons, 2009.

KOONTZ, H.; O’DONNEL, C.I. Princípios de administração: uma análise das funções administrativas. São Paulo: Livraria Pioneira Editora, 1982.

MACHADO, C. A. F. A-Risk: um método para identificar e quantificar risco de prazo em projetos de desenvolvimento de software. 2002. Tese (Doutorado em Informática Aplicada) - Pontíficia Universidade Católica do Paraná, Curitiba, 2002.

MARTINS, G. A.; THEÓPHILO, C. R. Metodologia da investigação científica para ciências sociais aplicadas. 2. ed. São Paulo: Atlas, 2009.

PMI (PROJECT MANAGEMENT INSTITUTE). A guide to the project management body of knowledge: PMBOK guide. 5. ed. Newton Square: Project Management Institute, 2013.

PRESSMAN, R. S. Engenhariade software. 7. ed. São Paulo: Makron Books, 2008.

PRITCHARD, C. L. Risk Management: Concepts and Guidance. 4. ed. ESI international, 2010.

RABECHINI, R. Jr.; Carvalho, M. M. Concepção de um programa de gerência de projetos em instituição de pesquisa. Biblioteca Digital de la Asociación Latino-Iberoamericana de Gestión Tecnológica, v. 1, n. 1, 1999.

SANTOS, A. R. Metodologia científica: a construção do conhecimento científico. 1. ed. Rio de Janeiro: DP&A, 1999.

SANTOS FILHO, J. C.; GAMBOA, S. S. Pesquisa educacional: quantidade-qualidade. 3. ed. São Paulo: Cortez, 1995.

SHENHAR, A. J.; Dvir, D. Reinventando gerenciamento de projetos: a abordagem diamante ao crescimento e inovação bem-sucedidos. 1. ed. São Paulo: Makron Books, 2010.

SNEDECOR, G. W.; COCHRAN, W. G. Statistical methods. 7. ed. Iowa: State University Press, 1980.

TAO, Y. A study of software development project risk management. Proceedings of the International Seminar on Future Information Technology and Management Engineering, p. 309-312, 2008.

TURNER, J. R. The handbook of project based management. 3. ed. New York: McGraw-Hill, 2009.

XIAOSONG, L.; SHUSHI, L.; WENJUN, C.; SONGJIANG, F. The application of risk matrix to software project risk management. International Forum on Information Technology and Applications. v. 2, p. 480-483, 2009.

YIN, R. K. Estudo de caso: planejamento e métodos. 4. ed. Porto Alegre: Bookman, 2010.

ZMUD, Robert W. Management of large software development efforts. MIS quarterly, p. 45-55, 1980.

Autor notes