IN4/TCU: Entendendo o fenômeno que está acontecendo nas pautas de TI no Governo Federal

Por Wanderson Alves de Lima

Em vigor desde 02 de Janeiro de 2009, a IN4 (Instrução Normativa Nº 4) da SLTI (Secretaria de Logística e Tecnologia da Informação) disciplina as contratações de serviços de Tecnologia da Informação pelos órgãos e entidades integrantes do SISP (Sistema de Administração dos Recursos de Informação e Informática), segundo os princípios de:
1) alinhamento entre planejamento de contrações e estratégia organizacional;
2) modelo do processo de contratação estruturado, baseado em fases, papéis, responsabilidades e documentos de apoio;
3) contratação e remuneração baseada em resultados; e
4) gestão dos processos de TI e da segurança da informação privativa da Administração pública.

Esses princípios visam melhorar o quadro levantado no Acórdão 1603/2008, da Governança de Tecnologia da Informação na Administração Pública Federal, onde foram identificados os seguintes problemas principais:
• Ausência de planejamento estratégico institucional e de TI;
• Deficiência na estrutura de pessoal;
• Tratamento inadequado à confidencialidade, integridade e disponibilidade das informações.

Um dos objetivos da governança de TI é assegurar que as ações de TI estejam alinhadas com os objetivos da instituição, contribuindo para alcançá-los. O desempenho da área de TI deve ser medido, os recursos propriamente alocados e os riscos inerentes, mitigados. Assim, é possível gerenciar e controlar as iniciativas de TI nas instituições para garantir o retorno de investimentos e a adoção de melhorias contínuas nos processos organizacionais. Garantir a correta aplicação dos recursos empregados em tecnologia da informação torna-se cada vez mais importante, tendo em vista que, somente na Administração Federal, o gasto em TI ultrapassa R$ 6 bilhões por ano, segundo dados do SIAFI (Sistema
Integrado de Administração Financeira) e do DEST (Departamento de Coordenação e Governança das
Empresas Estatais).
Para garantir que os investimentos promovam valor às organizações, é necessário que eles sejam realizados à luz de um planejamento baseado em objetivos e estratégias de como alcançá-los. Apenas elencando as iniciativas e programas a partir da distância entre a situação desejada e a situação atual, a TI conseguirá fornecer o melhor apoio à organização e, conseqüentemente, o retorno de investimento.
Assim, faz-se altamente necessária a definição da visão (aonde quer chegar) e os objetivos (como irá chegar à visão) da instituição para que a área de TI possa engenhar os processos de trabalho e derivar destes as demandas de automação para suportar os objetivos almejados. Desta forma, serão identificadas demandas de alto valor.
A partir daí, podemos avançar para o desafio seguinte: como priorizar essas demandas e desenvolvê-las de forma a alcançar soluções de alta qualidade, de menor custo, de alta adaptabilidade às mudanças e que reutilize os recursos/soluções já adquiridas pelo Governo Federal?
Assim, a IN4 regulamenta também o uso de pregão eletrônico na contratação de serviços, na aquisição e
produtos e no desenvolvimento de projetos de TI por terceiros no âmbito da administração pública federal.
Nas metas do governo destacam-se: a realização de contratações individuais em detrimento de contratos
guarda-chuva; a redução da dependência de terceiros assumindo para si os papéis de gestão e coordenação de TI; e alcançar soluções de melhor qualidade e de menor custo.
Hoje, a aquisição de produtos e commodities pelo Governo Federal já está bastante estruturada conforme o modelo do pregão eletrônico. As solicitações são realizadas com um alto nível de detalhes sobre os produtos, garantias e dinâmica de aceitação. No entanto, para a aquisição de serviços, dado sua natureza mais intangível, o uso de pregão eletrônico exige um cuidado maior na sua especificação, detalhamento e
forma de medição – para oferecer uma interface clara entre o tomador e o executor dos serviços. Para serviços de TI, essa complexidade é elevada ao topo. O que pode ser feito a esse respeito?
Nas palavras do titular da SLTI, Rogério Santanna: “O pregão leva em conta o menor preço ofertado, e o que garante a qualidade é a boa especificação dos bens e serviços adquiridos”. Assim, o caminho para o sucesso na contratação de serviços de TI está em praticar processos maduros de gestão de demandas, que abordem todo o ciclo de vida das aplicações, desde o entendimento da necessidade pelas áreas fins e de TI, a especificação dos requisitos de automação, as definições de interface e padrões com o fornecedor, até a implantação das mudanças com eficiência e segurança.
Logo, cadenciando os processos envolvidos na gestão de demandas como a figura abaixo, tem-se os insumos necessários para utilização de pregão eletrônico.

Por fim, o processo de compra deve evoluir para oferecer uma comunicação cada vez mais efetiva entre comprador e fornecedor, estabelecendo padrões de especificação de necessidades, procedimentos para a gestão de mudanças, perfilando os fornecedores segundo seus conhecimentos e habilidades e valiando-os segundo seus resultados e trabalhos realizados. Interessante comentar que, como conseqüência da IN4, temos um movimento natural de elevação da profissionalização da indústria de TI. Tendo o TCU como indutor do processo de aperfeiçoamento da governança de TI, os órgãos e entidades do governo federal serão motivados a desenvolver seus planejamentos estratégico institucional e de TI, direcionando assim os investimentos em iniciativas de maior valor para a nação.
Com um local centralizado para conduzir o processo de terceirização, obtém-se uma democratização da
informação de fornecedores, clientes e os resultados dos relacionamentos entre eles. Apoiados por processos de gestão de demandas, métricas, base histórica e dinamismo no processo de terceirização, os clientes podem tomar melhores decisões na escolha dos seus fornecedores. Com isso, ao mesmo tempo em que é reforçada a competência e a responsabilidade dos fornecedores vitoriosos, é gerado um movimento de aprendizagem e de melhoria nos demais fornecedores para superar seus fatores negativos. Assim, a relação de terceirização de serviços de TI se tornada cada vez mais madura e o mercado cada vez mais profissional.
Diante dos benefícios levantados, conclui-se que a iniciativa do governo federal em implantar uma normativa que incentive a orientação estratégica de TI e regulamente o uso de pregões eletrônicos promoverá um salto de clareza e eficiência nos processos de terceirização realizados por órgãos públicos. Logicamente não será solução imediata para todos os problemas existentes, mas gradativamente exigirá uma maior profissionalização da indústria de TI e realizará melhor uso dos recursos governamentais.

Produtividade e projetos bem sucedidos: O que está faltando?

