02 ETP Contratacao Servico Desenvolvimento Software Praticas Ageis Versao 22

TRIBUNAL DE CONTAS DA UNIÃO
Secretaria-Geral da Presidência
Secretaria de Soluções de Tecnologia da Informação
Sumário
1 Objeto a contratar ......................................................................................................... 3
2 Equipe de planejamento da contratação ....................................................................... 3
3 Necessidade da contratação e alinhamento com o planejamento institucional ............ 3
4 Resultados pretendidos ................................................................................................ 5
5 Justificativa da escolha do tipo de solução e proposta de modelo de contratação

inovador ............................................................................................................................... 6
6 Modelo de remuneração e demais requisitos da contratação ....................................... 8
7 Relação entre a demanda prevista e a quantidade a ser contratada .......................... 20
8 Modelo de execução do objeto ................................................................................... 21
8.1 Solicitação, execução e acompanhamento de serviços .............................................................. 21
8.2 Segurança da informação........................................................................................................... 23
8.3 Medidas de sustentação dos sistemas produzidos..................................................................... 23
9 Modelo de gestão contratual ....................................................................................... 24
9.1 Vigência do contrato .................................................................................................................. 24
9.2 Natureza do serviço ................................................................................................................... 24
9.3 Garantia de execução do contrato ............................................................................................. 25
9.4 Garantia dos produtos e serviços ............................................................................................... 25
9.5 Repactuação .............................................................................................................................. 25
10 Orçamento estimado ............................................................................................... 25
10.1 Levantamento de cargos e salários no mercado ........................................................................ 25
10.2 Levantamento de cargos e salários na Administração Pública ................................................... 26
10.3 Levantamento de cargos e salários junto a sindicatos ............................................................... 30
10.4 Remuneração dos profissionais nas propostas de fornecedores ................................................ 31
10.5 Cálculo da remuneração mínima ............................................................................................... 31
10.6 Cálculo da estimativa de preço .................................................................................................. 31
1
10.7 Critérios de aceitabilidade das propostas .................................................................................. 32
11 Condições do edital ................................................................................................. 33
11.1 Modalidade e tipo de licitação ................................................................................................... 33
11.2 Ata de Registro de Preço, IRP e Adesão Tardia .......................................................................... 33
11.3 Prazo para abertura da sessão pública ....................................................................................... 33
11.4 Parcelamento do objeto, subcontratação e possibilidade de participação de consórcio na

licitação ................................................................................................................................................. 34
11.5 Requisitos de habilitação técnica-operacional e econômica-financeira ..................................... 35
12 Providências para adequação do ambiente do órgão.............................................. 36
13 Análise de risco ....................................................................................................... 36
14 Relação entre o objeto da contratação em tela e o objeto do Contrato TCU nº

20/2013.............................................................................................................................. 37
15 Declaração de viabilidade da contratação ............................................................... 37
2
TC 010.494/2016-2
Tipo: Administrativo
Contratação de serviço de desenvolvimento de

software com práticas ágeis
Estudos Técnicos Preliminares
1 Objeto a contratar
Serviço de desenvolvimento de software com práticas ágeis.
2 Equipe de planejamento da contratação

 André Augusto Siqueira – matrícula 9313-0
 Eric Hans Messias da Silva – matrícula 9652-0
 George Atsushi Murakami – matrícula 8120-5
 Vitor Machado Ferreira – matrícula 8583-9
3 Necessidade da contratação e alinhamento com o planejamento

institucional
3.1. Em atenção ao princípio da eficiência, as unidades do Tribunal estão procurando
otimizar cada vez mais os seus processos de trabalho com o intuito de obter maiores
resultados com os recursos disponíveis. Ademais, percebe-se que geralmente a melhoria
do processo de negócio da unidade requer suporte de ferramenta de software.
3.2. Existe também grande necessidade de adequação e evolução dos sistemas de
informação atualmente em uso no Tribunal para atenderem novas necessidades que
surgem constantemente, em razão da dinâmica dos processos de trabalho do Tribunal, de
evolução tecnológica e de requisitos legais, como os derivados da Lei nº 12.527/2011 (Lei
de Acesso à Informação – LAI).
3.3. Em virtude destes fatos, é crescente a demanda por soluções de TI no TCU que
precisa ser acompanhada por aumento de capacidade de entrega pelas unidades
competentes, que são a Secretaria de Soluções de Tecnologia da Informação – STI e a
Secretaria de Infraestrutura de Tecnologia da Informação – Setic.
3
3.4. Atualmente, já existe considerável quantidade de demandas aguardando

disponibilidade de recursos da STI ou da Setic para serem priorizadas e atendidas. No
processo de elaboração do Plano Diretor de Tecnologia da Informação (PDTI) em vigor
(peça 6), identificou-se que 39% das demandas por soluções de TI não puderam ser
priorizadas por falta de recursos para o seu atendimento.
3.5. Considerando sua importância para a instituição, a referida necessidade de ampliar

a capacidade de resposta das unidades de TI foi consignada como direcionador de
tecnologia da informação no PDTI (peça 6), como mostra o excerto a seguir:
DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO

7) Aperfeiçoar e ampliar a capacidade de resposta para atendimento às necessidades de negócio
3.6. Cabe destacar que o atendimento desta necessidade é extremamente relevante

para impulsionar o alcance de outros direcionadores de tecnologia da informação e de
objetivos estratégicos do Tribunal, relacionados a seguir:
OBJETIVOS ESTRATÉGICOS (Fonte: PLANO ESTRATÉGICO DO TCU 2015 ~ 2021)

Aprimorar o uso da TI como instrumento de inovação para o controle
Assegurar suporte de bens e serviços adequado às necessidades do TCU
DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO (Fonte: PDTI 2015 ~ 2016)

1) Intensificar o uso de TI como instrumento de inovação, de transformação dos processos produtivos e de
incremento da produtividade
4
DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO (Fonte: PDTI 2015 ~ 2016)

5) Aprimorar a confiabilidade e a disponibilidade das soluções de TI por meio de iniciativas estruturantes da
infraestrutura tecnológica
6) Adoção progressiva de inovações tecnológicas ao processo de comunicação institucional e às soluções e

processos de trabalho habilitados por TI
8) Favorecer a transparência governamental e a prestação de serviços eletrônicos
4 Resultados pretendidos
4.1. Com a contratação em tela pretende-se ampliar a capacidade de provimento de
sistemas corporativos e, dessa forma, atender mais demandas do Tribunal por soluções
de TI tempestivamente, auxiliando assim na intensificação do uso de TI como instrumento
de inovação, de transformação dos processos produtivos e de incremento da
produtividade, colaborando ainda com a transparência governamental e a prestação de
serviços digitais.
4.2. Adicionalmente, em atenção ao disposto no Decreto-Lei 200/1067, pretende-se
executar de forma indireta o serviço ora contratado para que servidores da STI possam se
dedicar a atividades de planejamento, coordenação e controle.
Art. 6º As atividades da Administração Federal obedecerão aos seguintes princípios

fundamentais:
I - Planejamento.
II - Coordenação.
III - Descentralização.
IV - Delegação de Competência.
V - Controle.
(...)
Art.10 A execução das atividades da Administração Federal deverá ser amplamente
descentralizada. (...)
§ 7º Para melhor desincumbir-se das tarefas de planejamento, coordenação, supervisão e
controle e com o objetivo de impedir o crescimento desmesurado da máquina administrativa, a
Administração procurará desobrigar-se da realização material de tarefas executivas,
recorrendo, sempre que possível, à execução indireta, mediante contrato, desde que exista, na
área, iniciativa privada suficientemente desenvolvida e capacitada a desempenhar os encargos
de execução.
4.3. Considerando ainda o entendimento da Súmula-TCU 97, cabe destacar que a

atividade de desenvolvimento de software não é inerente aos cargos da Carreira de
Especialista do Tribunal de Contas da União. Em especial, esta atividade não consta no
5
rol de atribuições do cargo de Auditor Federal de Controle Externo, especialidade

Tecnologia da Informação, listadas no art. 9º da Resolução-TCU nº 154/2002, reproduzido
a seguir:
Art. 9° As atribuições do cargo de Auditor Federal de Controle Externo, especialidade

Tecnologia da Informação abrangem as dos cargos transformados de AFCE-Analista de
Sistemas e de AFCE-Programador para ACE-Tecnologia da Informação, e aos respectivos
ocupantes incumbe:
I - planejar e analisar ações, processos, rotinas e métodos de trabalho do Tribunal sujeitos a
aplicação de soluções de tecnologia da informação e determinar alternativas de racionalização
com vistas à implementação de soluções;
II - elaborar propostas orçamentárias para contratação de bens e serviços de tecnologia da
informação;
III - participar do processo de contratação de bens e serviços de tecnologia da informação,
mediante a execução de atividades tais como levantamentos de mercado, elaboração de
especificações e pontuações técnicas, análises de propostas técnicas e de preço;
IV - definir métodos, normas e padrões para aquisição, desenvolvimento, manutenção,
segurança física e lógica, integridade dos dados, desempenho e gestão de bens e serviços de
tecnologia de informação, bem como zelar pelo seu cumprimento;
V – auxiliar no diagnóstico de defeitos de funcionamento em equipamentos, programas,
aplicativos, sistemas e serviços de tecnologia da informação, propondo as medidas
necessárias para a solução;
VI - planejar, organizar, orientar, controlar e participar das atividades de implementação,
acesso e de suporte técnico aos usuários de tecnologia da informação internos e externos;
VII - acompanhar e fiscalizar a execução de contratos com empresas provedoras de soluções
de tecnologia da informação;
VIII - participar de trabalhos na área de Controle Externo e elaborar pareceres técnicos em
situações que requeiram elevada especialização em tecnologia da informação;
IX - executar outros trabalhos técnicos ou administrativos inerentes à sua área de atuação.
5 Justificativa da escolha do tipo de solução e proposta de modelo

de contratação inovador
5.1. Inicialmente, é oportuno ressaltar que a contratação de serviço de desenvolvimento
de software é apenas uma das iniciativas em curso visando o aumento da capacidade de
entrega da STI. Outras alternativas, como contratação de soluções já existentes no
mercado, a otimização dos processos internos da STI e a capacitação dos seus
servidores também estão sendo exploradas.
5.2. O quadro a seguir contém exemplos de implementação destas outras alternativas:
Alternativa Exemplos
Contratação de solução Contrato 72/2013: solução de gestão de pessoas (SGP);
pronta
Contrato 69/2013: solução de visualização de processos eletrônicos;
6
Contrato 53/2013: solução de data discovery (em uso na DGI);

Contrato 78/2013: solução para integração, qualidade e mascaramento de
dados;
Otimização de Iniciativas premiadas no 2º Evento de Reconhecimento de Trabalhos
processos internos Inovadores:
 Implantação da metodologia Kanban para a gestão do atendimento de
demandas de evolução das soluções de TI;
 Inovar – Projetos Pessoais.
Capacitação de Agile Brazil 2013 – 45 servidores da STI
servidores da STI
Agile Brazil 2014 – 6 servidores da STI
Treinamento de práticas ágeis – 14 servidores da STI
Curso Certified Scrum Developer – 10 servidores da STI
Curso Certified Scrum Master – 8 servidores da STI
5.3. Ademais, serviço similar ao que se deseja contratar é objeto de contrato vigente do
Tribunal (Contrato TCU nº 20/2013). Mais explicações sobre a relação entre o objeto da
contratação em tela e o do Contrato TCU nº 20/2013 encontram-se no item 14 deste
estudo.
5.4. Cabe destacar que contratação de serviço de desenvolvimento de software tem se
mostrado grande desafio para a Administração Pública. Comumente há dificuldade no
cumprimento dos prazos e requisitos de qualidade por parte do contratado, alto custo de
gestão contratual, prejuízo às ações dos órgãos dependentes dos sistemas a serem
desenvolvidos, entre outros.
5.5. Diante destes fatos, a STI iniciou avaliação de oportunidades de melhoria no
modelo de contratação ora adotado para serviço de desenvolvimento de software no
âmbito do Tribunal.
5.6. Umas das primeiras constatações foi a adoção exclusiva de metodologia tradicional
de desenvolvimento de software no modelo de execução contratual em detrimento de
metodologias ágeis que estão sendo gradativamente adotadas com sucesso na STI.
5.7. Partindo desta constatação, iniciou-se o estudo acerca da aplicabilidade de
métodos ágeis em contraste com metodologias tradicionais e sobre modelo de
remuneração de serviço de desenvolvimento de software com metodologia ágil (peça 3),
cujas conclusões foram:
a) Acredita-se que o modelo de remuneração de serviços de desenvolvimento
de software utilizando métrica vinculada ao produto (ex: ponto de função) é mais
apropriado para os domínios simples e complicado do framework Cynefin e
quando se utilizam metodologias tradicionais;
b) O desenvolvimento de sistemas corporativos no Tribunal enquadra-se, em
regra, no domínio complexo do framework Cynefin;
c) As metodologias ágeis são mais eficientes para se desenvolver software
neste contexto complexo;
7
d) Não se conhece métrica associada a produto de software com

características esperadas para utilização em desenvolvimento ágil e que seja
apropriada para fins de remuneração;
e) Não existindo métrica adequada, acredita-se ser necessária a criação de
modelo inovador para remuneração deste tipo de serviço, observando a legislação
vigente e a jurisprudência do TCU.
5.8. As características inovadoras deste novo modelo ora proposto estão descritas e
justificadas na seção 6 - Modelo de remuneração e demais requisitos da contratação.
6 Modelo de remuneração e demais requisitos da contratação

6.1. Modelo de remuneração
6.2. Como exposto anteriormente, entendeu-se oportuno e conveniente para o Tribunal
que novo modelo de remuneração fosse criado para contratação de serviço de
desenvolvimento de software com metodologias ágeis.
6.3. Inexistindo métrica derivada do produto de software construído que seja, por si só,
adequada para fins de pagamento (peça 3), decidiu-se por adotar modelo de
remuneração baseado no atendimento de níveis de serviço, em harmonia com a Súmula-
TCU 269, reproduzida a seguir:
Nas contratações para a prestação de serviços de tecnologia da informação, a
remuneração deve estar vinculada a resultados ou ao atendimento de níveis de
serviço, admitindo-se o pagamento por hora trabalhada ou por posto de serviço
somente quando as características do objeto não o permitirem, hipótese em que
a excepcionalidade deve estar prévia e adequadamente justificada nos
respectivos processos administrativos. (grifo nosso)
6.4. Porém, dados os requisitos necessários para adoção de metodologias ágeis no

desenvolvimento de software, em especial a necessidade de se ter equipe mínima
dedicada a somente um projeto por vez (justificativa mais adiante), entendeu-se ser
necessário dimensionar o volume de serviço a ser contratado também por equipe
responsável pela prestação do serviço, semelhante ao que ocorre com contratação por
posto de trabalho.
6.5. A especificação do modelo de remuneração ora proposto encontra-se na minuta de
Termo de Referência (peça 5). Em síntese, o modelo de contratação prevê que a
empresa contratada proverá equipe de desenvolvimento para prestação do serviço, sob
demanda que será formalizada por meio de ordem de serviço – OS e durante período a
ser definido de acordo com o projeto a ser executado, com a composição e qualificação
mínimas exigidas e será remunerada pelos postos de trabalho mediante atendimento de
níveis mínimos de serviço previstos no instrumento convocatório. Ou seja, caso haja
descumprimento de nível mínimo de serviço, haverá desconto no valor ofertado pela
contratada, de acordo com as regras estabelecidas no edital.
8
6.6. Trata-se, portanto, do que tem sido denominado de modelo híbrido na

jurisprudência do Tribunal, a saber: Acórdão nº 47/2013–TCU–Plenário (peça 8) e
Acórdão nº 1.125/2009-TCU–Plenário (peça 9).
6.7. Neste ponto, mostra-se oportuno reproduzir trecho do voto condutor do referido
Acórdão nº 1.125/2009-TCU–Plenário:
“A jurisprudência do Tribunal acena no sentido da inconveniência do modelo de
remuneração baseado apena em horas trabalhadas, uma vez que essa opção
não assegura a realização do objeto, o que atentaria contra o princípio da
eficiência.
Conforme verificado nos argumentos apresentados pela Infraero e nos termos

do multicitado Edital, foram definidos critérios para mensurar parte dos serviços
a serem executados (‘apoio técnico especializado e manutenção corretiva’ e
‘manutenção evolutiva, adaptativa e perfectiva’), no percentual de 46% do objeto
inicialmente previsto. Contudo, não há mensuração para o restante do objeto
licitado.
Verifica-se um modelo híbrido na execução dos serviços a serem contratados, já

que, conforme os critérios para aceitação dos serviços, a mensuração será feita
com base em horas trabalhadas e em resultados.
É possível identificar que os procedimentos adotados pela Infraero estão em

consonância com os Acórdãos 667/2005-TCU-Plenário e 786/2006-TCU-
Plenário, já transcritos no Relatório precedente, uma vez que a Infraero
estabeleceu critérios de mensuração dos serviços, estimativa prévia do volume
de serviços demandados, critérios de avaliação das especificações e quantidade
dos serviços, ferramenta de acompanhamento e fiscalização e ordem de serviço.
Dessa forma, em que pese a mensuração dos serviços não se basear em

remuneração por resultados, in totum, não se verifica irregularidade apta a
comprometer a lisura o certame em análise”. (grifo nosso)
6.8. Importa ressaltar que o Tribunal entendeu, nesses dois Acórdãos mencionados,
que tal modelo híbrido não afronta a legislação vigente nem a jurisprudência do Tribunal
para contratação de serviços de tecnologia da informação pois atende à diretriz de
pagamento por resultado.
6.9. Prestação do serviço exclusivamente de forma presencial e acompanhamento
por equipe técnica do Tribunal
6.10. Um dos pilares das metodologias ágeis é a comunicação eficiente e constante da
equipe de desenvolvimento com os demais envolvidos no projeto, como o representante
da área de negócios (Product Owner – PO), o ScrumMaster, entre outros.
6.11. Tal fato é constatado na literatura especializada, como em Rubin (2012), e também
mereceu menção no Acórdão nº 2.314/2013-TCU–Plenário (peça 7), conforme trechos do
relatório reproduzidos a seguir:
57. Princípio 4: pessoas relacionadas a negócios e desenvolvedores devem
9
trabalhar em conjunto e diariamente, durante todo o curso do projeto.
57.1. No cerne desse princípio, está o acesso e a comunicação entre as pessoas

da equipe que, independente do papel de cada uma, deve ser o mais simples
possível. Ferramentas automatizadas e encontros frequentes devem ser
utilizados a fim de que a transferência de conhecimento não aconteça apenas
por meio de produção e leitura de documentos, e sim por meio da comunicação
informal.
(...)
122. Valor 1: comunicação.
122.1. Enquanto os clientes têm visão dos problemas que desejam solucionar,
os desenvolvedores dominam as técnicas que influenciam a forma de resolver o
problema apresentado pelo cliente. O resultado do software é tão bom quanto a
capacidade de ambos se comunicarem.
122.2. Existem diversas formas para se estabelecer essa comunicação, mas

algumas se apresentam como melhores do que outras. Diálogos são mais
eficazes que videoconferências que, por sua vez, são melhores que
telefonemas, sendo esses mais expressivos que emails e assim
sucessivamente. O diálogo presencial evita que problemas de má compreensão
e ambiguidades comprometam negativamente o produto final.
(...)
Comunicação direta
165. As metodologias tradicionais são também chamadas de pesadas ou

orientadas à documentação. Além de detalharem as atividades que se deve
executar durante o desenvolvimento do software, também incentivam a
confecção de número considerável de documentos, como modelos, diagramas e
especificações. Desta forma, a principal maneira de comunicação entre as
pessoas é baseada em documentos formais.
166. Essa abordagem não é dispensada pelas metodologias ágeis, mas há uma
valorização maior na interação direta entre as pessoas de uma equipe a fim de
melhorar a transmissão e disseminação de conhecimento entre os indivíduos.
6.12. E no caso particular do TCU, entende-se ser essencial para o sucesso da

contratação acompanhamento da prestação do serviço por equipe de servidores do
Tribunal, para garantir, durante todo o processo de desenvolvimento, respeito a padrões
exigidos pelo TCU (ex: arquitetura de software), e também para identificar e remover
eventuais obstáculos alheios à contratada que podem impactar negativamente o projeto.
6.13. Quanto ao risco de caracterização de vínculo empregatício entre os terceiros e o
órgão público e consequente ilegalidade na contratação, não se enxerga caracterização
de subordinação hierárquica entre profissionais da contratada e servidores do Tribunal no
modelo de execução contratual ora proposto, mesmo sendo o serviço prestado
presencialmente, pelos motivos expostos a seguir.
10
6.14. Primeiro, porque será exigida a indicação de preposto pela contratada para
representa-la durante toda a vigência do contrato, em obediência ao art. 68 da Lei nº
8.666/93.
6.15. Além disto, será obrigação deste preposto alertar o fiscal do contrato qualquer
tentativa de ingerência do contratante sobre a gestão dos profissionais de sua empresa.
Neste sentido, de forma a possibilitar a identificação de interação estranha ao processo
de desenvolvimento ágil, exige-se que o preposto da contratada tenha conhecimentos de
processo de desenvolvimento de software baseado em Scrum.
6.16. Adicionalmente, entende-se que não há relação de subordinação hierárquica no
modelo ora proposto pelo fato de que na dinâmica de trabalho em metodologias ágeis a
comunicação que ocorre entre a equipe de desenvolvimento e os demais participantes do
projeto não é a transmissão de ordens de uma parte para outra, e sim o intercâmbio de
informações a que se refere o Acórdão nº 2.132/2010-TCU–Plenário no trecho do voto do
relator transcrito a seguir:
45. Por outro lado, não se pode negar que, sendo lícito o objeto para efeito de
terceirização, o sucesso da contratação, sob a ótica da eficiência das empresas
estatais, pode estar sujeito ao intercâmbio de informações entre profissionais do
quadro e da empresa terceirizada, mormente quando aqueles assumem o papel
de clientes destes, a exemplo dos contratos do BNDES acima examinados.
Naqueles casos, os objetos não se referiram a atividades-fim, tampouco ficou
demonstrado pela equipe relação de subordinação direta. Destarte, entendo que
a existência de habitualidade e pessoalidade, sem a comprovação cabal de
relação subordinativa, não implica ilegalidade do contrato de prestação de
serviço. (grifo nosso)
6.17. Ou seja, conforme consta nesta mesma transcrição, não havendo subordinação
hierárquica não há de se falar em ilegalidade no contrato de prestação de serviço.
6.18. Ademais, com o intuito de melhor esclarecer a matéria ora discutida, cabe
reproduzir trecho do voto condutor do Acórdão 1.258/2011-TCU-Plenário onde são
listadas práticas que caracterizam subordinação hierárquica, no entendimento deste
Tribunal:
Muito embora o objeto do Contrato n.º 74/2002 fosse a prestação de serviços de
apoio administrativo e atividades auxiliares nas dependências da Funasa,
verificou-se absoluto desvio de finalidade do contrato com a direta subordinação
dos empregados terceirizados à administração da Funasa, bem como uma
execução contratual marcada pelo desrespeito aos princípios da moralidade,
impessoalidade e isonomia.
Sobre a questão reproduzo trecho da instrução que foi destacado pelo Ministério
Público por bem demonstrar o contexto em que ocorria a contratação dos
profissionais terceirizados:
163. Destaca-se que, nos termos dos normativos aplicáveis, a indicação e
escolha de pessoas para a atuação no Contrato 74/2002 não poderia nem
sequer passar pela intervenção dos gestores da Funasa, entretanto o
conjunto de situações narradas demonstra que, de fato, a Fundação
encampou a gestão dos serviços que seriam prestados pelos terceirizados,
organizando e concedendo férias aos terceirizados, realizando a
substituição dos funcionários em afastamentos, organizando quadro de
11
cargos e promoções para os funcionários contratados, bem como indicando

