Embed Size (px)
Citation preview
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
APLICAÇÃO DAS MELHORES PRÁTICAS DE GERENCIAMENTO DE PROJETOS E MÉTODOS ÁGEIS NAS
AQUISIÇÕES DA ADMINISTRAÇÃO PÚBLICA
Por: Gean Felipe Alves de Oliveira
Orientador
Prof. Nelsom de Magalhães
Rio de Janeiro
2016
DOCUMENTO PROTEGID
O PELA
LEI D
E DIR
EITO AUTORAL
ヲ
UNIVERSIDADE CANDIDO MENDES
PÓS-GRADUAÇÃO “LATO SENSU”
AVM FACULDADE INTEGRADA
APLICAÇÃO DAS MELHORES PRÁTICAS DE GERENCIAMENTO DE PROJETOS E MÉTODOS ÁGEIS NAS
AQUISIÇÕES DA ADMINISTRAÇÃO PÚBLICA
Apresentação de monografia à AVM
Faculdade Integrada como requisito parcial
para obtenção do grau de especialista em
Gestão de Projetos.
Por: . Gean Felipe Alves de Oliveira
ン
AGRADECIMENTOS
Ao Eterno por ter me concedido saúde e
conhecimento, à minha esposa, pela
paciência na ausência, a meu filho pelas
horas de bagunça no computador e aos
professores e colegas de curso, pois juntos
trilhamos uma etapa importante de nossas
carreiras.
ヴ
DEDICATÓRIA
Dedico a meus pais, esposa e filhos que
sempre me inspiram para que eu alcance um
lugar de destaque na minha jornada
profissional.
ヵ
RESUMO
Esta monografia tem como objetivo Tratar da adoção das melhores práticas da gestão de projetos e métodos ágeis nas aquisições de projetos da administração pública, visando trazer elementos relevantes que fomentem o desenvolvimento e eficiência dos gestores públicos. Bem como, apresentar os Fundamentos da gerência de Projetos e como podem ser adaptados na Administração Pública Federal, apresentar os Fundamentos da metodologia ágil - Scrum e como esse framework pode ser utilizada para acompanhar o andamento dos projetos públicos e desempenho das equipes, criando uma metodologia prática e que tenha funcionalidade para ser consultada por gestores públicos envolvidos em projetos.
ヶ
METODOLOGIA
A metodologia utilizada para realização desta monografia foi uma pesquisa
bibliográfica tendo como fonte de consulta, informações obtidas através da leitura de
literaturas especialidades e sites oficiais que abordem as Compras Governamentais,
Gerenciamento de Projetos e Gerenciamento Ágil de Projetos.
As bases para realização do trabalho foram às referências bibliográficas e
experiência profissional na Marinha do Brasil atuando como gerente de suprimentos.
Α
SUMÁRIO
INTRODUÇÃO 08
CAPÍTULO I – FUNDAMENTOS DA GERÊNCIA DE PROJETOS 09
CAPÍTULO II – FUNDAMENTOS DO SCRUM 13
CAPÍTULO III – COMPRAS NO SERVIÇO PÚBLICO 21
CAPÍTULO IV – MELHOES PRÁTICAS DA GERÊNCIA DE PROJETOS 25
CONCLUSÃO 39
BIBLIOGRAFIA 40
WEBGRAFIA 41
ÍNDICE 42
ÍNDICE DE FIGURAS 45
ANEXOS 46
Β
INTRODUÇÃO
O presente trabalho visa demonstrar as melhores práticas de gestão de projetos
adotadas pela iniciativa privada a fim de otimizar o fluxo do processo de aquisições na
Administração Pública no Brasil que vem passando por algumas transformações e o
grande volume de recursos que os gestores públicos têm a responsabilidade de
administrar necessita de projetos bem elaborados, para que sua execução seja correta e a
finalidade seja atendida.
A escolha do objeto de estudo se deu pela importância do tema, visto que na
Administração pública o processo de aquisições, embora em grande parte sob a
perspectiva jurídica, a perspectiva jurídica não se presta aos interesses dos gestores de
aquisições públicas, que precisam de uma forma rápida, eficaz e confortável de gerir as
aquisições em projetos.
Os itens a seguir fazem uma contextualização dos principais assuntos relacionados
ao referido trabalho, que, na sequência, será descrito detalhadamente.
No capítulo I, é abordado a respeito das noções fundamentais da gerência de projetos, o
capítulo II aborda os fundamentos do Scrum, o capítulo III aborda as compras no
serviço público, no capítulo IV às melhores práticas do gerenciamento de aquisições em
projetos é estudada adotando a visão do PMI.
A conclusão descreve aplicação e os benefícios das melhores práticas do gerenciamento
de projetos nas aquisições da administração pública.
Γ
CAPÍTULO I
FUNDAMENTOS DA GERÊNCIA DE PROJETOS
1. Considerações Iniciais As transformações no mundo do trabalho nas últimas décadas levaram as
organizações a enfrentarem altos níveis de competitividade, buscando, assim, encontrar novas formas de trabalho e inovação. Nesse contexto, exige-se cada vez mais que o trabalho seja feito com menos recursos, o mais rápido possível e com maior qualidade.
No cenário governamental, a realidade não é diferente e observa-se que o Governo Federal busca cada vez mais reestruturar sua gestão com foco competitivo e voltado para a qualidade.
Segundo o Guia (PMBOK®, Quinta Edição, 2013, p.3), pode-se resumir o
conceito de projetos em três palavras: temporário, progressivo e delivering (que gera “entregas”).
Tanto na definição do PMI – Project Management Institute (que elabora o PMBOK®) quanto na do Governo Federal, a estrutura básica do conceito de projetos relaciona-se com a percepção clara de um produto a ser entregue (escopo) para um determinado esforço predefinido. Isso significa que ao iniciarmos um projeto já sabemos, a priori, "quando?" e "o que?" será entregue.
1.1. Características da gerência de projetos
Segundo o Guia (PMBOK®, Quinta Edição, 2013, p.38), projetos são
empreendimentos com objetivo específico e ciclo de vida definido, projetos são blocos de construção no desenho e na execução de estratégias organizacionais e os projetos são os precursores de produtos, serviços e processos organizacionais. Na gerência de um projeto são postas em prática às funções administrativas tradicionais de planejamento, organização, motivação, direção e controle. Para a conclusão bem-sucedida de um projeto, exigem-se tanto aptidões de liderança como administrativas. Os principais resultados de um projeto são o cumprimento dos objetivos de desempenho técnico, dos custos e de cronograma.
ヱヰ
1.2. Projetos Versus Operações
As operações são esforços contínuos que geram saídas repetitivas, com
recursos designados para realizar basicamente o mesmo conjunto de tarefas. O gerenciamento de operações é responsável pela supervisão, orientação e controle das operações de negócios.
Os projetos exigem atividades de gerenciamento de projetos e conjuntos de habilidades, enquanto que as operações exigem gerenciamento de processos de negócios.
Diferentemente da natureza contínua das operações, os projetos são esforços temporários.
Um projeto é diferente de uma operação, embora tenham alguns aspectos em comum, tais como:
• Realizados por pessoas. • Restringidos por recursos limitados. • Planejados, Executados e Controlados.
Entretanto podemos destacar algumas especificidades relativas a cada um. Veja o quadro abaixo:
Figura 1 - Especificidades do Projetos Versus Operações segundo David I. Cleland (2002, p.15).
ヱヱ
1.3. Contribuições da Gerência de Projetos
Segundo David I. Cleland (2002. p.9), a gerência de projetos amadureceu
como disciplina. Segue-se um resumo das mudanças mais importantes que
aconteceram na gerência de projetos desde seu surgimento:
1. O reconhecimento de que a gerência de projetos é uma disciplina por direito
próprio, como um ramo de conhecimentos e aptidões.
2. O descobrimento e o estabelecimento da legitimidade do desenho
organizacional matricial como meio de delegar autoridade, responsabilidade
implícita e responsabilidade assumida para a gerência dos recursos do projeto.
3. O estímulo e a propagação de associações profissionais no campo.
4. O desenvolvimento e a difusão do conceito de sistema de gerência de
projetos como um padrão de desempenho para a administração de recursos de um
projeto.
5. Melhora da produtividade, fornecendo caminho direto para solução de problemas. 6. Aumento dos lucros com redução de desperdício de tempo e recursos.
7. Melhores informações para tomada de decisões.
8. Melhora nas comunicações em todos os níveis.
9. Melhor definição do produto e melhor definição dos próprios
requerimentos.
10. Confiança na entrega no prazo e dentro do preço.
1.4. Processos de Gerência de Projetos
Segundo o Guia (PMBOK®, Quinta Edição, 2013, p.420), os projetos são
compostos por processos, que são definidos como uma série de ações que geram produtos. Os processos dos projetos são realizados por pessoas e, normalmente, se enquadram em duas categorias:
• Processos orientados ao Produto (especificação e criação dos produtos do projeto). • Processos da Gerência de Projetos (descrição, organização e trabalho do projeto).
Os grupos de processos estão ligados pelos resultados que produzem.
ヱン
CAPÍTULO II
FUNDAMENTOS DO SCRUM
2. Considerações Iniciais
Segundo Ken Schwaber (2009. p.3), o Scrum vem sendo utilizado para o
desenvolvimento de produtos complexos desde o início dos anos 90. Este guia descreve
como usar o Scrum para desenvolver produtos. Scrum não é um processo ou uma
técnica para o desenvolvimento de produtos. Ao invés disso, é um framework dentro do
qual você pode empregar diversos processos e técnicas. O papel do Scrum é fazer
transparecer a eficácia relativa das suas práticas de desenvolvimento para que você
possa melhorá-las, enquanto provê um framework dentro do qual produtos complexos
podem ser desenvolvidos.
2.1. Teoria do Scrum Scrum, que é fundamentado na teoria de controle de processos empíricos,
emprega uma abordagem iterativa e incremental para otimizar a previsibilidade e
controlar riscos. Três pilares sustentam qualquer implementação de controle de
processos empíricos.
2.1.1. O Primeiro Pilar é a Transparência A transparência garante que aspectos do processo que afetam o resultado
devem ser visíveis para aqueles que gerenciam os resultados. Esses aspectos
não apenas devem ser transparentes, mas também o que está sendo visto deve
ser conhecido. Isto é, quando alguém que inspeciona um processo acredita que
algo está pronto, isso deve ser equivalente à definição de pronto utilizada.
ヱヴ
2.1.2. O Segundo Pilar é a Inspeção
Os diversos aspectos do processo devem ser inspecionados com uma
frequência suficiente para que variações inaceitáveis no processo possam ser
detectadas. A frequência da inspeção deve levar em consideração que qualquer
processo é modificado pelo próprio ato da inspeção. O problema acontece
quando a frequência de inspeção necessária excede a tolerância do processo à
inspeção. Os outros fatores são a habilidade e a aplicação das pessoas em
inspecionar os resultados do trabalho.
2.1.3. O Terceiro Pilar é a Adaptação Se o inspetor determinar, a partir da inspeção, que um ou mais aspectos do
processo estão fora dos limites aceitáveis e que o produto resultante será
inaceitável, ele deverá ajustar o processo ou o material sendo processado. Esse
ajuste deve ser feito o mais rápido possível para minimizar desvios posteriores.
Existem três pontos para inspeção e adaptação em Scrum. A Reunião Diária é
utilizada para inspecionar o progresso em direção à Meta da Sprint e para
realizar adaptações que otimizem o valor do próximo dia de trabalho. Além
disso, as reuniões de Revisão da Sprint e de Planejamento da Sprint são
utilizadas para inspecionar o progresso em direção à Meta da Versão para
Entrega e para fazer as adaptações que otimizem o valor da próxima Sprint.
Finalmente, a Retrospectiva da Sprint é utilizada para revisar a Sprint passada
e definir que adaptações tornarão a próxima Sprint mais produtiva,
recompensadora e gratificante.
2.2. Conteúdo do Scrum
Segundo Ken Schwaber (2009. p.4), O framework Scrum consiste em um
conjunto formado por Times Scrum e seus papéis associados, Eventos com Duração
Fixa (Time-Boxes), Artefatos e Regras.
Times Scrum são projetados para otimizar flexibilidade e produtividade. Para esse
fim, eles são auto-organizáveis, interdisciplinares e trabalham em iterações.
Cada Time Scrum possui três papéis: 1) o ScrumMaster, que é responsável por
ヱヵ
garantir que o processo seja entendido e seguido; 2) o Product Owner, que é
responsável por maximizar o valor do trabalho que o Time Scrum faz; e 3) o Time,
que executa o trabalho propriamente dito. O Time consiste em desenvolvedores com
todas as habilidades necessárias para transformar os requisitos do Product Owner em
um pedaço potencialmente entregável do produto ao final da Sprint.
Scrum emprega os eventos com duração fixa (time-boxes) para criar regularidade.
Entre os elementos do Scrum que têm duração fixa, temos a reunião de
Planejamento da Versão para Entrega, a Sprint, a Reunião Diária, a Revisão da
Sprint e a Retrospectiva da Sprint. O coração do Scrum é a Sprint, que é uma
iteração de um mês ou menos, de duração consistente com o esforço de
desenvolvimento. Todas as Sprints utilizam o mesmo modelo de Scrum e todas as
Sprints têm como resultado um incremento do produto final que é potencialmente
entregável. Cada Sprint começa imediatamente após a anterior.
Scrum utiliza quatro artefatos principais. O Backlog do Produto é uma lista
priorizada de tudo que pode ser necessário no produto. O Backlog da Sprint é uma
lista de tarefas para transformar o Backlog do Produto, por uma Sprint, em um
incremento do produto potencialmente entregável. Um burndown é uma medida do
backlog restante pelo tempo. Um Burndown de Versão para Entrega mede o
Backlog do Produto restante ao longo do tempo de um plano de entrega. Um
Burndown de Sprint mede os itens do Backlog da Sprint restantes ao longo do tempo
de uma Sprint.
As Regras fazem o elo entre os eventos com duração fixa (time-boxes), os papéis e
os artefatos do Scrum. Suas regras são descritas ao longo deste documento. Por
exemplo, uma regra do Scrum diz que somente membros do Time – as pessoas
comprometidas em transformar o Backlog do Produto em um incremento - podem
falar durante uma Reunião Diária.
2.3. Papéis no Scrum
Segundo Ken Schwaber (2009. p.5), o Time Scrum é composto pelo
ScrumMaster, pelo Product Owner e pelo Time.
ヱヶ
Os membros do Time Scrum são chamados “porcos”. Qualquer outra pessoa é
chamada de “galinha”. “Galinhas” não podem dizer aos “porcos” como eles devem
fazer seu trabalho. Galinhas e porcos vêm da seguinte história:
Uma galinha e um porco estão juntos quando a galinha diz: “Vamos abrir um
restaurante!”
O porco reflete e então diz: “Como seria o nome desse restaurante?”
A galinha diz: “Presunto com Ovos!”
O porco diz: “Não, obrigado, eu estaria comprometido, mas você estaria apenas
envolvida!”
Uma dica do Ken Schwaber (2009. p.6), é de que o ScrumMaster trabalha com os
clientes e a gerência para identificar e designar um Product Owner. O ScrumMaster
ensina ao Product Owner como fazer seu trabalho. Espera-se dos Product Owners
que eles saibam como conseguir otimizar valor através do Scrum. Se eles não
souberem, consideramos o ScrumMaster responsável.
2.4. O ScrumMaster
O ScrumMaster é responsável por garantir que o Time Scrum esteja aderindo
aos valores do Scrum, às práticas e às regras. O ScrumMaster ajuda o Time Scrum
e a organização a adotarem o Scrum. O ScrumMaster educa o Time Scrum
treinando-o e levando-o a ser mais produtivo e a desenvolver produtos de maior
qualidade. O ScrumMaster ajuda o Time Scrum a entender e usar
autogerenciamento e interdisciplinaridade. No entanto, o ScrumMaster não
gerencia o Time Scrum; o Time Scrum é auto-organizável.
2.5. O Product Owner
O Product Owner é a única pessoa responsável pelo gerenciamento do Backlog
do Produto e por garantir o valor do trabalho realizado pelo Time. Essa pessoa
mantém o Backlog do Produto e garante que ele está visível para todos. Todos
sabem quais itens têm a maior prioridade, de forma que todos sabem em que se irá
trabalhar. O Product Owner é uma pessoa, e não um comitê. Podem existir comitês
ヱΑ
que aconselhem ou influenciem essa pessoa, mas quem quiser mudar a prioridade
de um item, terá que convencer o Product Owner. Empresas que adotam Scrum
podem perceber que isso influencia seus métodos para definir prioridades e
requisitos ao longo do tempo.
2.6. O Time
Ken Schwaber (2009. p.8), afirma que Times de desenvolvedores
transformam o Backlog do Produto em incrementos de funcionalidades
potencialmente entregáveis em cada Sprint. Times também são interdisciplinares:
membros do Time devem possuir todo o conhecimento necessário para criar um
incremento no trabalho. Membros do Time frequentemente possuem
conhecimentos especializados, como programação, controle de qualidade, análise
de negócios, arquitetura, projeto de interface de usuário ou projeto de banco de
dados. No entanto, os conhecimentos que os membros do Time devem
compartilhar - isto é, a habilidade de pegar um requisito e transformá-lo em um
produto utilizável - tendem a ser mais importantes do que aqueles que eles não
dividem. As pessoas que se recusam a programar porque são arquitetas ou
designers não se adaptam bem a Times.
Todos contribuem, mesmo que isso exija aprender novas habilidades ou lembrar-se
de antigas. Não há títulos em Times, e não há exceções a essa regra. Os Times
também não contém subtimes dedicados a áreas particulares como testes ou análise
de negócios.
Times também são auto-organizáveis. Ninguém - nem mesmo o ScrumMaster - diz
ao time como transformar o Backlog do Produto em incrementos de
funcionalidades entregáveis. O Time descobre por si só. Cada membro do Time
aplica sua especialidade a todos os problemas. A sinergia que resulta disso melhora
a eficiência e eficácia geral do Time como um todo.
O tamanho ótimo para um Time é de sete pessoas mais ou menos duas pessoas.
Quando há menos do que cinco membros em um Time, há menor interação e,
como resultado, há menor ganho de produtividade. Mais do que isso, o time poderá
encontrar limitações de conhecimento durante partes da Sprint e não ser capaz de
ヱΒ
entregar uma parte pronta do produto. Se há mais do que nove membros, há
simplesmente a necessidade de muita coordenação. Times grandes geram muita
complexidade para que um processo empírico consiga gerenciar. No entanto, temos
encontrado alguns Times bem-sucedidos que excederam os limites superior e
inferior dessa faixa de tamanhos. O Product Owner e o ScrumMaster não estão
incluídos nessa conta, a menos que também sejam porcos.
A composição do Time pode mudar ao final da Sprint. Toda vez que o Time muda,
a produtividade ganha através da auto-organização é reduzida. Deve-se tomar
cuidado ao mudar a composição do Time.
2.7. Eventos
Segundo Ken Schwaber (2009. p.9), Os Eventos com Duração Fixa (Time-
Boxes) no Scrum são a Reunião de Planejamento da Versão para Entrega, a Sprint,
a Reunião de Planejamento da Sprint, a Revisão da Sprint, a Retrospectiva da
Sprint e a Reunião Diária. Nesse estudo, abordaremos a Sprint e a Reunião diária.
2.8. A Sprint
A Sprint é uma iteração. Sprints são eventos com duração fixa. Durante a
Sprint, o ScrumMaster garante que não será feita nenhuma mudança que possa
afetar a Meta da Sprint. Tanto a composição do time quanto as metas de qualidade
devem permanecer constantes durante a Sprint. As Sprints contêm e consistem na
reunião de Planejamento de Sprint, o trabalho de desenvolvimento, a Revisão da
Sprint e a Retrospectiva da Sprint. As Sprints ocorrem uma após a outra, sem
intervalos entre elas.
Um projeto serve para cumprir alguma função. Em desenvolvimento de software, o
projeto é utilizado para desenvolver um produto ou sistema. Cada projeto consiste
em uma definição do que será desenvolvido, um plano para desenvolvê-lo, o
trabalho realizado de acordo com o plano e o produto resultante. Cada projeto
possui um horizonte, que é o período de tempo para o qual o plano é válido. Se o
horizonte for longo demais, a definição poderá ter mudado, variáveis demais
poderão ter surgido, o risco poderá ser grande demais etc. Scrum é um framework
ヱΓ
para projetos cujo horizonte não é superior ao período de um mês, onde já há
complexidade suficiente tal que um horizonte mais longo seria arriscado demais. A
previsibilidade do projeto deve ser controlada pelo menos a cada mês, e o risco de
que o projeto saia de controle ou se torne imprevisível é contido pelo menos a cada
mês.
2.9. Reunião Diária Cada time se encontra diariamente para uma reunião de 15 minutos chamada
Reunião Diária. Essa reunião é sempre feita no mesmo horário e no mesmo local
durante as Sprints.
As Reuniões Diárias melhoram a comunicação, eliminam outras reuniões,
identificam e removem impedimentos para o desenvolvimento, ressaltam e
promovem a tomada rápida de decisões e melhoram o nível de conhecimento de
todos acerca do projeto.
O ScrumMaster garante que o Time realize essa reunião. O Time é responsável por
conduzir a Reunião Diária. O ScrumMaster ensina o time a manter a Reunião Diária
com curta duração, reforçando as regras e garantido que as pessoas falem
brevemente. O ScrumMaster também enfatiza a regra de que galinhas não estão
autorizadas a falar e nem a interferir de modo algum na Reunião Diária.
A Reunião Diária não é uma reunião de status. Ela é só para as pessoas que estão
transformando os itens do Backlog do Produto em um incremento (o Time), e para
mais ninguém. O Time se comprometeu com uma Meta da Sprint, e a esses itens do
Backlog do Produto. A Reunião Diária é uma inspeção do progresso na direção da
Meta da Sprint (as três perguntas). Geralmente acontecem reuniões subsequentes
para realizar adaptações ao trabalho que está por vir na Sprint. A intenção é otimizar
a probabilidade de que o Time alcance sua Meta. Essa é uma reunião fundamental de
inspeção e adaptação no processo empírico do Scrum.
ヲヰ
2.10. Backlog do Produto
Segundo Ken Schwaber (2009. p.16), os requisitos para o produto que o(s)
Time(s) está(ão) desenvolvendo estão listados no Backlog do Produto. O Product
Owner é o responsável pelo Backlog do Produto, por seu conteúdo, por sua
disponibilidade e por sua priorização. O Backlog do Produto nunca está completo. A
seleção inicial para o seu desenvolvimento somente mostra os requisitos
inicialmente conhecidos e melhor entendidos. O Backlog do Produto evolui à
medida que o produto e o ambiente em que ele será usado evoluem. O Backlog é
dinâmico, no sentido de que ele está constantemente mudando para identificar o que
o produto necessita para ser apropriado, competitivo e útil. Enquanto existir um
produto, o Backlog de Produto também existirá.
O Backlog do Produto representa tudo que é necessário para desenvolver e lançar
um produto de sucesso. É uma lista de todas as características, funções, tecnologias,
melhorias e correções de defeitos que constituem as mudanças que serão efetuadas
no produto para versões futuras. Os itens do Backlog do Produto possuem os
atributos de descrição, prioridade e estimativa. A prioridade é determinada por risco,
valor e necessidade. Há diversas técnicas para dar valor a esses atributos.
O Backlog do Produto é ordenado por prioridade. O Backlog do Produto de mais
alta prioridade leva a atividades de desenvolvimento imediatas. Quanto mais alta sua
prioridade, mais urgente ele é, mais se pensou sobre ele e há mais consenso no que
diz respeito ao seu valor. O Backlog de mais alta prioridade é mais claro e possui
mais informações detalhadas do que o Backlog de prioridade mais baixa. Fazem-se
melhores estimativas quando baseadas em uma maior clareza e em mais detalhes.
Quanto mais baixa a prioridade, menor é o nível de detalhe, até que mal se consiga
entender o item.
À medida que um produto é utilizado, que seu valor aumenta e que o mercado
fornece feedback, o Backlog do Produto torna-se uma lista maior e mais
aprofundada. Os requisitos nunca param de mudar.
ヲヱ
CAPÍTULO III
COMPRAS NO SERVIÇO PÚBLICO
3. Considerações Iniciais
Segundo Viana (2010, p. 249), nas empresas estatais e autárquicas, como
também no serviço público em geral, ao contrário da iniciativa privada, as aquisições de
qualquer natureza obedecem à Lei nº 8.666/93, motivo pelo qual tornam-se totalmente
transparentes. Assim, a diferença entre os tipos de compras é a formalidade no serviço
público e a informalidade na iniciativa privada. Independentemente dessa
particularidade, os procedimentos são praticamente idênticos.
Em virtude dos aspectos jurídicos que envolvem os instrumentos legais, este
Capítulo procura sintetizá-los em seus aspectos mais importantes e significativos.
3.1 Licitação: Conceito
É o procedimento administrativo pelo qual a administração Pública, em
qualquer de seus níveis, prevendo comprar materiais e serviços, realizar obras, alienar
ou locar bens, segundo condições estipuladas previamente, convoca interessados para
apresentação de propostas, a fim de selecionar a que se revele mais conveniente em
função de parâmetros preestabelecidos e divulgados.
3.2. Finalidade
A licitação tem por finalidade propiciar igualdade de oportunidades entre
aqueles que desejam contratar com a Administração Pública, nos padrões previamente
definidos, sempre como importante fator de eficiência e moralidade nos negócios
públicos.
ヲヲ
A licitação destina-se a garantir a observância do princípio constitucional de
avaliar e selecionar a proposta mais vantajosa para a Administração e será processada e
julgada em estrita conformidade com os princípios básicos de legalidade, de
impessoalidade, de moralidade, de igualdade, publicidade, de probidade administrativa,
da vinculação ao instrumento convocatório, do julgamento objetivo e dos que lhe forem
correlatos.
3.3. Princípios
Para não descaracterizar e invalidar seu trabalho seletivo, o Instituto da
Licitação deve ser pautado nos seguintes princípios básicos: igualdade, publicidade,
probidade administrativa, procedimento formal, sigilo na apresentação das propostas,
vinculação ao instrumento convocatório, julgamento objetivo, adjudicação compulsória
ao vencedor.
3.4. Objeto da Licitação
A finalidade precípua da licitação será sempre a obtenção de seu objeto, ou seja,
um serviço, uma compra, uma alienação, uma locação, uma concessão ou uma
permissão, nas melhores condições para o Poder Público. O objeto deve ser
convenientemente definido no instrumento convocatório, sob pena de se dificultar ou
até mesmo impedir a execução do conseqüente contrato.
A definição do objeto é condição indispensável de legitimidade da licitação,
sem a qual não pode prosperar o procedimento licitatório, qualquer que seja a
modalidade sob pena de tornar-se inviável a formulação de ofertas, bem como seu
julgamento, e irrealizável o contrato subseqüente.
A inexistência do projeto básico ou termo de referência acarretará a anulação
dos contratos realizados e a responsabilização de quem lhes tenha dado.
Entre as disposições específicas para a contratação de obras e serviços, em seu
art. 6º, a Lei nº 8.666/93 conceitua os projetos básico e executivo a serem seguidos:
ヲン
a. projeto básico: é o conjunto de elementos que define a obra ou serviço, ou o
complexo de obras ou serviços objeto da licitação e que possibilita a
estimativa de seu custo final e prazo de execução;
b. projeto executivo: é o conjunto de elementos necessários e suficientes à
execução correta da obra.
3.5. Obra Em sentido administrativo amplo, obra é toda realização material a cargo da
administração executada diretamente por seus órgãos ou indiretamente por seus
contratos e legados.
Consoante o art. 6º, inciso I, da lei nº 8.666/93, a conceituação de obra abrange
toda construção, reforma, fabricação, recuperação ou ampliação, realizada por execução
direta ou indireta.
Todas essas realizações são obras, só podendo ser licitadas com projeto básico,
executadas com projeto executivo.
3.6. Serviço
Serviço, para fins de licitação, é toda atividade prestada para a administração
para o atendimento de suas necessidades ou de seus administrados. O que caracteriza o
serviço e o distingue da obra é a predominância da atividade sobre o material
empregado.
Ao conceituar serviço, a lei enumera exemplificadamente os mais freqüentes,
como demolição, fabricação, conserto, instalação, montagens, operação, reparação,
manutenção, transportes, comunicação ou trabalhos técnico-profissionais.
Para fins de licitação, é necessário distinguir os serviços comuns, os serviços
técnico-profissionais generalizados e técnico-profissionais especializados.
ヲヴ
3.7. Bens
Na licitação para compra de bens, a Administração deve especificar o objeto a
ser adquirido, indicando, para isso, a qualidade e a quantidade a ser comprada, bem
como as condições em que deseja adquirir. A perfeita caracterização do objeto da
compra é essencial para possibilitar a correta formulação das propostas e o
oferecimento das vantagens do negócio.
A compra pode ser a vista ou a prazo, com entrega total ou parcelada, sendo
sempre realizada por intermédio de um contrato bilateral perfeito, comunicativo e
oneroso, isto é, com obrigações recíprocas, com equivalência nessas obrigações e com
pagamento do preço, como contraprestação da transferência do domínio da coisa.
A Lei nº 8.666/93 exige a adequada caracterização do objeto da compra e a
indicação dos recursos financeiros para seu pagamento, adotando, ainda, além das
vantagens semelhantes às do setor privado, o princípio da padronização, o sistema de
registro de preços e mais recentemente através do regime diferenciado de contratações
públicas – RDC.
3.8. Limites de valor para licitação A Tabela Limites de Valor para Licitação, ilustrada na Figura 3.1, demonstra os
diferentes valores praticados a partir de 28-5-1998 e de acordo com cada modalidade.
Figura 4 - Limites de valor de licitação segundo Viana, João José (2010, p.255).
ヲヵ
CAPÍTULO IV
MELHORES PRÁTICAS DA GERÊNCIA DE PROJETOS
4. Considerações Iniciais
O gerenciamento de projetos¹ como área de conhecimento começou a ser
utilizado com mais relevância a partir da década de 70 e hoje é apontado por muitas
organizações como uma atividade importante para a alavancagem de resultados.
Nesse contexto, merece destaque uma unidade organizacional comumente implantada
para contribuir no aumento de eficiência e eficácia dos projetos, o Escritório de
Gerenciamento de Projetos. Já no setor público, a implantação de práticas de
gerenciamento de projetos é um desafio que através desse trabalho ambicionamos trilhar
o caminho a ser seguido pelos gestores de compras dos diversos órgãos da
Administração Pública.
4.1. Gerenciamento de Projetos Embora o gerenciamento de projetos já ocorra desde a antiguidade, seu
tratamento como área de conhecimento é recente. Sua origem ocorreu na área militar no
período pós-Segunda Guerra e por anos esteve relacionado a projetos espaciais, de
armamentos e a grandes obras de engenharia civil. Foi a partir dos anos 70 que o
gerenciamento de projetos começou a ser utilizado em diversos setores da economia.
Hoje, o gerenciamento de projetos é utilizado por organizações dos mais
diversos ramos de atividade, inclusive na área pública, e tem sido de fundamental
importância para transformar o planejamento em resultados, otimizar a alocação de
recursos, diminuir as surpresas, trazendo maior eficiência à gestão de projetos. Em 1969
foi criado nos EUA o Project Management Institute (PMI), uma entidade que congrega
os profissionais em gerenciamento de projetos – Project Management Professional
(PMP) – e dissemina um conjunto de conhecimentos reconhecidos como boas práticas
ヲヶ
na área, principalmente através de sua publicação mais referenciada pelos profissionais
da área, o Project Management Body of Knowledge (PMBOK).
4.2. Gerenciamento de Projetos na administração pública
Hoje, o gerenciamento de projetos é utilizado por organizações dos mais
diversos ramos de atividade, inclusive na área pública, e tem sido de fundamental
importância para transformar o planejamento em resultados, otimizar a alocação de
recursos, diminuir as surpresas, trazendo maior eficiência à gestão de projetos.
A utilização de boas práticas em gerenciamento de projetos no setor público é
ainda mais recente. Porém, à exigência crescente dos cidadãos por serviços públicos de
qualidade reforçam a importância desta prática em todas as esferas do poder público.
1 Projeto é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo. E
gerenciamento de projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas às
atividades do projeto a fim de atender aos seus requisitos (PMI, 2004).
ヲΑ
4.3. Gerenciamento de aquisições do projeto
Segundo o guia (PMBOK®, Terceira Edição pdf, 2004, p. 269) o gerenciamento
de aquisições do projeto inclui os processos para comprar ou adquirir os produtos,
serviços ou resultados necessários de fora da equipe do projeto para realizar o trabalho.
Este capítulo apresenta duas perspectivas de aquisição. A organização pode ser o
comprador ou o fornecedor do produto, serviço ou resultados sob um contrato.
O gerenciamento de aquisições do projeto inclui os processos de gerenciamento de
contratos e de controle de mudanças necessários para administrar os contratos ou pedidos
de compra emitidos por membros da equipe do projeto autorizados.
O gerenciamento de aquisições do projeto também inclui a administração de
qualquer contrato emitido por uma organização externa (o comprador) que está
adquirindo o projeto da organização executora (o fornecedor) e a administração de
obrigações contratuais estabelecidas para a equipe do projeto pelo contrato.
A Figura 4-1 fornece uma visão geral dos processos de gerenciamento de
aquisições do projeto, que segundo o guia (PMBOK®, Quinta Edição pdf, 2013, p. 355)
os processos de gerenciamento de aquisições do projeto incluem os seguintes itens:
12.1 Planejar o gerenciamento das aquisições— O processo de documentação das
decisões de compras do projeto, especificando a abordagem e identificando
fornecedores em potencial.
12.2 Conduzir as aquisições—O processo de obtenção de respostas de fornecedores,
seleção de um fornecedor e adjudicação de um contrato.
12.3 Controlar as aquisições—O processo de gerenciamento das relações de
aquisições, monitoramento do desempenho do contrato e realizações de mudanças e
correções nos contratos, conforme necessário.
12.4 Encerrar as aquisições—O processo de finalizar cada uma das aquisições do
projeto.
ヲΒ
Esses processos interagem entre si e também com os processos em outras áreas de
conhecimento. Cada processo pode envolver o esforço de uma ou mais pessoas ou de
grupos de pessoas, com base nas necessidades do projeto. Cada processo ocorre pelo
menos uma vez em todos os projetos e também em uma ou mais fases do projeto, se ele
estiver dividido em fases. Embora os processos sejam apresentados aqui como
componentes distintos com interfaces bem definidas, na prática eles se sobrepõem e
interagem de maneiras não detalhadas neste trabalho.
Os processos de gerenciamento de aquisições do projeto envolvem contratos que
são documentos legais entre um comprador e um fornecedor. Um contrato é um acordo
que gera obrigações para as partes que obriga o fornecedor a fornecer os produtos,
serviços ou resultados especificados e obriga o comprador a fornecer compensação
monetária ou outra compensação de valor. Um contrato é uma relação legal sujeita a
remediação nos tribunais. O acordo pode ser simples ou complexo e pode refletir a
simplicidade ou a complexidade das entregas. Um contrato inclui termos e condições e
pode incluir outros itens como a proposta ou publicações de marketing do fornecedor e
qualquer outra documentação em que o comprador esteja se baseando para estabelecer o
que o fornecedor deve realizar ou fornecer. É responsabilidade da equipe de
gerenciamento de projetos ajudar a adaptar o contrato às necessidades específicas do
projeto. Dependendo da área de aplicação, os contratos também podem ser chamados de
acordo, subcontrato ou pedido de compra. A maior parte das organizações possui
políticas e procedimentos documentados que definem especificamente quem pode
assinar e administrar esses acordos em nome da organização.
Embora todos os documentos do projeto estejam sujeitos a alguma forma de
análise e aprovação, a natureza de obrigação legal de um contrato geralmente significa que
estará sujeito a um processo de aprovação mais amplo. Em todos os casos, o foco
principal do processo de análise e aprovação garante que a linguagem do contrato
descreve os produtos, serviços ou resultados que irão satisfazer a necessidade do projeto
identificada. No caso de projetos importantes realizados por órgãos públicos, o processo de
análise pode incluir a revisão pública do acordo.
ヲΓ
A equipe de gerenciamento de projetos pode buscar desde o início o suporte de
especialistas nas áreas de contratação, compras e legislação. Esse envolvimento pode ser
exigido pela política de uma organização.
As diversas atividades envolvidas nos processos de gerenciamento de aquisições do
projeto compõem o ciclo de vida de um contrato. É possível evitar ou mitigar alguns
riscos identificáveis do projeto gerenciando ativamente o ciclo de vida do contrato e
redigindo cuidadosamente os termos e as condições do contrato. Assinar um contrato de
produtos ou serviços é um método de alocar a responsabilidade do gerenciamento ou de
assumir riscos potenciais.
Um projeto complexo pode envolver o gerenciamento de vários contratos ou
subcontratos simultaneamente ou em sequência. Nesses casos, o ciclo de vida de cada
contrato pode terminar durante qualquer fase do ciclo de vida do projeto. O
gerenciamento de aquisições do projeto é discutido dentro da perspectiva da relação
comprador-fornecedor. A relação comprador-fornecedor pode existir em muitos níveis em
qualquer projeto e entre organizações internas e externas à organização contratante.
Dependendo da área de aplicação, o fornecedor pode ser chamado de contratada,
subcontratada, vendedor, prestador de serviços ou distribuidor. Dependendo da posição
do comprador no ciclo de aquisição do projeto, ele pode ser chamado de cliente, usuário,
contratada principal, contratada, organização contratante, agência governamental,
solicitador de serviços ou adquirente. Durante o ciclo de vida do contrato, o fornecedor
pode ser considerado primeiramente um licitante, depois uma fonte selecionada e, em
seguida, o fornecedor ou vendedor contratado.
ンヰ
Figura 4-1 - Visão geral do gerenciamento de aquisições do projeto segundo PMBOK®, Quinta Edição (2013, p.356).
4.4. Planejar compras e aquisições
Conforme orientação do guia (PMBOK®, Terceira Edição pdf, 2004, p. 290), O
processo planejar compras e aquisições identifica quais necessidades do projeto podem
ser melhor atendidas pela compra ou aquisição de produtos, serviços ou resultados fora
da organização do projeto e quais necessidades do projeto podem ser realizadas pela
equipe do projeto durante a execução do projeto. Esse processo envolve a consideração
de como, o que, quanto, se e quando adquirir.
Quando o projeto obtém produtos, serviços e resultados exigidos para o
desempenho do projeto de fora da organização executora, os processos de planejar
compras e aquisições até Encerramento do contrato são executados para cada item a ser
comprado ou adquirido.
ンヱ
O processo planejar compras e aquisições também inclui a consideração de
possíveis fornecedores, especialmente se o comprador desejar exercer algum grau de
influência ou controle sobre as decisões de contratação. É necessário considerar também
quem é responsável por obter ou manter autorizações e licenças profissionais relevantes
que podem ser exigidas pela legislação, regulamentos ou política organizacional na
execução do projeto.
O cronograma do projeto pode influenciar significativamente o processo
planejar compras e aquisições. As decisões tomadas no desenvolvimento do plano de
gerenciamento de aquisições também podem influenciar o cronograma do projeto e estão
integradas ao desenvolvimento do cronograma, à estimativa de recursos da atividade e às
decisões de fazer ou comprar.
O processo planejar compras e aquisições inclui a análise dos riscos envolvidos em
cada decisão de fazer ou comprar; ele também inclui a análise do tipo de contrato
planejado para ser usado em relação à mitigação de riscos e à transferência de riscos para
o fornecedor.
Figura 4-2 - Planejar compras e aquisições: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®, Terceira Edição (2004, p.274).
ンヲ
4.5. Planejar contratações Planejar as contratações é o processo de obtenção de respostas de fornecedores,
seleção de um fornecedor e adjudicação de um contrato. Podemos observar que o
planejamento das contratações segundo a visão do guia (PMBOK®, Terceira Edição
pdf, 2004, p. 297), está intimamente relacionada a fase externa de uma licitação como
vimos no capítulo quatro. O principal benefício desse processo é prover o alinhamento
das expectativas internas e externas das partes interessadas através de acordos
estabelecidos. As entradas, ferramentas e técnicas, e saídas desse processo estão
ilustrados na Figura 4-3.
Figura 4-3 - Planejar contratações: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®, Terceira Edição (2004, p.281). 4.6. Solicitar respostas de fornecedores
O processo solicitar respostas de fornecedores obtém respostas, como cotações e
propostas, de possíveis fornecedores sobre como os requisitos do projeto podem ser
alcançados. Os possíveis fornecedores, normalmente sem custos diretos para o projeto ou o
comprador, gastam a maior parte do esforço real nesse processo. Essa fase do processo
refere-se a pesquisa de mercado pré licitatória que é de extrema importância para se estabelecer
o preço estimado pela Administração, caso essa pesquisa seja feita sem muitos cuidados pode-
se obter um preço abaixo do que se pratica no mercado, frustrando assim a licitação ou super
estimado esse preço ocasionando dano ao erário.
ンン
4.6.1. Ferramentas e técnicas
As reuniões com licitantes são reuniões entre o comprador e todos os
fornecedores em potencial antes de submeter uma licitação ou proposta. Elas são
usadas para assegurar que todos os fornecedores em potencial tenham um
entendimento claro e comum da aquisição (tanto dos requisitos técnicos quanto dos
contratuais) e que nenhum licitante receba um tratamento preferencial. Para serem
justos, os compradores devem ter muito cuidado para assegurar que todos os
fornecedores ouçam todas as perguntas de cada fornecedor em potencial e todas as
respostas do comprador.
Figura 4-6 - Solicitar respostas de fornecedores: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®, Terceira Edição (2004, p.284).
4.7. Selecionar fornecedores
Segundo a visão do guia (PMBOK®, Terceira Edição pdf, 2004, p. 286), O
processo selecionar fornecedores recebe cotações ou propostas e aplica critérios de
avaliação, conforme aplicável, para selecionar um ou mais fornecedores que sejam
qualificados e aceitáveis como um fornecedor. Muitos fatores como os seguintes podem
ser avaliados no processo de decisão de seleção de fornecedores: Preço ou custo podem ser
os principais determinantes para um item comercial padrão, mas o menor preço
proposto talvez não seja o menor custo se o fornecedor se mostrar incapaz de fornecer
os produtos, serviços ou resultados no momento oportuno.
ンヴ
As propostas muitas vezes são separadas em seções técnicas (abordagem) e
comerciais (preço), sendo que cada uma delas é avaliada separadamente. Às vezes, as
seções de gerenciamento são exigidas como parte da proposta e também precisam ser
avaliadas. Várias fontes poderiam ser exigidas para produtos, serviços e resultados
críticos para mitigar riscos que podem ser associados a problemas, como cronogramas
de entrega e requisitos de qualidade. Os custos potencialmente mais altos associados a
esses vários fornecedores, inclusive alguma perda de possíveis descontos de quantidade
e problemas de substituição e manutenção, são considerados.
As ferramentas e técnicas descritas aqui podem ser usadas sozinhas ou
combinadas ao processo selecionar fornecedores. Por exemplo, um sistema de
ponderação pode ser usado para selecionar um único fornecedor que será solicitado a
assinar um contrato padrão e estabelecer uma sequência de negociação classificando
todas as propostas pela média ponderada atribuída a cada proposta.
Nos principais itens de aquisição, é possível repetir o processo total de
solicitação de respostas de fornecedores e de avaliação de respostas de fornecedores.
Uma pequena lista de fornecedores qualificados pode ser estabelecida com base em uma
proposta preliminar. Uma avaliação mais detalhada poderá então ser conduzida com base
em uma proposta mais detalhada e abrangente solicitada dos fornecedores presentes na
lista pequena.
Figura 4-7 Selecionar fornecedores: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®, Terceira
Edição (2004, p.287).
ンヵ
4.8 Administração de contratos
Conforme o (PMBOK®, Terceira Edição pdf, 2004, p. 291), O comprador e o
fornecedor administram o contrato com objetivos semelhantes. Cada uma das partes
garante que tanto ela quanto a outra parte atendem às suas obrigações contratuais e que
seus próprios direitos legais estão protegidos. O processo Administração de contrato
garante que o desempenho do fornecedor atende aos requisitos contratuais e que o
comprador atua de acordo com os termos do contrato. Em projetos maiores com vários
fornecedores de produtos, serviços e resultados, um aspecto importante da administração
de contrato é o gerenciamento de interfaces entre os diversos fornecedores.
A natureza legal da relação contratual torna imperativo que a equipe de
gerenciamento de projetos esteja profundamente a par das implicações legais das ações
tomadas durante a administração de qualquer contrato. Devido às considerações legais,
muitas organizações tratam a administração de contrato como uma função
administrativa separada da organização do projeto. Embora um administrador de
contratos possa estar na equipe do projeto, essa pessoa normalmente se reporta para um
supervisor de um departamento diferente. Isso geralmente será verdadeiro se a
organização executora for também o fornecedor do projeto para um cliente externo.
A administração de contrato inclui a aplicação dos processos de gerenciamento de
projetos adequados às relações contratuais e a integração das saídas desses processos ao
gerenciamento geral do projeto. Essa integração ocorrerá com frequência em vários níveis
quando existirem diversos fornecedores e muitos produtos, serviços ou resultados
envolvidos. Os processos de gerenciamento de projetos aplicados incluem, mas não se
limitam a:
a) orientar e gerenciar a execução do projeto para autorizar o trabalho
da contratada no tempo adequado
b) relatório de desempenho para monitorar os custos, o cronograma e
o desempenho técnico da contratada
c) realizar o controle da qualidade para inspecionar e verificar a
adequação do produto da contratada
ンヶ
d) controle integrado de mudanças para garantir que as mudanças
sejam aprovadas corretamente e que todas as pessoas que precisam conhecê-las
estão cientes dessas mudanças
e) monitoramento e controle de riscos para garantir que os riscos
sejam mitigados.
A administração de contrato também possui um componente de gerenciamento
financeiro que envolve o monitoramento de pagamentos ao fornecedor. Isso garante que
as condições de pagamento definidas no contrato sejam atendidas e que a compensação
ao fornecedor esteja ligada ao seu progresso, conforme definido no contrato.
O processo Administração de contrato analisa e documenta a qualidade do
desempenho atual ou passado de um fornecedor com base no contrato e nas ações
corretivas estabelecidas. Além disso, o desempenho é documentado como base para
futuras relações com o fornecedor. A avaliação do desempenho do fornecedor pelo
comprador é executada principalmente para confirmar a competência ou a falta de
competência do fornecedor em relação à realização de trabalhos semelhantes no projeto
ou em outros projetos. Avaliações semelhantes também são executadas quando
necessário para confirmar que um fornecedor não está atendendo às suas obrigações
contratuais e quando o comprador considera a realização de ações corretivas.
A administração do contrato inclui o gerenciamento de uma rescisão do trabalho
contratado por algum motivo, por conveniência ou por descumprimento das obrigações
de acordo com a cláusula de término de vigência do contrato. Os contratos podem ser
aditados a qualquer momento antes do seu encerramento por acordo mútuo, em
conformidade com os termos de controle de mudanças do contrato. Talvez esses
aditamentos não beneficiem sempre da mesma forma o fornecedor e o comprador.
ンΑ
Figura 4-8 - Administração de contrato: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®, Terceira Edição (2004, p.291).
4.9. Encerramento do contrato
Segundo o guia (PMBOK®, Terceira Edição pdf, 2004, p. 295), O processo
Encerramento do contrato dá suporte ao processo encerrar o projeto, pois envolve a
confirmação de que todo o trabalho e as entregas foram aceitáveis. O processo
Encerramento do contrato também envolve atividades administrativas, como a
atualização de registros para refletir resultados finais e o arquivamento dessas
informações para uso futuro. O encerramento do contrato aborda cada contrato aplicável
ao projeto ou a uma de suas fases. Em projetos com várias fases, o prazo contratual pode
aplicar-se somente a uma determinada fase do contrato. Nesses casos, o processo
Encerramento do contrato encerra o(s) contrato(s) aplicável(eis) a essa fase do projeto.
Reclamações não resolvidas podem estar sujeitas a processo judicial após o encerramento
do contrato. Os termos e condições do contrato podem recomendar procedimentos
específicos para o encerramento do contrato.
A rescisão de um contrato é um caso especial de encerramento do contrato e
pode resultar de um acordo mútuo entre as partes ou de descumprimento das
obrigações de uma das partes. Os direitos e responsabilidades das partes no caso de uma
rescisão estão incluídos em uma cláusula de término de vigência do contrato. Com base
nesses termos e condições do contrato, o comprador pode ter o direito de finalizar o
ンΒ
contrato inteiro ou uma parte do projeto, por qualquer motivo ou conveniência, a
qualquer momento. No entanto, com base nesses termos e condições do contrato, talvez
o comprador precise compensar o fornecedor pelos seus preparativos e por qualquer
trabalho terminado e aceito relacionado à parte finalizada do contrato.
Figura 4-9 - Encerramento do contrato: Entradas, ferramentas e técnicas, e saídas segundo PMBOK®,
Terceira Edição (2004, p.296).
ンΓ
CONCLUSÃO
Neste trabalho foi possível constatar que é possível adotar o Scrum no
gerenciamento das aquisições, embora tenha sido desenvolvido para o gerenciamento
de projetos de software, mas ainda existe pouca maturidade nos setores públicos quanto
a adoção das melhores práticas do gerenciamento de projetos. A grande maioria das
administrações confirma a importância do gerenciamento de projetos, entretanto ainda o
utiliza de forma empírica e/ou descoordenada.
Podemos constatar que as organizações públicas, devido a sua cultura requerem
um gerenciamento de projetos adaptado as limitações impostas pela lei de licitações,
diferentemente do gerenciamento de projetos executado por empresas privadas. No
entanto, as limitações impostas pela lei não devem ser vistas como barreiras
intransponíveis, pois a necessidade de se gerenciar um projeto de modo eficaz e
eficiente exige a busca de adaptações dos processos de gerenciamento a esta realidade.
Mas, para que isso ocorra é preciso mudar a cultura estatal, criar estruturas, capacitar
profissionais, é importante a adoção padronizada de padrões, políticas e procedimentos
integrados para a gestão de projetos governamentais. E ainda, a utilização efetiva dos
recursos de tecnologia e comunicação como peça fundamental para essa gestão efetiva.
Enfim, trata-se de um grande desafio, e que não pode ser implementado por
apenas uma única área de um órgão governamental, e sim por todas as diversas áreas
componentes do órgão da administração governamental interessado na adoção das
melhores práticas da gerência de projetos.
ヴヰ
BIBLIOGRAFIA
CLELAND, David I. Gerência de Projetos, revisão técnica de Carlos A. C. Salles Jr. –
Rio de Janeiro. Reichmann & Affonso, 2002.
OLIVEIRA, Gean. Gerenciamento de Compras Governamentais – Monografia de Pós
Graduação em Gestão de Compras e Suprimentos, AVM Faculdade Integrada – Rio de
Janeiro, 2015.
PMI. Um guia do conjunto de conhecimentos em gerenciamento de projetos: Guia
PMBOK. 3. ed. Newton Square, PA: Project Management Institute, 2004.
PMI, Project Management Institute. A Guide to the Project Management Body of
Knowledgment (PMBOK Guide). Project Management Institute, 2013.
SUTHERLAND, Jeff. Scrum: A Arte de fazer o dobro do trabalho na metade do tempo;
tradução de Natalie Gerhart. – São Paulo. LeYa, 2014.
VIANA, João José. Administração de Materiais: um enfoque prático. São Paulo. Atlas,
2010.
ヴヱ
WEBGRAFIA
SCRUM HALF. <URL:http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-
scrum-glossario> data de acesso: 16/02/2016.
ヴヲ
ÍNDICE
FOLHA DE ROSTO 02
AGRADECIMENTO 03
DEDICATÓRIA 04
RESUMO 05
METODOLOGIA 06
SUMÁRIO 07
INTRODUÇÃO 08
CAPÍTULO I 09
FUNDAMENTOS DA GERÊNCIA DE PROJETOS
1 – Considerações iniciais 09
1.1 – Características da gerência de projetos 09
1.2 - Projeto Versus Operações 10
1.3 - Contribuições da Gerência de Projetos 11
1.4 - Processos de Gerência de Projetos 11
1.5 – Áreas do gerenciamento de projetos 12
CAPÍTULO II 13
FUNDAMENTOS DO SCRUM
2 – Considerações iniciais 13
2.1 – Teoria do Scrum 13
2.1.1 – O Primeiro Pilar é a Transparência 13
2.1.2 – O Segundo Pilar é a Inspeção 14
2.1.3 - O Terceiro Pilar é a Adaptação 14
2.2 – Conteúdo do Scrum 14
ヴン
2.3 – Papéis do Scrum 15
2.4 – O ScrumMaster 16
2.5 – O Product Owner 16
2.6 – O Time 17
2.7 – Eventos 18
2.8 – A Sprint 18
2.9 – Reunião Diária 19
2.10 – Backlog do Produto 20
CAPÍTULO III 21
AQUISIÇÕES NO SERVIÇO PÚBLICO
3 – Considerações Iniciais 21
3.1 – Licitações: Conceito 21
3.2 – Finalidade 21
3.3 – Princípios 22
3.4 – Objeto da Licitação 22
3.5 - Obra 23
3.6 – Serviço 23
3.7 – Bens 24
3.8 – Limites de valor de licitação 24
CAPÍTULO IV 25
MELHORES PRÁTICAS DA GERÊNCIA DE PROJETOS
4 – Considerações Iniciais 25
ヴヴ
4.1 – Gerenciamento de Projetos 25
4.2 – Gerenciamento de Projetos na administração pública 26
4.3 – Gerenciamento de aquisições em projetos 27
4.4 – Planejar compras e aquisições 30
4.5 – Planejar contratações 32
4.6 – Solicitar respostas de fornecedores 32
4.6.1 – Ferramentas e técnicas 33
4.7 – Selecionar fornecedores 33
4.8 – Administração de contratos 35
4.9 – Encerramento de contratos 37
CONCLUSÃO 39
BIBLIOGRAFIA 40
WEBGRAFIA 41
ÍNDICE 42
ÍNDICE DE FIGURAS 45
ANEXOS 46
ヴヵ
ÍNDICE DE FIGURAS
Figura 1 - Especificidades do Projetos Versus Operações 10
Figura 2 - Relacionamento entre os grupos de processos 12
Figura 3 - Áreas de gerenciamento de projetos 12
Figura 4 - Limites de valor de licitação 24
Figura 4-2 - Planejar compras e aquisições 31
Figura 4-3 - Planejar contratações: Entradas, ferramentas e técnicas, e saídas 32
Figura 4-6 - Solicitar respostas de fornecedores 33
Figura 4-7 - Selecionar fornecedores: Entradas, ferramentas e técnicas, e saídas 34
Figura 4-8 - Administração de contrato: Entradas, ferramentas e técnicas, e saídas 37
Figura 4-9 - Encerramento do contrato: Entradas, ferramentas e técnicas, e saídas 38
ヴヶ
ANEXOS
Índice de anexos
Anexo 1 Aprendendo os Termos do Scrum - Glossário
ヴΑ
ANEXO 1
INTERNET
http://blog.myscrumhalf.com/2011/08/aprendendo-os-termos-scrum-glossario
Aprendendo os Termos Scrum – Glossário Postado em 3 de agosto de 2011 por Ester Lima de Campos, M.Sc., CSP, CSPO e CSM, Scrum Master at GPE Ltda.
Burndown Chart – O objetivo de um gráfico burndown é apresentar a porção de trabalho finalizada em comparação com o trabalho planejado. Esse gráfico apresenta duas linhas: uma representando o trabalho planejado caso fosse executado de maneira uniforme ao longo da Sprint e outra apresentando o trabalho realmente já realizado pela Equipe de Desenvolvimento. É comum a Equipe de Desenvolvimento usar esse gráfico ao longo da Sprint, para medir os pontos das histórias finalizadas ao longo dos dias da Sprint e ter uma visibilidade do ritmo, verificando se está adequado para atingir a meta da sprint, cumprindo com o que foi planejado.
Burnup Chart – O objetivo de um gráfico burnup é apresentar a evolução do trabalho em direção ao produto final. Nesse gráfico são traçadas duas linhas, uma apresentando a evolução do Product Backlog (esse pode aumentar a medida que o projeto vai sendo desenvolvido) e a outra apresentando a evolução do que já foi realizado pela equipe durante as Sprints já realizadas. Ele dá a visibilidade do andamento do projeto.
Dono do Produto – Ver Product Owner.
Equipe de Desenvolvimento - É um dos três papéis no Scrum. A equipe de desenvolvimento é a responsável pelo desenvolvimento da Sprint, trabalhando nas Tarefas de cada História para a finalização dos trabalhos.
Estimativa – Pontuação estimada do esforço necessário para implementação de uma História. As estimativas podem ser em story points, seguindo a pontuação usada no planing poker.
Histórias - São itens do Product Backlog que representam parte do produto a ser implementado. As Histórias devem conter uma descrição detalhada do que deve ser implementado.
História Preparada - É uma História que já está preparada para ser estimada pela Equipe de Desenvolvimento, a fim de poder ser incluída em uma Sprint. A definição de "preparada" é elaborada em comum acordo entre Equipe de Desenvolvimento e PO.
História Pronta – Uma "História Pronta" é uma História executada na Sprint, pronta para ser apresentada ao PO, para a sua avaliação. A história pronta é apresentada ao PO
ヴΒ
na Reunião de Revisão, quando o mesmo pode aceitá-la ou não. A definição de "pronta" é elaborada em comum acordo entre Equipe de Desenvolvimento e PO.
Impedimentos - Problemas que surgem durante a Sprint e que impedem a equipe de trabalhar em ou finalizar alguma História. Os impedimentos são responsabilidades do Scrum Master, que deve providenciar a remoção dos mesmos.
Meta da Sprint – A meta da Sprint é o que o PO espera conseguir ao final da Sprint e que deve orientar o trabalho e os esforços da Equipe de Desenvolvimento durante toda a Sprint.
Planning Poker -Técnica de para a estimação das Histórias do Product Backlog. É baseada no uso de cartas, como no poker, que tem a seguinte numeração, adaptada da Série de Fibonacci: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100.
Pontos de História – Representa em pontos o esforço da Equipe de Desenvolvimento para realizar uma História. Ver quais são os pontos em Planning Poker.
Product Backlog – Lista de itens, ou Histórias, que devem ser implementados para a criação do produto desejado ou desenvolvimento do projeto.
Product Owner – É um dos três papéis no Scrum. O Product Owner é o responsável pelo Product Backlog. Ele que define e prioriza as funcionalidades desejadas para o produto, ou as atividades necessárias ao projeto, descrevendo-as em forma de Histórias no Product Backlog.
Quadro de Tarefas – Artefato utilizado pela equipe para apresentar o trabalho que deve ser implementado pela Equipe de Desenvolvimento. A divisão mais comum desse quadro se dá como uma matriz de 3 colunas que são: Tarefas a Fazer, Tarefas em andamento e Tarefas Concluídas; e onde cada linha representa uma História do Sprint Backlog. No início da Sprint todas as Tarefas estão concentradas na primeira coluna (Tarefas a fazer) e é esperado que ao final da Sprint todas as Tarefas estejam na última coluna (Tarefas concluídas). O quadro de tarefas dá a visibilidade do andamento dos trabalho ao longo da Sprint, pois é atualizado diariamente ou toda vez que um membro da Equipe de Desenvolvimento assume a responsabilidade por dar andamento a uma Tarefa de uma História.
Reunião de Planejamento 1
Reunião realizada no início da Sprint, para planejá-la.
Com participação obrigatória do Product Owner, do Scrum Master e da Equipe de Desenvolvimento.
Duração máxima de 2 horas para Sprints de Timebox de 2 semanas.
Nessa reunião são apresentadas as Histórias Preparadas na sequência em que se encontram no Product Backlog, e Equipe de Desenvolvimento e Product Owner discutem a respeito de cada uma dessas Histórias, para esclarecimento dos detalhes do que deve ser implementado e, se necessário, permitir o ajuste dos pontos estimados pela Equipe de Desenvolvimento.
ヴΓ
Ao final da reunião temos a Sprint criada com data de início e término, respeitando o Timebox das Sprints e temos selecionadas as Histórias que farão parte do Sprint Backlog. Normalmente as Histórias são incluídas baseadas nos pontos estimados e limitadas à velocidade da Equipe de Desenvolvimento.
Reunião de Planejamento 2
Ocorre após a Reunião de Planejamento 1.
Reunião de planejamento dos trabalhos da Equipe de Desenvolvimento na Sprint.
Duração máxima de 2 horas para Sprints de Timebox de 2 semanas.
Nessa reunião a Equipe divide cada História em Tarefas.
Essas tarefas podem ser anotadas em post-its e fixadas no Quadro de Tarefas para maior transparência do andamento dos trabalhos ao longo da Sprint. Ou lançadas em software que suporte o Scrum.
Reunião Diária
Reunião realizada diariamente, preferencialmente no início da manhã ou ao final do dia.
Com participação da Equipe de Desenvolvimento e do Scrum Master.
A reunião é realizada com todos os participantes de pé.
Com duração máxima de 15 minutos.
O objetivo dessa reunião é comunicar o andamento dos trabalhos deixando-o transparente para todos da Equipe de Desenvolvimento.
É uma reunião curta para manter o foco na transparência e não na discussão técnica de problemas e soluções.
É uma reunião onde os membros da equipe assumem compromissos com os demais. Respondendo a 3 perguntas:
1. O que você fez ontem?
2. O que você fará hoje?
3. Há impedimentos no seu caminho?
Reunião de Retrospectiva
Realizada após a Reunião de Revisão.
Com participação da Equipe de Desenvolvimento e Scrum Master. O PO participa apenas se convidado.
Duração máxima de 2 horas para Sprints de Timebox de 2 semanas.
O objetivo é inspecionar a Sprint encerrada para permitir a adaptação.
ヵヰ
Nessa reunião a Equipe deve levantar os pontos positivos e negativos da Sprint e ao final da discussão deve-se ter como resultado final uma lista de ações para melhoria do processo como um todo.
Reunião de Revisão
Realizada ao final de cada Sprint.
Com participação da Equipe de Desenvolvimento, Scrum Master e PO.
Duração máxima de 2 horas para Sprints de Timebox de 2 semanas.
O objetivo dessa reunião é a Equipe de Desenvolvimento apresentar ao PO o que foi realizado na Sprint.
O PO aceita ou não as histórias apresentadas, com base no que foi combinado no planejamento da Sprint e na definição de História Pronta.
Scrum Master – É um dos três papéis no Scrum. O Scrum Master atua como facilitador da Equipe de Desenvolvimento e auxiliar do Product Owner, ajudando na manutenção do Product Backlog, removendo impedimentos e protegendo a Equipe de Desenvolvimento de interferências externas, para garantir a produtividade e a eficiência do trabalho. É o Scrum Master que procura assegurar o uso das práticas e valores do Scrum.
Scrum – É uma Metodologia Ágil para gestão e planejamento de projetos.
Sprint - Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de 2 semanas, 3 ou 4 semanas, que é o Timebox das Sprints. As Sprints devem ter sempre a mesma duração.
Sprint Backlog – Lista de Histórias selecionadas para ser trabalhada em uma Sprint, de acordo com a Velocidade da Equipe de Desenvolvimento.
Stand-Up Meeting – See Dailly Meeting.
