Qualquer tipo de mudança na organização e as pseudo-metodologias
de desenvolvimento de qualquer empresa de tecnologia costumam 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 é 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 as 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 tudo isso? 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.

Certa vez, 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á havíamos 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 porquê.

Mas a discussã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
aquém 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 as regras internas não estão sendo
suficientes, por que não deveríamos tentar outras? 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.