Por Roberto Argento (http://www.linkedin.com/in/robertoargento)

Há cerca de um mês deparei-me com o artigo de Joe Marasco: “Software development productivity and Project success rates: Are we attacking the right problem?” . Ele toca num assunto que havia chamado minha atenção durante várias sessões de “project assessments” que eu me dediquei em 2005. Durante o ano passado participei da avaliação de cerca de 14 projetos ou organizações de desenvolvimento em 6 países da América latina (México, Brasil, Chile, Argentina, Peru e Colômbia), em diversos setores da economia (finanças, seguros, telecom, software houses, órgão públicos, energia) e abrangendo diversas tecnologias. Do desenvolvimento Java ao mainframe, da criação de produtos de prateleira à manutenção de ERPs. Nesses diagnósticos dois aspectos se sobressaíram.

O primeiro deles está relacionado ao estágio de desenvolvimento que a indústria de software se encontra em nossa região. É interessante notar que não há diferenças significativas de maturidade entre os projetos dessa pequena amostra. Estamos todos mais ou menos com as mesmas questões e caminhando na mesma direção.

O outro aspecto está relacionado a um problema comum a todos os projetos analisados: levantamento de requisitos . Não importa o sintoma apresentado pela equipe: “Não conseguimos testar, os sistemas são muito voláteis” ou “Os usuários mudam de idéia muitas vezes” ou “Tudo muda o tempo todo”. O fato é que todos os projetos analisados usam técnicas muito primárias para levantamento de requisitos. É quase como se quisessem tirar esse “problema” da frente e começar a desenvolver. É esse ponto que gostaria de explorar um pouco mais.

O interessante é que quase todas as equipes possuem bons padrões de documentação de requisitos: especificações funcionais, modelos, planilhas, etc. Entretanto, praticamente todos os grupos usam apenas uma técnica de levantamento de requisitos. Muitos deles recebem as especificações escritas e as tomam como boas, sem um aprofundamento maior, seja do problema ou da solução. É quase como se uma testemunha fosse interrogada apenas pelo promotor ou pelo advogado de defesa, sem nenhuma verificação ou busca de contradições no seu depoimento.

O senhor Marasco coloca esse tema sobre outro ponto de vista. Ele apresenta um contraste entre o importante ganho de produtividade das equipes de nas últimas décadas e a relativa pequena melhora na taxa de êxito nos projetos. Segundo o Chaos Report , publicado desde 1994 pelo Standish Group, a taxa de sucesso em projetos passou de 16% em 94, para 28% em 2001 e 31% em 2003. Nesse ritmo, apenas em 2014 vamos conseguir fazer com que metade dos projetos de desenvolvimento tenha sucesso.

Joe Marasco defende a tese que estamos sendo muito bons em desenvolver novas soluções, mas pouco eficientes em levantar o problema correto e os requisitos corretos. Ou seja, fazemos mais rápido e com técnicas mais sofisticadas as soluções erradas.

A prática de gerência de requisitos nos ensina que devemos combinar várias técnicas para levantar e esclarecer os requisitos. Assim conseguiremos validar o que um grupo está nos dizendo, o reinquirindo de outras formas e/ou comparando suas repostas com as de outros grupos. Técnicas como entrevistas, questionários, workshops, brain storms, entre outras, são raramente usadas de forma combinada com esse propósito.

Nossa experiência tem mostrado que não basta o uso de técnicas como casos de uso e desenvolvimento iterativo ou o uso de ferramentas de gerência de requisitos que permitam controlá-los, acompanhar suas mudanças e manter a rastreabilidade entre eles e os demais artefatos de software. Tudo isso é importante e garante um ganho de produtividade significativo, mas o uso de técnicas mais sofisticadas de levantamento é chave para quebrarmos o ciclo de construir a aplicação que achamos ser correta, receber as críticas, tentar novamente,...

Muitas vezes o simples treinamento em conjunto dos analistas de negócio, usuários e o pessoal de sistemas nas técnicas corretas, como aquelas descritas no RUP , reduzem graves problemas de entendimento entre os dois grupos. Em outras, o uso de uma consultoria especializada pode ajudar à organização a reduzir o abismo entre as áreas, diminuindo o estresse e facilitando o sucesso coletivo.

Como um colega costuma dizer: “Os usuários sabem o que querem, mas em geral não sabem descrevê-lo! Mas quando o vêem sabem identificá-lo”. Somente com um trabalho sistemático de levantamento das necessidades de negócios, dos requisitos de software, das especificações funcionais e não-funcionais, suportado por ferramentas que possibilitem o gerenciamento e a colaboração é que poderemos levar nossas equipes de desenvolvimento a um novo patamar. O patamar de produtividade e qualidade que nossas organizações precisam para competir no mundo plano .

Referências:

“Software development productivity and Project sucess rates: Are we attacking the right problem?”, por Joe Marasco, CEO, Ravenflow:
http://www-128.ibm.com/developerworks/rational/library/feb06/marasco/index.html?ca=drs-#rate

“Requirements: An introduction” por Scott McEwen, Metasys Technologies, Inc.
http://www-128.ibm.com/developerworks/rational/library/4166.html

Para mais informações ver: http://www.standishgroup.com

“Dissecting business from software requirements” por Jochen Krebs:
http://www-128.ibm.com/developerworks/rational/library/aug05/krebs/index.html

RUP - Rational Unfied Process
http://www-128.ibm.com/developerworks/rational/products/rup

Por que utilizar uma Metodologia de Desenvolvimento de Sistemas

Por Roosevelt Benvindo de Oliveira

A informalidade em projetos de TI tornou-se um fator de fracasso em muitos projetos. Alguns estudos, como por exemplo, às pesquisas publicadas pelo Standish Group, revelam que a quantidade de projetos fora do prazo, custo ou até mesmo abandonados, está diminuindo através da adoção de metodologias de gerenciamento de projetos. No entanto, não basta somente gerenciar melhor os projetos. É preciso aliar o bom gerenciamento de projetos com a escolha da melhor solução metodológica, observando sempre a cultura organizacional da empresa.
Uma Metodologia de Desenvolvimento de Sistemas é composta por seqüências de atividades executadas de forma organizada, que visam à construção de um Sistema de Informação com qualidade, no prazo e custo determinados, deve ser adequada à organização, de forma a otimizar o desenvolvimento de sistemas sem, no entanto, burocratizar a execução das atividades. Por este motivo, uma MDS desenvolvida para uma organização é eficiente apenas para a organização que a gerou, tornando-se menos eficiente em outra organização. Outra característica importante é que ela deve ser mutável, ou seja, da mesma forma que uma organização muda ao longo do tempo, ela deve adequar-se às mudanças de forma a manter a produtividade e eficiência desejada.
Existem diversas abordagens de ciclo de vida de software nas quais podemos basear uma MDS. Podemos citar, dentre as principais, o modelo Cascata, Evolucionário, por Prototipação, Iterativo e Incremental, dentre outros. Cada abordagem de ciclo de vida possui vantagens e desvantagens que precisam ser observadas na elaboração. Por exemplo, para softwares que tenham os requisitos estáveis e imutáveis, a abordagem em Cascata é mais eficiente. No entanto, seria um desastre a adoção do mesmo modelo para softwares que tenham os requisitos instáveis e mutáveis. Isso reforça o conceito de que cada organização deva ter sua própria metodologia e que a mesma deve ser desenvolvida observando a cultura organizacional e a estrutura de desenvolvimento proposta na organização.
Existem várias metodologias, nas mais variadas abordagens de ciclo de vida, disponíveis no mercado. Podemos destacar, dentre as principais, o RUP, OPENUP, XP, SCRUM. Pode-se também, conforme o caso, fazer um misto entre metodologias, obtendo assim o melhor de cada metodologia envolvida.
Quando bem implantada, traz, entre outros, os seguintes benefícios:
· Independência de indivíduos e facilidade de manutenção: Como os sistemas são bem estruturados e têm documentação padronizada e atualizada, um analista consegue, em pouco tempo, dar manutenção em um sistema que não conhece, evitando a figura do “dono do sistema”, situação desvantajosa tanto para a organização quanto para o próprio analista.
· Aumento da produtividade: Sistemas bem construídos têm mais partes reutilizáveis.
· Um bom gerenciamento de projetos: Como as etapas e produtos estão bem definidos, é possível saber a cada momento como está o andamento do projeto.
Uma metodologia atinge seu objetivo se for prática, de fácil utilização, rápida aprendizagem e, na medida do possível, suportada por ferramentas que automatizem tarefas repetitivas e mantenham o trabalho organizado. Portanto quando bem desenvolvida e adaptada à organização é uma poderosa ferramenta para se alcançar maturidade em desenvolvimento de projetos de TI.

Guia de Certificações do PMI - PMP

Por Roosevelt Benvindo de Oliveira

Segue um roteiro com os primeiros passos necessários para se tirar a certificação PMP. Antes de tudo lembre-se: "Basta darmos um primeiro passo e já não estaremos mais no mesmo lugar!!!"

O Project Management Institute (PMI) é uma instituição sem fins lucrativos criada nos Estados Unidos em 1969 com a finalidade de promover avanços nas técnicas de gerenciamento de projetos através da qualificação profissional.Vivemos numa sociedade em que a competição e o rápido avanço tecnológico são realidades. Dessa maneira, se faz cada vez mais necessária a capacitação qualitativa dos profissionais dos diversos setores da economia. Pensando dessa maneira que o Project Management Institute vem promover essa capacitação. Hoje, essa organização é a única que possui seu processo de certificação não só reconhecido em todo mundo, como também pela International Organization for Standardization (ISO).

O Project Management Professional (PMP) foi criado em 1984 e hoje é o principal produto do PMI. Consiste na certificação da qualidade profissional individual promovida por esse instituto e reconhecida em todo o mundo, tanto no que diz respeito ao conhecimento quanto à experiência necessária ao bom desempenho da missão de gerenciar projetos.O Certified Associate in Project Management (CAPM) foi instituído em 2002 e amplamente revisado em 2004, e está voltado para praticantes de gerenciamento de projetos que demonstrem conhecimento fundamental em gerenciamento de projetos, que atuem sob a orientação de gerentes de projetos experientes, e que ainda não atendam aos requisitos de experiência na área que os qualifiquem para a certificação PMP. Vale ressaltar que as empresas vêm exigindo a certificação PMP e, com isso, a certificação CAPM não parece ser um bom caminho por uma questão de mercado.

O Que é o Processo de Certificação PMP?
O processo de certificação PMP consiste em uma pré-qualificação do candidato seguida de uma prova teórica sobre as áreas de conhecimentos em gerenciamento de projetos segundo o Guia PMBoK.

E porque se Certificar?
• Profissionalização do papel de gerência de projetos.
• Ampliação da empregabilidade do profissional;
• Reconhecimento do grau de qualificação atestado internacionalmente;
• Possibilidade de adicionar um aumento salarial médio acima de 10%;
• Segundo dados do próprio PMI, em torno de 61% dos empregadores reembolsam o exame de certificação e as taxas de preparação aos candidatos aprovados.

Requisitos para Certificação
Em linhas gerais o candidato precisa comprovar experiência em projetos equivalente a um mínimo de 4500 ou 7500 horas dependendo se é ou não formado em nível superior, além de educação na área de gerenciamento de projetos.

Para se certificar como PMP você precisará:
• Ter Background Educacional
• Comprovar Experiência na área através de:
1)Para quem tem nível superior: Comprovação de no mínimo 4.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos;
2)Para quem tem nível médio: Comprovação de no mínimo 7.500 hs de atividades de liderança e direção em projetos. Essas atividades obrigatoriamente têm que ter ocorrido no período compreendido entre os últimos OITO anos.
• Mínimo de 35 horas de educação recebida específica na área de gerenciamento de projetos.
• Estar de acordo com o Código de Conduta Profissional do PMI.
• Pagar a taxa de inscrição; (US$405.00 para membros ou US$555.00 para os que não forem membros).
• Passar na prova de certificação.
Obs.: Quanto à comprovação das horas, o PMI atua exigindo que o candidato formalize (através de assinatura) que está sujeito às diretrizes de ética da entidade. No momento da submissão do pacote ele exige que, para cada projeto reportado, seja indicado um contato que possa verificar a experiência informada (deve ser preenchido um formulário por projeto -tantos quantos necessários para atingir o mínimo das horas, - 4500 ou 7500, conforme o caso.). Posteriormente, por um processo de amostragem, o PMI audita os pacotes submetidos. Se o candidato for auditado, receberá solicitações para que apresente comprovações das horas trabalhadas. Caso não consiga fazê-lo, estará passível de sanções definidas pelas Diretrizes de Ética do PMI. (Muita atenção a esta observação. Não invente projetos, pois esta auditoria realmente acontece e conheço pessoas que foram auditadas).

A taxa de inscrição para a prova é de US$ 405.00 para membros do PMI ou US$ 555.00 para os não membros. Recomendo fortemente que se associem ao PMI em virtude dos benefícios que vocês terão tais como o recebimento de publicações técnicas com artigos de interesse da comunidade de gerenciamento de projetos.

Vide comparativo:
Filiando-se ao PMI e ao capítulo de seu estado: Filiação ao PMI - Anuidade (US$ 119,00) + Filiação ao PMI – 1ª Inscrição (US$ 10,00) + Filiação ao capítulo DF (US$ 20,00) + Inscrição p/ Prova (US$ 405,00) = US$ 554,00
Sem filiar-se ao PMI: Inscrição p/ Prova (US$ 555,00) = US$ 555,00

Observamos que optando por se tornar membro do PMI, bem como do Capítulo, você obterá maiores benefícios em função do investimento realizado, revertendo para si, mais benefícios além do direito de realizar o exame, posto que você ainda economizará US$ 1.00. Além dos benefícios em tornar-se membro, você pagará US$ 100.00 a menos caso precise fazer o reexame, uma vez que a taxa de reexame é de US$ 275,00 para membros do PMI e US$ 375,00 para não membros. (Vale a pena pensar nisso!!)

Uma vez cumpridos os requisitos apresentados, você receberá uma carta de elegibilidade credenciando-o a se submeter a prova em um dos locais autorizados para tal. A carta de elegibilidade tem um ano de validade.

Etapas do Processo de Certificação PMP
1º - Qualificação:
Consiste na verificação por parte do PMI das informações submetidas para que seja avaliado se o candidato é ou não habilitado a prestar o exame teórico. Em caso afirmativo, será encaminhada ao candidato uma carta informando-lhe todos os dados necessários para a marcação da prova,informações sobre adiamento e cancelamento, número de elegibilidade que o identifique e permita o agendamento do exame, além de informações sobre o local e condições de realização do exame.
2º - O Exame
De posse dessas informações, o candidato entrará em contato com um dos centros de testes e assim efetuará a marcação de seu exame, através da informação de seu número de elegibilidade.Isso irá autorizá-lo a fazer a prova, indicando-o local e condições para fazer o exame de certificação.O exame é realizado on-line via computador, sendo o resultado informado imediatamente após o término da prova. Em Brasília, a casa Thomas Jefferson é o centro Prometric autorizado para o exame PMP.
O exame para PMP consiste de uma prova de múltipla escolha com 200 questões - com 4 opções de resposta cada - sobre toda a área de conhecimento compilada no PMBoK. O candidato tem um máximo de 4 horas para completar o teste. O teste é composto de 175 questões válidas para o exame e de 25 questões de validação, as quais estão ordenadas de forma aleatória.O percentual mínimo de acerto das questões da prova para garantir a qualificação do profissional deve ser de 60, 57%, representando 106 das 175 questões. Cada questão tem apenas 1 (uma) única resposta correta dentre quatro alternativas possíveis. Todas as questões têm o mesmo valor -> 1(um) ponto, independentemente de sua complexidade. Os assuntos são divididos percentualmente da seguinte maneira:

- 11% -> Iniciação;

- 23% -> Planejamento;

- 27% -> Execução;

- 21% -> Controle;

- 9% -> Fechamento;

- 9% -> Responsabilidade Profissional.

Acessem o site http://www.pmi.org/ para maiores informações e para iniciarem todo o processo.
Bem, compreender o processo de certificação PMP é o primeiro passo para iniciar a empreitada! Disponibilizarei nos próximos posts o material que utilizei para estudar para a prova.