Gestão de Projetos de TI: Planejamento, ROI e Controle

Introdução

%IMAGE_1%

Introdução

Nesta primeira parte vamos rever e analisar as áreas e atividades que a gestão deve cobrir e que devem estar envolvidas para o desenvolvimento de projetos de TI. A gestão é o mecanismo de atuação na empresa ou entidade responsável pela tecnologia da informação; ao mesmo tempo, a função de desenvolvimento tem custo próprio.

Antes de prosseguir, devemos esclarecer que a “direção” a que nos referimos é, especialmente, de nível superior (CEO, presidente, gerentes funcionais), sem excluir qualquer outro nível. Em particular, o grau de envolvimento da gestão deve ser diretamente proporcional ao seu nível de responsabilidade, correspondendo ao mais alto nível de liderança o papel de patrocinador.

Através de critérios de liderança são estabelecidas estratégias e táticas que permitem gerenciar e controlar conceitos tais como:

• O desenvolvimento organizacional de projetos de TI, alocando os recursos humanos necessários e avaliando a terceirização. Esses recursos, dependendo da estratégia a seguir, podem ser totalmente centralizados no papel dos sistemas de informação ou distribuídos entre este papel e funções usuárias.
• Os critérios e comissões que regulam e controlam as prioridades e a rentabilidade dos projetos a serem desenvolvidos, bem como o estabelecimento de um plano anual que consolide os projetos em curso e os pendentes.
• Os planos de ação que levam ao aumento da “industrialização” em detrimento da “navegação” no processo de desenvolvimento de projetos. Estes planos incluem:

• Gestão e controlo dos recursos utilizados, que conduzem ao conhecimento dos custos.
• Previsões que indiquem, tanto a priori como a posteriori, os benefícios e custos, tanto ao nível do projeto como do plano global.
• Passos que tornam “industriais” os projetos de desenvolvimento, tais como produtividade, qualidade, prazos, compliance, etc.

Todas essas estratégias e planos devem ser apoiados por uma atribuição de responsabilidades para os vários estratos da empresa ou entidade de gestão, envolvendo a alta administração, os utilizadores e os sistemas de informação.

São responsabilidades da gestão de utilizadores, em todos os níveis, as seguintes:

• Estabelecer uma estratégia global para informatizar a sua própria função. Esta estratégia deve ser confrontada com os sistemas de informação e atender às necessidades operacionais ou de processos de negócio envolvidos na função.
• Determinar os benefícios que resultarão da informatização, em nível de projeto e do plano de informatização. Esses benefícios derivam principalmente de dois parâmetros: economia orçamental e aumento da produtividade dos recursos humanos.
• Comprometer-se com a rentabilidade do plano de projeto de informatização, com os custos conhecidos, indicando logicamente o nível de intervenção dos sistemas de informação. Esse retorno deve basear-se em critérios de oportunidade de investimento, viabilidade técnica e custo.

As responsabilidades dos sistemas de informação de gestão incluem:

• Estabelecer uma estratégia global de tecnologia da informação aprovada pela alta gestão, abordando questões como centralização versus descentralização de hardware, nível de computação pessoal, redes, sistemas de escritório, e-mail, continuidade das operações, etc.
• Na área de desenvolvimento deve ser responsável por:
• Definir um ambiente técnico para testes e desenvolvimento de projetos e para a manutenção de aplicações em produção.
• Implementar um plano de desenvolvimento e melhoria das atividades, em áreas como custos e procedimentos, com medidas que aumentem a maturidade organizacional.
• Propor, implementar e monitorar um plano organizacional de recursos humanos: estruturas centralizadas ou descentralizadas, analistas funcionais, etc.
• Assegurar a recolha e alocação de recursos humanos e a contratação para cada projeto de desenvolvimento.
• Manter um plano anual, atualizado, dos projetos de desenvolvimento.
• Estabelecer um plano de formação técnica e monitorar a conformidade com o desenvolvimento profissional.

Para que todas estas estratégias e responsabilidades sejam cumpridas, é fundamental o envolvimento direto da alta direção da empresa ou entidade. É inútil tentar se essa condição não for satisfeita.

Com base na análise de diferentes aspetos a considerar, esta primeira parte do documento subdivide-se nas seis subáreas seguintes:

• Como gerir o desenvolvimento de negócios
• Business case
• Geração do plano de TI
• Implementação do plano e controle
• Envolvimento da gestão
• Padrões e instrumentos técnicos

2

Como gerir o desenvolvimento de negócios

%IMAGE_2%

Como gestão do desenvolvimento de negócios

Assumindo que as aplicações suportam as operações essenciais da empresa ou entidade, e que o fluxo de trabalho interliga diferentes áreas funcionais e departamentais, deve-se considerar como a “polia” (motor) deve ser gerida com princípios de negócio.

Este negócio está contido no ambiente da empresa ou entidade e abrange o desenvolvimento. Nem sempre se faturam clientes externos; do ponto de vista interno, os custos devem ser compensados pelos benefícios internos produzidos — esse é o princípio básico que exige gestão direta por todas as direções, em particular pela função de informática e desenvolvimento.

Como tal negócio, os parâmetros a considerar são: recursos e custos (humanos e financeiros), benefícios e economias, e, portanto, o equilíbrio entre custos, prazos, prioridades e satisfação dos clientes/usuários.

Esse negócio deve ser regido por um plano anual que define os objetivos a cumprir nesse período e que pode ser revisto uma ou duas vezes por ano (ou trimestralmente).

Para considerar o desenvolvimento como um negócio rentável também é necessário observar algumas premissas organizacionais, tais como:

Definição. O mais alto nível de gerência deve definir o quadro de ação, resumido em dois parâmetros fundamentais: a estratégia de TI (organização centralizada ou descentralizada; prioridades; tipos de computação pessoal; e-mail; etc.) e as táticas de curto prazo quanto ao investimento anual em recursos técnicos e humanos (próprios e contratados).

Decisão. No âmbito das atividades definidas pela alta gestão, os departamentos funcionais fornecem planos de informática, sem prejuízo da possibilidade de auditoria sobre os custos totais e a rentabilidade dos projetos individuais.

Implementação. A função de informática (e desenvolvimento) deve consolidar e controlar a execução do plano de projetos. Além disso, deve propor estruturas organizacionais e responder às abordagens estratégicas (aceitas total ou parcialmente pelas funções), que se expressam em planos táticos anuais controlados pela TI.

Controle geral. O controle deve ser exercido por comissões definidas pela alta gestão para garantir o cumprimento dos limites estabelecidos: rentabilidade dos projetos, investimentos em instalações e recursos, etc.

Essas premissas são critérios claros que devem ser acrescentados e cumpridos por todas as funções envolvidas para alcançar os benefícios previstos.

Essa perceção de benefícios baseia-se em controle e comunicação, ambos executados em paralelo, especialmente em projetos individuais ou conjuntos de pequenas melhorias.

Para projetos individuais, procede-se à revisão uma vez que a aplicação está em produção, avaliando se atendeu às necessidades do utilizador e se os objetivos da mecanização foram cumpridos.

Em paralelo com os requisitos estabelecem-se as reduções de custos (ver Capítulo 3 - Business Case). As poupanças estimadas durante a fase de requisitos, recursos humanos e financeiros devem ser aplicadas pelas funções ou organizações responsáveis — função usuária e equipa de qualificação para a aplicação (que solicitou o projeto).

Ao rever, deve-se comparar os custos reais incorridos com os previstos no business case. A responsabilidade por desvios é partilhada entre a função usuária (e seus analistas funcionais ou descentralizados) e a TI no desenvolvimento e implementação.

As análises são encaminhadas pela função de informática tanto ao papel do utilizador (por conhecimento) como ao presidente da comissão de rentabilidade (para controlo) e às funções responsáveis pela alocação de recursos humanos e financeiros.

Nos casos de matrizes de pequenos projetos (cada um com até três meses-homem de esforço, geralmente melhorias), as revisões são mensais ou bimestrais, reportando os custos totais e as poupanças ocorridas no período e as mesmas organizações e pessoas envolvidas.

Finalmente, como resumo, o desenvolvimento é um negócio essencial para a empresa ou organização e deve obedecer às pressuposições e revisões descritas; todos os projetos de desenvolvimento devem ser lucrativos ou autorizados explicitamente pela alta administração.

3

Business Case

%IMAGE_3%

"Business Case"

Este capítulo discute o procedimento a seguir para planear, a priori, o retorno de um projeto de software, ou seja, o retorno que será obtido uma vez que o aplicativo esteja instalado e em uso.

No business case desempenha papel fundamental a função proprietário, definida como o “dono”.

O dono é um diretor que faz parte da função que solicitou o projeto. Como patrocinador do projeto, será o interlocutor em nome da função usuária e dos utilizadores finais junto à organização de desenvolvimento e manutenção de aplicações.

As principais responsabilidades do dono desde a proposta do projeto até que se torne uma aplicação em produção são:

• Quantificar as economias e os benefícios que irão ocorrer nos utilizadores finais (melhoria da produtividade, capacidade de fazer mais, melhor qualidade, etc.) quando o aplicativo estiver em produção.
• Expressar os requisitos e características documentadas que o aplicativo deve ter.
• Fornecer dados de teste necessários para validar que o pedido cumpre os requisitos.
• Definir o grau de confidencialidade dos componentes individuais da futura aplicação (formulários, ecrãs, ficheiros, etc.).
• Providenciar formação adequada aos utilizadores finais para operar a futura aplicação.
• Supervisionar a fase de entrada em produção (conversão de ficheiros, se aplicável), pela qual o projeto passa a execução operacional.

Em todas estas responsabilidades, o dono deve ser apoiado por analistas funcionais.

Além disso, os analistas funcionais apoiam o proprietário nas suas responsabilidades após o “nascimento” da aplicação. As responsabilidades do proprietário durante o ciclo de vida da aplicação incluem:

• Validar que o funcionamento da aplicação é compatível com os requisitos e características estabelecidas na proposta de projeto. Essa validação confirmará as economias e os benefícios propostos.
• Ser o canal entre os utilizadores finais e o papel dos Sistemas de Informação, tendo em conta as listas de utilizadores vigentes e as distinções de acesso e confidencialidade.
• Verificar se as execuções, performances, lançamentos etc. realizados em produção estão corretos (ficheiros atualizados com conteúdo e calendário, saídas esperadas, etc.).
• Ser o ponto focal dos utilizadores finais em termos de novas necessidades, melhorias e modificações, iniciando as solicitações adequadas ao desenvolvimento e à manutenção de aplicações.

Em última análise, a coordenação e a representação dos utilizadores finais pelo dono do projeto estão relacionadas com o papel dos Sistemas de Informação, quer em produção, quer em desenvolvimento.

Isto significa que qualquer projeto de desenvolvimento — novo, de modificação ou melhoria de uma aplicação existente — deve ser baseado na rentabilidade ou ter aprovação explícita da alta administração (ou delegado).

Os componentes básicos da rentabilidade são comparados entre a redução de custos e os benefícios. Estes componentes devem ser planeados na fase de requisitos e comprometidos pelo proprietário e pelo desenvolvedor nas fases finais de análise e design externo.

Todas as alterações ocorridas durante o desenvolvimento, testes de integração e instalação devem desencadear uma revisão da rentabilidade feita pelo proprietário. Se a alteração produziu um retorno negativo (custos superiores às poupanças), é necessária a autorização do delegado pela gerência sénior (normalmente o controlador ou auditor) para continuar o desenvolvimento do projeto.

Durante todo o desenvolvimento deve-se confrontar a evolução dos custos reais com o planeado, comparando-os com a parte correspondente do trabalho realizado. Este contraste, realizado pelo gerente de projeto e revisto nas reuniões de acompanhamento, é fundamental para garantir que os custos não divergirem do previsto. Em caso de desvio que torne o projeto não lucrativo, os desenvolvedores devem parar e pedir autorização da gerência sénior para continuar. Esses casos costumam exigir provas e informação adicionais.

Qualquer circunstância que diminua ou ponha em risco a rentabilidade deve ser comunicada e autorizada pela direção, informando também a gestão de utilizadores e o proprietário.

3.1 Implementação

A condução e o controlo de um business case para cada plano de projeto devem envolver ações anuais como:

• Plano de projetos de controle (tema tratado no Capítulo 7).
• Envolvimento da alta administração, gestão e proprietário usuário, e liderança do desenvolvimento.

A articulação de um corpo para assegurar e coordenar esse segundo ponto depende do tamanho da empresa, da sua dispersão geográfica, do grau de autonomia e delegação nas unidades de TI, e da centralização/descentralização operacional.

A criação desse órgão é essencial, pois garante a rentabilidade do desenvolvimento de aplicações, desempenhando papel análogo à comissão que autoriza fabricar e comercializar um novo produto numa empresa de manufatura.

Este órgão pode ter nomes diferentes (gestão da informação, tecnologia da informação, comité de aplicação, etc.), mas o objetivo básico é que a empresa tenha um plano contínuo de projetos de TI rentáveis, individualmente.

O corpo deve reunir-se com frequência predefinida (por exemplo, até três vezes por ano) e ser presidido por um gerente sénior. Parte do desempenho global e do papel ao nível dos custos deve ser apoiado pela alta gestão, especialmente quando o desenvolvimento envolve vários recursos ou unidades da organização.

O secretário desse órgão deve assegurar logística, agendas, existência de registos das questões pendentes e gerir os meios que contenham os dados exigidos pelos projetos. É desejável que o secretário conheça as aplicações de suporte e as línguas dos utilizadores finais.

Os participantes nas reuniões convocadas pelo presidente incluem diretores das funções usuárias (autores dos projetos), o CIO, desenvolvimento e os responsáveis por Garantia de Sistemas ou qualidade (assunto discutido no Capítulo 5).

Os oradores são os diretores dos analistas funcionais, em nome dos proprietários e utilizadores, e os diretores de desenvolvimento apresentam os projetos solicitados e os seus relacionamentos.

3.2 Conceitos básicos

Para calcular a rentabilidade (ou o tempo para recuperar o investimento) de um projeto de desenvolvimento, é necessário conhecer os seus custos e as poupanças/benefícios.

A primeira ocorre antes de o projeto se tornar uma aplicação operacional. A poupança ou benefício surge quando os utilizadores começam a usar o aplicativo em produção.

3.2.1 Custos do Projeto

Os componentes dos custos de um projeto de desenvolvimento, novo ou de alteração de uma aplicação existente, são: pessoas, outsourcing e equipamentos.

As pessoas envolvidas incluem diferentes perfis e experências, localizadas quer na organização usuária (proprietários e utilizadores) quer na organização de TI. A unidade básica de medida é o mês-homem, embora em alguns ambientes use-se a semana.

O custo mês-homem por cada tipo de profissional deve ser calculado e atualizado pelo departamento responsável (custos, planeamento, recursos humanos ou, em última análise, a organização de TI).

Terceirização (outsourcing) refere-se ao custo de trabalho contratado externo. A redução destes custos depende do tipo de tarefa, das características da empresa subcontratada e das circunstâncias da empresa contratante. A compra de pacotes de software também se enquadra neste conceito.

O componente equipamento refere-se ao custo de hardware e software a adquirir para desenvolvimento, testes ou operação da aplicação. Por exemplo, em projetos de mecanização de armazém, todos os custos de leitores de código de barras e unidades de comunicação devem ser incluídos.

Conhecidos os elementos e a sua soma, e antes de analisar a economia, é necessário saber se esse custo é acessível para a empresa. Também é desejável avaliar se o projeto pode ser realizado com ferramentas e TI do usuário, minimizando custos.

3.2.2 Poupança do Projeto

O cálculo das poupanças ou benefícios que o projeto produzirá, quando em operação, passa de estimativa (na fase de requisitos) a compromisso (após a análise funcional).

No mundo dos negócios, os custos de desenvolvimento são por vezes estimados com menor formalidade; isso causa uma espiral de falta de empenho por parte de desenvolvedores e utilizadores. A única forma de reduzir essa espiral é atacar ambos os pontos: estimativas de custos e reavaliação dos benefícios.

As poupanças devem ser explicitamente indicadas pela função usuária que solicita o desenvolvimento, descrevendo como serão aplicados os recursos humanos e financeiros.

Existem várias formas de avaliar poupança, mas dois parâmetros básicos a definir são:

• Quanto tempo levará para construir essas economias.
• Qual o "mix" entre pessoas e/ou dinheiro e, dentro de cada variável, o que distingue entre "reduções" e "evita".

Como a poupança é estimada ao longo dos anos, a primeira pergunta é o período a considerar para a acumulação (simples ou ponderada). Recomendamos considerar que dois anos após o início da produção a aplicação permanecerá sem alterações que afetem significativamente os benefícios esperados. Esse critério deve ser estabelecido pela organização referida no ponto 3.1.

Para quantificar a poupança deve-se determinar a soma das poupanças originadas em recursos humanos e em recursos monetários, aplicando ponderadores conforme se trate de "redução" ou "evita".

Entende-se por redução a diminuição de pessoas (mês-homem) e/ou dinheiro que deixa de ser gasto quando a aplicação entra em produção. Por evita entende-se recursos que não precisam de ser aumentados para suportar maior volume de negócio (novos produtos, novos clientes) mas que evitam custos futuros.

3.3 Rentabilidade

Um projeto de desenvolvimento é rentável quando as poupanças/benefícios anuais são iguais ou superiores aos custos acumulados do projeto. O ponto no tempo em que a soma das poupanças anuais iguala o investimento é o Payback (RI). A partir desse ponto o investimento passa a ser lucrativo.

Antes de definir o RI, separam-se os projetos do plano anual em dois tipos:

• Projetos identificáveis individualmente: esforço de desenvolvimento superior a três meses-homem.
• Projetos não identificáveis individualmente: geralmente pequenas melhorias em aplicações existentes, com esforço inferior a três meses-homem.

Para projetos individualmente identificáveis o RI é considerado dois anos (ou menos), porque a soma das poupanças em dois anos é a referência. Para projetos de melhoria (esforço individual inferior a três meses-homem) agrupa-se o esforço e aplica-se um RI de um ano (ou menos).

O plano anual também inclui projetos de manutenção. A manutenção corretiva não é rentável e deve constar claramente no plano anual, com esforços estritamente controlados para evitar dispersões e desperdício.

3.4 Cálculo do fator

Com base no exposto, podemos calcular o fator entre a poupança e os custos:

Poupança (dois anos em produção) / Custos (de desenvolvimento) = FACTOR

A poupança é a soma dos benefícios relacionados com recursos humanos (pessoas) e recursos monetários (em milhares de moeda local). Aplica-se uma ponderação conforme se trate de "redução" ou "evita" (ver 3.2.2).

Pesos indicativos:

A poupança anual de recursos humanos, por exemplo, será calculada como: custo anual de uma pessoa × número de pessoas por ano × 2 anos × ponderação aplicável.

Da mesma forma, a poupança financeira (tesouraria) será calculada em K (milhares) ao longo de dois anos × ponderação aplicável.

Custos são obtidos pela soma prevista de meses-homem dedicados ao projeto (mês-homem de análise, desenvolvimento, contratos, centros de processamento para a mudança para produção, etc.). Devem ainda ser adicionados equipamentos ou software específicos, se aplicável.

3.5 Correlação entre factor e RI

O factor mínimo depende do tipo de projeto:

• Projetos identificáveis individualmente (desenvolvimento > 3 meses-homem): o factor deve ser ≥ 1 (RI ≤ 2 anos).
• Projetos de melhoria (esforço individual ≤ 3 meses-homem): o factor deve ser ≥ 2 (RI ≤ 1 ano).

O plano anual inclui também projetos de manutenção. A manutenção corretiva não é rentável e deve constar separadamente e controlada para evitar dissipação de recursos.

3.6 Alternativas

A avaliação da lucratividade pode ser feita de várias formas, por exemplo acumulando custos planejados e reais anualmente e acumulando benefícios anualmente a partir da disponibilidade da aplicação. O retorno ocorre quando as duas grandezas são iguais.

Em sistemas muito grandes a recuperação do investimento pode ultrapassar dois anos. Projetos de software no plano de uma empresa devem basear-se em desempenho individual e, excecionalmente, requerer aprovação formal da gestão de topo.

4

Geração do Plano de TI

Geração do plano de TI

Qualquer empresa ou entidade deve ter um plano anual de TI (focado em projetos de desenvolvimento) e rever esse plano duas ou três vezes por ano para que se mantenha atualizado.

Vamos ver o que pelo menos um plano de projeto de desenvolvimento deve conter:

• Ser o único ponto de referência para saber o que se está a fazer e o que fazer a seguir.
• Servir para planear e alocar recursos humanos para a implementação.
• Conter os projetos em desenvolvimento, consumindo recursos até a data efetiva do plano.
• Conter os projetos pendentes de início e os recursos humanos anuais que serão consumidos.
• Conter os projetos que são rentáveis (ou com autorização expressa), desde a fase de requisitos ou após a análise funcional.
• Indicar, ao nível do projeto, a quantidade de recursos humanos para cada ano, distinguindo entre analistas funcionais (função usuária), terceirização prevista e desenvolvedores (analistas orgânicos e programadores).
• Ser uma continuação dos planos anteriores, garantindo que não desapareçam projetos iniciados sem justificação e aprovação do órgão competente.

4.1 Sequência do processo

O plano do projeto deve ser construído de baixo para cima a partir das necessidades de computação dos utilizadores finais, que conhecem os problemas operacionais e podem propor soluções.

Essas necessidades são entregues aos departamentos funcionais de TI (analistas funcionais), cuja primeira missão é analisar o problema e fazer um diagnóstico inicial de viabilidade para uma solução informatizada.

Os departamentos funcionais formam o primeiro elo no processo de geração do plano de aplicações e consolidam as possíveis áreas subdivididas na função, sugerindo proprietários de futuras aplicações e interagindo com os proprietários das aplicações existentes.

Os requisitos devem ser reforçados pela função, estimando também os esforços necessários (analistas funcionais e utilizadores) para a evolução previsível dos projetos.

Antes de apresentar o plano à direção da função, o departamento deve reunir-se com o desenvolvimento para trocar informações e obter estimativas de esforço de desenvolvimento.

Após a elaboração do plano “bruto”, o departamento reúne-se com a liderança funcional para analisar questões como:

• Quais projetos são mais rentáveis.
• Quais são mais importantes, consequentes ou vitais.
• Que esforço e custo podem ser tratados com os recursos disponíveis.

Paralelamente, a organização de desenvolvimento estima esforços e prazos por projeto.

O departamento funcional valida o plano, classifica prioridades (normalmente pela rentabilidade) e envia uma cópia ao secretariado de rentabilidade, que:

• Valida se todos os dados são necessários.
• Totaliza os valores e valida a viabilidade do plano.
• Inclui projetos de manutenção de fácil execução pelos desenvolvedores.
• Consolida os vários planos funcionais para a reunião do comité ou órgão.

Se os totais estiverem dentro dos limites estabelecidos pela alta administração (recursos humanos, custos de outsourcing e custos específicos do plano) procede-se a reuniões de comissão para aprovação. Caso contrário, adapta-se o plano e repete-se o processo até a aprovação.

Na reunião de revisão de rentabilidade, cada função discute os seus projetos, exigindo justificativas e validações pela organização de desenvolvimento. O presidente do comité tem autoridade para alterar prioridades, recursos ou questionar custos.

O secretariado elabora uma ata com os acontecimentos notáveis e a envia às funções; a ata é assinada pelo presidente.

Uma vez aprovados, os planos funcionais permitem que cada função defina prioridades entre os seus projetos. O plano consolidado é distribuído a todas as funções e é o único ponto de referência para toda a empresa.

4.2 Alternativas e críticas

Existem várias metodologias para priorizar projetos (por exemplo, estudos como o de DJ Martin Buss). O importante é que o processo:

• Esteja acordado com as pessoas envolvidas e seja endossado pela gerência sénior ou seu delegado.
• Inclua uma lista de projetos em desenvolvimento e outra de projetos notáveis por qualquer motivo.
• Registre esforços, estimativas de custo e poupança de cada projeto.
• Comprove o envolvimento e o compromisso da direção e dos utilizadores.
• Garanta continuidade entre planos consecutivos.
• Registe projetos cancelados no último ano, custos incorridos, motivos e aprovações existentes.

5

Implementação do Plano e Controle

O propósito do plano de desenvolvimento de aplicações é a sua realização. Quanto mais rigoroso e exato for o plano, melhor; mas deve existir alguma flexibilidade controlada para circunstâncias imprevistas.

A implementação do plano exige sincronização entre utilizadores, funções e desenvolvimento, especialmente em testes integrados, formação de utilizadores e coordenação entre operações e centro técnico.

O desenvolvimento deve funcionar como uma linha de produção, demonstrando excelência nos procedimentos, aumento de qualidade e metas numéricas de controlo, assegurando transparência da informação aos utilizadores e às direções.

5.1 Componentes

Os componentes envolvidos na implementação do plano respondem às perguntas clássicas: quem, o quê, como e quando. Aqui vamos analisar os três primeiros; o quando é tratado nos processos da Parte 2.

5.1.1 O que fazer

O plano de desenvolvimento inclui tarefas como:

• Novos projetos de desenvolvimento (não iniciados).
• Projetos em continuação (já iniciados).
• Modificações e melhorias em aplicações existentes.
• Manutenção de aplicações em produção.
• Instalações em produção e alterações de ambiente decorrentes dos pontos anteriores.

5.1.2 Quem dirige, coordena e controla

Esta questão depende do tipo de organização de TI (centralizada, semi-descentralizada, etc.) e do tipo de projeto (funcional, multifuncional, grande, pequeno).

Aqui esclarecemos papéis e responsabilidades:

"Líder do projeto" ou Coordenador de Projeto é a pessoa que lidera a implementação do projeto, estabelece o plano, coordena as interações e informa a direção de TI e/ou funcional. Não tem controle hierárquico sobre todas as pessoas envolvidas; o seu perfil é baseado na capacidade de organizar, planear e coordenar, com formação técnica adequada.

Esse papel é adequado quando o projeto pertence a uma única função usuária e pode ser desempenhado por um analista funcional.

Project Manager ou Gerente de Projeto é uma pessoa de nível diretivo com responsabilidades semelhantes ao líder de projeto, mas com autoridade para gerir pessoas alocadas ao projeto, maior tomada de decisão e responsabilidade sobre recursos humanos e cumprimento de compromissos. Este modelo é adequado para projetos multifuncionais ou técnicos específicos.

Dependendo do tipo de projeto e da maturidade da organização, a responsabilidade pode concentrar-se de formas diferentes, sem eximir cada departamento das suas responsabilidades e sem eliminar o envolvimento da direção de TI.

5.1.3 Gestão da implementação do plano

O controle mais rico em informação é realizado através de reuniões regulares (mensais) nas quais o gerente de projeto apresenta relatórios comparando a situação real com o planejado, explicando desvios e propondo ações corretivas.

Estas reuniões são presididas pelo CIO ou diretor de desenvolvimento e contam com a participação de diretores e profissionais-chave. Uma cópia das atas é enviada ao secretariado de rentabilidade para permitir o acompanhamento do plano.

Nas reuniões, analisam-se mais detalhadamente os projetos críticos e oferece-se visão geral dos restantes.

Outra forma de controlo são os comentários técnicos, realizados por profissionais que analisam e ajudam a resolver problemas técnicos para evitar ou corrigir desvios em termos de consumo de recursos ou prazos.

As revisões técnicas podem ser enquadradas nas reuniões mensais de acompanhamento ou na iniciativa "Sistemas de Garantia" e realizadas por profissionais internos ou externos.

As reuniões periódicas devem ser suportadas por ferramentas que disponibilizem os dados do projeto atualizados.

Além do controlo em desenvolvimento, é fundamental analisar, quando o projeto se torna aplicação em produção, o resultado real em comparação com a estimativa (esforços, requisitos, etc.), para validar e melhorar processos futuros.

As melhores métricas para análise posterior são numéricas, permitindo comparação com outros projetos. Uma unidade homogénea de medida (por exemplo, Pontos de Função) é necessária para garantir validade nas comparações e fundamentar projeções futuras.

Medidas derivadas incluem:

• Produção total: Pontos de Função produzidos por mês/ano.
• Produtividade: Pontos de Função / mês-homem.
• Qualidade: Falhas / Pontos de Função.
• Alvo "on target": número de projetos concluídos dentro do prazo e custo previstos.

Quando um projeto é concluído no prazo e cumpre as funções previstas na fase de requisitos, as economias prometidas no Business Case são atribuídas à função usuária perante a comissão de rentabilidade.

5.1.4 Como apoiar a implementação do plano

O apoio relaciona-se com aspetos técnicos e profissionais para apoiar a gestão ao nível necessário. Estas atividades abrangem:

• Analistas funcionais que pertencem às funções usuárias e apoiam a fase de requisitos e análise funcional.
• Analistas e programadores orgânicos, pertencentes à organização central de desenvolvimento, responsáveis por design, desenvolvimento, testes e manutenção.

5.1.4.1 Centro de Suporte ao Desenvolvimento

O departamento de suporte tem como responsabilidade investigar, selecionar, aprender, ensinar e resolver problemas relativos a novas ferramentas técnicas, metodologias e produtos, visando melhorar produtividade e qualidade.

O suporte técnico ajuda a otimizar testes (regressão), criação e uso de código reutilizável e análise de erros repetitivos (por exemplo, técnicas Ishikawa e gráficos de Pareto).

O departamento de apoio deve servir tanto o desenvolvimento quanto as funções usuárias e dimensionar os recursos humanos consoante o grau de mecanização da empresa.

Uma forma elementar de avaliar o grau de mecanização é comparar os esforços previstos para projetos de melhoria com os de outros projetos. Se os esforços de melhoria forem baixos, a mecanização é reduzida e a percentagem de analistas funcionais no total de recursos de desenvolvimento pode variar entre 30% e 50%.

Os objetivos primários do departamento de suporte são otimizar recursos humanos e a excelência das atividades, já que a organização de desenvolvimento é, em certo sentido, um "monopólio" de necessidades de TI.

O departamento de suporte também deve estabelecer e controlar acordos de serviço entre desenvolvimento e exploração (centro de processamento), definindo níveis de serviço, independência de ambientes de teste, capacidade da máquina, tempos de resposta, capacidade batch, agendamento e disponibilidade.

O departamento fiscaliza o cumprimento do acordo de serviço e leva exceções ao desenvolvimento. Deve ainda coordenar a divulgação do uso de plataformas técnicas, métodos e ferramentas.

O tamanho do centro de suporte pode variar, tipicamente entre 5% e 10% dos analistas e programadores.

5.1.4.2 Sistemas de Garantia (garantes da qualidade e controlo)

As pessoas no papel de Sistemas de Garantia (ou Assurance Project) atuam como auditores do processo de desenvolvimento, auxiliando profissionais e gestão mediante medidas e controlos internos.

Essa função deve ser independente dos desenvolvedores e, na prática, depende do diretor de desenvolvimento ou do CIO. O número de pessoas nesta função deve ser reduzido (não exceder 5% dos desenvolvedores) e os membros devem ter formação técnica e experiência em gestão de projetos.

As áreas de atuação podem dividir-se em revisão do processo de desenvolvimento e apoio para resolução.

Relativamente ao processo, a Garantia deve avaliar:

• Validade e consistência dos planos antes e depois da aprovação pelo comité.
• Riscos dos projetos ao longo do desenvolvimento, dispondo de procedimentos para classificar e comunicar riscos e acompanhar ações corretivas.
• Cumprimento da metodologia de desenvolvimento, participando nas revisões mensais e validando documentos assinados para a transição de fases.
• Garantir que segurança e auditabilidade foram implementadas e testadas corretamente.
• A qualidade do produto final, garantindo que a aplicação cumpre os requisitos expressos pelo usuário/proprietário.

Quanto ao apoio, a Garantia fornece conselhos sobre metas numéricas (produtividade, qualidade, aderência a prazos), acompanha evoluções, deteta desvios e promove programas de melhoria contínua da qualidade do processo de desenvolvimento.

As atividades da Garantia são auditáveis e focadas na organização e processos de desenvolvimento.

5.1.4.3 Manutenção

Manutenção é um conceito amplo e importante que merece clarificação. Existem diferentes tipos de manutenção:

• Manutenção perfeccionadora. Melhora ou estende funcionalidades de uma aplicação em produção (é uma melhoria e, como tal, deve ser tratada como projeto com máximo retorno ou payback reduzido).
• Manutenção adaptativa. Modificações necessárias noutras aplicações como resultado de um novo projeto. Os custos dessas mudanças devem ser incluídos no business case do projeto originador.
• Manutenção corretiva. Ações para restaurar aplicações em produção ao seu estado de funcionamento anterior (corrigir defeitos). Estes custos não produzem benefícios adicionais e devem ser rigorosamente controlados, representando tipicamente até 15% do total gasto em desenvolvimento.

5.1.5 Alternativa: Terceirização

A terceirização (outsourcing) pode ser uma opção temporária ou permanente, dependendo da decisão da alta administração. Nem sempre há oferta suficiente no mercado para gerir todo o desenvolvimento externamente.

A terceirização é uma alternativa complementar quando a empresa não tem recursos humanos suficientes para realizar o plano aprovado (projetos rentáveis e urgentes).

A decisão de terceirizar deve basear-se na premissa de que o custo contratado não seja superior ao custo de realização com recursos próprios. Para isso deve-se estimar previamente o custo interno equivalente por tarefa.

Uma vez adoptada essa abordagem, a empresa pode escolher entre três modos de contratação:

• Turnkey (entrega total por preço fixo): aplicável quando o projeto está bem definido e com pouquíssimas interfaces com outras aplicações. Vantagem: custo fixo conhecido; desvantagem: alterações de requisitos tendem a aumentar o custo do contratante.
• Contratação por recursos: contratação de profissionais que trabalham nas instalações da empresa, partilhando ambientes de teste. Este método é comum e flexível, com risco de perda de controlo se não houver procedimentos bem definidos.
• Contratação por tarefas: forma mais evoluída. Requer controlo estabelecido, procedimentos e formação dos contratados. Exige separação clara de ambientes (teste/manutenção/produção) e políticas que garantam continuidade caso o contrato termine.

Para contratação por tarefas é desejável agrupar projetos por áreas funcionais consistentes e limitar o número de contratantes para evitar dispersão do conhecimento. Deve também haver fases iniciais de recrutamento que se pagam nas fases seguintes.

Apresenta-se uma matriz empírica de fatores (aplicada em mais de 200 projetos) que multiplica os esforços do plano para obter os esforços ajustados quando se recorre a contratantes. Essa matriz distingue fases (1, 2, 3) e impacta análise e desenvolvimento, tanto para aplicações existentes como para novos desenvolvimentos. (Ver quadros e exemplos de aplicação no texto original.)

Exemplo de matrizes e fatores (resumo):

O texto original inclui um exemplo detalhado de aplicação desses fatores a um conjunto de previsões de vendas com esforços de 3 mês-homem de análise e 10 mês-homem de desenvolvimento, ilustrando como evoluem custos e rentabilidade nas fases 1, 2 e 3.

Notas finais sobre terceirização:

• Escolha do modo depende de custos comparativos internos/externos, disponibilidade de recursos e urgência.
• Em contratos turnkey, prever cláusulas de manutenção e gestão de alterações para evitar dependência excessiva do fornecedor.
• Em contratos por recursos, controlar claramente o ritmo e evitar dispersão das equipas contratadas.
• Em contratos por tarefas, estabelecer procedimentos, formação e separação de ambientes, além de garantir que, em caso de interrupção, a manutenção corretiva e melhorias possam ser assumidas internamente.

As matrizes e exemplos continuam a demonstrar como, com o tempo e repetição, os fatores diminuem e se estabilizam, permitindo capitalizar o investimento no recrutamento e assegurar a rentabilidade dos projetos.

"Como priorizar os projetos de TI." DJ Martin Buss, Harvard Business Review Deusto, fev. 1983.