pessoas para serem admitidas, promovidas, substituídas ou demitidas pela
empresa contratada, conforme detalhado às fls. 951 a 961 da instrução
precedente (fl. 1655, v. 8). (grifou-se)
6.19. Além do já mencionado, no relatório vinculado ao Acórdão 3.294/2011-TCU-

Plenário cita-se outro critério para caracterizar a subordinação hierárquica, que é o de
controle de horário e ausências dos prestadores de serviço por servidor público, e não
pelo preposto da empresa contratada:
Foi constatado, ainda, que o controle de horário e ausências, por exemplo, é
realizado pelos gerentes dos postos, o que caracteriza uma relação de
subordinação entre os funcionários terceirizados e os chefes dos postos,
servidores públicos municipais comissionados.
6.20. Pelo exposto, entende-se que a prestação do serviço de forma presencial nas
condições previstas no Termo de Referência não caracteriza subordinação hierárquica
nem terceirização ilegal.
6.21. Qualificação exigida dos profissionais que prestarão o serviço
6.22. Dentre as possíveis causas citadas por gestores para problemas ocorridos na
execução de contratos de desenvolvimento de software na Administração Pública,
usualmente está a qualificação insuficiente de profissionais alocados pela empresa
contratada para a prestação do serviço.
6.23. Acredita-se que tal fato decorre, primordialmente, de dois fatores: modelo de
remuneração previsto no contrato, incluindo aqui a questão de preço inexequível, e
estrutura piramidal de fábrica de software implementada pelas empresas prestadoras de
serviço. Para maiores informações acerca deste assunto, ver peça 3.
6.24. Sobre o modelo de remuneração, discutiu-se o assunto no estudo consignado na
peça 3 e também no item específico 6.1 - Modelo de remuneração.
6.25. Quanto ao esquema piramidal de fábrica, nota-se que, não havendo determinação
em contrário no edital da contratação pública, o usual é que as empresas contratem
poucos analistas-programadores altamente qualificados (seniores), alguns de qualificação
mediana (plenos) e muitos de menor qualificação (juniores). Forma-se, assim, uma
espécie de pirâmide com poucos profissionais mais qualificados no topo e com maior
número de profissionais com menor qualificação na base.
6.26. A experiência prática dos gestores de TI, porém, mostra que tal estrutura não
atende a todas as necessidades da Administração Pública, especialmente quando há
maior complexidade nos requisitos técnicos e de negócio, como é o caso, em regra, no
TCU.
6.27. Desta forma, entende-se necessário maior cuidado quanto ao modelo de
remuneração a ser adotado (assunto já abordado neste documento) e à qualificação
técnica exigida de todos os profissionais que irão prestar o serviço de desenvolvimento de
software.
12
6.28. A qualificação que se entende necessária ao prestador de serviço pode ser dividida
em duas partes: conhecimentos técnicos e competências comportamentais do
profissional.
6.29. As exigências técnicas, incluindo formação acadêmica e certificações exigidas do
profissional, referem-se a tecnologias e metodologias de trabalho necessárias ao
desenvolvimento de sistemas corporativos no TCU, considerando a plataforma
tecnológica adotada no Tribunal, a arquitetura de software a ser seguida, níveis de
qualidade exigidos e práticas de desenvolvimento em uso nesta Secretaria de Soluções
de TI.
6.30. Entende-se que as competências comportamentais exigidas, como proatividade,
capacidade de trabalho em equipe, capacidade de auto gerenciamento e tomada de
decisão, capacidade de comunicação, entre outros, são essenciais para o
desenvolvimento de software quando adotadas metodologias ágeis.
6.31. Tal entendimento decorre da experiência prática na adoção de métodos ágeis
nesta Secretaria de Soluções de TI, além do conhecimento adquirido por meio da
literatura especializada (ex: Rubin, 2012) e da participação em eventos e congressos
sobre o tema (ex: Agile Brazil 2013 – TC 010.092/2013-7, Agile Brazil 2014 – TC
019.894/2014-7, etc).
6.32. Analisando o mercado privado de trabalho no ramo de tecnologia da informação,
conclui-se que a qualificação exigida (conhecimentos técnicos mais competências
comportamentais) é encontrada, em regra, em analistas-programadores de nível sênior,
não sendo comuns em profissionais de nível inferior.
6.33. Quanto a opção por equipe de desenvolvimento somente com membros de nível
sênior, as justificativas para esta proposta serão apresentadas a seguir.
6.34. Primeiro, conforme exposto logo acima, a complexidade da plataforma tecnológica
utilizada para o desenvolvimento de sistemas corporativos do Tribunal, em conjunto com
o alto nível de exigência em termos da qualidade do produto de software construído,
implica na exigência de profissional altamente qualificado.
6.35. Adicionalmente, mesmo que eventualmente apareçam tarefas de menor
complexidade que profissionais de menor nível pudessem atender, há de se considerar o
ônus que estes profissionais representariam aos de maior nível, em virtude da
necessidade de apoio e orientação, quando não houvesse tarefas de menor
complexidade a fazer e toda a equipe precisasse realizar atividades de maior
complexidade.
6.36. Cabe ainda destacar que, devido à adoção de práticas ágeis, todo membro da
equipe de desenvolvimento irá interagir diretamente com representantes das áreas de
negócio do Tribunal, sendo que estes últimos poderão pertencer a diferentes níveis
hierárquicos do TCU. Neste sentido, entende-se que a alta senioridade do profissional
contratado mitigará risco de comunicação ineficiente entre as partes, o que prejudicaria o
andamento do projeto e oneraria demasiadamente a equipe do Tribunal.
13
6.37. Outrossim, a experiência ao longo dos anos nas unidades de TI do Tribunal tem
demonstrado que o custo-benefício de se ter profissionais de menor remuneração e,
consequentemente, de menor competência atendendo às necessidades do órgão tem se
mostrado desfavorável ao TCU.
6.38. Ou seja, acredita-se que a eventual economia na menor remuneração paga ao
contratado não compensa as desvantagens e riscos decorrentes, como atraso e baixa
qualidade dos produtos entregues, insatisfação das unidades de negócio que acabam mal
atendidas, o não alcance dos benefícios esperados com o projeto, necessidade de
retrabalho futuro, etc.
6.39. Diante das experiências anteriores, acredita-se o resultado obtido com a prestação
do serviço por profissionais de TI altamente qualificados torna vantajosa a análise custo-
benefício desta escolha, mesmo aumentando o valor a ser investido em virtude da
necessidade remuneração compatível.
6.40. E como benefício complementar ao Tribunal, há de se ressaltar que quanto maior o
nível do analista de TI e, consequentemente, da sua remuneração, menor o risco de
rotatividade deste profissional. Sabe-se que rotatividade de pessoal implica, em regra,
perda de produtividade. Tais fatos já foram constatados pelas unidades de tecnologia da
informação do Tribunal no âmbito de vários contratos.
6.41. Quantitativo mínimo de profissionais na equipe de desenvolvimento e
dedicação exclusiva
6.42. A literatura especializada em metodologias ágeis (ex: Rubin, 2012) defende que
uma equipe de desenvolvimento típica deve ter 7 membros dedicados ao projeto, com
variação 2 membros para mais ou para menos.
6.43. Com base na experiência prática obtida com a adoção de desenvolvimento ágil na
STI, concorda-se que este é realmente o tamanho de equipe aproximado para que haja
maior eficiência no trabalho conjunto.
6.44. Ademais, para possibilitar práticas como programação em pares previstas no
Extreme Programming (XP), entende-se ser mais apropriado que a equipe tenha,
preferencialmente, número par de membros.
6.45. Desta forma, definiu-se que uma equipe de desenvolvimento deve ter, em regra, 6
integrantes, podendo contudo o Tribunal, de acordo com o sistema a ser implementado,
optar por um quantitativo menor ou maior de profissionais na equipe, dentro de limites
preestabelecidos, sendo o valor da remuneração da contratada reduzido ou acrescido de
forma proporcional.
6.46. Além disso, procura-se evitar o compartilhamento de equipes em diferentes
projetos quando se adota metodologia ágil de desenvolvimento. Conforme consta na
literatura especializada (Rubin, 2012) e se vê na prática no Tribunal, o desenvolvimento
ágil é mais eficiente quando a equipe está dedicada a um único projeto por vez.
6.47. A seguir, reproduz-se trecho de Rubin (2012) no qual se discute a possibilidade do
mesmo time de desenvolvedores atuar em mais de um projeto.
14
Se uma organização possui múltiplos produtos, ela terá múltiplos backlogs. A

melhor maneira de se lidar com múltiplos backlogs é atribuí-los a uma ou mais
equipes dedicadas exclusivamente a cada backlog. Em alguns casos, porém,
uma equipe pode acabar trabalhando em mais de um backlog. Como discutido
no capítulo 11, nossa meta deve ser minimizar a quantidade de projetos
paralelos nos quais as equipes trabalham. A solução primária, e geralmente a
melhor, é ter a equipe trabalhando em um projeto por vez. (tradução livre, grifou-
se)
6.48. No desenvolvimento ágil, o que ocorre com maior frequência é o compartilhamento

de profissional com determinada especialização (ex: designer de interface gráfica) entre
diferentes equipes. Ressalte-se que, entretanto, não se imagina tal possibilidade na
contratação ora proposta.
6.49. Remuneração mínima para o profissional prestador de serviço.
6.50. Mostra-se oportuno, incialmente, reconhecer que indefinição jurisprudencial no
TCU sobre a possibilidade da Administração Pública fixar remuneração mínima para
prestador de serviço. Conforme bem sintetizou a Conjur em parecer exarado no âmbito do
TC 000.550/2015-9 (peça 23 do referido processo), em alguns casos, entendeu o Tribunal
não ser possível a definição deste limite mínimo remuneratório (Acórdãos 963/2004 1,
1.094/2004, 2.028/2006, 2.144/2006, 1.699/2007, 1.910/2007, todos do Plenário), já em
outros julgados admitiu o TCU esta possibilidade (Acórdãos 256/2005, 290/2006,
421/2007, 1.024/2007 e 614/2008, todos do Plenário).
6.51. Os entendimentos divergentes foram confrontados, por exemplo, no Acórdão nº
614/2008-TCU–Plenário (peça 10), conforme mencionado em trecho do voto condutor do
Acórdão nº 47/2013-TCU–Plenário (peça 8), reproduzido a seguir:
17. Quanto ao estabelecimento de valores salariais mínimos a serem pagos aos
profissionais a serem disponibilizados pela contratada (subitem 3.b), este
Tribunal se manifestou de forma paradigmática sobre a questão por meio do
Acórdão 614/2008-Plenário.
18. Nesse decisum, o Ministro-Substituto Marcos Bemquerer Costa, cujo Voto

Revisor foi adotado pelo TCU, assim se posicionou:
“38. Assim, em termos de contratação para execução indireta de serviços

pagos por disponibilidade ou baseados na locação de postos de trabalho,
não considero, com base na mencionada jurisprudência desta Casa,
haver entendimento firmado acerca da inaplicabilidade do § 3º do art. 44
da Lei n. 8.666/1993. A bem da verdade, observo que a compreensão da
contratação de mão-de-obra terceirizada abrange dois caminhos a
percorrer: um, que aponta a obrigatoriedade de adoção dos pisos
salariais definidos em pactos laborais; e outro que indica a possibilidade
de a Administração Pública estipular valores mínimos de remuneração
com base em pesquisas de mercado efetuadas previamente e calcadas
tanto em dados obtidos junto a associações e sindicatos de cada
15
categoria profissional quanto em informações divulgadas por outros

