Uma vez um grande amigo meu e agora diretor em uma instituição financeira me disse que sair da área de TI era uma prioridade na cabeça da maioria porque o analista de sistemas, mais especificamente o programador, era o novo peão de obra.
Fiquei com isso na minha cabeça e por mais que ele tenha razão do ponto de vista financeiro, um gerente em média ganha várias vezes o que um analista em média ganha, eu não conseguia concordar com o conceito proposto. O programador é a peça mais fundamental do bom uso de um departamento de TI de uma empresa. Sem ele, a TI vai se limitar a disponibilizar produtos caixa fechada, tornando-se uma commodity.
Mas ao invés de me indignar, vamos ver o que criou esta imagem que, não se enganem, está na cabeça de muitos diretores por aí.
O datilógrafo de código
Há uma figura que deve ser evitada a todo custo que é o datilógrafo de código. Aquele profissional que pega uma especificação do sistema e sai digitando código que faz somente o que está escrito no documento.
Meu caro, se você já se justificou para o seu cliente dizendo que "isso não estava especificado", você é um datilógrafo de código!
De nada adianta conhecer os frameworks do mercado, várias linguagens de programação, otimizar queries como ninguém se ao fim e ao cabo, a funcionalidade entregada não ajuda ao negócio da empresa.
O programador como peça fundamental de sua estratégia de negócio
Não importa o tamanho da empresa, se ela tem uma área de TI, espera-se que esta capacite a empresa a fazer mais e melhor com cada vez menos recursos, mesmo que a empresa não tenha o foco em TI.
Veja o caso do atendimento bancário, antigamente os guichês eram para contas com digitos finais específicos, ou seja, se a fila das contas 0 e 1 estivesse grande e as demais filas vazias, não havia a possibilidade do guichê vazio atender aos usuários...
O resultado era esse:
Com o auxílio da TI isso passou a ser dinâmico e cada caixa atender a qualquer usuário, reduzindo as filas e o tempo de atendimento.
Agora, quem ainda vai fisicamente ao banco, vê isso menos ainda. Na maior parte dos casos, nem chega a ver a fila, resolvendo tudo no caixa eletrônico.
Essa é a evolução que tem que ser buscada na TI estratégica!
Quando é iniciado um novo projeto, este quer aproveitar uma oportunidade ou atender a uma necessidade do negócio. Essa necessidade só será atendida se ela estiver na mente do programador.
Note que evito usar os termos "analista de sistemas" "Analista de negócios", "agilidade", "especialistas de requisitos" porque todas passam exatamente a mesma idéia: Quando o programador aprende sobre o negócio da empresa, este se torna algo diferente e mais valioso. Entender o negócio não é mais um diferencial, e sim a obrigação do programador.
Não aposente os seus livros de design patterns ou deixe de estudar os frameworks, mas inclua na sua leitura as notícias da linha de negócio a sua empresa ou da sua área. Eduque-se sobre o que diferencia uma empresa de sucesso de uma empresa estagnada.
Independente da sua metodologia de trabalho ser ágil ou não, converse com o seu cliente regularmente e não somente antes da homologação de novos entregáveis. Se o seu cliente não tem conhecimento de TI isso é ainda mais crítico, pois é você quem pode indicar as melhores formas de otimizar o trabalho dele.
Se houver uma forma de acompanhar o trabalho de seu cliente por um dia, faça! Em breve falarei sobre design thinking e como isso pode ajudá-lo a melhorar os processos de seu cliente.
