Como introduzir novas tecnologias no seu ambiente de trabalho

Na correria do dia-a-dia as vezes fica um pouco complicado da gente utilizar aquela linguagem de programação diferente, ou aquela biblioteca maluca que você leu ontem no hackernews. Muitas coisas para serem entregues, um certo medo de tentar coisas novas e possíveis problemas que podem vir a partir disso fazem com que a gente não saia muito da nossa zona de conforto.

Por um lado, isso pode ser bom, porque vamos nos especializar na tecnologia que estamos usando e, normalmente, com mais experiência menos bugs serão gerados. Por outro lado, vamos ficar parados na tecnologia, sendo que pode existir algo que resolva o nosso problema de uma forma mais fácil, ou de uma maneira melhor do que fazemos hoje. Sem contar que ficaremos limitados a pensar conforme nossas ferramentas, limitando nossa criatividade na hora de construir soluções.

Martelo e parafuso (CC Justin Baeder/flickr)

Se você tem um martelo pra apertar um parafuso, ou você não aperta o parafuso ou usa o martelo de um jeito doido pra apertar o parafuso. Será que não era mais fácil utilizar uma parafusadora?

Nesse post vou abordar os prós e contras de utilizar tecnologias novas no seu dia a dia, e também falar um pouco de qual o melhor momento para introduzir algo novo, assim como falar um pouco da minha experiência na Bionexo sobre o assunto.

Disclaimer: Tudo aqui é a minha opinião sobre o assunto, que pode mudar com o tempo, então se você tem uma opinião diferente, escreve ai nos comentários :)

Qual é o momento certo?

Então você estava lendo as noticias, buscando por bibliotecas novas, tentando solucionar um problema, e acabou encontrando algo que achou muito legal que gostaria muito de aprender e utilizar. Coincidentemente, você tem um projeto pequeno que essa tecnologia se encaixaria perfeitamente. O que fazer?

É importante antes de tudo analisar se o projeto que você vai construir permite que você utilize algo novo que você não tem muito conhecimento. Você deve analisar um pouco qual será a complexidade de implementar a solução utilizando o que encontrou de novo. Se for muito complexo, faça alguns testes antes, implemente algo puramente por aprendizado e entenda se realmente faz sentido. As vezes vale a pena esperar por um projeto mais simples. Se o projeto for algo muito critico, faça o mesmo.

Depois que você entendeu que a tecnologia que você encontrou realmente funcionará muito bem com o projeto que você está fazendo, é importante você entender o que a sua equipe acha disso. É importante que todos estejam convencidos e acreditando que realmente esta é a melhor forma de solucionar o problema. As vezes é interessante construir algum Proof of Concept para comparar a implementação e ajudar nesse processo de convencimento.

Pense também que esse projeto não será mantido exclusivamente por você a vida inteira. Qual o mercado para a tecnologia que você está utilizando? O conhecimento será difundido entre seus colegas? O projeto está bem documentado, incluindo a motivação para escolha da tal tecnologia? A tecnologia já está sólida ou pode mudar tudo a qualquer momento?

Depois que você passou por tudo isso e convenceu sua equipe, chega a hora de implementar a solução.

Mão na massa!

Na implementação, é bem legal você tentar compartilhar o aprendizado com a sua equipe. Faça coding-dojos, como fizemos aqui na Bionexo para aprender React+Redux. Faça bastante pair programming, já que você está usando algo que não conhece e é mais interessante ter duas pessoas atentas ao código e aprendendo juntas.

Como estamos tratando de algo novo, pode ser que durante a implementação você perceba que algo não será possível, ou demorará mais do que o esperado. É importante você constantemente comunicar o resto da sua equipe do que está acontecendo, caso contrário essa pode ser sua última oportunidade de utilizar algo novo. Transparência é sempre a chave do sucesso.

Ao finalizar o desenvolvimento, teste seu código no ambiente cópia de produção. É importante fazer testes de performance e carga no que foi desenvolvido, por ser algo novo que você não sabe direito como vai se comportar com a sua solução atual. Lembrando que, antes de iniciar o desenvolvimento, também é importante pesquisar sobre cases e entender se sua aplicação terá capacidade de atender sua carga atual, caso contrário, talvez você esteja utilizando a ferramenta errada.

Deixe sempre bem claro que pode não dar certo e qual será sua abordagem caso não dê certo. Tenha em mente uma solução fallback, para que você possa ir para algum lugar caso tudo dê errado, e crie também uma definição de falha. Em que momento você vai mudar o seu plano e caminhar para a implementação do fallback? É importante ter isso claro, para evitar que você fique "batendo cabeça" por mais tempo que o necessário.

Tá em produção, e agora?

Depois que tudo estiver finalizado e entregue em produção, não está pronto ainda. Garanta métricas de sucesso do seu desenvolvimento e não esqueça de construir monitorações de qualidade. Tudo que puder dar errado dará no ambiente de produção, então garanta que você seja avisado quando algo de ruim acontecer.

Além disso, é importante difundir o conhecimento para as outras equipes. Faça tech-talks e documentações para os outros, mostre como seu desenvolvimento foi construído, quais os problemas que você passou e dicas de como fazer o troubleshooting da sua aplicação.

Mas eu não tenho autonomia :(

Claro que nem tudo são flores, muitas vezes nós trabalhamos em projetos e organizações que não nos dão autonomia o suficiente para propor esse tipo de solução. Como lidar com essas situações?

Algumas formas já foram citadas, mas vou ressaltar aqui. Nesse tipo de situação é ainda mais importante de vir com algo mais concreto e uma certa prova de que o que você está propondo realmente faz sentido. Tente montar uma relação de confiança, seja transparente e mostre também os downsides de sua ideia. Mostre cases de outras organizações que seguiram o que você está propondo e o que isso trouxe para o ambiente de trabalho.

Muitas vezes você pode se deparar com situações que as pessoas ficam totalmente fechadas a partir de um certo momento, e não importa o que você disser suas ideias serão rebatidas e rebatidas. Nesse tipo de situação é importante saber ceder um pouco para conseguir algo, e ir introduzindo a mudança aos poucos. Com o tempo, conforme todos forem percebendo o valor que está sendo trazido, as pessoas vão querer fazer parte dessas mudanças e receberão suas ideias mais abertamente.

No final, o importante é você se divertir no processo de aprendizado, entregar algo de qualidade e valor, e cativar sua equipe em ser curiosa e ter a sede de aprender algo novo. :)

Contextualizando um pouco: Aqui na Bionexo trabalhamos com uma equipe de desenvolvimento com mais ou menos 20 pessoas, incluindo Devs, QAs e Agile Coaches. Além disso temos uma equipe de produtos dentro de tecnologia e os Product Managers participam ativamente nos times.

Como utilizamos metodologias ágeis, o daily é fundamental para sincronizar os integrantes do time referente ao andamento das tarefas e levantar possíveis problemas. E quando algo novo com uma complexidade um pouco maior é entregue, fazemos Tech-Talks com toda a tecnologia para explicar o que foi feito e difundir o conhecimento.

Além disso temos um dia por mês reservado para trabalharmos no que quisermos, desde que traga valor para a empresa, o que acaba sendo um bom momento para tentar coisas novas.

Gostou? Estamos contratando, dá uma olhada no nosso Linkedin :).

Valeu a todos da Bionexo que revisaram o artigo e narciso.benigno pela experiência compartilhada!

Qualquer dúvida, sugestão ou opinião contraria comente aí em baixo e vamos conversar!