[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?
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
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
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
Quanto custa ou quanto vale? A experiência do Banco Central do Brasil.
Esses são os princípios norteadores do meu trabalho no Bacen, em relação a metodologias e novas contratações.
Esses são os princípios norteadores do meu trabalho no Bacen, em relação a metodologias e novas contratações.
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.
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.
Muitos desafios nos impõem..
É 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.
É 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.
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.
Enfim: discutir e implantar medidas de valor é muito difícil!
Seguem alguns pontos em desenvolvimento lá no Banco Central...
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
Obrigado!
Espero que a apresentação tenha possibilitado alguns insights sobre como aprimorar o estado do desenvolvimento de sistemas na sua organização!
Lao Tzu ou “alguém bem esperto da internet” disse isso...
Até a próxima!