órgãos públicos que tenham recentemente contratado o mesmo tipo de
serviço.
39. Acrescente-se que essas pesquisas devem ser anexadas aos

processos licitatórios para que os critérios utilizados pelo órgão
contratante para estipular a remuneração mínima, devidamente
fundamentados, sejam explicitados aos interessados em participar do
certame.”
19. (...).
20. Bem se sabe que esse Acórdão também considerou indevida a

fixação de piso salarial para serviços que devem ser medidos e pagos por
resultados, o que seria o caso dos serviços de TI cuja contratação ora se
aprecia. Todavia, como visto acima, o TST justificou nos documentos
licitatórios a adoção de medição também por homens-hora/postos de
trabalho, o que justifica a fixação dos limites salariais mínimos para tais
itens de serviço apenas. (grifo nosso)
6.52. Outrossim, nesse mesmo Acórdão nº 47/2013-TCU–Plenário (peça 8), conforme

consta ainda no trecho anteriormente reproduzido, entendeu-se que não é indevida a
fixação de limites salariais mínimos para os profissionais que irão prestar o serviço
contratado em modelo híbrido como o caso em tela.
6.53. Em virtude das informações levantadas no decorrer destes estudos técnicos
preliminares, considerando as linhas jurisprudenciais divergentes, alinha-se ao
entendimento de que é possível fixar remuneração mínima para prestadores de serviço e
que tal prática é vantajosa para a contratação ora proposta e não comprometerá o caráter
competitivo do certame, conforme justificado a seguir.
6.54. Pelo exposto neste estudo, o desenvolvimento de sistemas corporativos para o
TCU exige alto grau de qualificação do profissional para que se obtenha resultado
tempestivo, com qualidade e aderente às necessidades das áreas de negócio do Tribunal.
6.55. Contudo, é oportuno ressaltar que, pelo relato de diversos gestores públicos, há
significativo histórico de contratações de serviço de desenvolvimento de software nos
quais os prestadores de serviço possuíam qualificação aquém da necessária, resultando
em falhas na execução do contrato, não atendimento dos níveis mínimos de serviço
exigidos, entrega de produtos de software com baixa qualidade e atendimento
inadequado da necessidade da instituição.
6.56. Adicionalmente, percebe-se que aplicação de glosas e sanções sem sempre se
mostram eficazes para obter a regular prestação do serviço.
6.57. Desta forma, entende-se que a definição de patamar remuneratório mínimo no
caso em tela atende à exigência do item 9.2.3.1 do Acórdão nº 2.582/2012–TCU–
Plenário, reproduzido a seguir:
16
9.2.3. relativamente aos contratos de execução indireta e contínua de serviços:

9.2.3.1. somente estipule valores mínimos de remuneração dos trabalhadores,
nos contratos em que há alocação de postos de trabalho, quando houver
necessidade de afastar o risco de selecionar colaboradores com capacitação
inferior à necessária para execução dos serviços contratados;
6.58. Nesta linha, cabe ainda reproduzir outro trecho do voto revisor do citado Acórdão
nº 614/2008-TCU–Plenário, no qual o discorre-se sobre a vantajosidade da fixação destes
limites salariais mínimos para a Administração Pública:
31.A dinâmica da economia capitalista induz as empresas a objetivarem
constante aumento nos seus lucros. O que se verifica com as licitantes
prestadoras de serviços terceirizados, portanto, é que, tendenciosamente,
buscam majorar seus ganhos por meio da diminuição nos valores da
remuneração de seus empregados, que constituem o mais relevante custo
desse tipo de contrato.
32.Ao contratar empresas que remuneram mal seus empregados, a

Administração Pública corre o risco de que os profissionais terceirizados não
possuam experiência e qualificação suficientes para prestar serviços com o nível
de qualidade adequado.
33.Importante ressaltar que a gradação dos salários praticados no mercado está

associada à experiência acumulada e à qualificação adquirida no desempenho
da atividade laboral. Assim, o que se verifica é que profissionais que se prestam
a receber salário inferior à média da área em que atuam, em geral, têm pouca
experiência e baixa especialização.
34.Nesse contexto, cumpre ao órgão licitante definir o perfil do profissional

prestador de serviços. Se há necessidade de se garantir o emprego de mão-de-
obra capacitada, o estabelecimento de uma política de remuneração mínima
pode ser uma solução.
35. Acrescente-se que estudos de aproveitamento de mão-de-obra têm

detectado que o descontentamento do profissional com sua remuneração
repercute em baixa eficiência e pouca produtividade. Nesse sentido, a visão
gerencial de administração que vem sendo implementada no serviço público
desde o início da década de noventa não comporta a desvalorização do
empregado prestador de serviços que pode ocasionar ineficiência, contratação
de pessoas sem a qualificação necessária e a indesejável rotatividade de mão-
de-obra (o turnover).
36.O intuito de obter a contratação mais barata para a Administração Pública

não deve prevalecer a qualquer custo, ou, ainda, a terceirização de mão-de-obra
no setor público não deve estar associada à utilização de trabalhadores mal
remunerados.
37.Em consonância com o processo de valorização dos servidores públicos que

vem ocorrendo no âmbito da Administração Pública Federal, o trinômio
qualidade da mão-de-obra, alta produtividade e boa remuneração deve ser
17
observado também para os trabalhadores terceirizados, aos quais deve ser

garantida uma remuneração mínima, condizente com as atribuições que lhe são
impostas.
6.59. Na mesma esteira, mostra-se oportuno também destacar entendimento consignado

no Acórdão nº 189/2011-TCU–Plenário (peça 12), que também menciona o voto condutor
do Acórdão nº 256/2005-TCU-Plenário:
O Ministro Marcos Vilaça foi um dos primeiros a chamar a atenção para a
necessidade de se flexibilizar, em determinadas situações, a vedação ora
comentada, como deixou claro no voto que impulsionou ao Acórdão nº
256/2005-TCU-Plenário, a saber:
‘20. Observo, por último, que não está se propondo a desconsideração da

vedação ao estabelecimento de preço mínimo imposta pelo art. 40 da Lei
nº 8.666/1993 que, aliás, constitui notável avanço em relação ao regime do
antigo Decreto-lei nº 2.300/1986. Trata-se aqui de uma situação específica,
em que o estabelecimento de piso salarial visa preservar a dignidade do
trabalho, criar condições propícias à eficiente realização do serviço e não
implica benefícios diretos à empresa contratada (mas sim aos
trabalhadores), nem cria obstáculos à competição ou tem a capacidade de
determinar o preço final da contratação.’ (grifo nosso).
6.60. Quanto ao impacto da fixação destes limites salariais na competividade da

licitação, vale reproduzir trecho do voto condutor do Acórdão nº 1.327/2006-TCU–Plenário
(peça 11), também mencionado no voto revisor do Ministro Marcos Bemquerer destacado
anteriormente:
Comungo da intelecção de que tal previsão editalícia não necessariamente
afeta a competitividade de certames licitatórios para tais atividades. É que o
estabelecimento de um mesmo piso salarial a ser seguido por todas as licitantes
em tese não cria condições suficientes para favorecer algumas das empresas
em prejuízo das demais. Ao reverso, penso que, na esteira do entendimento
esposado pelo eminente Ministro Marcos Vilaça no voto condutor do Acórdão
256/2005 - TCU - Plenário, a fixação prévia de uma referência para a
remuneração a ser paga aos empregados reduz a incerteza das empresas no
estabelecimento de seus custos e a insegurança quanto à disponibilidade de
mão-de-obra qualificada disposta a trabalhar por aquela remuneração. Isso, de
certo modo, pode funcionar como um atrativo ao comparecimento de mais
interessadas ao certame. (grifo nosso)
6.61. Pelo exposto, entende-se que não só possível legalmente como também oportuno
e conveniente para o Tribunal a fixação de limites salariais mínimos na contratação em
tela, desde de que respeitados os valores efetivamente praticados no mercado.
6.62. Níveis mínimos de serviço.
6.63. Na definição dos níveis mínimos de serviço, procurou-se definir indicadores e
metas que favorecessem a adoção de práticas ágeis no serviço de desenvolvimento de
18
software a ser contratado e que refletissem as diferentes dimensões de resultado

inerentes a este tipo de serviço.
6.64. Desta forma, optou-se por definir métrica denominada Índice de Evolução do
Sistema (IES) resultante de três indicadores de desempenho que buscam refletir
produtividade, qualidade e aderência das práticas adotadas aos princípios e valores de
desenvolvimento ágil de software.
6.65. Decidiu-se, ainda, por atribuir maior peso às dimensões de produtividade e
qualidade por se considerar mais valioso o resultado final do que o processo adotado e
pela margem de subjetividade da avaliação do Product Owner.
6.66. Além disso, considerando imprecisões das métricas adotadas para mensuração de
produtividade, o fato das linhas de base para produtividade e para qualidade terem sido
estabelecidas considerando desempenho de equipes de desenvolvimento compostas por
servidores do Tribunal que possuem alta qualificação técnica além de domínio da
arquitetura tecnológica e bons conhecimentos do negócio do TCU, entende-se adequado
não prever glosa caso o Índice de Evolução do Sistema (IES) alcance o mínimo de 80%,
havendo, contudo, desconto no caso do IES ficar abaixo deste valor.
6.67. Excepcionalmente, considerando que usualmente no início de todo projeto são
investidos consideráveis recursos em atividades preparatórias como criação do ambiente
de desenvolvimento do projeto e no aprendizado da visão geral da solução, incluindo aqui
os principais conceitos e regras da área de negócio a ser atendida, serão definidos níveis
mínimos de serviço diferenciados para a primeira aferição do Índice de Evolução do
Sistema (IES) da Ordem de Serviço.
6.68. Índice de Produtividade (IP)
6.69. A produtividade do serviço será medida pela evolução do tamanho funcional do
sistema e pela a quantidade de novas linhas de código adicionadas ao software.
6.70. Por evolução do tamanho funcional entende-se a quantidade de pontos de função
correspondentes a inclusões, alterações e exclusões realizadas no sistema ao se
comparar duas versões deste software.
6.71. Cada métrica (tamanho funcional e linhas de código) possui virtudes e limitações.
Ou seja, cada métrica pode capturar certos aspectos da produtividade do serviço de
desenvolvimento de software e ignorar outros. Mais detalhes sobre limitações da métrica
de tamanho funcional encontram-se na peça 3.
6.72. A adoção das duas métricas em conjunto tem o objetivo de mitigar risco de
imprecisão na mensuração de produtividade do serviço por limitação dessas métricas.
6.73. Cabe ressaltar que a adoção de ferramenta automatizada de aferição de qualidade
de código (ex: SonarQube) mitiga risco de distorções na métrica de linhas de código ao
apontar ocorrências como trechos de código não utilizados ou duplicados, entre outros.
6.74. A produtividade-base em tamanho funcional foi estabelecida considerando as
medições realizadas nos projetos correspondentes às versões 1 e 2 do módulo de Contas
do e-TCU (peças 37, 46 e 47), que possui características semelhantes aos que serão
19
executados pela empresa contratada (ex: projetos de desenvolvimento de software com

adoção de práticas ágeis na plataforma tecnológica Java, equipe composta por
profissionais de nível sênior, entre outros).
6.75. A produtividade-base em linhas de código considerou dados do mesmo projeto no
mesmo período, porém a fonte das informações foi a ferramenta de software GIT utilizada
neste projeto.
6.76. O quadro a seguir resume os dados obtidos deste projeto:
Projetos Módulo de Contas do e-TCU (eContas) – versões 1 e 2

Produtividade em Pontos de Função 0,56 PF / DIA-DESENVOLVEDOR
Produtividade em linhas de código 33,33 LINHAS DE CÓDIGO / DIA-DESENVOLVEDOR
6.77. Índice de Qualidade (IQ)

6.78. O Índice de Qualidade (IQ) será obtido a partir de indicadores de qualidade do
código-fonte do software aferidos com apoio da ferramenta SonarQube, versão 5.0 ou
superior.
6.79. Trata-se de ferramenta de software livre amplamente utilizada tanto no Brasil
quanto no restante do mundo, de forma que sua adoção pelo Tribunal aproxima as
características da execução do serviço ora contratado às práticas de mercado.
6.80. Ademais, a qualidade do código-fonte de software é essencial para permitir
manutenções e evoluções de regras de negócio com baixo custo. Ou seja, quando o
código-fonte do software não possui qualidade adequada eventuais alterações no sistema
podem ser tornar demasiadamente onerosas ou mesmo inviáveis, a ponto de ser mais
vantajoso o redesenvolvimento do software.
6.81. Avaliação do Product Owner (APO)
6.82. A avaliação do Product Owner (APO) visa aferir se princípios e valores de
desenvolvimento ágil estão sendo observados pela equipe técnica da contratada.
6.83. Os itens desta avaliação foram inspirados nos princípios do manifesto ágil
(http://www.agilemanifesto.org/principles.html) e no valor “comunicação” do Extreme
Programming - XP.
7 Relação entre a demanda prevista e a quantidade a ser contratada

7.1. Conforme figura apresentada no item 3 deste estudo, no processo de elaboração
do PDTI para o biênio 2015 / 2016 não puderam ser priorizadas 49 demandas (projetos)
por soluções de TI de interesse do Tribunal.
7.2. Destas demandas, 23 foram de sistemas corporativos que poderiam ser atendidas
com apoio da contratação em tela.
20
7.3. Porém, deve-se destacar que cada novo projeto de desenvolvimento de software,
mesmo executado de forma indireta, requer acompanhamento e gestão da STI, além de
participação ativa da unidade de negócio demandante da solução.
7.4. Desta forma, considerando a capacidade disponível desta Secretaria de Soluções
de TI para gerenciar projetos de novos sistemas corporativos e para realizar a fiscalização
contratual, apesar de existir demanda reprimida em quantidade superior, entende-se que
4 (quatro) projetos (equipes) simultâneos é quantitativo razoável para o volume de
serviços ora contratado.
8 Modelo de execução do objeto

8.1 Solicitação, execução e acompanhamento de serviços
8.1.1 Em seguida será descrito, em linhas gerais, o modelo de execução do objeto.
8.1.2 Havendo necessidade de desenvolvimento de novo sistema de forma indireta, o

Tribunal requisitará à empresa, por meio de ordem de serviço, a disponibilização de
equipe de desenvolvimento para prestação do serviço contratado, com a qualificação
exigida e com o tamanho especificado pelo TCU, no prazo previsto.
8.1.3 O tamanho de equipe previsto no edital poderá ser reduzido ou aumentado pelo
Tribunal, considerando as características do projeto a ser executado por essa equipe.
Caso esta alteração ocorra, a remuneração da empresa contratada será ajustada de
forma proporcional.
8.1.4 Juntamente com a equipe de desenvolvimento, a empresa contratada deverá

designar preposto para representá-la junto ao Tribunal durante a execução do serviço.
Este preposto não poderá ser um dos membros da equipe de desenvolvimento.
8.1.5 Estando a equipe de desenvolvimento disponível, será iniciada a execução do

projeto seguindo o processo de desenvolvimento ágil adotado no TCU.
8.1.6 A equipe da contratada será acompanhada por equipe de servidores do Tribunal

que irão aferir se o serviço está sendo prestado satisfatoriamente, ou seja, se os padrões
de arquitetura do Tribunal, se os seus requisitos de qualidade e de negócio estão sendo
atendidos, entre outros. Esta equipe de servidores deverá ainda apoiar o fiscal do contrato
em suas atribuições.
8.1.7 A equipe de servidores do TCU será responsável também por tratar eventuais
obstáculos à regular prestação do serviço cuja solução seja de responsabilidade do
Tribunal.
8.1.8 O tamanho desta equipe de servidores do Tribunal deverá ser dimensionado

considerando fatores como as características do projeto, o tamanho da equipe técnica da
contratada, entre outros.
21
8.1.9 Em particular, os papéis de Product Owner (PO) e ScrumMaster previstos na

metodologia ágil Scrum serão desempenhados por servidores do Tribunal.
8.1.10 Periodicamente, o Tribunal irá aferir o atendimento dos níveis de serviço previstos
no Termo de Referência e identificar eventuais descontos e sanções a serem aplicadas à
contratada.
8.1.11 Cabe destacar que os prazos para disponibilização da equipe terceirizada e o

prazo de antecedência para aviso pelo Tribunal da prorrogação ou da antecipação do
término da Ordem de Serviço foram definidos considerando eventual necessidade de
contratação e posterior demissão de profissionais sob o regime da Consolidação das Leis
do Trabalho - CLT.
8.1.12 Oportuno ressaltar que, conforme exposto anteriormente, a relação entre os

servidores do Tribunal e os membros da equipe de desenvolvimento da empresa
contratada não será de subordinação hierárquica. A interação entre esses profissionais
consistirá, essencialmente, na troca de informações necessária para a adequada
prestação do serviço.
8.1.13 Neste sentido, vale lembrar que o preposto da empresa deverá acompanhar o
andamento dos trabalhos e se manifestar no caso de eventual desvio de nesta relação
entre os servidores do Tribunal e os profissionais da contratada.
8.1.14 Além disso, as regras de controle da efetiva ocupação dos postos de trabalho
foram adaptadas para as particularidades do serviço de desenvolvimento de software.
8.1.15 Em geral, em contratações por posto de trabalho, caso o profissional terceirizado

falte ao serviço, a empresa contratada é obrigada a alocar temporariamente outro
profissional para preencher o posto e executar o serviço contratado.
8.1.16 Cabe lembrar que, neste tipo de contratação, as ausências de profissionais são
estimadas pelas licitantes e o custo da substituição é incluído em suas propostas. Ou
seja, o custo de manter o posto de trabalho ocupado é contabilizado nas planilhas de
preços apresentadas ao órgão público.
8.1.17 Contudo, tratando-se de desenvolvimento de software, a substituição de um

profissional por outro para cobrir ausências pontuais não é, em regra, efetiva para manter
a prestação do serviço com qualidade e eficiência. Isso porque não é realista esperar que
um profissional, mesmo altamente qualificado, consiga produzir algo similar aos demais
membros da equipe de desenvolvimento em curto espaço de tempo sem conhecer nada
acerca do projeto (ex: objetivo do sistema, regras de negócio envolvidas, situação atual
do projeto, arquitetura técnica utilizada, etc).
8.1.18 Pode-se afirmar ainda que a necessidade de substituir profissional com alta
qualificação em ausências pontuais torna-se risco significativo para a empresa contratada
e geralmente tal fato reflete-se em majoração no lucro ou nos custos indiretos previstos
pela licitante.
22
8.1.19 Considerando o exposto e em atenção aos princípios da eficiência e da

razoabilidade, optou-se por flexibilizar as exigências referentes à ocupação dos postos de
trabalho na contratação em tela.
8.1.20 Com regras mais flexíveis, reconhece-se que o licitante ainda precisa estimar
eventuais ausências de seus profissionais e, de alguma forma, incluir tal custo em sua
proposta de preços. Por exemplo, em caso de licença por motivo de saúde, a empresa
deverá continuar remunerando o profissional (até o limite a partir do qual o seu salário é
coberto pela seguridade social) sem receber contrapartida do órgão contratante.
8.1.21 Contudo, entende-se que esta sistemática tende a reduzir custos e riscos
adicionais derivados na necessidade de alocação de profissionais substitutos no contrato.
8.1.22 Por outro lado, é preciso também garantir certo patamar de ocupação destes
postos de trabalho para que a prestação do serviço ao Tribunal não seja prejudicada, no
caso, por exemplo, da empresa contratada considerar mais vantajoso para ela não alocar
a quantidade solicitada de profissionais, em determinados períodos ou situações (ex: no
caso de dificuldade para seleção e contratação de novos profissionais no mercado).
8.2 Segurança da informação
8.2.1 Considerando que a equipe da empresa contratada eventualmente precisará ter

acesso a informações não públicas para prestar o serviço contratado, todos os seus
membros deverão assinar o Termo de Compromisso de Manutenção de Sigilo e Respeito
às Normas de Segurança que constará como anexo do edital.
8.2.2 Ademais, será atribuição também da equipe do TCU designada para acompanhar a
prestação do serviço mitigar risco de uso indevido das informações não públicas pelos
profissionais da empresa contratada.
8.3 Medidas de sustentação dos sistemas produzidos
8.3.1 Como em toda contratação de bens e serviços de TI, é prudente que o Tribunal
adote as medidas possíveis para mitigar riscos de dependência excessiva do fornecedor.
8.3.2 No caso em tela, entende-se ser necessário evitar que a eventual descontinuidade
na prestação do serviço contratado comprometa demasiadamente a implantação e a
sustentação dos sistemas desenvolvidos.
8.3.3 Para mitigar tal risco, recorreremos novamente à equipe do TCU responsável pelo
acompanhamento da prestação dos serviços contratados. Esta equipe será responsável
por deter o conhecimento técnico e de negócio associados aos sistemas desenvolvidos
pela equipe terceirizada e posteriormente transmiti-lo aos próximos profissionais que
forem designados para prosseguir com a execução do serviço de desenvolvimento de
software.
8.3.4 Espera-se, ainda, que esta equipe do TCU seja capaz de atender demandas
emergenciais, como incidentes no funcionamento do sistema em produção, ou mesmo
23
prosseguir com o desenvolvimento do software em ritmo compatível com a quantidade de

servidores que compõem a equipe.
9 Modelo de gestão contratual

9.1 Vigência do contrato
9.1.1 Propõe-se que a vigência do contrato seja de 12 meses, prorrogáveis até 60

meses.
9.2 Natureza do serviço
9.2.1 A caracterização do serviço de desenvolvimento de software como serviço de

natureza continuada já foi justificada em contratação anterior (Contrato TCU nº 20/1013),
conforme item 11 dos estudos técnicos preliminares (peça 2) do TC 012.189/2012-0, cujo
trecho encontra-se reproduzido a seguir:
11.3 Nos últimos anos, o uso da tecnologia da informação no dia-a-dia
das organizações tem se intensificado de forma crescente e acentuada.
O estoque crescente de demandas e a necessidade de provimento
cada vez mais célere de soluções exigem mudanças e ampliação da
capacidade de resposta. No caso do Tribunal, as demandas por novas
soluções de TI para apoiar os processos de trabalho confirmam essa
tendência. Ao mesmo tempo, quanto maior a inserção da tecnologia da
informação no funcionamento do Tribunal, em especial o uso intensivo
do processo eletrônico, maior a dependência das áreas de negócio,
com comprometimento das atividades. A interrupção no funcionamento
de uma solução de TI se propaga, imediatamente, para a área de
negócio. No caso das soluções que suportam o uso do processo
eletrônico, significa interromper a realização de qualquer atividade de
controle externo, por impossibilidade de acesso aos autos processuais.
11.4 Adicionalmente, há que se considerar o dinamismo inerente tanto
à tecnologia da informação quanto aos requisitos de negócio.
Mudanças no processo de trabalho, advento de novas tecnologias, ou
a introdução de uma solução de TI no ambiente organizacional,
invariavelmente, geram novas necessidades e novas demandas por
informatização. Nesse contexto, a velocidade de evolução e de
adaptação das soluções de TI tem impacto direto nos resultados da
instituição.
11.5 Portanto, entende-se não haver dúvida de que os serviços de
desenvolvimento, manutenção e testes de sistemas de informação não
podem ser interrompidos, por serem imprescindíveis ao funcionamento
do TCU. Ainda, a orientação estratégica do Tribunal de intensificar e
aprimorar o uso de TI nas ações de controle externo e na gestão
institucional reforça, ainda mais, essa premissa. (...)
24
9.3 Garantia de execução do contrato
9.3.1 Sugere-se exigir da contratada a prestação de garantia de execução do contrato no

valor equivalente a 5% do valor anual do contrato, com fulcro no art. 56 da Lei nº
8.666/93, com o intuito de garantir o devido ressarcimento ao Tribunal no caso de
eventual inadimplemento ou inadequação dos serviços prestados.
9.4 Garantia dos produtos e serviços
9.4.1 O prazo de garantia dos serviços entregues no âmbito deste contrato será de 120
(cento e vinte) dias, contados após o seu recebimento definitivo.
9.5 Repactuação
9.5.1 Sugere-se admitir repactuação dos valores do contrato visando a sua adequação
aos novos preços de mercado, nos termos da legislação vigente.
10 Orçamento estimado
10.1 Levantamento de cargos e salários no mercado
10.1.1 Inicialmente, realizou-se pesquisa por informações de cargos e salários publicadas

por empresas e sites especializados (peças 23 a 25).
10.1.2 Conforme consta na pesquisa da empresa Robert Half e do site Curriculum.com.br

(peças 23 e 24), o salário do profissional varia de acordo com o porte da empresa na qual
ele trabalha.
10.1.3 Ainda de acordo com a empresa Robert Half (peça 23, página 2), considera-se
grande empresa aquela que tem faturamento superior a R$ 500 milhões anuais.
10.1.4 Haja vista que o orçamento do TCU em 2014 foi de aproximadamente um bilhão e
seiscentos milhões de reais (peça 26), entende-se que o Tribunal pode ser equiparado à
empresa de grande porte para fins desta pesquisa de preços.
10.1.5 Na pesquisa da empresa Robert Half, o cargo de Analista de Sistemas Sênior

(Senior Application Analyst) é o que mais se aproxima do perfil profissional especificado
nesta contratação.
10.1.6 Segundo esta pesquisa, o salário deste cargo em empresa de grande porte varia
entre R$ 8.100,00 e R$ 12.000,00, o que dá a média de R$ 10.050,00.
Fonte Robert Half (peça 23, página 39)

Cargo Analista de Sistemas Sênior
Faixa Salarial R$ 8.000,00 ~ R$ 12.000,00
Valor médio R$ 10.050,00
25
10.1.7 No site Curriculum.com.br, existem três cargos que se assemelham com o perfil
procurado (peça 24), cujos respectivos salários e valor médio encontram-se no quadro a
seguir:
Fonte Curriculum.com.br (peça 24)

Cargo Média Salarial
Analista Desenvolvedor Java Sênior R$ 7.922,18
Analista Programador Java Sênior R$ 7.333,33
Desenvolvedor Java Sênior R$ 8.500,00
10.1.8 O Instituto de Pesquisas Datafolha publicava médias salarias para perfil similar ao
desejado nesta contratação. Como a última publicação foi em abril de 2015 (peça 25),
aplicou-se a inflação do período para se obter valor atualizado.
Fonte Datafolha (peça 25 – página 3)

Cargo Analista de Sistemas Sênior
Inflação (IPCA) de abril/2015 a fevereiro/2016 11%
Valor atualizado R$ 12.446,67
10.1.9 No caso da pesquisa do Datafolha, importa ainda ressaltar que a média se refere
aos valores praticados na Grande São Paulo. Contudo, conforme pesquisa recente da
Revista Veja (peça 34), Brasília tem o 3º maior custo de vida do país, logo atrás de São
Paulo, além do que cada remuneração levantada nesta análise será analisada em
conjunto com valores obtidos de outras fontes. Desta forma, entende-se que a informação
deste Instituto de Pesquisa pode ser utilizada nesta pesquisa de preços.
10.1.10 Consolidando as informações das três fontes de pesquisas de cargos e

salários de mercado, temos o seguinte:
Fonte Remuneração (R$)
Robert Half 10.050,00
Curriculum.com.br 7.918,50
Datafolha 12.446,67
Média 10.138,39
10.2 Levantamento de cargos e salários na Administração Pública
26
10.2.1 A pesquisa de preços no âmbito da Administração Pública iniciou-se com consulta

aos órgãos membros da Comunidade de Tecnologia da Informação Aplicada ao Controle
– TIControle (peça 27). A TIControle atualmente é composta por cerca de 18 órgãos como
Controladoria-Geral da União - CGU, Departamento de Polícia Federal - DPF, Supremo
Tribunal Federal - STF, Superior Tribunal de Justiça - STJ, Tribunal Superior Eleitoral -
TSE, Conselho Nacional de Justiça – CNJ, Conselho da Justiça Federal - CJF, Ministério
Público Federal - MPF, Conselho Nacional do Ministério Público - CNMP, etc, além do
próprio TCU.
10.2.2 Em atenção ao questionamento do TCU, alguns órgãos responderam que não

possuíam contrato com objeto similar (CJF e Senado Federal), enquanto outros
responderam que não foi exigida, em suas contratações, a apresentação da remuneração
dos profissionais prestadores de serviço (STF, TST e TSE) (peça 28).
10.2.3 A única resposta da TIControle com informações acerca de cargos e salários foi a
do CNJ, que indicou o seu Contrato CNJ nº 49/2011, atualmente em seu 6º Termo Aditivo
(peça 29). A qualificação exigida para cada cargo (perfil profissional) encontra-se no
Anexo A ao Contrato (peça 29, páginas 21 a 23), enquanto a remuneração vigente para o
período de 26/1/2015 a 25/1/2016 encontra-se no Anexo B-I ao 6º Termo Aditivo (peça
29, página 40).
10.2.4 Os perfis profissionais contidos no Contrato CNJ nº 49/2011 similares ao da

contratação em tela e suas respectivas remunerações são as seguintes:
Perfil Profissional (CNJ) Remuneração (R$)
Arquiteto de Software 7.694,58
Analista de Sistemas Sênior 7.093,44
Analista Desenvolvedor Sênior 5.770,94
10.2.5 Contudo, ao analisar a qualificação mínima exigida para esses perfis, percebeu-se
o seguinte:
a) apesar do termo “Analista” em sua descrição, para o perfil “Analista Desenvolvedor

Sênior” exige-se somente conhecimentos de desenvolvimento / programação, e
não de análise de sistemas;
b) o perfil “Analista de Sistemas Sênior” também possui qualificação exigida de

desenvolvimento / programação, o que o torna similar ao cargo descrito como
“Analista Desenvolvedor Sênior”;
c) o perfil “Arquiteto de Software” possui qualificação bastante similar a de “Analista

de Sistemas Sênior”, distinguindo-se basicamente pela exigência de tempo mínimo
de experiência com a plataforma tecnológica Java2EE (6 meses) e pelo acréscimo
27
de experiência mínima de 6 meses no framework JBoss Seam, que é uma

biblioteca de software utilizada para construção de aplicativos para a Web em
Java.
10.2.6 Portanto, pela diferença de qualificação exigida entre o perfil “Arquiteto de

Software” e “Analista de Sistemas Sênior”, entende-se que o Arquiteto pode ser
considerado, ao menos no âmbito da referida contratação do CNJ, como um Analista
Desenvolvedor mais qualificado que o de nível Sênior.
10.2.7 Ademais, ao comparar a qualificação dos perfis do Contrato CNJ nº 49/2011 com o
exigido para o Analista Programador Sênior da contratação em tela (peça 5 – Item 5.4),
tem-se que a qualificação mínima a ser aceita pelo Tribunal é superior até ao perfil
“Arquiteto de Software” da contratação do Conselho Nacional de Justiça.
10.2.8 Por este motivo e pelo fato de não haver perfil profissional com qualificação
superior no mencionado Contrato CNJ, entende-se mais adequado utilizar a remuneração
do perfil “Arquiteto de Software” nesta pesquisa de preços do que a remuneração do perfil
“Analista de Sistemas Sênior”, apesar da denominação deste último perfil possuir maior
similaridade com a da contratação do TCU.
Perfil Profissional (CNJ) Remuneração (R$)
Arquiteto de Software 7.694,58
10.2.9 Além dessa contratação do CNJ, outro contrato público útil para balizar o
levantamento de preços na Administração Pública ora realizado é o Contrato nº 20/2013
do próprio TCU (peças 30 e 31).
10.2.10 Nesta contratação do Tribunal, exigiu-se qualificação mínima para

profissionais que compõe a chamada equipe-chave da empresa contratada (peça 31, item
5.13, páginas 48 a 51) e a remuneração dos profissionais prestadores de serviço foi
apresentada no âmbito do primeiro processo de repactuação (TC 013.694/2014-6), que
determinaria os valores válidos para o período de 20/05/2014 a 19/05/2015.
10.2.11 No rol de profissionais da equipe-chave (peça 31, item 5.13, páginas 48 a

51), não há perfil denominado de “Analista Programador Sênior”, como especificado na
contratação em tela (peça 5 – Item 5.4). Porém, assim como ocorrido na comparação com
o Contrato CNJ nº 49/2011, percebe-se que a qualificação ora exigida para o prestador de
serviço é superior a do perfil “Arquiteto de Software” previsto no Contrato TCU nº 20/2013.
10.2.12 Portanto, assim como foi feito com o referido Contrato CNJ, esta pesquisa
de preços considerará a remuneração do perfil “Arquiteto de Software” no lugar do perfil
“Analista de Sistemas Sênior” deste contrato do TCU.
28
10.2.13 Quanto ao valor a ser considerado, toma-se inicialmente a remuneração

sugerida na instrução da Dicad (peça 32) para o período de 20/05/2014 a 19/05/2015, que
é de R$ 6.174,41.
10.2.14 Considerando que novo processo de repactuação do referido Contrato TCU

(TC 016.712/2015-3) ainda se encontra em estágio preliminar de instrução, para se obter
remuneração aproximada da que seria a praticada atualmente, o valor sugerido pela
Dicad será corrigido utilizando a variação do IPCA acumulada entre 05/2015 e 02/2016.
Utilizando-se a “Calculadora do cidadão” disponível no site do Banco Central
(www.bcb.gov.br), chega-se ao valor de R$ 6.677,67.
10.2.15 Adicionalmente, com o intuito de encontrar outras referências de valores

praticados pela Administração Pública, recorreu-se à Secretaria de Logística e Tecnologia
da Informação (SLTI) do Ministério do Planejamento, Orçamento e Gestão - MPOG, pela
sua função como órgão central do Sistema de Administração dos Recursos de Tecnologia
da Informação – SISP que congrega atualmente cerca de 260 instituições públicas.
10.2.16 A resposta obtida do SISP (peça 33) fez referência a pregão recente da
Diretoria de Tecnologia da Informação do próprio MPOG (04/2015), no qual foi feita
diligência às licitantes questionando os perfis profissionais que prestariam o serviço de
desenvolvimento de software a ser contratado com a respectiva remuneração.
10.2.17 Nas respostas enviadas pelas empresas (peça 34), não há o perfil “Analista
de Sistemas” ou “Analista Programador” de nível Sênior, e também não há informações
acerca da qualificação de cada perfil profissional informado. Desta forma, visando obter
remuneração aproximada do perfil exigido na contratação em tela, optou-se por seguir a
regra adotada na análise dos contratos do CNJ e do próprio TCU e foram considerados os
valores apresentados para o cargo (competência) de “Arquiteto de Software”:
Empresa Remuneração (R$)
Basis (peça 34 – página 4) 7.000,00
G & P (peça 34 – página 9) 7.500,00
MK (peça 34 – página 14) 5.300,00
Média 6.600,00
10.2.18 No âmbito desta pesquisa, encontrou-se ainda o pregão 22/2015 do

Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPq, agência do
Ministério da Ciência, Tecnologia e Inovação – MCTI (peça 45). No edital deste certame,
foram definidos requisitos mínimos para perfis profissionais envolvidos no serviço de
desenvolvimento de software (peça 45, páginas 81 e 82), dentre eles os de Analista de
Sistemas e de Arquiteto de Software. E com o intuito de auxiliar as empresas licitantes na
29
formulação de suas propostas, o CNPq divulgou os salários praticados no contrato com

objeto similar atualmente vigente (peça 45 – página 212).
10.2.19 Assim como ocorreu no comparativo realizado com a contratação do CNJ,

entende-se que a qualificação exigida para estes dois perfis na licitação do CNPq é
inferior a ora exigida para o perfil Analista Programador Sênior (peça 5 – Item 5.4). Desta
forma, será adotado o mesmo critério para efeito de estimativa de preços, que é o de
considerar o salário vigente do perfil Arquiteto de Software da contratação do CNPq, e
não o do perfil Analista de Sistemas Sênior.
10.2.20 Para isso, será feita a média aritmética do salário praticado para o perfil
Arquiteto de Software nas duas espécies do serviço contratado:
Perfil Espécie do Serviço Remuneração (R$)
Manutenção Adaptativa, Perfectiva e 9.323,32

Corretiva
Arquiteto de Software
Manutenção Evolutiva 7.987,50
Média 8.655,41
10.2.21 Consolidando as informações obtidas a partir dos contratos dos quatro

órgãos públicos (CNJ, TCU, MPOG e CNPq), temos o seguinte:
Órgão Remuneração (R$)
CNJ 7.694,58
TCU 6.677,67
MPOG 6.600,00
CNPq 8.655,41
Média 7.406,92
10.3 Levantamento de cargos e salários junto a sindicatos
10.3.1 Buscando ampliar a pesquisa de remuneração praticada no mercado, foram

enviadas mensagens para o Sindicado dos Trabalhadores de Empresas e Órgãos
Públicos e Privados de Processamento de Dados, Serviços de Informática, Similares e
Profissionais de Processamento de Dados do Distrito Federal – SINDPD-DF (peça 35) e
para o Sindicado das Empresas de Serviços de Informática do Distrito Federal - Sindsei-
30
DF (peça 36) questionando se os sindicatos poderiam apoiar de alguma forma esta

pesquisa.
10.3.2 As mensagens foram enviadas no dia 3/8/2015 e, em virtude da ausência de

resposta, foram reiteradas no dia 11/8/2015, aplicando por analogia o disposto na
Portaria-TCU 128/2014, art. 11, inc. I.
10.3.3 Não havendo resposta dos sindicatos até o término do restante dos estudos
técnicos preliminares, optou-se por prosseguir com o processo licitatório com os valores
obtidos de outras fontes, aplicando também por analogia o disposto na Portaria-TCU
128/2014, art. 11, inc. II.
10.4 Remuneração dos profissionais nas propostas de fornecedores
10.4.1 No âmbito da pesquisa de mercado, foram solicitadas propostas comerciais para a

contratação em tela a várias empresas do ramo (peça 38). Passados mais de 5 dias úteis,
a solicitação foi reiterada para aqueles fornecedores que não se manifestaram, em
atenção ao inc. I do art. 11 da Portaria-TCU 12/2014 (peça 39).
10.4.2 Dentre as propostas de fornecedores recebidas (peças 40 a 44), apesar de ter sido
solicitada proposta detalhada, somente uma (peça 42, página 11) detalhou sua planilha
de composição de custos e estimou o salário a ser pago para os seus profissionais.
Empresa Remuneração (R$)
Stefanini (peça 42, página 11) 11.800,00
10.5 Cálculo da remuneração mínima
10.5.1 Para o cálculo da remuneração mínima a ser aceita para o profissional terceirizado,
serão consideradas as médias das remunerações levantadas junto às empresas de
pesquisa de cargos e salários, dos valores praticados na Administração Pública e das
remunerações informadas nas propostas de fornecedores, conforme quadro a seguir:
Fonte Remuneração (R$)
Empresas de pesquisa 10.138,39
Administração Pública 7.406,92
Propostas de fornecedores 11.800,00
Média 9.781,77
10.6 Cálculo da estimativa de preço

31
10.6.1 Considerando que somente uma empresa apresentou proposta com planilha
detalhada de composição de custos, a estimativa total do valor da contratação foi obtida
por média aritmética das propostas apresentadas, aplicando-se, por analogia, o disposto
no art. 9º da Portaria 128/2014.
10.6.2 Como justificativa, cabe ressaltar que o objeto da contratação não parece ser
propício ao chamado “jogo de planilhas”. Por exemplo, se um fornecedor reduzir seu
percentual de lucro mas majorar o valor atribuído a outros itens (ex: custos indiretos) de
sua composição de preços, não terá como posteriormente aumentar o volume de
execução somente destes outros itens para elevar sua remuneração total em detrimento
do interesse público.
10.6.3 Por este motivo, entende-se que a adoção da fórmula de cálculo do referido art. 9º
da Portaria 128/2014 para obtenção do valor total estimado da contratação não trará risco
significativo ao procedimento de seleção da proposta mais vantajosa para à
Administração.
10.6.4 Neste sentido, os preços ofertados nas propostas dos fornecedores foram
consolidados no quadro a seguir:
Empresa Valor unitário mensal (R$)
CTIS (peça 40) 235.520,00
Cast (peça 41) 289.236,86
Stefanini (peça 42) 177.891,01
Indra (peça 43) 146.080,22
Tecnisys (peça 44) 217.927,78
Média 213.331,17
10.6.5 Com este valor unitário mensal estimado, estimativa total de preço da contratação
é a seguinte:
Valor unitário Valor unitário Valor total

Nº Item Qtd Unidade
mensal (R$) anual (R$) anual (R$)
Serviço de desenvolvimento Equipe

1 4 213.331,17 2.559.974,08 10.239.896,32
de software com práticas ágeis técnica
10.7 Critérios de aceitabilidade das propostas
32
10.7.1 Adicionalmente ao disposto na Lei 8.666/93, art. 44, § 3º e art. 48, serão
desclassificadas propostas que:
 Apresentarem valor global superior ao estimado pelo Tribunal;
 Não respeitarem a remuneração mínima para o perfil profissional

denominado “Analista Programador Java nível Sênior” estabelecida no Edital;
 Informarem valores de tributos incompatíveis com a legislação vigente.
11 Condições do edital
11.1 Modalidade e tipo de licitação
11.1.1 Entende-se que o serviço a ser contratado é considerado serviço comum nos
termos do § 2o do art. 3º do Decreto 3.555/2000 e, desta forma, a modalidade de licitação
deve ser o pregão, preferencialmente na forma eletrônica, com tipo “menor preço”.
11.2 Ata de Registro de Preço, IRP e Adesão Tardia
11.2.1 Apesar da demanda potencial para o objeto a ser contratado (item 7 deste
documento), ainda não é possível determinar precisamente o volume de serviço que será
necessário. Prevê-se que o serviço será solicitado na medida que o Tribunal priorizar
novos projetos com base em seus critérios institucionais e se organizar para executar,
fiscalizar e gerenciar o contrato.
11.2.2 Desta forma, com fulcro no Decreto 7892/2013, art. 3º, inciso IV, solicita-se que o
presente processo licitatório resulte em ata de registro de preço.
11.2.3 Todavia, entende-se que as características do objeto são muito específicas para as
necessidades do Tribunal de tal forma que o serviço a ser contratado não poderia ser
transposto para outro ente público sem as devidas adaptações ou sem incorrer em riscos
advindos das realidades distintas existentes nos órgãos da Administração Pública
Federal.
11.2.4 Como exemplos de peculiaridades do TCU, pode-se citar o nível de exigência de

qualidade do código-fonte, a qualificação exigida do prestador de serviço, as práticas
ágeis adotadas, entre outros.
11.2.5 Desta forma, sugere-se que não seja publicada Intenção de Registro de Preço para
este certame. No mesmo sentido, solicita-se que não seja previsto nenhum quantitativo
para adesão por outro órgão público após o registro de preços (adesão tardia).
11.3 Prazo para abertura da sessão pública
11.3.1 Considerando o caráter inovador do modelo de contratação ora proposto, solicita-

se que haja ao menos 12 dias úteis de prazo entre a publicação do edital e a abertura da
sessão pública do pregão, para que haja tempo hábil para as licitantes estudarem o edital,
33
enviarem eventuais questionamentos à comissão de licitação do Tribunal e formularem

adequadamente suas propostas de preço.
11.4 Parcelamento do objeto, subcontratação e possibilidade de participação de

consórcio na licitação
11.4.1 Em relação a eventual parcelamento do objeto, cabe inicialmente reproduzir trecho

do voto condutor do Acórdão nº 1.214/2013-TCU-Plenário:
22. No caso dos serviços terceirizados, a partir da experiência relatada pelos

agentes públicos que participaram do grupo de estudos, como regra, não se revela
benéfico o parcelamento para a execução de serviços com menor nível de
especialização, como aqueles prestados por garçom, mensageiro, motorista,
recepcionista etc. Isso porque as empresas que atuam no mercado prestam todos
esses tipos de serviço, sendo especializadas não em algum deles especificamente,
mas na administração de mão de obra. Assim, um eventual parcelamento não
ampliaria a competitividade das licitações e potencialmente aumentaria o custo da
contratação, uma vez que se empresas diversas ganharem a prestação de
diferentes serviços dessa natureza, o custo fixo por posto de trabalho será maior.
Além disso, aumentaria a dificuldade de gerenciamento dos contratos por parte da
administração, que teria de se relacionar com um maior número de empresas.
23. Situação diferente apontada pelo grupo ocorre no caso da prestação de

serviços técnicos, com maior grau de especialização, como de manutenção predial,
serviços de engenharia em geral, informática etc., cujas empresas prestadoras
atuam de forma segmentada no mercado. Nesses casos, como regra, o
parcelamento trará uma maior competitividade aos certames, com a tendência de
obtenção de melhores preços e a possibilidade de contratações de empresas mais
especializadas que, potencialmente, prestarão serviços de melhor qualidade.
(grifou-se)
11.4.2 Portanto, quanto a eventual parcelamento do objeto, entende-se que a contratação

em tela segue diretriz estabelecida no referido Acórdão ao contratar serviço de
desenvolvimento de software de forma destacada de outros serviços com menor grau de
especialização.
11.4.3 Adicionalmente, em linha com o trecho grifado do mencionado voto, entende-se

que eventual parcelamento do objeto em lotes, apesar de teoricamente possível, traria
risco de majorar o custo por posto de trabalho para o Tribunal por redução de ganhos de
escala não compensados por efetivo aumento de competição no certame.
11.4.4 Nesta mesma esteira, entende-se que o objeto da contratação em tela não possui
complexidade que necessite de subcontratação ou permissão para participação de
consórcios para ampliar a disputa na licitação.
34
11.4.5 Por este motivo, sugere-se ainda que não seja permitida a subcontratação neste
contrato nem a participação de consórcios neste certame.
11.5 Requisitos de habilitação técnica-operacional e econômica-financeira
11.5.1 Requisitos de qualificação técnico-operacional
11.5.1.1 Sugere-se que a licitante deva atender os seguintes requisitos de

qualificação técnico-operacional para habilitação no certame:
 Comprovação de, no mínimo, 3 (três) anos de experiência na execução de serviços

de desenvolvimento de software, comprovados por meio de atestados ou
declarações de capacidade técnica, cópias de contratos, registros em órgãos
oficiais, ou outros documentos idôneos.
11.5.1.2 Sugere-se a exigência de qualificação técnica-operacional com fulcro na

alínea a do inciso I do art. 13 da Portaria-TCU nº 128/2014, que dispõe sobre a licitação e
a execução de contratos de serviços no âmbito da Secretaria do Tribunal.
11.5.2 Requisito de qualificação econômico-financeira
11.5.2.1 Considerando a necessidade de investimentos significativos da empresa

após a assinatura do contrato e antes que tenha direito a algum pagamento por parte do
Tribunal, sugere-se a exigência da comprovação de qualificação econômico-financeira da
licitante nos termos do inciso III do art. 13 da Portaria TCU nº 128/2014, com a seguinte
adequação em relação à exigência referente ao Patrimônio Líquido:
Patrimônio Líquido igual ou superior a 1/12 (um doze avos) do valor total dos
contratos firmados com a Administração Pública e com a iniciativa privada cujo
objeto seja prestação de serviços mediante a disponibilização de empregado de
maneira exclusiva, na forma de posto de trabalho, vigentes na data da sessão
pública de abertura deste Pregão.
11.5.2.2 Considerando que atualmente a prestação de serviços de desenvolvimento

de software para o setor público, em regra, não utiliza o modelo popularmente
denominado de “terceirização” como definido no inciso I do art. 2º da referida Portaria
TCU nº 128/2014, e que é comum que a mesma empresa que preste este serviço
também mantenha contratos com objetos de outra natureza (ex: serviço de suporte
técnico e atualização de versão de software, contrato de fornecimento de equipamentos
ou de licenças de software, etc), procurou-se ajustar o requisito de qualificação
econômico-financeira para as especificidades da contratação em tela, observando o
espírito desta exigência, conforme item “III.a – Qualificação econômico-financeira” do
relatório vinculado ao Acórdão nº 1.214/2013-TCU–Plenário.
35
12 Providências para adequação do ambiente do órgão

12.1. Considerando que a prestação de serviço será feita presencialmente, será
necessário providenciar espaço físico, mobiliário e equipamentos para uso pelos
profissionais da empresa contrata.
12.2. Adicionalmente, será necessário criar contas de rede para estes profissionais e
conceder acesso aos repositórios de arquivos e demais serviços de TI necessários ao
desempenho de suas atividades, respeitando a política de segurança da informação do
Tribunal.
13 Análise de risco
Probabil. Ações de mitigação ou Responsáveis Período de
No. Descrição do Risco Impacto
Ocorrência contingência pelas ações Execução
1 Inadequação do Média Alto Limitação do volume de STI, AdgeTI Planejamento
modelo de contratação serviços contratados. da
contratação.
Discussão e construção
do modelo com apoio de
outras unidades do
Tribunal.
2 Prestador de serviço Média Alto Exigência no Termo de STI Planejamento
com qualificação Referência de da
insuficiente qualificação para todos contratação.
os prestadores de
serviço.
Fixação de limites
salariais mínimos para
os profissionais.
3 Falha na estratégia de Baixa Alto Discussão e construção STI, AdgeTI, Planejamento
execução do contrato da estratégia de Seginf, e execução
execução contratual Adgepres, da
com as unidades Seadmin contratação.
envolvidas.
4 Preço inexequível Baixa Alto Fixação de limites STI Planejamento
salariais mínimos para da
os profissionais. contratação.
5 Ausência de espaço Média Alto Solicitação dos recursos STI Planejamento
físico, mobiliário e necessários à Segedam da
equipamentos para os e à Setic com a devida contratação.
prestadores de serviço antecedência.
6 Ausência de equipe da Média Alto Discussão e construção STI, AdgeTI, Planejamento
STI necessária à da estratégia de Seginf, da
execução contratual execução contratual Adgepres, contratação.
com as unidades Seadmin
envolvidas.
7 Gestor da solução Baixa Alto Avaliar a disponibilidade STI, AdgeTI, Execução do
(Product Owner) de TI do gestor no momento Seginf, contrato.
a ser desenvolvida da seleção do projeto a Adgepres,
sem a disponibilidade ser desenvolvido com o Seadmin
necessária para serviço contratado.
acompanhar o projeto.
8 Baixa maturidade dos Baixa Alto Avaliar a maturidade STI, AdgeTI, Execução do
requisitos de negócio dos requisitos no Seginf, contrato.
da solução a ser momento da seleção do Adgepres,
desenvolvida com o projeto a ser Seadmin
serviço contratado. desenvolvido com o
serviço contratado.
36
14 Relação entre o objeto da contratação em tela e o objeto do

Contrato TCU nº 20/2013
14.1. Considerando a vigência do Contrato TCU nº 20/2013 cujo objeto é a prestação de
serviços presenciais e não presenciais de desenvolvimento, manutenção e testes de
sistemas de informação, entende-se oportuno esclarecer a sua relação com a contratação
ora solicitada.
14.2. Conforme já mencionado neste documento, no decorrer da execução do referido
contrato identificaram-se situações nas quais a contratação de serviço de
desenvolvimento de software prevendo adoção de metodologia ágil seria mais apropriada,
em contraposição à metodologia tradicional prevista no Contrato TCU nº 20/2013.
14.3. Em outras situações, entretanto, o modelo de prestação de serviço definido no
contrato vigente se mostrou satisfatória, a ponto inclusive do Tribunal ter prorrogado a sua
vigência até maio de 2016.
14.4. Cabe destacar que a metodologia de desenvolvimento de software adotada
diferencia significativamente as características do serviço, a ponto do Tribunal entender
que eventual mudança na metodologia prevista em contrato público se enquadra como
alteração de objeto e, portanto, afronta o princípio da vinculação ao instrumento
convocatório instituído no art. 3º da Lei 8.666/1993 (Acórdão 3051/2013 – TCU –
Plenário).
14.5. Ademais, a escolha de qual serviço utilizar (o previsto no Contrato TCU nº 20/2013
ou no contrato resultante do processo licitatório em tela) não será feito de modo arbitrário
pela STI. A decisão será baseada na metodologia que se acreditar mais adequada para o
caso concreto.
14.6. Adicionalmente, outra razão para manutenção do Contrato TCU nº 20/2013 é a
abrangência neste instrumento contratual vigente de plataformas tecnológicas não
previstas no âmbito desta nova contratação, como EPM/Sharepoint, BI, ASP, entre outros
14.7. Pelo exposto, entende-se não haver impedimento para o convívio do contrato
derivado deste processo com o Contrato TCU nº 20/2013.
15 Declaração de viabilidade da contratação

15.1. Considerando os estudos realizados, a fundamentação aduzida aos autos
relativamente às necessidades a serem atendidas, ao alinhamento com o planejamento
institucional, ao levantamento de preços junto a empresas fornecedoras e também
considerando a previsão no orçamento de 2015 dos recursos financeiros necessários, a
equipe manifesta-se pela viabilidade da presente proposta de contratação.
Brasília, em 13 de abril de 2016
37
Assinam eletronicamente o documento:

Equipe de Planejamento da Contratação
André Augusto Siqueira – matrícula 9313-0
Eric Hans Messias da Silva – matrícula 9652-0
George Atsushi Murakami – matrícula 8120-5
Vitor Machado Ferreira – matrícula 8583-9
De acordo
Rodrigo César Santos Felisdório
Secretário da STI
38
Anexo I – Bibliografia
Bibliografia
Rubin, Kenneth S. Essential Scrum: A Practical Guide to the Most Popular Agile Process. Addison-Wesley
Professional. 2012. (Disponível na biblioteca virtual Safari Books Online)
39

02 ETP Contratacao Servico Desenvolvimento Software Praticas Ageis Versao 22

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

02 ETP Contratacao Servico Desenvolvimento Software Praticas Ageis Versao 22

Hochgeladen von

Copyright:

Verfügbare Formate

TRIBUNAL DE CONTAS DA UNIÃO

1 Objeto a contratar ......................................................................................................... 3

2 Equipe de planejamento da contratação ....................................................................... 3

3 Necessidade da contratação e alinhamento com o planejamento institucional ............ 3

4 Resultados pretendidos ................................................................................................ 5

5 Justificativa da escolha do tipo de solução e proposta de modelo de contratação

6 Modelo de remuneração e demais requisitos da contratação ....................................... 8

7 Relação entre a demanda prevista e a quantidade a ser contratada .......................... 20

8 Modelo de execução do objeto ................................................................................... 21

8.1 Solicitação, execução e acompanhamento de serviços .............................................................. 21

8.2 Segurança da informação........................................................................................................... 23

8.3 Medidas de sustentação dos sistemas produzidos..................................................................... 23

9 Modelo de gestão contratual ....................................................................................... 24

9.1 Vigência do contrato .................................................................................................................. 24

9.2 Natureza do serviço ................................................................................................................... 24

9.3 Garantia de execução do contrato ............................................................................................. 25

9.4 Garantia dos produtos e serviços ............................................................................................... 25

9.5 Repactuação .............................................................................................................................. 25

10 Orçamento estimado ............................................................................................... 25

10.1 Levantamento de cargos e salários no mercado ........................................................................ 25

10.2 Levantamento de cargos e salários na Administração Pública ................................................... 26

10.3 Levantamento de cargos e salários junto a sindicatos ............................................................... 30

10.4 Remuneração dos profissionais nas propostas de fornecedores ................................................ 31

10.5 Cálculo da remuneração mínima ............................................................................................... 31

10.6 Cálculo da estimativa de preço .................................................................................................. 31

10.7 Critérios de aceitabilidade das propostas .................................................................................. 32

11 Condições do edital ................................................................................................. 33

11.1 Modalidade e tipo de licitação ................................................................................................... 33

11.2 Ata de Registro de Preço, IRP e Adesão Tardia .......................................................................... 33

11.3 Prazo para abertura da sessão pública ....................................................................................... 33

11.4 Parcelamento do objeto, subcontratação e possibilidade de participação de consórcio na

11.5 Requisitos de habilitação técnica-operacional e econômica-financeira ..................................... 35

12 Providências para adequação do ambiente do órgão.............................................. 36

13 Análise de risco ....................................................................................................... 36

14 Relação entre o objeto da contratação em tela e o objeto do Contrato TCU nº

15 Declaração de viabilidade da contratação ............................................................... 37

Contratação de serviço de desenvolvimento de

Estudos Técnicos Preliminares

2 Equipe de planejamento da contratação

3 Necessidade da contratação e alinhamento com o planejamento

3.4. Atualmente, já existe considerável quantidade de demandas aguardando

3.5. Considerando sua importância para a instituição, a referida necessidade de ampliar

DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO

3.6. Cabe destacar que o atendimento desta necessidade é extremamente relevante

OBJETIVOS ESTRATÉGICOS (Fonte: PLANO ESTRATÉGICO DO TCU 2015 ~ 2021)

Assegurar suporte de bens e serviços adequado às necessidades do TCU

DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO (Fonte: PDTI 2015 ~ 2016)

DIRECIONADORES DE TECNOLOGIA DA INFORMAÇÃO (Fonte: PDTI 2015 ~ 2016)

6) Adoção progressiva de inovações tecnológicas ao processo de comunicação institucional e às soluções e

8) Favorecer a transparência governamental e a prestação de serviços eletrônicos

Art. 6º As atividades da Administração Federal obedecerão aos seguintes princípios

4.3. Considerando ainda o entendimento da Súmula-TCU 97, cabe destacar que a

rol de atribuições do cargo de Auditor Federal de Controle Externo, especialidade

Art. 9° As atribuições do cargo de Auditor Federal de Controle Externo, especialidade

5 Justificativa da escolha do tipo de solução e proposta de modelo

Contrato 53/2013: solução de data discovery (em uso na DGI);

d) Não se conhece métrica associada a produto de software com

6 Modelo de remuneração e demais requisitos da contratação

6.4. Porém, dados os requisitos necessários para adoção de metodologias ágeis no

6.6. Trata-se, portanto, do que tem sido denominado de modelo híbrido na

Conforme verificado nos argumentos apresentados pela Infraero e nos termos

Verifica-se um modelo híbrido na execução dos serviços a serem contratados, já

É possível identificar que os procedimentos adotados pela Infraero estão em

Dessa forma, em que pese a mensuração dos serviços não se basear em