Tentar ou continuar na mesma?

Tentar ou continuar na mesma?: "

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.

"