Este documento discute como contratar uma fábrica de software de forma a garantir bons resultados e qualidade, evitando armadilhas comuns. Ele sugere usar métricas próprias em vez de pontos de função, definir claramente os papéis de Product Owner e Líder Técnico, e estruturar o trabalho em sprints e entregas contínuas para manter o engajamento do cliente. Também trata da importância de exigir perfis qualificados e experiência dos desenvolvedores, e remunerar atividades cruciais como refatoração e

1. Como acertar na contratação de
fábrica de software
Não deixe a 8.666 te atrapalhar !
Yuri Morais
yuri.morais@senado.leg.br

2. Quem é esse?
Yuri Morais
• Analista de TI no Senado
• Líder de projetos ágeis
• Mestre em Computação (UFPB)
Certificações: Scrum Master, Product Owner, ITIL, Java
Professor
Ex-Auditor

3. O que eu gostaria no meu contrato...

4. • The best developer is 10x
better than an average
developer
• General skills: complete
job, start to finish
– Avoid specialization

5. Expectativa
Realidade

6. REALIDADE...
• Tenho que usar Pontos de Função?
• Vou “aceitar mudanças” e pagar tudo em
dobro?
• Ninguém quer ser fiscal desse contrato
• Meu cliente não se engaja
• O software funciona, mas a qualidade...
• Os desenvolvedores mudam
constantemente / são inexperientes

7. Tenho que usar
Pontos de Função ?

8. Ponto de Função não é obrigatório
• O importante é vincular aos resultados
– Acórdão TCU 2362/2015 e Súmula-TCU 269
• Criamos uma métrica própria (UST)
• O que é remunerável? (exemplos)
Telas
Relatórios jasper
Comportamentos
Regras de negócio
Integrações
Estruturas de dados
Reuniões Scrum
Testes BDD
Requisitos (reuniões)
Requisitos (escrita de
histórias)

9. O que ganhamos com isso?
• Não precisamos de especialistas em APF
• Pagamentos mais adequados
– Principalmente nas mudanças
• Revisões do repertório de UST
– Permitido a cada 6 meses
– Fizemos uma revisão em janeiro/2019
Fizemos uma nota técnica justificando as mudanças recorrentes

10. Eu não quero ser fiscal...

11. Atores - fiscalização descentralizada
Gestor Fiscal
Líder Técnico (TI)
+
P.O. (negócio)
Líder Técnico
+
P.O. (negócio)
Senado
Empresa Time 1 Time 2 Time 3

12. Quem define os Requisitos?
• Product Owner (representa os clientes)
– direciona o projeto, prioriza o que será
feito, conversa com as áreas envolvidas,
cuida do patrocínio do projeto
• Líder Técnico (representa a TI)
– influencia e orienta o PO, detalha os
requisitos num nível mais técnico
– define estratégias de desenvolvimento junto
à equipe de desenvolvimento
– Acompanha diariamente o time de desenvolvimento

13. Meu cliente não se
engaja

14. Preparação para início de projetos
Definir PO e Líder
técnico
Visão do produto
Primeiras entregas com
requisitos claros
PO é “treinado” no
processo Scrum
Impactos mapeados
(mudanças organizacionais)
Tecnologia
conhecida
Baseado no

15. Mantendo o fluxo contínuo
Sprint 1OS1 Sprint 2OS2 Sprint XOSX
Requisito
preparado
(ready)
Requisito
preparado
(ready)
Projeto = Sequência de Ordens de Serviço
PO
Backlog
Visão
Roadmap

16. Os desenvolvedores
mudam
constantemente
/ são inexperientes...

17. Perfil profissional e Qualidade
• Exigência de perfil
– Experiência + Certificação
– Fullstack: não gostamos de especializações
• Turnover é “penalizado” (nível de serviço)
• Qualidade de código medida pelo Sonar
– também por code review (quando necessário)
– Inclui cobertura de testes

18. Remuneração de atividades importantes
Refatoração
Fator = 50%
Dados sensíveis
Fator = 150% a 200%
Prototipar uma hipótese
4 a 40 UST
Ajustar ambiente
4 a 24 UST
Feedback e adaptação
( ≠ retrabalho)

19. Oportunidades de melhoria
• Tabela de UST não é exata
• passível de interpretação caso a caso
• Viabilidade do modelo para “pequenas
manutenções”
• Dificuldades com equipes remotas
• Queremos ser uma fábrica de features ?
• Como integrar Design/UX ao processo ?
• Métrica: Posto de trabalho voltou?

20. yuri.morais@senado.leg.br
/in/yuri-morais/
slideshare.net/yurimorais Agosto/2019