Hoje em dia ficou muito fácil aprender a programar. Se você realmente tem vontade, é possível:
Fazer cursos pela internet: Existem inúmeras opções pagas e gratuitas. Para quem entende inglês, existe o Udemy, CodeSchool e o Coursera; para quem não se dá muito bem com o inglês, também temos ótimas plataformas nacionais, como: Alura, iMasters, TreinaWeb…
Fazer cursos presenciais: Além das opções EAD (ensino a distância), há uma infinidade de instituições que oferecem cursos de programação. Alguns exemplos são a Caelum e a Impacta.
Livros e ebooks: Aqui também há opções excelentes tanto em inglês como em português. Eu particularmente gosto muito dos livros da Casa do Código.
Enfim, hoje quem tem vontade real de aprender, consegue de forma autodidata e às vezes com baixo investimento. Entretanto, apesar de toda a facilidade que temos hoje muitos jovens que ingressam na área, até mesmo gente que já trabalha na área há anos, e possuem uma série de problemas preocupantes. Alguns exemplos:
- Achar que já sabe tudo
- Se acomodar naquilo que já sabe
- Copiar o código ao invés de entendê-lo
- Implementar sem testar
Existe uma série de problemas técnicos e não técnicos que iremos discutir em outros artigos, mas o que quero discutir neste é: o programador que não entende e não tem interesse no negócio.
Para dar um exemplo, vou utilizar o meu caso. Há aproximadamente três anos que trabalho na área de Healthcare. Em resumo, minha empresa desenvolve soluções web para laboratórios, clínicas e hospitais de todos os portes. Temos soluções para medicina diagnóstica, gestão laboratorial, diagnóstico por imagem, logística e afins. Quando eu comecei, mal sabia o que estava fazendo. Criava funcionalidades e telas de acordo com as especificações que eram passadas nas estórias (Scrum). Mas com o tempo, fui promovido e comecei a lidar mais diretamente com os clientes, os produtos e suas integrações. E foi ai que o bicho começou a pegar…
Para começar, eu tinha uma dificuldade tremenda para atender os suportes (problemas em produção) e alterar as integrações. Isso porque eu não entendia nada sobre como o negócio e como as coisas deveriam funcionar. “Será que faz sentido um exame do tipo X estar agrupado com um do tipo Y?”, “Um documento deste tipo pode ser exibido na internet?”, “Os valores padrões de visualização estão corretos?”. E como você faz quando está com todas essas dúvidas enquanto o paciente está lá esperando ou quando você está muito próximo ao deadline?
Outra coisa que começou a acontecer muito foram reclamações sobre os layouts e fluxos das telas. Era comum escutar coisas assim do cliente: “Mas os médicos não precisam aprovar procedimento X para fazer Y”, “Os médicos estão tendo que acessar muitas telas pra liberar o exame”, “Os pacientes não consegue acessar os exames, está confuso”. Ou seja, como eu não entendia o negócio, não fazia ideia de como fazer as telas e fluxos de maneira que fizessem mais sentido ao dia a dia dos profissionais que iriam usar. Em resumo: Usabilidade e UX.
Depois de um período apanhando, me aproximei mais dos clientes e dos negócios. Como fiz isso? Existem algumas maneiras, como:
- Conversar com o seu gerente/líder: mostre que você tem interesse em se aproximar da área de negócios. É muito provável que ele comece a abrir espaço para que você participe de reuniões com os clientes.
- Ler sobre o assunto: um aspecto importante é sempre a leitura. É essencial que você leia sobre a área de negócio em que você atua.
- Não fugir dos problemas em produção: muitos dos problemas em produção, como foi citado, acontecem por que a equipe não compreende como o usuário pensa. Quando estas situações acontecerem, use como experiência para aprender mais sobre o seu cliente e o negócio como um todo.
Hoje atuo como Scrum Master na minha equipe e sempre passo esta orientação. Ao entender o negócio, o seu código:
- Terá mais qualidade
- Terá menos retrabalho
- Atenderá de forma mais satisfatória o seu cliente
E vocês, já tiveram situações parecidas com essas? Conhecem programadores que se isolam da área de negócios? Vamos discutir 🙂
10 Comentários
Em todo meu tempo de facul, o pessoal do meu curso nunca demonstrou interesse em entender de negócios e requisitos. Acho que isso deve ocorrer com a maioria dos programadores que estão ingressando no mercado ainda.
Olá Renan!
Acredito que seja comum que ainda na faculdade as pessoas tenham menos interesse em entender sobre negócios, mas mesmo assim é preocupante que ninguém se interesse por requisitos. Eles são parte fundamental do ciclo de desenvolvimento de software! Um software que não resolve um problema, que não atende um requisito, não serve pra nada.
Se você estiver ingressando no mercado agora, ingresse com o pé direito! 😉
Parabéns pelo artigo! Estou ingresssando agora no mercado de TI, mais especificamente na programação com a linguagem Java. Vejo, quase que diariamente, os professores “baterem na tecla” sobre a importância dos requisitos. Um grande amigo meu é Arquiteto de Software em Berlin – Alemanha em uma renomada Multinacional e ele sempre me fala da importância dos mesmo, explicado de forma brilhante aqui no artigo. Pretendo seguir essa linha inovadora de programadores, adaptando-me a esta nova geração.
Abraço
adorei a matéria,concordo com o que você disse no artigo, sou formado em análise e desenvolvimento de sistemas e sempre fui focado em desenvolvimento de aplicações, comecei na faculdade com java, tenho conhecimento em php e agora estou a prendendo C# e a sua framework web .NET , sem a parte de análise de requisitos e sem um bom planejamento da execução do software (diagramas de classes), entre outros o sistema fica bem confuso, na minha faculdade todos pensavam assim, que codificação é mais importante que a parte de requisitos e planejamento mas na verdade descobri que ambas andam juntas.
Olá Filipe Augusto!
Antes de tudo, muito obrigado pelo elogio! É exatamente este o ponto: Se não entendermos o problema, não há como solucioná-lo. Siga este pensamento analítico e você com certeza vai se destacar no mercado!
Olá José Carlos!
Vejo que você, assim como eu, acabou aprendendo da pior maneira, apanhando rsrs. Realmente é difícil para quem está ingressando neste mercado entender a necessidade de entender bem os requisitos. Mas é bem isso que você disse, planejamento e codificação são ambas importantes e andam juntas.
Normalmente é assim que começo á ver as coisas, Sou Fanatico por Tecnologia da Informação, iniciante no caso, com foco em aprofunda os conhecimentos nessa área que a todos momento . se torna cada vez mais importante na vida, no cotidiano, em diversas materias lidas até agora, vejo que necessita muito do conhecimento em PROGRAMAÇÃO, BANCO DE DADOS, SEGURANÇA E ETC . várias atividades pra ser exercidas nessa maravilhosa área que exige bastante conhecimento. pretendo iniciar o curso. depôs de tantas pesquisa, ainda tenho duvidas, e melhor investir no Curso TECNICO INFORMÁTICA, OU GRADUAÇÃO . apesar que os valores de ambos estão quais o mesmo ..
Faz um tempo que penso dessa maneira: Quem vai programar, deve entender do negocio, deve ter contato com o cliente sem meio campo. Quando uma analista de requisitos faz o meio de campo entre o cliente e o programador, muito se perde, o analista dificilmente pensa como programador, ele não sabe detalhes da implementação, ele não sabe do hall de possibilidades para um problema, ele não sabe dos impedimentos que determinada solução pode ter, etc… Resumindo, o programador deve entender do negócio, sempre!
O artigo é de 2016 mas o assunto é atual e muito importante.
Qualquer profissional (não me refiro à TI, que já são um bando de maxo de salto alto) deve e precisa conhecer do negócio… Além disso, precisa se envolver em questões que por vezes, não está relacionado á sua especialidade… Como gestão e finanças.
Para evitar que eu me tornasse um tecnocrata, fiz curso de extensão em gestão de pessoas e de gestão financeira. Isso melhorou muito minha atuação profissional.
As empresas continuam sonhando por profissionais que vestem a camisa, se envolvem e buscam se juntar ao time, observando a missão e os valores da empresa…
Isso não são palavrinhas bonitinhas! Isso é questão de sobrevivência!
Proteja e defenda a empresa que paga o seu salário e não deixa vc morrer de fome!
Diego, muito bom o artigo.
Posso falar por mim mesmo, de um outro ponto de vista.
Sempre atuei como analista de sistemas/requisitos, porém em 2017 devido a algumas mudanças na empresa em qual trabalho eu comecei a atuar como desenvolvedor.
Foi um grande desafio, visto que minhas experiências até então eram majoritariamente na área de análise.
Posso dizer que o meu conhecimento de negócio até então somado ao meu perfil mais analista me trouxeram uma grande facilidade em logo colocar a mão na massa. Depois de dominado o básico do framework que utilizávamos eu conseguia facilmente implementar pequenas evoluções e realizar correções, tudo devido ao fato de conhecer muito bem o negócio. Eu tinha muita segurança em realizar as alterações devido a este conhecimento.
O conhecer do negócio também traz um outro grande benefício que é os desenvolvedores poderem ajudar na proposta da solução, não deixando somente na mão do PO/analista a construção da solução. E isso no final resulta em uma solução muito bem mais elaborada e com foco na real necessidade do cliente.