Qualquer tipo de mudança na organização e pseudo-metodologias de desenvolvimento de qualquer empresa de tecnologia costuma ser um grande pesadelo. Isso é assim por vários motivos.
Geralmente os gerentes e diretores (na maioria das vezes) serão duros e contra qualquer tipo de mudança simplesmente pelo fato de a empresa ter gastado centenas de milhares de dinheiros, logo, pensarão por muito tempo que isso (metodologia customizada) deverá dar algum resultado, o que acaba não acontecendo na maioria da vezes. Essa negligência e fraqueza em assumir logo o prejuízo e tentar mudar – para melhor – acaba acarretando em prejuízos muito maiores no futuro, demissões em larga escala, troca de diretoria e por aí vai, já vi isso antes.
Outra justificativa muito usada para evitar mudanças será a falácia de que “em time que está ganhando não se mexe“. Grande parte das vezes falta coragem ou maturidade para enxergar que o time não está ganhando e que precisa ser modificado, sim. Também não é incomum encontrar situações onde a mudança não é vista com bons olhos pois as metodologias pra inglês ver, as certificações (de parede) e demais honrarias são mais valorizadas do que às pessoas e o produto que a organização entrega, então, nesses casos pouca importa se está bom ou ruim.
Mas onde eu quero chegar com esse post? Todas estas situações que falei até agora são conhecidas pela maioria dos desenvolvedores e sabemos que são situações difíceis de serem vencidas, eu mesmo já fracassei em algumas tentativas de mudança diante de tais situações e felizmente já obtive muitos sucessos também.
Recentemente, almoçando com um grande amigo acabamos caindo no papo sobre as nossas empresas e clientes e falamos sobre um caso em especial. Um cliente em que já haviámos trabalhado, onde enfrentamos todas aquelas situações anteriores de uma só vez – acreditem! – continuava na mesma. Com os mesmos problemas de sempre (atraso), mesmos gerentes/diretores e as mesmas pseudo-metodologias e regras internas, a única coisa que não era a mesma eram os clientes, nem preciso dizer o porque.
Mas a disucssão não chegou a ser prática ao ponto de “seja ágil”, “você precisa praticar TDD/BDD”, “agarre-se ao PMBok” ou “se você não aderir ao Scrum não vai ter jeito”, nada disso, não estávamos questionando a metodologia, nem as regras em si, mas sim a resistência em mudar. Fazendo uma breve retrospectiva vimos que 100% dos últimos projetos não haviam sido entregues na data prevista, desses 100%, 100% tiveram o orçamento o estourado e, desses 100%, 100% não atenderam a todas as expectativas do cliente e foram entregues com features a quem do esperado.
Diante de um cenário como esse, por que não deveríamos tentar mudar? Por que não tentar fazer alguma coisa diferente? Se estamos “sendo ágeis com scrum+xp” por que não tentar um modelo mais lento!? Se o RUP/MPS.Br/QualquerCoisa não está dando certo, por que não mudar e tentar outro? Se as metodologias e regras internas não estão sendo suficientes, por que não deveríamos tentar outra? Com um histórico de atrasos e fracassos, o que poderia acontecer de pior, atrasar 9 semanas ao invés de apenas 7!?
Não fique na mesma por muito tempo, mesmo que o seu time esteja ganhando e esteja realmente na frente, experimente mudar, tente melhorar, evoluir. Avalie sempre não só as mudanças, mas veja o que elas poderão fazer por sua organização, por seus projetos, se algo pode ser melhorado, vá em frente, se algo pode piorar, avalie o seu presente e passado e veja se vai, de fato, piorar, ou se você já estava “na pior” e não estava se dando conta. Não seja cético correndo atrás do que está na moda, na crista da onda, isso nem sempre será bom pra você, mas procure sempre avaliar sua situação e ver o que você pode tentar melhorar e o que pode, sem prejuízos, continuar na mesma.
O fato é, a grande maioria das pessoas não gostam de mudanças, principalmente se forem impostas. Claro que dependendo do time, mas uma boa idéia para quem está em equipes resistentes é provocar as mudanças.
Tive um caso clássico, entrei num time “Cascateiro”, não tinha política de testes unitários, entregavam o sistema cheio de inconsistência e atrasados. Comecei usando SeleniumIDE, o pessoal começou a notar que o que eu entregava tinha menos erros e todos se interessaram a mudar.
E concordo contigo, devemos sim estar constantemente avaliando nosso trabalho, porque sempre há o que melhorar, se a mudança trouxe dores de cabeça, também é bom, faz o time crescer. Parabéns pelo post!
Já tive uma experiência (de tentar mudar e não conseguir) dessas e se essa mudança (que era a idealização de vários desenvolvedores que pensavam da mesma forma) tivesse acontecido, o formato de desenvolvimento desse determinado projeto teria mudado da água para o vinho e, por conseguência, a data de término deste teria uma outra história e várias pessoas sairiam felizes da vida.
Mas, como nem tudo são flores, em projetos existem as pessoas que podem e as que não podem. Normalmente essas pessoas que podem possuem o poder. Portanto, elas podem ou não acatar as mudanças. É triste mas é fato.
Está enraizada na cabeça dos “chefes” a definição do comando-controle. Com o comando-controle o chefe alimenta seu ego, se sente importante e no fim esquece do que ele realmente deve fazer: alimentar talentos, orquestrar o que existe de melhor em uma equipe, para que o trabalho de TODOS gere retorno.
“Peça perdão, não peça permissão.”
Li isso em um livro recentemente, é mais ou menos como o Marcos Sousa falou: Comece a trabalhar diferente, e se não gostarem ai volte ao padrão. Claro que nem sempre se aplica ;)
Mas tem muito gerente/chefe/desenvolvedor cabeça dura, que não sai da zona de conforto por nada. Mas “legal” mesmo é quando tem processos para mudar os processos.
Acho que tem um ponto aí que não foi mencionado: se em uma determinada empresa um gestor qualquer “incentivou” o uso de uma metodologia que não está dando certo, possivelmente ele vai ser o mais resistente a uma mudança, simplesmente porque na cabeça dele parar de usar a metodologia que ele escolheu significa que ele foi incompetente para fazer esse trabalho. Vejam bem: *na cabeça dele* significa isso. Já vi essa situação acontecendo algumas vezes. Óbvio que não necessariamente isso vai significar que essa pessoa foi incompetente, mas parece que pra algumas pessoas retirar a sua idéia de prática significa que as pessoas estão tirando você de jogo junto. Não sei se estou conseguindo demonstrar bem o que estou querendo dizer, mas o que vejo é que existe muito individualismo no mercado corporativo. Muita gente se esconde atrás do termo “trabalho em equipe” apenas para conseguir ganhos pessoais.
@Marcio,
Tem toda razão, este é um ponto importantíssimo e realmente acontece com certa frequência, entendi bem o seu ponto no comentário. Creio que isso acaba acontecendo por dois motivos: orgulho ou medo. Orgulho do gestor em não abrir mão da metodologia que ele escolheu, mesmo estando ela sendo um fracasso ou então medo de que ele possa ser demitido, culpado e rebaixado de cargo.
Seguindo a linha do que falei antes, mas por outro ponto de vista, tem uma situação curiosa que aconteceu na minha empresa atual. Lá não tem processo pra nada. O pouco que tem fomos nós, os desenvolvedores, que criamos, no pouquíssimo tempo que temos disponível. Não é muita coisa, infelizmente. Meu chefe “sugeriu” que criássemos um processo para controlar melhor os nossos projetos. Sendo que nós sabemos que uma das filiais da nossa empresa foi responsável por dar à empresa o rótulo de CMMI nível 5, e sem falar de outra filial que já tem um processo criado, baseado no RUP, e dizem que funciona bem. Um dia, como quem não quer nada, sugeri que uma dessas filiais nos dessem uma “consultoria” ou “coaching” sobre implantação de processo, afinal, a “empresa” já tem processo, então pra que inventar a roda duas vezes? Pra que passar pelos mesmos problemas que a empresa, considerando o todo, já teve? Claro que é uma boa oportunidade pra aprender, mas teria que ser nós mesmos que deveríamos criar e implantar o processo, em paralelo com os projetos normais, e sem remanejamento de nada, que fique claro. Resumindo, tinha que ser na base do “se virem”. Enfim, meu chefe disse que teríamos que ser nós mesmos que deveríamos fazer isso porque seria um ótimo “produto” para promover a equipe dele. Sem querer entrar em muitos detalhes, percebi de cara qual a real intenção dele: promover o nome dele para a empresa. Ele não queria promover a equipe. Infelizmente eu sei disso porque já o conheço de outros carnavais, e sei que ele prefere um sucesso individual do que melhorar a produtividade da empresa. Se ele estivesse pensando na empresa, obviamente teria corrido atrás de uma das soluções já prontas, bastava dar um telefonema. Mas o horizonte limitado só o permitiu enxergar que nós deveríamos fazer isso. Nem preciso dizer que o countdown timer está correndo né?
@Marcio
Infelizmente esse tipo de situação, assim como a que você descreveu anteriormente, acontecem bastante. E creio que muitas vezes elas andam juntinhas.
Imagine num caso como você descreveu, a pessoa não quer o bem da empresa, deseja apenas se auto-promover. Então ignora a metodologia interna e cria uma outra. Isso vai demandar bastante trabalho e esforço. Digamos que ao final a metodologia não dê certo, ou fique pior do que a existente na empresa. Agora começará a outra situação. A mesma pessoa que ignorou a empresa pensando somente em benefício próprio irá fazer de tudo pra não deixar de utilizar a metodologia que ele formou, afinal de contas, seria assumir o fracasso. Imagine como a empresa perdeu com tudo isso, perdendo tempo e dinheiro pra criar outra metodologia e depois sendo prejudicada pelo ego e orgulho de uma pessoa que não sabe trabalhar em equipe.