Mai 27th, 2008
Não jogue dinheiro fora com melhoria de processos
Certo dia, em certa empresa, fui convidado para participar de um treinamento sobre SCM (Gerência de Configuração). SCM é uma das áreas de avaliação para obter a certificação CMM que a empresa estava buscando. Realmente achei que o treinamento era válido pois a empresa não tinha uma cultura muito forte em Gestão de Configuração, porém, o treinamento foi um desastre. A consultoria que “estava nos ajudando” a obter o selo não explicou o que é SCM no treinamento. Basicamente eles ensinaram quais documentos a gente precisaria preencher e quando tirar as baselines para conseguir passar no assessment. A empresa obteve o selo CMM 2 a um custo próximo de MEIO MILHÃO de reais, mas não tem internamente boas práticas de desenvolvimento.
Olhando o CMM/i não tenho muitas críticas ao modelo em sí, mas sim critico o que essa “certificação” se tornou, a motivação das empresas para obtê-la e essas consultorias “tarja-preta” que te “ajudam” a obter o selo. Isso seria assunto para um outro artigo (não postem comentários defendendo CMMi, deixe isso para o outro artigo, ok?).
O ponto que quero comentar aqui é que ter projetos ou equipes externas para obter melhoria de processos é um grande engodo. Nunca ví isso funcionar e coleciono casos onde esse tipo de prática provou ser ineficaz. Sabe aquelas pessoas “responsáveis por definir os processos”? É delas que estou falando.
Não vou mentir pra vocês. Eu já participei desses “projetos” internos e confesso que essas iniciativas de melhoria de processo falharam miseravelmente. Quando digo que falharam estou pensando no lado financeiro da coisa não importando a melhoria obtida. Pare para pensar: Numa conta rápida esses “responsáveis por definir processos” são profissionais caro$ e custam mais de R$ 15 mil por mês. Se você tiver 2 ou 3 deles o custo pode ultrapassar R$ 45 mil reais por mês. Será que as ineficiências do processo são mais caras que 500 mil reais no ano? Qual é o ROI disso?
Eu ministro treinamento de UML. O que eu ensino (e já escreví sobre isso) é que UML não é documentação e nem especificação firme. É comum empresários e alunos associarem UML com melhoria de processo não sei porque. Por conta disso, tenho muito contato com esses “responsáveis pelos processos”. Eu uso o treinamento para mudar a cabeça de muitos com relação a processos de desenvolvimento. Um depoimento de uma aluna no ano passado resume o que ocorre em geral:
“- Os caras que cuidam dos processos lá na minha empresa são muito fechados. Eles não aceitam a opinião das equipes. A visão que eles têm do processo é que qualquer pessoa poderia pegar qualquer papel, mesmo sem conhecimento, e as coisas funcionariam mecanicamente. Segundo eles, AS PESSOAS NEM PRECISARIAM CONVERSAR, as tarefas chegariam pela ferramenta de gestão, o artefato é preenchido e encaminhado para o próximo responsável…”
Essa aluna em especial ficou surpresa quando expliquei a natureza empírica de um processo de desenvolvimento de software. O processo nunca é ÚNICO para a empresa toda. Cada projeto pode necessitar de um processo diferenciado. O processo pode inclusive mudar de iteração para iteração.
Nenhuma literatura prega essa “intervenção externa” para melhoria de processos de desenvolvimento de software dentro das equipes. Isso pode funcionar para um cartório, uma linha de montagem, um supermercado e etc… Porém, o Manifesto Ágil é claro ao dizer que pessoas são mais importantes que processos. O que nos traz à solução da equação: Na minha experiência, todas as vezes que um empresário/gerente me procurou falando que o problema era falta de processos eu ví que o problema dele era falta de capacitação e não de processos. Ví que corpo técnico não sabia levantar requisitos, eleger uma arquitetura, gerenciar o projeto e ter uma cultura de teste. Se as pessoas não sabem ou fingem que sabem fazer as tarefas dificilmente o desenvolvimento do software terá qualidade e produtividade. Não adianta por arreio em cavalo chucro. Ao invés de pagar centenas de milhares de reais para melhorar o processo de “fora-para-dentro”, gastar 50 mil em bons treinamentos traz mais resultados palpáveis no curto prazo.
Bons processos surgem de boas práticas de desenvolvimento de software. Bons processos surgem de boas pessoas em constante colaboração. O processo é uma coisa que emerge da equipe e não algo que é imposto externamente. Geralmente o que esses empresários precisam é de treinamento e não de consultoria de processos. As pessoas precisam conhecer desenvolvimento de software. O primeiro valor ágil é muito sobre isso e empresas que estão tendo suce$$o (leia-se dinheiro) já aprenderam que investir em pessoas é mais vantajoso que investir em “projetos de melhoria” de processos. Exemplos:
Google
http://blog.aspercom.com.br/2008/04/10/culturaempresarialemalta/
Thoughtworks
http://www.thoughtworks.com/who-we-are/TW-history-MA.html
Ainda sobre a ThoughtWorks, o Phillip Calçado “Shoes” nos falou um pouco sobre os processos de um projeto no blog dele (aproveite os links do post e também veja a opinião do Dr. Ivar Jacobson sobre o assunto). Essa lista envolve muitas outras empresas, inclusive aqui no Brasil. Esses exemplos são mais caracterizados pois são empresas grandes com projetos grandes e lucratividade compatível (grande). Essas empresas não têm esses “departamentos” de melhoria de processos, mas sim, bons departamentos de RH e de empowerment.
É engraçado como está tendo um movimento muito grande da indústria nesse sentido. A própria nova linha de produtos da IBM Rational (veja http://jazz.net) declaradamente diz “People not Organizations build great Software”. Creio que essa segunda geração de produtos alinhe de vez a IBM com Agilidade e enterre o RUP Waterfall praticado no mercado. Por mais que alguns de nossos “gestores tupiniquins” queiram fechar os olhos, desenvolvimento de software é puramente dependente de pessoas e não de processos. A alta rotatividade que temos hoje é um problema gerencial e não um problema do desenvolvimento de software em sí. É uma ilusão enorme achar que melhorar o processo irá diminuir a dependência das pessoas.
Se você é “a pessoa responsável pelos processos” não desanime! Existe uma alternativa! O foco da melhoria dos processos deve ser treinamento e menthoring. Acredite, os resultados serão muito melhores. Ajuste o foco para as práticas e para a colaboração das pessoas. Deixe de lado as reuniões inúteis, a definição de papéis e os templates do modelo de artefatos. Todas as metodologias são fundamentadas em valores e não em modelos de artefatos.
Enviar por e-mail | Hits para esta publicação: 3011
Muito legal o post.
Eu sempre costumo falar:
“Quer melhorar processos? Invista nas pessoas.”
Um dia serei ouvido
[]´s
Ótimo post, Rodrigo.
Eu tento convencer as pessoas que estão ao meu redor que essas mesmas pessoas são responsáveis por no mínimo 90% do desenvolvimento de software, e que há pouco trabalho sendo feito para preservar esse recurso [na empresa onde eu trabalho, no caso]. O conhecimento é intangível, assim como o bom relacionamento e comunicação de uma equipe, mas a soma de todos esses fatores trazem resultados rápidos e muito satisfatórios. Ainda não tenho liberdade suficiente para adotar algumas posturas dentro da empresa, mas aos poucos vou injetando boas idéias nas pessoas que trabalham comigo.
Recentemente passamos por todo um “processo de melhoria de processos”, com o objetivo de obter a certificação ISO. O investimento não foi muito grande, mas não mudou muita coisa. Todo mundo continua trabalhando sem seguir os processos e um mês após a auditoria, tudo já era caos novamente. Um caos controlado, se é que me entende. Ou seja: ROI praticamente 0.
Um abraço.
Não acho que o título está apropriado. Melhoria de processos não é só cmmi. O título sugere algo que o texto não explica.
E seus exemplos são justamente a forma errada que se faz. Não gosto desse pensamento de PSDB (se não conseguimos acabar com a corrupção acabemos com as estatais ; traduzindo: se “ninguem” consegue criar um processo interessante com CMMI acabemos com o CMMI).
Paula, o título está mais que apropriado. Não jogar dinheiro fora com melhoria de processos é investir nas pessoas, principalmente em treinamento. O texto está claro nesse sentido.
Pior que o pensamento de privatizar seria um pensamento de querer controlar tudo estatizando as empresas privadas como um único modelo, completo, controlado, observável e previsível. Infelizmente desenvolvimento de software não se encaixa nesse perfil.
Se ninguém consegue criar um processo interessante com CMMi, RUP, XP ou Scrum é bem provável que esses modelos são mal planejados, mal comunicados ou mal compreendidos. Isso é completamente irrelevante para o artigo em questão.
Caro xará,
Concordo com você quando diz que capacitar a equipe é muito profícuo. Uma equipe sem capacitação fica girando em círculos, não sai do lugar. Também concordo que as empresas que têm prestado esse serviço de melhoria de processos são mercenárias.
No entanto, discordo quanto à melhoria de processos. Ela deve existir, capacitação interna e processos se complementam, não se conflitam. Deve existir investimento em ambos.
Olá Rodrigo…
Antes de responder, se tiver um tempo dá uma lida nisso aqui:
http://gc.blog.br/2008/05/27/como-estamos-indo-com-a-adocao-de-scrum-na-globocom/
(também quero deixar claro que eu e o Guilherme não combinamos de publicar esses artigos juntos!!!)
;)
O ponto do meu post é que assim como o design de uma aplicação é emergente o processo de desenvolvimento também é. Qualquer tipo de otimização precoce não é aconselhada.
Não faz o mínimo sentido ter qualquer tipo de elemento externo à equipe técnica dizendo o que ela tem que fazer [Schwaber]. Um bom investimento em processo que não é treinamento é o “Scrum of Scrums” que a Globo.com está fazendo (vide post do Guilherme).
Isso é Ciência. Para ter alteração no processo você deve ter parâmetros palpáveis e observáveis que justifiquem a alteração.
Conheço um caso em que a empresa não estava sendo satisfatoria em sua produção. Com isso, o gestor começou a pensar em adquirir o Maker ou Genexus acreditando que isso traria produtividade. O que na minha opnião, não resolveria!
Talves o problema de capacitação seja a causa raiz de toda essa reviravolta!
Esse post vai ser arquivado junto com o post do Guilherme sobre a adoção do scrum na globo.com, como argumentação sobre essa revolução que as vezes acaba virando uma tempestade em copo de água por conta da moda!
parabens!
É a velha história dos Tool Vendors dar Katanas para crianças de 3 anos..
Obrigado!
;)
É impressionante como a falsa segurança de um processo todo controlado, medido e previsivel (isso é o que as pessoas pensam!) ainda está presente nos gestores de TI atuais, pelo menos no Brasil.
O Waterfall continua enraízado em nossa cultara de gestão por simples jogo de interesses. Essas metodologias (CMM/i e similares…) só beneficiam pessoas que não querem se comprometer, não estão interessadas na real satisfação do cliente e querem se manter no mercado, muitas vezes sendo incompetentes no que fazem (afinal este tipo de processo permite que as pessoas se escondam atrás desta burocracia). Existem milhares de papéis (analista, projetista, analista de negocios, gerentes e mais gerentes, analista de qualidade…blah blah blah) a serem desempenhados, mas estes papeis são tratados como se fossem exercidos por robôs. Isso gera o tipo de frase: “Mas eu faço análise, prazo não é comigo!”. Eu sonho um dia poder trabalhar com uma metodologia ágil, enquanto isso não chega vou me lamentando por aí.
Excelente artigo!!
[…] A história do Venturus não podia ser diferente do que o Guilherme falou no post dele. Antes da Agilidade o que existia eram Gantt Charts nunca cumpridos, maiores “controles” operacionais e um processo cascata tentando ser previsível. O simples fato de tornar o processo iterativo-incremental já mostrou resultados positivos nos primeiros Sprints. Com as outras práticas do Scrum de inspeção e adaptação boas rotinas de trabalho estão emergindo das equipes e o processo segue em melhoria contínua. […]
[…] Não jogue dinheiro fora com melhoria de processos (tags: agile to-read) […]
Parabéns pelo artigo. Concordo plenamento no que você disse que processos bons necessitam obrigatoriamente de boas práticas de desenvolvimento. Comento isso, pois vivo na prática esse problema.
[…] Bom galera, gostaria de dizer que me motivei a escrever essas idéias depois de ler um excelente post do Rodrigo Yoshima no Blog Débito Técnico. É bom saber que ainda existem pessoas que tem a capacidade de provocar o pensamento e instigar a busca por explicações. […]
Excelente artigo,
Ter uma equipe capacitada é o ideal, porém, empresas erram muitas vezes no perfil do profissional que elas selecionam.
Escrevi um artigo sobre o perfil que considero ser o de um profissional ágil.
http://aprenderaspx.wordpress.com/2009/09/14/qual-o-perfil-profissional-que-a-metodologia-agil-precisa/
Abraços!