Por que a estimativa do projeto falhou?


Nessa seção, nós apresentaremos o processo de Requisição De Proposta (RFP) da SH. Recentemente, a SH ganhou um grande projeto usando o processo de RFP. Depois de três meses, os gestores da SH perceberam que os produtos do projeto não poderiam ser entregues dentro do custo previsto. Por conseguinte, o projeto poderia tornar-se um provável prejuízo. A fim de prevenir possíveis prejuízos no futuro, a SH decidiu investigar as causas raízes para evitar futuras falhas nestes cáculos.

A Análise de Causa Raiz vem sendo conduzida na indústria através de uma variedade de técnicas (ver [1]). Enquanto os fluxogramas têm sido identificados como ferramentas potenciais para facilitar a Análise de Causa Raiz, a prática recorrente baseia-se, principalmente, em brainstormings e em técnicas pouco formais [2]. O fato de que organizações de grande porte possuem, usualmente, um grande número de documentos sobre seus processos de negócio, em termos de seus modelos, não tem sido bem explorado até hoje. Por outro lado, quanto ao reprojeto de processos de negócio, o foco tradicional ainda é no desenho de modelos que reflitam as práticas atuais (chamados modelos as-is) seguidos pelo desenho de modelos de processos melhorados (to-be) [3]. Nesse contexto, a ponte entre processos as-is e to-be é insuficientemente feita com o auxílio de ferramentas populares de modelagem de processos. Na realidade, a combinação de modelos de processos de negócio e Análise de Causa Raiz tem o potencial de revelar problemas em uma organização de uma maneira mais sistemática, dependendo, cada vez menos, da intuição dos envolvidos na análise.

Em um primeiro momento, a SH se debruçou sobre o modelo do processo. A figura 1 descreve o processo de RFP como um modelo de processos de negócio na notação EPC. Nesse artigo, nós usamos EPCs para fins de ilustração. No entanto, outras linguagens, como BPMN ou Redes de Petri (Petri nets), também poderiam ser usadas. Um EPC captura, basicamente, a estrutura de controle de um processo de negócio. Caixas arredondadas em um EPC definem as chamadas funções, isto é, as atividades de um processo, como Revisar Requisitos ou Estimar. As funções são executadas por entidades organizacionais (elipses, ao lado esquerdo) as quais geram inputs e criam outputs (ao lado direito). Os chamados eventos (hexágonos) descrevem as pré-condições e pós-condições de funções. Um processo possui, no mínimo, um evento de início e um evento de fim – nesse caso, é RFP recebida e Resposta enviada. Condições para encaminhamento do fluxograma são capturadas pelos chamados conectores (círculos). Nesse processo, existe um conector de divisão (split) e um conector de junção (join). Ambos são conectores tipo XOR: o conector de divisão descreve um ponto de decisão e o conector de junção converge os dois ramos alternativos. Para detalhes formais de EPCs, ver [4].

O processo começa com o evento de Requisição de Proposta sendo mandado de uma empresa cliente e essa RFP sendo recebida pela SH. A RFP documenta os requisitos de alto nível do sistema a ser desenvolvido e normalmente pede à SH uma resposta oferecendo uma proposta de solução, uma estimativa de tempo e o custo para finalizar o trabalho e um plano de projeto indicativo. Como um primeiro passo, o departamento de marketing/vendas revê a RFP para determinar os parâmetros da resposta (Conduzir Revisão Preliminar). Essa revisão fornece um primeiro insight a respeito dos lucros potenciais do projeto da SH e os interesses estratégicos da empresa sobre o cliente. Dependendo dessa informação, uma decisão é feita (conector XOR): se o negócio tem maior probabilidade de não ser atrativo, a SH irá Declinar RFP; caso contrário, outros passos para realizar a resposta à RFP serão tomados.

Essa série de passos começa com uma revisão dos requisitos do cliente pelo departamento de negócios, o qual encaminha a RFP para o departamento de desenvolvimento. Esse departamento formula uma solução técnica baseada na RFP. Essa solução é revisada antes de ser usada como base para as estimativas de custos e de esforços. Essas estimativas e a solução técnica desenvolvida são a base para propor um plano indicativo de projeto, articulado pelo time de gestão de projetos. Em particular, o cronograma, os custos e o time do projeto são especificados nesse plano indicativo de projeto. Esse plano, juntamente com as estimativas e com a solução conceitual, é input para o departamento de negócios Formular Resposta à RFP. O departamento de marketing/vendas envia, finalmente, a resposta à RFP ao cliente em potencial.

O modelo de RFP oferece aos gestores da SH uma visão geral inicial do processo. Entretanto, isso não revela, precisamente, os problemas na sua execução. Para rastrear as causas raízes da entrada em projetos não rentáveis, a SH deseja utilizar uma abordagem mais sistemática. Em particular, eles estão convencidos de que as técnicas vindas da engenharia de requisitos poderiam ser úteis.


Figura 1 - PROCESSO DE SOLICITAÇÃO DE PROPOSTAS DE UM SOFTWARE




_____________________________

22Engenharia de requisitos (ou requirement engineering) é um processo que envolve todas as atividades necessárias para a produção de um documento sobre os requisitos (funcionais ou não-funcionais) de um sistema e sua manutenção durante o tempo. (N. do T.)