28 Abr, 2008
Síndrome da Gestão Covarde
No sábado ministrei um Workshop 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 excessõ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.
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.
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…



