Arquivo | Gestão Pública RSS feed for this section

A oportunidade pode ser única: vá de Paralelismo (fast tracking)!

17 Nov

Sempre que estou prestes a concluir algum projeto gosto de analisar as principais ações adotadas em seu planejamento e execução para avaliar os resultados efetivamente entregues. Desta vez, construirei essa análise com vocês, aqui neste novo post!

Na publicação passada, quando abordei sobre a Eficácia e Eficiência no Gerenciamento de Projetos (clique para ver), procurei enfatizar a necessidade de concentrar esforços em fazer com que o projeto atendesse não só aos requisitos “burocráticos”, mas, principalmente, àqueles que permeassem a qualidade, expectativas e aprendizado.

Ainda influenciado pelos meus vagos pensamentos deste último post, eu comecei a conjecturar sobre um novo projeto que entra em sua Fase de Encerramento. A proposta do projeto está em desenvolver uma Ferramenta de Gestão de Atendimento ao Cliente. Este projeto não chega a possuir alta complexidade de implementação de suas funcionalidades. Entretanto, tivemos (Equipe do Projeto) que fazer uso de algumas técnicas de GP bem interessantes como, por exemplo, o Paralelismo de algumas atividades da Fase de Execução.

Se a análise deste projeto partisse do proposto de [eficácia + eficiência = efetividade] seria ideal envolver as pessoas que demandaram e ajudaram a construir o projeto.  Não que isto não seja importante, ao contrário: é muito importante!!! No entanto, vou restringir, ao menos por enquanto, à análise do uso da técnica do Paralelismo neste projeto.

Pra começar, recorri ao Guia PMBOK v4 para buscar a definição do que seria a técnica do Paralelismo:

“Uma técnica específica para compressão do cronograma de um projeto que altera a lógica de rede sobrepondo algumas fases que normalmente seriam realizadas em sequência, como a fase de projeto e a fase de construção, ou para realizar atividades do cronograma em paralelo.”

Essa definição não poderia ser melhor!

A história do nosso projeto é bastante simples: as fases de iniciação e planejamento do projeto não foram sobrepostas, ou seja, seguiram bem a metodologia proposta pela empresa. Mas, as Iterações foram reorganizadas de forma a serem paralelizadas. Ao invés de se concluir uma Iteração para então iniciar a próxima, optamos por implementar várias Iterações no mesmo período, mas que seriam complementares entre si.

E por que disso?! PRAZO! PRAZO!! PRAZO!!!

A compressão do cronograma é uma técnica de “redução da duração do cronograma do projeto sem reduzir o seu escopo“.

Lembro que reduzir escopo para alcançar a restrição de prazo nem sempre é uma boa opção: o cliente não vê com bons olhos ter suas necessidades do projeto minimizadas. Ele se sente impotente e, com isso, acaba se afastando do projeto. Em casos assim, é comum utilizar algumas técnicas de Compressão do Cronograma, como a técnica do Paralelismo!

Para que você possa entender melhor o contexto do projeto, nós utilizamos a metodologia da empresa (ativo organizacional) de Gerenciamento de Projetos e Engenharia de Software, a qual estava embasada no Manifesto Ágil. O conceito de ciclos era algo bem forte na metodologia. E para iniciar um próximo ciclo, necessariamente, o anterior deveria estar homologado pelo cliente.

A imagem 1 a seguir demonstra como o projeto foi inicialmente planejado, sem considerar a sobreposição de tarefas:

Imagem 1: execução do projeto de forma linear.

Facilmente, pelo Gráfico de Gantt, podemos constatar as Iterações encadeadas. O Software seria construído de forma incremental. Outra observação que faço está relacionada ao caminho crítico destacado em amarelo, veja como ele foi alterado na imagem abaixo.

Já a imagem 2 demonstra o uso do Paralelismo no projeto para os ciclos de 1 a 5:

Imagem 2: execução do projeto utilizando Paralelismo.

Com essas duas imagens pode-se comparar o quanto o cronograma é modificado e, principalmente, como o caminho crítico é afetado quando utilizamos alguma técnica de compressão do cronograma.

A primeira coisa que me vem à cabeça, quando utilizo a técnica de Compressão do Cronograma, está relacionada à precariedade em seu uso quando temos uma iteração (ciclo) sendo utilizado como insumo para a implementação do próximo ciclo:

1 – A integração do sistema ficou altamente empobrecida. O que gerou dificuldade de compreensão do fluxo de funcionamento do sistema como um todo;

2 – Geração de retrabalho decorrente da integração dos ciclos;

3 – Sensível incremento nos custos do projeto. A linearidade do projeto se perdeu. Novos recursos humanos tiveram que ser adicionados ao projeto para permitir a execução de atividades em paralelo.

4 – As estimativas de duração das atividades foram impactadas, pela falta do insumo para planejamento do próximo ciclo;

5 – Sobrecarga de trabalho para alguns perfis da equipe;

A sobrecarga de alguns perfis como Analista de Testes e o Designer de Interface, se justifica, já que, tiveram que se dividir entre uma e outra iteração. De certa forma, isto os pressionou e comprometeu seus desempenhos. Não havia disponibilidade de contratação ou alocação de outros recursos com este perfil para o projeto.

O versionamento de documentos, a gestão de atividades e priorização ficou dificultada. Muitas vezes, havia necessidade de parar o projeto para sanar dúvidas que deveriam ser respondidas na Homologação de Cada Ciclo desenvolvido anteriormente – lembro que um ciclo serve de insumo para outro.

Naturalmente, o Paralelismo implica em riscos de integração. Quando se utiliza o desenvolvimento simultâneo de ciclos, a integração deve ser muito bem planejada e o custo disso deve ser previamente aprovado. Nem sempre é fácil prever a variação dos custos do projeto quando se utiliza a Compressão do Cronograma!

E o cliente, como fica nesta situação?

É neste ponto que devemos verificar o Custo x Benefício do uso desta técnica de Compressão do Cronograma. O que será escrito aqui não pode ser tratado como regra para todos os projetos, até porque os projetos não são iguais, ok?

O custo do projeto, apesar de ter evoluído, não era algo determinante para continuar ou não o projeto. Basicamente, o esforço de custo estava em alocação de recursos humanos para o projeto. E este custo já estava pago. Se a equipe não fosse alocada para este projeto estaria em outro mais prioritário. Sobre contratos hora homem no serviço público brasileiro, eu publiquei o post que trata deste tema – IN 1 – Procedimentos para o desenvolvimento, disponibilização e uso do Software Público Brasileiro.

No entanto, o cliente enxergou no projeto uma oportunidade de alavancar seu setor de atendimento ao cliente, que até então era precário. Ou seja: o projeto fazia parte de uma estratégia organizacional maior!

Nestes casos, a Gerência do Projeto deve entrar em ação!

Quando se usa o Paralelismo, o cliente tem que está bem mais envolvido do que o normal. É também essencial que o Cliente esteja ciente dos riscos envolvidos nesta operação. Ele deve ser parceiro do projeto!

Para gerenciar as expectativas do cliente, o Gerente de Projetos deve dar autonomia a equipe técnica para resolver questões de implementação e, principalmente, necessita mantê-lo informado da relação de evolução do Escopo x Tempo x Custo. A análise de valor agregado é fundamental para que o cliente veja o quanto a decisão de antecipar o prazo custou ao projeto!

Lembro que a oportunidade para realizar o projeto era única, já que, havia recursos disponíveis, patrocínio e vontade política!

No entanto, mesmo com os entraves apresentados acima, seria o Paralelismo o fim dos tempos no Gerenciamento de Projetos?!

Não! De forma alguma!

Tente enxergá-lo como uma oportunidade. Explico:

Propiciar aos clientes da empresa um atendimento mais qualificado  é algo que deve ser visto como investimento e não custo. O prazo deveria ser atendido, já que a vontade política para realizar o projeto passava por essa restrição. Em qualquer projeto, não se pode perder o patrocínio, ainda mais quando voltado para órgão público.

Neste caso, a Técnica de Compressão do Cronograma baseada no Paralelismo é muito importante.

Aí convenhamos: mesmo com todas as dificuldades no Gerenciamento do Projeto e nos eventuais fracassos obtidos em relação a isso, sob a ótica do cliente o projeto atendeu as expectativas técnicas e negociais, já que cumpriu com seu escopo e com os objetivos políticos determinados para ele.

Veja o porquê do dilema de Eficácia e Eficiência continuou a ventilar os meus pensamentos…

É isso! Continue visitando o blog!

Até a próxima!

P.S.: este blog concorre ao TOP BLOG 2011. Não se esqueça de apoiar!

Anúncios

Dica Rápida:TCU Contrata Profissional de Gestão de Processos

22 Jul

TCU contrata profissional de gestão de processos para trabalho com duração de 5 meses. A seleção será por meio de análise de currículo. A data limite para enviar a documentação é até o dia 29/07 às 18:00.

Requisitos:

  • Formação Acadêmica: Engenharia, Administração, Contabilidade, Economia, Tecnologia da Informação e áreas relacionadas.
  • Curso de extensão na área de Gestão de Processos e Pós-Graduação com programa relacionado a gestão de processos.

Entrar em contato por: ucp@tcu.gov.br

IN 1 – Procedimentos para o desenvolvimento, disponibilização e uso do Software Público Brasileiro.

21 Fev

O Ministério Planejamento, Orçamento e Gestão parece realmente estar motivado a por ordem na casa, ao menos quando o assunto é TI. No último dia 17 de janeiro, foi lançada a Instrução Normativa 01, que trata do SPB – Software Público Brasileiro.

Talvez, a IN em questão não cause o impacto da IN4, que está voltada para a governança de TI. Mas a nova instrução normativa tem sua importância. Neste post quero apresentar alguns pontos que me chamaram atenção e TENTAR definir a pretensão da IN 1.

As razões:

  • O software ser tratado como um objeto de compartilhamento, sem que haja competição pelo bem. Ou seja, o bem – software – é público.
  • As demandas recorrentes e similares entre os órgãos públicos faz do SPB importante instrumento de racionalização e criação de acervo de soluções já desenvolvidas pelos diferentes poderes e esferas governamentais.

O que é o SPB:

  • É um tipo específico de software que adota um modelo de licença livre para o código-fonte, a proteção de identidade original entre o seu nome, marca, código-fonte, documentação e outros artefatos relacionados por meio do modelo de Licença Pública de Marca – LPM” e é disponibilizado na internet em ambiente virtual público, sendo tratado como um benefício para a sociedade, o mercado e o cidadão (…).”

Similar à IN 4, esta nova instrução normativa também define alguns conceitos importantes, como os de software, software livre, tecnologia proprietária, marca, licença pública de marca (LPM), SISP, Órgão Central do SISP, Portal do Software Público Brasileiro, comunidade virtual, comunidade aberta no Portal SPB, ofertante de SPB, coordenador institucional e coordenador técnico.

Destaco os conceitos de:

a)      Software Livre: software cujo modelo de licença livre atende aos quatro tipos de liberdade definidas pela Free Software Foundation

b)      Tecnologia Proprietária: aquela cuja cópia, uso, redistribuição ou modificação são, em alguma medida, restringidas ou liberadas mediante contrato.

c)       Licença Pública de Marca – LPM: tipo de licença de uso de marca que preserva a identidade original entre o nome, a marca, o código-fonte, a documentação e outros artefatos relacionados ao Software Público Brasileiro e na qual o titular do registro consente genericamente, sem necessidade de qualquer tipo de autorização prévia e/ou específica, que outros utilizem gratuitamente a marca para fins de cópia, distribuição, compartilhamento e transmissão em qualquer dispositivo físico ou virtual, inclusive com propósitos comerciais, desde que respeitada as regras e requisitos previstos na IN.

Outro ponto que merece ser ressaltado é o capítulo que destaca o desenvolvimento e disponibilização do SPB. Neste capítulo, caso você queira se tornar um parceiro do governo em softwares livres, será possível encontrar os requisitos: técnicos e jurídicos, do Portal do Software Público Brasileiro, da Oferta de Software, da Solicitação de Software e da Coordenação das Comunidades Virtuais. Para quem se interessa no tema, vale dar uma lida mais aprofundada sobre estes requisitos.

O acesso ao SPB

  • O usuário, seja pessoa física ou jurídica, deverá aceitar, no ato de cadastramento, alguns requisitos impostos na IN. Muitos destes requisitos estão envolvidos ao conceito de software livre, LPM, responsabilidade pessoal por todos os riscos relacionados à qualidade e ao desempenho dos softwares disponibilizados no Portal SPB.

Como eu vejo a iniciativa: interessante!

Tudo que envolve organização e racionalização de iniciativas de software, que possam impactar em melhor gestão de investimentos e gastos, é benvinda. Lembro que nos últimos anos os gastos do governo federal com projetos de software já estão iguais ou superiores aos de engenharia. Daí já podemos entender a preocupação do MPOG.

O SPB será bastante útil no momento em que todos os órgãos do serviço público estiverem com seu inventário de softwares bem consolidado e integrado. E essa tarefa não é nada fácil.

Mais do que isso, o SPB prega diversos requisitos que o software deve possuir, para então poder fazer parte do portal do software público brasileiro. E aí vêm à pergunta, quantos projetos de software no governo cumprem todos os requisitos? Tem que pensar nisso para poder dimensionar o tamanho do desafio que a IN1 propõe.

Do outro lado está o incentivo ao desenvolvimento de projetos de Softwares com tais características. Aqui vejo uma grande possibilidade!  As empresas parceiras ou contratadas pelos órgãos públicos, se condicionadas a isso, terão que mudar suas estratégias. Como ficaram as soluções desenvolvidas com base em sistemas proprietários? Não farão parte do SPB? Pelos requisitos apresentados, não! Então se abre uma grande possibilidade para as empresas pequenas, mas eficientes, que não estão vinculadas a soluções proprietárias.

É preciso definir com clareza quais serão os benefícios para o parceiro e para os próprios órgãos da administração pública. Volto a dizer, a ideia é excelente! Basta ter organização e boa vontade para tornar a medida uma grande oportunidade de organização e racionalização!

Até a próxima!!!!!

Acesse: http://www.softwarepublico.gov.br
Download da IN2

Imagem: http://libertario08.wordpress.com/

Nova IN 4 – Ordem no Caos?

4 Jan

Muito se sabe das dificuldades e dos meandros das contrações, especialmente de serviços, na administração pública brasileira. Por ter me formado profissionalmente em Brasília e, inevitavelmente, ter prestado serviços para alguns órgãos públicos instalados na cidade, vou tecer breves impressões sobre a IN 4 (instrução normativa 4), lançada em 2008 pela SECRETARIA DE LOGÍSTICA E TECNOLOGIA DA INFORMAÇÃO do Ministério do Planejamento e que foi atualizada no mês de novembro 2010.

No último congresso de gerenciamento de projetos PMI-DF, realizado em Brasília no mês de outubro, tive a oportunidade de assistir a uma palestra sobre as dificuldades e os riscos de contratação de serviços de TI no serviço público. O nome da palestra (só para deixar registrado) foi: “Altos Riscos na contratação e Gerenciamento de Projetos na Área Pública e abordagem para respectiva mitigação” por Paulo Keglevich de Buzin. Antes de tudo já exponho que a palestra foi muito significativa, principalmente pelo simples fato do tema ser abordado sob a perspectiva do consultor, ou seja, de quem é contratado.

Mas o que quero mostrar é exatamente as contradições e os interesses envolvidos em cada um dos lados envolvidos nessa história: o contratante (administração pública) e o contratado (empresas prestadoras de serviço de TI). Em um tempo não muito remoto, em que, inclusive, eu trabalhei diretamente, muito se via os contratos por Hora Homem, no formato de outsourcing.

Basicamente era assim: o órgão contratava um serviço que não se sabia muito pra que era, e o contratado realizava o trabalho conforme era demandado. Se a empresa tivesse 100 pessoas alocadas em um núcleo de algum órgão, e conforme o perfil destas pessoas, ao final do mês se emitia uma fatura contabilizada por valor Hora Homem (HH) para pagamento. Pois bem: ter medidas de qualidade, produtividade, trabalhos realizados conforme escopo/metas/objetivos e riscos era algo que nem se passava na cabeça. Ou seja, por eu ter profissionais alocados para o “projeto” eu simplesmente recebia valores. Mesmo que 99 dos 100 profissionais alocados nada fizessem durante todo o mês. Absurdo? Talvez.

(É bom lembrar que a gestão destes projetos era muito eficiente pelo lado da contratada!)

Enfim, neste modelo de contratação e gestão de projetos o caos estava instalado. Aí vem a IN 4, que vem a  normatizar  muito do que já está na lei de licitações (8.666). Para que um órgão contrate serviços de TI, caso seja algo comum, ou seja, bens e serviços comuns de TI, obrigatoriamente, deve-se realizar a licitação pela modalidade Pregão. Isso implica em redução de preços. Conseqüência: a administração pública passa a comprar com valores menores. Mas isso realmente traz consigo os melhores serviços ou produtos? Bom, essa é outra questão que deve ser analisada com bastante calma e eu deixarei para outro momento.

Por enquanto, vou focar na IN 4. Então, já sabemos que se for para serviços e produtos comuns, a modalidade deve ser Pregão. Mas o problema central, estava no montante gasto agregado à grandes disperdícios. A IN 4 nada mais fez que o óbvio. É uma tentativa do governo federal em colocar ordem no caos. Primeiramente, ela está voltada para o caos interno. Ela apresenta conceitos e definições importantes, além de fases do processo de contratação que envolve: planejar, monitorar e controlar e aceitar. Além disso, ela dá a oportunidade do departamento de TI de se aproximar das demais áreas de negócio. A IN4 estabelece algo que eu considero fundamental: o estabelecimento de um comitê executivo de TI. Bingo! Esse é o grande negócio. Não se pode achar que a TI deve entender de tudo e contratar da forma que ela quiser. Não! O comitê vai indicar a forma de fazer isso.

Outro aspecto importante da instrução normativa encontra-se no detalhamento das fases. Nela está indicada a responsabilidade de cada um dos personagens envolvidos no processo de contratação. E isso envolve, necessariamente, o departamento que demanda a contratação, a TI que formata essa necessidade, a contabilidade ou outro órgão similar que diz se tem orçamento e uma equipe de gerência do projeto que acompanha e fiscaliza a execução e a entrega dos trabalhos. Outro passo importante é que os departamentos de TI passaram a ser gerenciados exclusivamente por funcionários de carreira e, mais do que isso, a gestão não pode ser objeto de terceirização.

Bom, e o outro lado, o do contratado? A coisa se complicou.  Lembro que a IN 4 foi adotada a partir de uma perspectiva interna. Diante disso, consultores e empresas do setor terão que se adequar à nova realidade. É possível fazer muito com pouco? Eu vejo que sim. Antes a realidade era de caos absoluto. Hoje é de tentar por ordem neste caos. Para o profissional sério e competente a situação de hoje é bem melhor. Acredito que se a IN4 e sua atualização for bem seguida, as empresas prestadoras de serviço poderão encontrar nos órgãos equipes entrosadas e mais qualificadas, além de uma gestão mais eficiente do processo (espera-se). Com isso, não se trabalhará no escuro. E isso é ótimo para todos!

 

 

IN 4: IN4 – 2008-Contratação de Serviços

Boa semana a todos e até a próxima!!!

imagem tirada da internet – Google Images
%d bloggers like this: