Introduzindo novas tecnologias

quarta-feira, 30 de março de 2011

Em conversa recente com amigos, levantamos a dificuldade de se introduzir novas tecnologias, como um novo ambiente ou uma nova linguagem de programação em uma organização. A questão não se resume a problemas técnicos, mas a problemas pessoais, barreiras psicológicas, etc.

Por exemplo, se uma pessoa se considera em uma zona de conforto (por exemplo, se ela domina bastante uma linguagem de programação popular) pode haver uma certa resistência em colocá-la para aprender uma nova tecnologia (como outra linguagem de programação).

Para resolver problemas como estes, há diversos tipos de abordagens, envolvendo, inclusive, tirá-la da zona de conforto. No entanto, o propósito deste post é discutir questões organizacionais e levantar 5 pontos interessantes para definir uma estratégia para a introdução de novas tecnologias, mais especificamente, de uma nova linguagem de programação, na esperança de que alguns destes pontos possam ser úteis inclusive em outros contextos.

Existem vários motivadores para que uma organização resolva adotar uma nova tecnologia. Entre eles, a exigência de um projeto específico ou de um cliente importante ou até uma meta organizacional. Estes cenários tem suas peculiaridades e devem ser exploradas de forma diferenciada.

Se um projeto específico deve ser feito com uma tecnologia diferente da que a equipe está acostumada a trabalhar, pode ser conveniente, para reduzir os riscos do projeto, investir em treinamentos, contratar gente especializada ou encontrar algum colaborador que detenha conhecimento suficiente e possa dedicar atenção suficiente à equipe do projeto. Após a conclusão do projeto e seu período de manutenção, a mesma demanda por aquela tecnologia pode não ser mais necessária e evoluções podem ser feitas por membros da equipe que adquiriram conhecimento através do primeiro projeto.

Diferentemente deste cenário, a de exigência de um cliente importante ou uma meta estratégica da organização são questões mais duradouras e mais impactantes na organização pois outros futuros projetos serão garantidamente construídos sobre a nova base tecnológica.

O início de todo projeto já traz suas próprias complicações. Todos os envolvidos estão se familiarizando com os objetivos do cliente, com os padrões do projeto, sua arquitetura, suas funcionalidades e restrições. Além da própria curva de aprendizado do projeto, trazer uma nova linguagem de programação traz as curvas de aprendizado do ambiente de desenvolvimento e da linguagem em si, além de bibliotecas e frameworks de terceiros, sem as quais se torna muito custoso desenvolver softwares profissionalmente.

Assim, iniciar com uma equipe inexperiente um projeto com tantas novidades pode ser bastante caótico. Enquanto uma organização pode achar que um projeto pequeno pode ser utilizado, vale lembrar que um atraso de 1 semana em um projeto de 1 mês é muito pior que um atraso de 2 semanas em um projeto de 6 meses. Por outro lado, passar 2 meses na construção de um projeto para descobrir que é inviável na tecnologia escolhida pode inviabilizar o projeto completamente.

Então, quais ações poderiam ser adotadas para minimizar o impacto da introdução de uma nova tecnologia, como uma linguagem de programação?

Minha primeira sugestão é simples:

Quando se trata de atingir um objetivo/meta organizacional, o custo deve ser organizacional e o treinamento da equipe deve ser encarado da mesma forma: como um investimento para se atingir um objetivo.
Logo, pode ser contratado um treinamento, uma consultoria especializada para coaching/mentoring ou tentar orientar o aprendizado individual dos colaboradores.
Uma forma simples de fazer isto é a minha primeira proposta:

1- Alocar pequenas tarefas para cada colaborador.
Por exemplo, um fica responsável por configurar o ambiente e documentar de forma que outros consigam fazê-lo. Outro configura de acordo com o conhecimento registrado e cria uma projeto de exemplo, como o famoso "hello world", registrando seu aprendizado. Um terceiro pode implementar algo simples, como um cadastro de usuários, e um quarto, um sistema de login.
Através de atividades simples e pequenas, pode-se construir e incrementar o conhecimento organizacional, levando à minha segunda proposta.

2- Projeto startup.
Um projeto configurado com algumas funcionalidades simples e comuns pode ser replicado para servir como ponto de partida para outro projeto. Além de servir como exemplo, pode já trazer algumas funcionalidades comuns já implementadas, bastando fazer pequenos ajustes. Isto diminui o tempo e custo do projeto, compensando pelos gastos no aprendizado. Como outros projetos serão feitos na mesma tecnologia, a cada projeto, uma parte deste investimento será retornado.
Um projeto interno também pode ser utilizado se for considerado que seu investimento trará retorno para organização, no entanto, às vezes vale mais a pena escolher um pacote de funcionalidades comuns que irão se repetir em projetos externos ao invés de escolher um projeto interno com muitas especificidades.

3- Investigar, no início do projeto, como resolver as partes mais complicadas, as que se julga serem mais difíceis de serem feitas.
Muitas vezes pode-se descobrir frameworks ou bibliotecas que sozinhos ou combinados podem resolver o problema de forma satisfatória, no entanto, pode-se descobrir que tudo terá que ser construído do zero ou que esta é a forma mais apropriada para aquele cenário. Saber disto no início do projeto ajuda a determinar se a escolha da tecnologia foi adequada, se as necessidades serão atendidas e a minimizar o impacto destes riscos. Também, resolver estas questões pode trazer uma sensação de confiança e tranquilidade à equipe, o que pode ajudar a garantir o sucesso do projeto e até animá-los no aprendizado da nova tecnologia.

4- Escolher o cliente é tão importante quanto escolher o projeto.
Alguns clientes são mais tolerantes a pequenos atrasos que outros, alguns podem aceitar compensações (como uma ou outra funcionalidade extra) ao contrário de outros. Às vezes esta questão tem que ser levada em consideração na escolha de um primeiro projeto em uma nova tecnologia.

5- Rever o plano de implantação com antecedência.
Se a sua organização não tem um plano de implantação mas mesmo assim irá implantar o projeto, convém não só fazer um teste da implantação antes do primeiro release como documentar os passos tomados e as dificuldades encontradas, para que no momento do primeiro release, tudo siga suavemente. Isto é importante tanto para a moral da equipe, em saber que o primeiro release foi implantado e está funcionando corretamente quanto para que não se virem noites tentando resolver problemas de última hora, o que pode inclusive afetar a imagem da organização para o cliente.

Abraço a todos!

Bookmark and Share

Nenhum comentário:

Postar um comentário

 
addthis_config = { data_ga_tracker: pageTracker }