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.
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!!
Pingback:Débito Técnico » Blog Archive » Um exemplo a ser seguido
Pingback:links for 2008-06-02 « pabloidz
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.
Pingback:1up4Developers » Blog Archive » Waterfalling…
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!
Ótimo post. Eu sou uma das reponsáveis por elaborar e institucionalizar processos no local onde trabalho, e este post me fez repensar algumas coisas. Espero em breve poder dar o retorno disto, aqui, na prática.
Obrigada por compartilhar o conhecimento.
Caroline! Realmente esperamos o seu sucesso. Reconhecer o problema na maioria das vezes é meio caminho andado. A macro estrutura do processo pode ser um framework empirico como o Scrum. Processos de software não tem relação com processos e artefatos. Abraços!
Rodrigo, parabéns pelo post. Excelente visão.
Tenho acompanhado uma empresa (como consultor) na implementação e customização de uma ERP, e o que me impressiona é que tenho visto que mesmo empresas fora do ramo de TI (mas que hoje dependem totalmente de TI, seja por símples planílhas em excel, seja por avançadas ERPs), a melhoria não vem do “mapeamento” de processos, mas principalmente da melhoria na capacitação das pessoas (e do espírito colaborativo delas).
Estou juntando informações valiosas sobre Agil e Srcum para o meu trabalho junto ao cliente, que certamente serão enriquecidas no próximo sábado, quando farei o treinamento com você na Aspercom.
Abraços!
Grande Yoshima, sou um dessas caras responsável por definir, institucionalizar, adaptar e melhorar o Processo de Desenvolvimento e as Ferramentas de Apoio ao Processo, dentre outras coisas…
E hoje (2011), após ter sido responsável pelo sucesso da avaliação MPS.BR Nível F final do ano passado e estar a 2 meses de uma avaliacao CMMI L2 lá na empresa, a cada dia tenho mais certeza e sinto mais na pele tudo que você falou nesse seu texto de 2008:
– CMMI e MPS.BR são excelentes modelos.
Mas, o grande problema é que CMMI/MPS.BR virou um mercado de “certificação” (Eu sei que CMMI/MPS.BR não são certificações) para empresas e temos hoje dois tipos de consultorias no mercado:
* Aquelas que ajudam a melhorar os processos e a organização como um todo (quem usam o modelo como um guia, mas que não seguem ele a risca ou melhor que fazem adaptações no plano ao longo do caminho, que reconhecem falhas nos modelos e que não estão nem um pouco ai para “quando vamos obter essa “certificação”?” Inclusive, eles mesmo propoem treinamentos quando encontram uma dificuldade técnica na equipe.(Eu sei que CMMI/MPS.BR não são certificações)
* Aquelas que ajudam unicamente a passar na avaliação, mas que pregam a melhoria de processo. Nesse modelo de consultoria tudo é guiado para a avaliação, para o que os avaliadores vão achar desse artefato ou desse Plano Organizacional ou dessa politica….enfim. Nesse modelo a melhoria de processos é guiada para os Avaliadores e não para os Clientes. Essas são as tarjas-pretas.
E, porque esse mercado (principalmente o tarja-preta) se tornou e ainda é tão forte atualmente?
* Pouquissimos empresários tem essa visão de que é preciso melhorar é a capacitação das pessoas da organização isto é, investir nas pessoas, e os que tem essa visão não investem justamente porque tem medo do fenomeno da alta rotatividade que eles mesmo criaram no mercado. Ex:
Empresario / Diretor de TI: ___ Não vou pagar um treinamento sobre testes (ou seilá o que for) para os meus funcionários, porque se eles fizerem esse curso nas minhas costas…depois eles vão para outra empresa e eu me ferro.(ou seja, não vou bancar eles de otário) Já se eu investir no processo de desenvolvimento, opá, as pessoas podem sair e eu nunca vou “perder” esse investimento porque a certificação é da Organização (é minha) e não de alguem em especifico…Então, não importa o custo, os empresários mesquinhos (90% do que temos hoje) sempre vão preferir investir em melhorias de processo do que melhorias da capacidade técnica/profissional dos seus funcionários por causa da alta rotatividade que temos hoje em TI. (Alias, tem uns empresários que tão bancando de espertinho, eles pagam o curso pra você, mas você tem que assinar um contrato que ficará mais X anos da empresa após a conclusão do curso e caso não fique tem q pagar o valor do curso com multa….) Entendeu o pq desse mercado ser tão forte? Enquanto não tivermos uma mudança drastica de pensamento desses empresários, vamos continuar nessa “merda”.
Esses empresários mesquinhos já são certificados Extreme Go Horse Process desde criancinhas, não precisam de mais uma certificação.
RUP é um puta framework de processos. (só quem já estudou profundamente ele sabe do que eu to falando). Mas, tem gente que ainda insiste em usar o RUP cascata ai eu te pergunto porque? R: Por falta de capacidade técnica ou por falta de experiências práticas. Como resolver isso?
Enquanto isso, esses empresários mesquinhos vão continuar jogando dinheiro fora com melhorias de processo de software para inglês ver….
E eu, vou seguir as tuas dicas, investir mais tempo em mentoring e treinamentos do que em definição e melhoria de processos..
Grande Abraço
Pingback:Melhoria de processo (externa) melhora? « new Blog();