Ricardo Fernandes Luiz

Agile, desenvolvimento de software, gestão, marketing, e tecnologia em geral

O olho do dono que engorda o ROI

with 5 comments

 

Saudações pessoal!!

Nas últimas 2 semanas, tenho tido discussões frequentes com os membros do #SDC da stefanini a respeito das dificuldades que temos enfrentado na adoção de agile em grandes empresas.

Depois de muitas conversas uma das conclusões que chegamos é que  o alto número de intermediários e cargos, e a política de aprovação de orçamentos emperra a adoção de agile em grandes empresas. Infelizmente em grandes empresas lidamos com intermediários que muitas vezes não estão preocupados em maximizar o ROI, e sim em contratar uma empresa que sirva de seguro para seu cargo. Há uma frase do mundo de TI que diz “Ninguém nunca foi demitido por ter contratado a IBM” que frisa bem este espírito, para quem não entendeu significa que quando o projeto não der certo a defesa da pessoa que contratou será “Mas eu contratei a IBM, se eles não resolveram o problema, quem resolveria?”, algo que não aconteceria, por exemplo se este mesmo projeto fosse realizado por uma pequena empresa, a culpa pelo projeto falho cairia sobre o contratante que não soube escolher um bom fornecedor para realizar o seu projeto.

Este contratante que geralmente não é o dono, mas tem um cargo executivo, tem um budget pré-estabelecido para gastar com determinados projetos. Não interessa para ele investir tempo em quanto do escopo será realmente utilizado e qual a prioridade dos itens necessários para o projeto, para ele é muito mais fácil elaborar uma RFP (e aqui temos alguns dos problemas da RFP) informando quais itens a consultoria terá que assumir, e então passar o risco do projeto para a consultoria, que em troca colocará a famosa “reserva de contigência”, popularmente conhecida como gordura, no projeto, para se proteger do risco.

É claro que se isto fosse feito de modo a diminuir o risco para a consultoria a empresa que contrata iria gastar menos. É como contrair um empréstimo, quando a empresa contrai um empréstimo dando garantias como patrimônios que o empréstimo será pago o valor do juros é menor, quanto maior o risco, maior o juros, e consequentemente maior o gasto que a empresa vai ter para ter o mesmo valor de empréstimo.

Mas qual seria o interesse em investir tempo para economizar um valor que ele já tem aprovado para gastar? E o pior, este valor na verdade para ele é um valor virtual, pois não sairá do bolso dele… Será que existe uma forma para grandes empresas quebrarem este paradigma?

Existe um grupo chamado “Beyound Budgeting Round Table” que propõe não só uma nova forma de controle orçamentário, mas também uma nova forma de gestão, já aplicada em empresas como Toyota, Unilever e o banco UBS, entre outros. Para quem quizer se aprofundar um pouco mais segue uma página sobre o que é beyound budgeting da MetaManagement, que através do Niels Pflaeging, representa o Beyound Budgeting no Brasil.

Não sei quanto tempo ainda levará para que presidentes de empresas despertem para este tipo de gestão que é cada vez mais necessário neste mundo tão dinâmico, mas acredito que as empresas que despertarem primeiro terão um diferencial em gestão de custos e investimento em capital humano.

Para finalizar, deixo vocês com a palestra do Niels Pflaeging, e um artigo da HSM.

Written by Ricardo F. Luiz

21/12/2010 às 1:57 am

5 Respostas

Subscribe to comments with RSS.

  1. Meu caro Pera,

    Responder a RFP é diferente de entregar um produto!

    Ainda temos problemas com projetos pelos motivos que citou (e concordo) e principalmente pela forma que projetos de software são comprados.

    O grande problema está na forma que se compra software. Empresas que vendem Agile não deixam de passar pelos mesmos percausos, mas tendem a não prolongar primeiro prejuizo!

    O mercado só compra assim ainda porque vender “commodite” interessa à maior parte das grande consultorias…

    Qq hora trocamos mais ideias à respeito.

    Abs

    André Vidal

    22/12/2010 at 3:50 pm

    • Exato, o problema está em como os projetos de software são comprados. Quando na RFP já estão restritos o prazo, o valor, e o escopo do projeto o que acaba variando é a qualidade, ou frequentemente o prazo e a qualidade. A gestão de custos de projetos com RFP seguindo estas restrições acaba sendo realizada da seguinte forma: http://gohorseprocess.wordpress.com/gestao-dos-custos/

      Abraços!

      ricardofluiz

      22/12/2010 at 6:55 pm

  2. Tenta começar a usar Kanban e leadtimes desde que inicia uma user story ate, que mostre os tempos de espera entre cada etapa onde existem mudança de mãos… isso traz um pouco mais de transparencia onde estão os gargalos… e da uma metrica para otimização do fluxo inteiro, graficamente fica facil mostrar que 70% do tempo a equipe esta esperando algum decidir alguma coisa ou homologar algo.

    Abraços,
    Juan.

    Juan Bernabo

    02/01/2011 at 9:12 pm

    • Obrigado pela contribuição Juan!
      Utilizamos o Kanban, o maior problema é que até o nível hierárquico que temos acesso, que é a diretoria da empresa, não há um grande interesse em mudar, eles tem um budget muito grande e quando mostramos o tempo ocioso que a equipe fica por causa dos gargalos deles, eles assinam o cheque e não mudam nada…
      A diretoria do cliente fica assinando cheques, nós recebendo cheques, e o processo como todo não melhora…
      Acho que se chegássemos no nível do presidente da empresa, aí sim talvez a coisa mudaria…

      ricardofluiz

      03/01/2011 at 1:38 am

  3. […] Se quiser dar uma olhada, pode acessar aqui !!! […]


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: