Menu fechado

Síndrome da Gestão Covarde

No sábado ministrei um curso Scrum e surgiram alguns assuntos que achei legal “documentar” aqui.

Se eu pudesse pegar um único valor ágil do XP e pudesse dar “uma injeção” desse valor nas pessoas eu escolheria a CORAGEM. Logicamente a coragem não é tudo que as pessoas e as empresas necessitam, porém, vejo que a falta de coragem gera uma paralisia. A paralisia é um dos sintomas do medo.

“Courage is effective action in the face of fear.”
Kent Beck

Creio que a definição do Kent Beck acima não necessita de tradução (acho que não sou muito bom em traduções, já que muita gente reclama delas nas minhas publicações). É interessante notar que coragem é uma ação e não um sentimento. É uma ação em resposta ao medo.

Algumas pessoas me perguntam porque sou tão crítico com relação aos “gerentes”. Bem, tenho contato com muitos profissionais de tecnologia nos treinamentos da Aspercom. Meu conhecimento dos problemas do mercado vem desses profissionais. Atualmente vejo que muitas práticas erradas adotadas pelas empresas, citadas nas minhas publicações, são defendidas por “gerentes covardes”.

As práticas ágeis estão começando a despontar aqui no Brasil. Scrum é uma metodologia que cresce a cada dia. Minha visão do mercado é que temos 3 “camadas de decisão” sobre a adoção de práticas ágeis. Só esse assunto já geraria um artigo, mas, só para iniciar o assunto “gestão covarde”, essas camadas são:

1. O Empre$ário
2. Os “Gerentes”
3. As equipes

Por mais incrível que possa aparecer, o empresariado (os caras que estão pagando a cara conta do desenvolvimento de software “Tradicional”), aceita Agilidade. É isso mesmo! Se você conversar com qualquer empresário você terá o seguinte padrão de diálogo:

Você: – O quanto você está gastando com projetos de software atualmente?
Empresário: – Muito!
Você: – E você está satisfeito com os resultados?
Empresário: – Não… os projetos atrasam, a aderência das soluções ao negócio geralmente são precárias e trocamos farpas com o fornecedor diariamente…
Você: – Você já ouviu falar em desenvolvimento iterativo?
Empresário: – Não…
Você: – O desenvolvimento iterativo é uma maneira de você diminuir o risco dos projetos, avaliando o trabalho do fornecedor durante todo o projeto e não somente no final. É uma forma de contratação que permitirá você proteger o investimento. Se o fornecedor não te atender da maneira esperada você não perde dinheiro…
Empresário: Puxa, me fala mais desse tal projeto iterativo…

Não há dúvidas que os benefícios para quem está pagando a conta são inúmeros para quem adota o desenvolvimento ágil. Sobre as equipes, elas também adorariam (com poucas exceções) adotar uma postura ágil. As equipes estão sobrecarregadas de burocracia, e muitos profissionais estão cansados da ineficiência de tantas práticas ruins. E o melhor de tudo: os profissionais estão estudando. Vejo cada vez mais nos meus treinamentos, nos fóruns de discussão e também nas pessoas que buscam informações no site da Aspercom que a procura por abordagens ágeis e as boas práticas de desenvolvimento de software estão em alta.

O problema está no nível gerencial. Os gerentes que compram, os que estão do lado do empresário, se sentem de mãos atadas, levados pelas más práticas do mercado. Os gerentes do lado do fornecedor, principalmente as “fábricas de software” tomam uma postura covarde pois não estão dispostos a correr riscos para atender melhor seus clientes. Para eles, as práticas ruins são boas, pois não arriscam seus salários que pingam a cada mês e eles não precisam aprender mais nada. Pegando esses gerentes do lado fornecedor, vemos algumas espécies de covardias do gerenciamento:

Gestor Covarde

Gestor Covarde foi um termo que encontrei para demonstrar um gerente que tem uma aversão patológica ao risco. Devemos buscar e mitigar riscos e não temê-los. O gerente covarde natural geralmente inicia o trabalho pelas tarefas menos arriscadas para mostrar que o projeto andou. Uma frase comum ao gerente covarde é:

– Este software é crítico. Vamos começar a comê-lo pelas beiradas. Vamos fazer todos os cadastrais e relatórios primeiro, depois fazemos o “core business”.

O gestor covarde teme as funcionalidades críticas de um software e tende a desenvolvê-las no final. As boas práticas de programação nos dizem o contrário: começe a desenvolver o software por aquilo que é mais complexo ou por aquilo que é mais crítico para os usuários. Como já havia comentado no post “Por que Gantt Charts não servem para projetos de Software?”, é comum que o gerente covarde mostre resultados maquiados. Nunca confie num relatório de status se problemas de negócio não estão sendo resolvidos através de software funcionando.

[photopress:salvadordali.jpg,full,pp_image]

Uma coisa que poucas pessoas compreendem é que dificilmente existe dependência entre requisitos. Você pode começar a fazer o software por onde você quiser. É preferível que você inicie o desenvolvimento pelas funcionalidades mais importantes do seu cliente para demonstrar valor iterativamente. Se é um sofware de vendas nós iniciamos o desenvolvimento pelo Pedido de Vendas. Se é um software de prontuário eletrônico começamos o desenvolvimento pela Prescrição. Se é um software para automação de uma oficina, começamos pela abertura de atendimento. Inicie por aquilo que é mais significativo e o projeto será entregue antes do prazo. É aí que entra a coragem. Bem, algumas equipes podem ser covardes também.

Geralmente quando apresento isso os covardes retrucam:

– Como é que você vai demonstrar o pedido de vendas primeiro se você não tem o cadastro de produtos, o cadastro de clientes, o cadastro de usuários e blá, blá, blá?

Minha resposta: – Já ouviu falar do comando SQL INSERT?

O fato dessas entidades (produtos, cliente, usuário) serem parcialmente necessárias para a emissão do pedido, as telas de cadastro dessas entidades não são necessárias. Repito: Dificilmente existe dependências entre requisitos de software. Ao menos com relação a maneira que o software é construído. Você pode começar a construir o software por qualquer parte.

Existem outras características do gestor covarde. Geralmente ele cobra prazos mas desconhece os problemas. É acostumado a dar uns gritos e socos na mesa de vez em quando. É comum ele se esconder atrás de um Gantt Chart. Tem um post interessante que abri no GUJ:

http://www.guj.com.br/posts/list/68516.java

Gerente-Proxy

Uma definição formal do que é um proxy pode ser encontrada aqui.

http://pt.wikipedia.org/wiki/Proxy

Já teve alguma experiência em projetos onde “tudo deve passar pelo gerente”? Qualquer dúvida a tirar com o cliente deve primeiro passar pelo gerente? Esse é o gerente-proxy. Esse gerente é aquele que tem medo do que a equipe possa falar para o cliente. E também teme as verdades que o cliente possa falar para a equipe. A desculpa mais esfarrapada é: -“Não vamos perguntar a mesma coisa duas vezes para o cliente”. Geralmente nos meus projetos eu pergunto mais de 10 vezes a mesma coisa para os clientes e até agora não tive reclamações deles. Se o cliente não está disposto a participar é muito questionável a necessidade do projeto.

O Gerente-Proxy geralmente teme estar por fora das coisas que acontecem no projeto. Mas antes disso, ele tem medo de “sair do escopo”. Escopo em software é muito mal compreendido. É comum confundir escopo com requisitos detalhados em projetos de software. É comum achar que para se ter estimativas os requisitos devem estar documentados. Poucos entendem a natureza empírica de um projeto de software.

[photopress:gerenteProxy.jpg,full,pp_image]

A colaboração entre os reais usuários e a equipe é primordial para o sucesso do projeto. Isso é defendido em todas as metodologias de desenvolvimento de projetos de sofware. Essa comunicação deve ser constante e não deve ter barreiras entre os desenvolvedores e os especialistas do negócio. É comum que ao final de um projeto que teve essa comunicação os desenvolvedores tenham um conhecimento do negócio muito próximo aos especialistas.

Tenho muitas outras espécies de gestores covardes. Mas fica para outros posts…

12 Comentários

  1. Guilherme Piccin

    Muito bom o post, Rodrigo. Pela sua experiência, você acredita que a adoção de metodologias ágeis e processos organizacionais menos burocráticos e mais funcionais tem ocorrido mais nas empresas menores ou as grandes empresas [IBM, Accenture, etc] já estão adotando essas metodologias? Um abraço

  2. Rodrigo Yoshima

    Empresas menores, sem dúvida. Principalmente aqui no BR, mas creio que no mundo não deva ser diferente. Não vejo um movimento de empresas grandes aqui no Brasil declarando a busca por metodologias ágeis. Tem um post meio “misterioso” com relação à Datasul, mas nada muito confiável:

    http://governanca.wordpress.com/2008/03/18/scrum-a-nova-gestao-de-projetos/

    A Globo.com usa:

    http://blog.fragmental.com.br/2007/08/15/introduzindo-agilidade-num-ambiente/

    (mas não sei se é um esforço isolado do Phillip Calçado e do Guilherme Chapiewski)

    Algumas empresas grandes como ThoughtWorks, Google são NATURALMENTE ágeis (veja meu post “Cultura Empresarial em alta” aqui no blog).

    Microsoft, 3M, Yahoo!, Toyota são outros cases grandes de adoção principalmente do Scrum.

  3. Paula

    Gostei do post. Tem conceitos realmente visiveis. Mas um ponto me deixou intrigada. Trabalho em uma empresa CMMI nivel 2 e faço exatamente isso:
    “…avaliando o trabalho do fornecedor durante todo o projeto e não somente no final. ”
    Toda semana tem troca de informação com o cliente e ele avalia prototipos.

    Ou seja, não é só a casadinha SCRUM + XP que faz isso acontecer.

  4. Rodrigo Yoshima

    Paula, eu não critico o modelo CMMI. Eu geralmente critico as motivações das empresas para obter a certificação e a maneira como consultorias desenvolvem o “projeto de certificação”.

    A grande diferença entre a sua abordagem e a abordagem iterativa é a entrega. Projetos iterativos entregam software funcionando e não protótipos. A troca de informações é pouco efetiva se você não entrega software funcionando. Pode ser que um protótipo seja muito enriquecedor, porém, no projeto iterativo o cliente pode decidir a qualquer momento ir para o software para produção.

    E geralmente é isso que acontece. Nos meus projetos a coisa mais comum do mundo é terminar o projeto 3 ou 4 iterações antes do final. Geralmente a 50% do projeto o software já está em produção. O objetivo de um projeto de software é resolver problemas de negócio e não implementar requisitos.

    Obrigado pela sua participação!

  5. Pingback:Débito Técnico » Blog Archive » Sim! Nós agilistas temos escopo…

  6. Pingback:Sim! Nós agilistas temos escopo… « Blog Visão Ágil

  7. Marcelo Zeferino

    Ótimo post.

    Acho que um grande problema das empresas grandes é, devido a sua imagem, ter medo de perder sua variedade de documentos sobre os projetos. “Requisitos detalhados ao extremo no início para fazer exatamente o que o cliente quer”. Por mais que no íntimo nem eles acreditem mais que isso funcione, ainda assim utilizam para terem uma sensação mentirosa de segurança…

    E o pior, há muita gente aprendendo isso em faculdades… Tem gente se formando com os conceitos ultrapassados que o Peter Drucker falou e criticou há um tempo atrás…

    Mas, vamo que vamo…

  8. Pingback:Scrum Master « Ielo's Blog

  9. Pingback:ABI3C – IELOTI » Blog Archive » Scrum Master

  10. Henrique Lobo Weissmann

    Gostei muito deste post. É fascinante quando é encontrada a analogia perfeita para um problema que sabemos existir, vêmos ocorrer na nossa frente mas difícilmente conseguimos descrevê-lo justamente por não conseguir encontrar uma descrição adequada.

    Eu tenho uma teoria a respeito: acredito que a maior parte dos problemas (com raríssimas excessões) tem como origem a nossa má compreensão da linguagem que, no caso, ocorre principalmente porque usamos termos inadequados para descrever o que fazemos.

    Gostaria muito de saber sua opinião a respeito disto Rodrigo, recentemente consegui por em palavras neste link: http://www.itexto.net/devkico/?p=1230

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *