SlideShare una empresa de Scribd logo
1 de 23
Quanto custa ou quanto
vale?
A experiência do Banco Central
Brasília, agosto de 2017.
Os Princípios
Mais esforço para entregas do que para métricas.
Mais incentivo a qualidade do que a quantidade.
Mais interações entre pessoas do que entre documentos.
Mais prazos acordados do que prazos derivados.
“Mesmo havendo valor nos itens à direita, valorizamos mais
os itens à esquerda.”
Os Princípios
O valor dos projetos entregues... e não só o custo
Estamos investindo nos projetos certos?
As métricas significativas... e não só as “objetivas”
Estamos medindo o que deveria ser medido?
A comunicação... e não só a documentação
Estamos gerando documentação útil sem burocracia?
Conclusão
Nós não vamos resolver o paradoxo do
“lucro-incompetência” enquanto a
remuneração estiver atrelada somente a
métricas “objetivas” baseadas puramente em
esforço, quantidade ou complexidade.
Histórico muito resumido
• 2008: piloto ágil
• 2012: primeiro contrato com “inspiração ágil”
• 2013: o PDS-BC Ágil é, formalmente, o único processo de
desenvolvimento corporativo
• 2014: estabelecidos critérios de priorização de projetos
• 2015: fim do primeiro contrato com “inspiração ágil”
• 2016: publicado PDTI 2016-2019
• 2017: segundo contrato com “inspiração ágil”
• 2017-: entregas, entregas, entregas...
Desafios
O que é o valor de um produto?
• É o custo do trabalho para fazê-lo?
• É a sua utilidade?
• É o seu retorno do investimento?
• É o seu significado?
• É objetivo ou subjetivo?
O que é o valor de um produto?
Any organization that designs a system (defined
broadly) will produce a design whose structure is a
copy of the organization's communication structure.
Conway’s Law, 1967
É difícil.
Conclusão
Lá no Bacen...
Agile Trends Gov 2017 - Quanto custa ou quanto vale?
Lista de Priorização
Projeto Cliente
Pontuação
Técnica
Prazo
Previsto
1IntegraBC - Autorizações DEORF 78,00 24
2BcJur3 - Gestão de Créditos PGBCB 74,76 24
32017 Integração e-BC DEMAP 66,88 13
4Estrutura de Planejamento e Acompanhamento da Difis DEGEF 64,58 22
5Observa – BC DECON 62,18 43
6Automação de Processos da Supervisão DEGEF 61,14 46
7RDE-ROF - Empréstimos e Títulos DEPEC 58,36 11
8Atualização tecnológica do STR 2 DEBAN 57,68 16
9Integração das Informações de Monitoramento - I2M DESIG 56,18 10
10Conexão eSocial DEPES 55,76 18
Agile Trends Gov 2017 - Quanto custa ou quanto vale?
Agile Trends Gov 2017 - Quanto custa ou quanto vale?
Cultura de Projetos e Cultura de Entregas
O valor das entregas... e não só dos projetos
As entregas estão ocorrendo (só) nos projetos?
Cultura de Projetos e Cultura de Entregas
Entrega em produção?
SPI
0,85
CPI
0,85
Priorização de Histórias
𝑨𝑶𝑳 =
𝑯𝑼 𝒑𝒓𝒐𝒏𝒕𝒂𝒔
𝑯𝑼 𝒑𝒓𝒆𝒗𝒊𝒔𝒕𝒂𝒔
=
𝟖𝟐
𝟗𝟐
= 𝟎, 𝟖𝟗
Conclusão
Desempenho também pode ser feedback.
Indicador de
Avaliação de
Desempenho
1,12
Abr/17 a Jul/17 Ago/17
0,250,500,751,00>1
Conclusão
Remunerar por resultado significa remunerar
por valor entregue, não (ou não só) pelo
custo da solução.
O tripé do contrato: Custo + Desempenho + Valor
Mais desafios
• Incentivos
• Métodos
• Gestão
• Desempenho
• Normativos
• Cultura, cultura e cultura...
Obrigado!
When the best leader's work is done the
people say “We did it ourselves”.
Lao Tzu
Apresentação de 2016:
https://pt.slideshare.net/eduweller/agile-trends-br-gov-2016-o-caminho-da-iluminao
eduardo.weller@bcb.gov.br

Más contenido relacionado

Similar a Agile Trends Gov 2017 - Quanto custa ou quanto vale?

Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)
Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)
Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)Alessandro Almeida
 
Apresentacao dox
Apresentacao doxApresentacao dox
Apresentacao doxthathyna
 
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesTDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesMauricio Bitencourt, CBPP
 
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...Mauricio Bitencourt
 
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014Alessandro Gonçalves
 
Governança de TI.pptx
Governança de TI.pptxGovernança de TI.pptx
Governança de TI.pptxssusera0a510
 
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesBPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesMauricio Bitencourt, CBPP
 
Gestão de Projetos e Empreendedorismo (23/04/2014)
Gestão de Projetos e Empreendedorismo (23/04/2014)Gestão de Projetos e Empreendedorismo (23/04/2014)
Gestão de Projetos e Empreendedorismo (23/04/2014)Alessandro Almeida
 
Agile Trends BR Gov 2016 - O caminho da iluminação
Agile Trends BR Gov 2016  - O caminho da iluminaçãoAgile Trends BR Gov 2016  - O caminho da iluminação
Agile Trends BR Gov 2016 - O caminho da iluminaçãoEduardo Weller
 
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)Alessandro Almeida
 
E-Book B2B E-Consulting Corp. 2010
 E-Book B2B E-Consulting Corp. 2010 E-Book B2B E-Consulting Corp. 2010
E-Book B2B E-Consulting Corp. 2010E-Consulting Corp.
 
E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010
 E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010 E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010
E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010DOM Strategy Partners
 
Inovação no setor público - EloGroup
Inovação no setor público - EloGroupInovação no setor público - EloGroup
Inovação no setor público - EloGroupEloGroup
 
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...EloGroup
 
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...EloGroup
 
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...EloGroup
 

Similar a Agile Trends Gov 2017 - Quanto custa ou quanto vale? (20)

Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)
Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)
Gestão de Projetos e Empreendedorismo: SIN-NA7 (22/10/2013)
 
Apresentacao dox
Apresentacao doxApresentacao dox
Apresentacao dox
 
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e DecisõesTDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
TDC 2017 Porto Alegre - Transformação Digital de Processos, Casos e Decisões
 
Apresentação Final
Apresentação FinalApresentação Final
Apresentação Final
 
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...
Construção da Arquitetura de Processos: Foco na Proposta de Valor, Governança...
 
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
Apresentação Gerenciamento de Projetos TI Corinthians ECC Abril 2014
 
Governança de TI.pptx
Governança de TI.pptxGovernança de TI.pptx
Governança de TI.pptx
 
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e DecisõesBPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
BPM Day 2017 Mato Grosso - Transformação Digital de Processos, Casos e Decisões
 
Gestão de Projetos e Empreendedorismo (23/04/2014)
Gestão de Projetos e Empreendedorismo (23/04/2014)Gestão de Projetos e Empreendedorismo (23/04/2014)
Gestão de Projetos e Empreendedorismo (23/04/2014)
 
Agile Trends BR Gov 2016 - O caminho da iluminação
Agile Trends BR Gov 2016  - O caminho da iluminaçãoAgile Trends BR Gov 2016  - O caminho da iluminação
Agile Trends BR Gov 2016 - O caminho da iluminação
 
TESI - Apresentação Final
TESI - Apresentação FinalTESI - Apresentação Final
TESI - Apresentação Final
 
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)
Gestão de Projetos e Empreendedorismo: TAD-NC4 (21/10/2013)
 
Apresentação Final
Apresentação FinalApresentação Final
Apresentação Final
 
E-Book B2B E-Consulting Corp. 2010
 E-Book B2B E-Consulting Corp. 2010 E-Book B2B E-Consulting Corp. 2010
E-Book B2B E-Consulting Corp. 2010
 
E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010
 E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010 E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010
E-Book B2B e Cadeias Digitalmente Integradas DOM Strategy Partners 2010
 
PRODEB
PRODEBPRODEB
PRODEB
 
Inovação no setor público - EloGroup
Inovação no setor público - EloGroupInovação no setor público - EloGroup
Inovação no setor público - EloGroup
 
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
 
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
MCTI – Como estabelecer um novo paradigma de gestão no serviço público por me...
 
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...
[BPM DAY Brasília 2012] Transformação dos serviços prestados pelo MCTI à Soci...
 

Agile Trends Gov 2017 - Quanto custa ou quanto vale?

  • 1. Quanto custa ou quanto vale? A experiência do Banco Central Brasília, agosto de 2017.
  • 2. Os Princípios Mais esforço para entregas do que para métricas. Mais incentivo a qualidade do que a quantidade. Mais interações entre pessoas do que entre documentos. Mais prazos acordados do que prazos derivados. “Mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.”
  • 3. Os Princípios O valor dos projetos entregues... e não só o custo Estamos investindo nos projetos certos? As métricas significativas... e não só as “objetivas” Estamos medindo o que deveria ser medido? A comunicação... e não só a documentação Estamos gerando documentação útil sem burocracia?
  • 4. Conclusão Nós não vamos resolver o paradoxo do “lucro-incompetência” enquanto a remuneração estiver atrelada somente a métricas “objetivas” baseadas puramente em esforço, quantidade ou complexidade.
  • 5. Histórico muito resumido • 2008: piloto ágil • 2012: primeiro contrato com “inspiração ágil” • 2013: o PDS-BC Ágil é, formalmente, o único processo de desenvolvimento corporativo • 2014: estabelecidos critérios de priorização de projetos • 2015: fim do primeiro contrato com “inspiração ágil” • 2016: publicado PDTI 2016-2019 • 2017: segundo contrato com “inspiração ágil” • 2017-: entregas, entregas, entregas...
  • 7. O que é o valor de um produto? • É o custo do trabalho para fazê-lo? • É a sua utilidade? • É o seu retorno do investimento? • É o seu significado? • É objetivo ou subjetivo?
  • 8. O que é o valor de um produto?
  • 9. Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. Conway’s Law, 1967
  • 13. Lista de Priorização Projeto Cliente Pontuação Técnica Prazo Previsto 1IntegraBC - Autorizações DEORF 78,00 24 2BcJur3 - Gestão de Créditos PGBCB 74,76 24 32017 Integração e-BC DEMAP 66,88 13 4Estrutura de Planejamento e Acompanhamento da Difis DEGEF 64,58 22 5Observa – BC DECON 62,18 43 6Automação de Processos da Supervisão DEGEF 61,14 46 7RDE-ROF - Empréstimos e Títulos DEPEC 58,36 11 8Atualização tecnológica do STR 2 DEBAN 57,68 16 9Integração das Informações de Monitoramento - I2M DESIG 56,18 10 10Conexão eSocial DEPES 55,76 18
  • 16. Cultura de Projetos e Cultura de Entregas O valor das entregas... e não só dos projetos As entregas estão ocorrendo (só) nos projetos?
  • 17. Cultura de Projetos e Cultura de Entregas Entrega em produção? SPI 0,85 CPI 0,85
  • 18. Priorização de Histórias 𝑨𝑶𝑳 = 𝑯𝑼 𝒑𝒓𝒐𝒏𝒕𝒂𝒔 𝑯𝑼 𝒑𝒓𝒆𝒗𝒊𝒔𝒕𝒂𝒔 = 𝟖𝟐 𝟗𝟐 = 𝟎, 𝟖𝟗
  • 19. Conclusão Desempenho também pode ser feedback. Indicador de Avaliação de Desempenho 1,12 Abr/17 a Jul/17 Ago/17 0,250,500,751,00>1
  • 20. Conclusão Remunerar por resultado significa remunerar por valor entregue, não (ou não só) pelo custo da solução. O tripé do contrato: Custo + Desempenho + Valor
  • 21. Mais desafios • Incentivos • Métodos • Gestão • Desempenho • Normativos • Cultura, cultura e cultura...
  • 23. When the best leader's work is done the people say “We did it ourselves”. Lao Tzu Apresentação de 2016: https://pt.slideshare.net/eduweller/agile-trends-br-gov-2016-o-caminho-da-iluminao eduardo.weller@bcb.gov.br

Notas del editor

  1. Quanto custa ou quanto vale? A experiência do Banco Central do Brasil.
  2. Esses são os princípios norteadores do meu trabalho no Bacen, em relação a metodologias e novas contratações.
  3. Esses são os princípios norteadores do meu trabalho no Bacen, em relação a metodologias e novas contratações.
  4. Paradoxo do Lucro-incompetência: definição do TCU (Min. Augusto Sherman) “quanto menor a qualificação dos profissionais alocados na prestação de serviço, maior o número de horas necessário para executá-lo, maior a margem de lucro da empresa contratada e maior o custo para a Administração” É necessário discutir o que significa “competência”. “Competência” deve ser entregar aquilo que precisa ser entregue e, portanto, agregar valor com a entrega. Por exemplo, se métrica de pagamento for vinculada exclusivamente à complexidade, há o incentivo para execução de mais tarefas complexas, podendo resultar, por exemplo, em projetos maiores e mais difíceis de execução, enquanto uma solução mais simples e mais curta, mas que agregue igual ou superior valor aos processos de negócio, seria relegada, por custar menos. Outro ponto possível do incentivo à complexidade é falsa superqualificação de profissionais, majorando o custo para a Administração. O profissional verdadeiramente competente deve buscar as soluções mais simples, rápidas e com alto valor a agregar. Se a métrica for relacionado a tamanho/tempo de construção da solução, é possível que os projetos durem muito tempo. O que vale mais, uma solução que leva 2 meses para ser feita ou uma outra solução, que também resolve o problema, mas que leva 2 dias pra ser feita? É necessário uma métrica, em conjunto com acordos de níveis de serviço adequados, que incentive a entrega de software que agregue valor, sustentável, com qualidade e com desempenho. Executar mais pontos de função não necessariamente agrega valor às entregas.
  5. Paradoxo do Lucro-incompetência: definição do TCU (Min. Augusto Sherman) “quanto menor a qualificação dos profissionais alocados na prestação de serviço, maior o número de horas necessário para executá-lo, maior a margem de lucro da empresa contratada e maior o custo para a Administração” É necessário discutir o que significa “competência”. “Competência” deve ser entregar aquilo que precisa ser entregue e, portanto, agregar valor com a entrega. Por exemplo, se métrica de pagamento for vinculada exclusivamente à complexidade, há o incentivo para execução de mais tarefas complexas, podendo resultar, por exemplo, em projetos maiores e mais difíceis de execução, enquanto uma solução mais simples e mais curta, mas que agregue igual ou superior valor aos processos de negócio, seria relegada, por custar menos. Outro ponto possível do incentivo à complexidade é falsa superqualificação de profissionais, majorando o custo para a Administração. O profissional verdadeiramente competente deve buscar as soluções mais simples, rápidas e com alto valor a agregar. Se a métrica for relacionado a tamanho/tempo de construção da solução, é possível que os projetos durem muito tempo. O que vale mais, uma solução que leva 2 meses para ser feita ou uma outra solução, que também resolve o problema, mas que leva 2 dias pra ser feita? É necessário uma métrica, em conjunto com acordos de níveis de serviço adequados, que incentive a entrega de software que agregue valor, sustentável, com qualidade e com desempenho. Executar mais pontos de função não necessariamente agrega valor às entregas.
  6. Muitos desafios nos impõem..
  7. É a combinação de tudo isso, dentro da cultura organizacional, que forma o conceito de valor. No Bacen há e haverá bastante discussão sobre esse ponto, na medida em que ainda precisamos amadurecer uma mudança de cultura. Valor é um conceito amplo e não pode ser só objetivo ou só subjetivo. Mas isso não pode nos impedir de procurar por ele, e procurar a melhor forma de mensurá-lo.
  8. É a combinação de tudo isso, dentro da cultura organizacional, que forma o conceito de valor. No Bacen há e haverá bastante discussão sobre esse ponto, na medida em que ainda precisamos amadurecer uma mudança de cultura. Valor é um conceito amplo e não pode ser só objetivo ou só subjetivo. Mas isso não pode nos impedir de procurar por ele, e procurar a melhor forma de mensurá-lo.
  9. Um grande desafio à disseminação do conceito e da cultura de valor é a complexidade da organização. Organizações complexas oferecem impedâncias de comunicação entre as áreas. Em geral, há diversos incentivos para que a organização possua grande profundidade e largura. Em primeiro lugar, cada “caixa” representa um incentivo financeiro para o seu gerente.
  10. Enfim: discutir e implantar medidas de valor é muito difícil!
  11. Seguem alguns pontos em desenvolvimento lá no Banco Central...
  12. A discussão sobre entrega de valor apareceu no último PDTI do Bacen. O papel do Departamento da Tecnologia da Informação, assim descrito (houve muita discussão até chegarmos a esse texto), é gerar valor para que o Bacen cumpra sua missão, de assegurar a estabilidade do poder de compra da moeda e um sistema financeiro sólido e eficiente. Logo, podemos fazer alguma ilações de valor aqui: precisamos entender que o valor do nosso trabalho deve estar, de alguma forma, conectado à estabilidade do poder de compra da moeda e a solidez e eficiência do sistema financeiro nacional. O PDTI atual abordou o tema de “entrega de valor” e, penso eu, os próximos deverão aprofundá-lo, baseado nas nossas experiências.
  13. Suponho que todos os órgãos maiores já possuem listagem semelhantes, de priorização de projetos. Isso porque, em regra, há mais demandas de TI do que a TI pode atender. É preciso criar métodos para ordenar as demandas, e esses métodos devem ser de conhecimento de todo o órgão. No Bacen, antes de iniciar cada projeto, as áreas de negócio e a TI preenchem um formulário, com questões sobre urgência, necessidade, criticidade de cada projeto, e alinhamento de negócio à cadeia de valor do Banco, além de riscos a serem mitigados com o projeto, de modo que seja possível, ao final do questionário, atribuir uma “pontuação técnica” ao projeto. Essa pontuação e o prazo são encaminhadas à alta gestão do Banco, que ainda pode dar uma pontuação gerencial e alterar a ordem. A dificuldade aqui, no processo, é fazer com que os projetos e o valor que eles entregam sejam disseminados para a alta gestão do banco, haja vista a complexidade do organograma (conforme mostrado em slide anterior). Em geral, a alta gestão mantém a Pontuação Técnica. A Pontuação Técnica é usada como fator de ajuste na remuneração no contrato de fábrica. O incentivo, aqui, é fazer com que a contratada invista mais nos projetos que entregam mais valor. Ainda há, também, o desafio de encurtar o prazo dos projetos.
  14. Estes são todos os indicadores do PDTI. São fruto de meses de discussão na equipe, não foi fácil chegarmos até eles!
  15. Em relação a valor, destaco esses 4 indicadores. O Índice de Alinhamento Estratégico é obtido pela razão entre a pontuação dos projetos em execução e a pontuação total dos projetos que estão no topo da lista (mesma quantidade de projetos em execução). Ou seja, se eu tenho 10 projetos em execução, eu somo todos os pontos desses projetos e divido pelo total de pontos dos 10 primeiros projetos da lista. Se der 100%, isso significa que todos os projetos em execução são os primeiros 10 projetos. Na duração dos projetos, há diversos pontos de vista no Bacen, e suponho que há em todos os órgãos. Os pontos de vista passam pela efetividade de impor um time-box a um projeto. Existe a opinião de que o tempo do projeto é menos relevante, o importante é medir as entregas que precisam ocorrer durante esse tempo. Particularmente, sou favorável a impor time-boxes mais restritos a projetos, como incentivo a que haja priorização de valor para as entregas. É razoável supor que, em um projeto bem gerenciado, as entregas valiosas sejam priorizados no time-box, e que escopo menos importante acabe por não ser feito durante o projeto, economizando recursos. O time-box mais restrito é um dos conceitos mais difíceis de implantar na organização, há diversos incentivos para que não ocorra, como por exemplo, receio de que o projeto perca prioridade e financiamento se o seu tempo de vida for curto. Frase de usuário: “pode ser o time-box que quiserem, desde que caiba tudo nele”. O índice de satisfação de clientes é realizado por pesquisa às áreas de negócio, com perguntas direcionadas à parceria do Deinf com a área de negócio – se o Deinf é considerado parceiro estratégico do departamento. O índice de efetividade no uso do sistemas foi criado para medir e expor o quanto os sistemas entregues pelo Deinf estão, de fato, sendo usados e contribuindo para a geração de valor nas áreas de negócio do Bacen. Observe que ainda não foi apurado, pois há discussão entre nós sobre a melhor forma de apurar e qual a granularidade da apuração (por sistema? Por funcionalidade? Por cada linha de código escrita?). Não é um indicador fácil de aplicar. Todavia há um consenso de que um sistema que não esteja em produção contribui com ZERO para o índice, pois não agregou valor, não foi efetivo.
  16. Outro desafio a ser superado, em termos de cultura, que reflete nos processos da organização (que é complexa), é a cultura de projetos em detrimento da cultura de entregas. Há muitos incentivos para criação de um projeto corporativo, como a viabilização de aporte financeiro, a prioridade da organização, a visibilidade do trabalho (e posterior recompensa). No entanto, um projeto não pode ser visto apenas como um meio mais fácil para obtenção de recursos. Um projeto deve existir para a sua finalidade, de geração de valor para a organização. As métricas de progresso de um projeto, no entanto, dificilmente medem as entregas e o valor gerado por elas. É comum a organização controlar se o projeto está “atrasado” (em relação a um cronograma de tarefas) e se os custos estão controlados (em relação a um cronograma de desembolsos). O que é preciso controlar, além disso, é se houve entrega de valor ao longo do projeto. Por exemplo, é possível verificar que projetos “em dia” e com os custos controlados, ainda que estejam no fim, ainda não entregaram software em produção, ou seja, ainda não geraram nenhum valor para a organização. É necessário, na medida possível, sempre priorizar a entrega de valor, o mais cedo possível no projeto, de forma sustentável, com qualidade. Todavia é possível afirmar que um projeto não é a única forma de entrega de valor. Uma vez instaurada uma cultura de métricas de entrega, é possível trabalhar com intervalos de tempo menores, com “micro-gestão”, entregas curtas e que agreguem valor. A métrica principal passa a ser as entregas, dentro e fora de um projeto. É possível que muitos projetos possam deixar de existir formalmente e passarem a ser tratados por pools, observando que esses pools poderiam ter seu desempenho medido por entregas. Essa abordagem poderia existir nas contratações de fábrica, bem como nos desenvolvimentos internos. Em geral, acredito que as boas métricas servem tanto a desenvolvimentos internos quanto a contratações de terceiros.
  17. Outro desafio a ser superado, em termos de cultura, que reflete nos processos da organização (que é complexa), é a cultura de projetos em detrimento da cultura de entregas. Há muitos incentivos para criação de um projeto corporativo, como a viabilização de aporte financeiro, a prioridade da organização, a visibilidade do trabalho (e posterior recompensa). No entanto, um projeto não pode ser visto apenas como um meio mais fácil para obtenção de recursos. Um projeto deve existir para a sua finalidade, de geração de valor para a organização. As métricas de progresso de um projeto, no entanto, dificilmente medem as entregas e o valor gerado por elas. É comum a organização controlar se o projeto está “atrasado” (em relação a um cronograma de tarefas) e se os custos estão controlados (em relação a um cronograma de desembolsos). O que é preciso controlar, além disso, é se houve entrega de valor ao longo do projeto. Por exemplo, é possível verificar que projetos “em dia” e com os custos controlados, ainda que estejam no fim, ainda não entregaram software em produção, ou seja, ainda não geraram nenhum valor para a organização. É necessário, na medida possível, sempre priorizar a entrega de valor, o mais cedo possível no projeto, de forma sustentável, com qualidade. Todavia é possível afirmar que um projeto não é a única forma de entrega de valor. Uma vez instaurada uma cultura de métricas de entrega, é possível trabalhar com intervalos de tempo menores, com “micro-gestão”, entregas curtas e que agreguem valor. A métrica principal passa a ser as entregas, dentro e fora de um projeto. É possível que muitos projetos possam deixar de existir formalmente e passarem a ser tratados por pools, observando que esses pools poderiam ter seu desempenho medido por entregas. Essa abordagem poderia existir nas contratações de fábrica, bem como nos desenvolvimentos internos. Em geral, acredito que as boas métricas servem tanto a desenvolvimentos internos quanto a contratações de terceiros.
  18. Acima um exemplo de micro-gestão orientado a entrega de valor, que está sendo aplicado ao novo contrato de fábrica, em execução no Bacen. A metodologia exige o valor de negócio por história entregue, calculado de forma simples a partir da soma de benefício + prejuízo (da história não ser feita). Observar que, nesse caso específico, não necessariamente uma história precisa estar em produção para ser valorada – os critérios de aceitação técnicos podem variar de acordo com a situação. O Bacen também “demora” a colocar software em produção, desse modo não é viável condicionar o pagamento da contratada a software em execução em produção. O incentivo, aqui, é fazer com que a equipe de desenvolvimento (contratada ou não) priorize as histórias que tragam maior valor e demandem menor custo, ou seja, a equipe é orientada ao custo-benefício de cada história. Histórias grandes/complexas e que agregam pouco valor tendem a serem descartadas pela equipe, inclusive com anuência do PO. Essa abordagem embute risco proporcional ao tamanho das histórias. AOL = Atingimento do Objetivo da Liberação. No contrato, é um Acordo de Nível de Serviço. Essa mudança de cultura tem sido implantada no Bacen, e não tem sido fácil. Há dificuldades das equipes em valorar as histórias e organizar as releases por objetivos de negócio. A frase: “o objetivo da release é realizar todas as histórias”, ainda que não seja dita, exprime um modelo de pensamento comum.
  19. Aqui retornamos a questão dos incentivos. Para a terceirizada, o incentivo é a remuneração financeira. Temos uma ressalva no Bacen – o valor entregue, de forma efetiva, pressupõe, como dito, software rodando em ambiente de produção. Ainda temos um longo caminho até podermos amarrar a remuneração e desempenho das equipes com o uso efetivo de software em produção. Para efeito de contratação, portanto, consideramos valor entregue o software entregue e validado pela equipe. Reforçando: ao remunerarmos só pelo custo, o incentivo é pelas soluções custosas, nem sempre as mais efetivas ou as que agregam mais valor. Uma proposta razoável para a contratação é uma métrica que remunere o custo da solução desde que o valor tenha sido entregue, com os devidos incentivos para que o valor seja entregue no menor tempo possível. Observando sempre, claro, os padrões de qualidade para aceitação do produto.
  20. Aqui retornamos a questão dos incentivos. Para a terceirizada, o incentivo é a remuneração financeira. Temos uma ressalva no Bacen – o valor entregue, de forma efetiva, pressupõe, como dito, software rodando em ambiente de produção. Ainda temos um longo caminho até podermos amarrar a remuneração e desempenho das equipes com o uso efetivo de software em produção. Para efeito de contratação, portanto, consideramos valor entregue o software entregue e validado pela equipe. Reforçando: ao remunerarmos só pelo custo, o incentivo é pelas soluções custosas, nem sempre as mais efetivas ou as que agregam mais valor. Uma proposta razoável para a contratação é uma métrica que remunere o custo da solução desde que o valor tenha sido entregue, com os devidos incentivos para que o valor seja entregue no menor tempo possível. Observando sempre, claro, os padrões de qualidade para aceitação do produto.
  21. Muitos desafios se impõem na construção de uma cultura de valor. Incentivos – é preciso analisar, sempre, que incentivos estamos fornecendo, para equipes internas e terceirizadas, em especial quando há remuneração financeira envolvido. É necessário criar ciclos virtuosos de entrega de produtos que agreguem valor. Em geral, ainda há muitos poços de remuneração não vinculadas a entregas. Métodos e processos – os processos de desenvolvimento e gestão devem ser vistos como ferramentas úteis para entrega de valor, não como etapas burocráticas ou manutenção de eventuais procedimentos que incentivam ou recompensam mais a documentação do que as entregas. Gestão – é preciso mensurar e acompanhar, na gestão dos projetos, a taxa de entregas. Não pode ser aceitável somente a métrica de que “não está atrasado” e “está dentro dos custos” sem oferecer, também, a informação “quais as entregas que ocorreram no período”. Desempenho – é muito difícil mensurar desempenho, tanto para equipes internas quanto para equipes terceirizadas. Em geral, é preciso conferir se o desempenho está associado às entregas realizadas e o valor gerado por esses entregas durante um período de tempo. Se há um grande valor entregue em um curto período de tempo, o desempenho é excelente. Talvez seja a dimensão mais difícil de apurar. Normativos e legislação e auditoria – é preciso orientar as normas e leis para a entrega de valor. Atualmente nos procupamos muito com o custo e o tempo da solução, gerando grande burocracia e farto material auditável para essas dimensões. Mas não há, por exemplo, auditoria sobre o valor agregado. Há, também, a preocupação do legislador em legislar para facilitar o trabalho do auditor, mas não necessariamente para facilitar o trabalho do produtor do software, o principal sujeito da geração de valor. Cultura – finalmente, para que seja possível desenvolver processos, métodos, métricas de trabalho que incentivem um ciclo virtuoso de geração de valor, é preciso mudar a cultura de todos os envolvidos no processo: do time de desenvolvimento, dos gerentes, dos POs e usuários, dos auditores, dos legisladores. Esse é o grande desafio que temos que superar, um dia depois do outro, todos os dias.
  22. Obrigado! Espero que a apresentação tenha possibilitado alguns insights sobre como aprimorar o estado do desenvolvimento de sistemas na sua organização!
  23. Lao Tzu ou “alguém bem esperto da internet” disse isso... Até a próxima!