Tag: programação

Categorias
Tech

3 motivos para a falha de projetos de software

Trabalhando por muitos anos no desenvolvimento, já tive a oportunidade de participar de muitos projetos de software. Boa parte deles como membro de equipe, alguns como Scrum Master e outros como freelancer, fazendo todo o trabalho sozinho.

Isso me trouxe alguma experiência no quesito projeto de software.

Acompanhei projetos que deram muito certo e outros que nem tanto. Sobre estes sempre fica a pergunta: “por que este projeto falhou?”.

Cada projeto tem suas características específicas, mas para me aprofundar mais nos motivos gerais das falhas resolvi fazer uma rápida pesquisa para procurar artigos acadêmicos que falam sobre esse assunto.

Analisando alguns deles fica claro quais são os principais motivos listados.

  • objetivos não realistas ou não articulados
  • software que não atende às reais necessidades do negócio
  • requisitos de sistema, requisitos dos usuários e especificação de requisitos mal definidos
  • gestão de projeto deficiente
  • metodologias/práticas de desenvolvimento desleixadas
  • prazos e orçamentos do projeto
  • estimativas imprecisas dos recursos necessários
  • má comunicação entre clientes, desenvolvedores e usuários
  • uso de tecnologia imatura
  • pressões comerciais
  • satisfação do cliente
  • qualidade do produto
  • entre outros (lista completa neste artigo)

Como podemos perceber, são muitas as possíveis causas de um projeto de software ser malsucedido.

Essas pesquisas foram feitas com diversos projetos e estão em artigos espalhados por aí, mas eu quero focar naqueles motivos que já senti na pele, como um envolvido no projeto.

1. Requisitos de sistema mal definidos

Este é um caso muito mais comum do que se imagina. Acontece o tempo todo e já passei por diversos projetos com esse problema, por isso ele está no topo da minha lista.

Análise de requisitos é um processo complicado e demorado. É preciso da atenção de um profissional especialista e que vai conseguir levantar exatamente tudo que é preciso para que aquele projeto de software atenda às necessidades dos interessados.

Isso faz parte de projetos de softwares mais tradicionais e não necessariamente funciona do mesmo jeito em projetos ágeis, em empresas que necessitam de entregas mais constantes como as startups de tecnologia ou que possuem prazo e orçamento mais apertado como as fábricas de software menores.

Acontece que não ter um levantamento de requisitos tradicional não libera ninguém de levantar requisitos.

Talvez alguns gestores não entendam que o uso de métodos ágeis não é desculpa para que as descrições de tarefas sejam muito bem pensadas e completas.

“Gastar” tempo levantando requisitos bem definidos com os stakeholders (as partes interessadas no projeto) aumenta as chances de uma entrega mais assertiva e rápida do software.

2. Gestão de projeto deficiente

Eis um tópico extremamente genérico e que afeta muito os projetos de software. Uma má gestão pode significar diferentes problemas para a equipe, incluindo o tópico anterior.

Mesmo que as equipes ágeis sejam autogerenciáveis segundo a teoria, normalmente existe alguém que centraliza essa tarefa mais do que os outros membros. Além disso, em muitos casos, os executivos da empresa costumam não permitir tanta autonomia para que a equipe se gerencie.

A gestão de projetos deficiente acaba tendo um impacto muito grande na motivação da equipe, na falha de comunicação, na necessidade de retrabalho, na má administração dos recursos e dos prazos, etc.

Já presenciei alguns casos de má gestão e a responsabilidade pela falha do projeto costuma sobrar para os membros da equipe…

3. Qualidade do produto

Em alguns casos na minha experiência o produto tinha um potencial incrível, poderia trazer muito valor para os usuários… mas simplesmente não funcionou quando eles precisaram.

A qualidade do produto faz parte do valor agregado entregue em qualquer projeto.

É muito comum existir um membro da equipe focado nesse assunto. Uma pessoa para garantir a qualidade do software e mantê-lo sempre na sua melhor versão possível, sem erros e sem problemas de usabilidade.

Projetos de software que falham por falta de qualidade do produto não precisam de muita explicação, não é…

Eis um investimento que vale a pena, mas que muitas vezes é subestimado pelos responsáveis do projeto.

Entre outros…

Os motivos selecionados aqui são os que mais me chamaram a atenção por acontecerem em diversos projetos os quais eu participei. Por isso estão nesta lista em ordem de importância.

Na minha experiência pessoal eu não vejo um motivo específico para a falha de projetos de software e sim uma combinação de problemas que se acumulam e minam o projeto como um todo.

Em diversos dos casos que presenciei mais de um desses itens estavam combinados com outros também descritos na primeira lista retirada dos artigos pesquisados no início dessa publicação.

O que fazer?

Pessoalmente, acredito que uma das formas de evitar a falha de um projeto é ouvindo as pessoas envolvidas. Aproveitar a experiência de quem participa do desenvolvimento para tentar entender o que está acontecendo durante todo o processo.

Uma liderança mais aberta e que se importa com a opinião dos envolvidos tem maior chance de identificar um possível motivo de falha antes que o mesmo se torne irreversível para o projeto.

A chave é não esperar o projeto chegar em um nível crítico para então parar para analisar o que pode estar dando errado.

Por isso as empresas que mais crescem e entregam tecnologias incríveis valorizam tanto os profissionais que colaboram para que isso aconteça. Mantendo sempre um ambiente com menos fricção para comunicação e mais atenção ao que está acontecendo durante as iterações de desenvolvimento.

Para você, quais são os maiores motivos para a falha em projetos de software? Deixe sua opinião sobre o assunto nos comentários.

Até a próxima!

Categorias
Crônicas

Retrospectiva 2017

Equipe Tikal Tech 2017

Ao final de cada ano, desde 2015, comecei uma pequena tradição inspirada pelo meu amigo e chefe Fernando Freitas Alves. Escrever uma retrospectiva do ano que passou.

Talvez a parte mais importante seja parar para pensar em tudo que aconteceu. Minha grande motivação para escrever em 2015 foi o fato de que aquele ano me ensinou mais do que qualquer outro em toda a minha vida.

Já a retrospectiva de 2016 mostrou que ano passado foi de estabilização no trabalho e na vida pessoal. Apesar de não ter muitos avanços na parte da saúde, uma das metas que continuei tendo em 2017.

Como sempre faço em minha vida, em 2017 experimentei diversas maneiras de me manter em uma rotina mais saudável. Tentei algumas novas atividades físicas, como o Crossfit por exemplo, e infelizmente não consegui dar continuidade como deveria.

Também me arrisquei em técnicas de jejum intermitente para perda de peso e melhora da atividade cerebral… sem sucesso.

Graças a mais um ano de falhas na área da saúde percebi que preciso dar uma importância maior para este tópico na minha escala de metas para 2018. O primeiro passo já foi dado: horário marcado na nutricionista já para janeiro.

Mas tive uma pequena conquista nesse ano. Foi agora, bem no finalzinho, em dezembro mesmo. Foi uma amostra de que posso atingir algo se me esforçar um pouco. Parei de roer unhas! Graças a um aplicativo chamado Coach.me.

Roer unhas era um hábito que estava difícil de largar e por isso resolvi usar como um experimento desse aplicativo. Acredite se quiser, estou sentindo as unhas batendo nas teclas neste exato momento como há anos não sentia. Um pequeno passo, mas uma grande prova de que posso conseguir mudar alguns hábitos em 2018, certo?

Outra pequena conquista desse ano foi o café sem açúcar. Sempre tomei café muito doce, mas com a ideia do jejum intermitente veio a necessidade de tomar café ao natural.

O primeiro dia sempre é estranho. Você faz careta a cada gole, mas no dia seguinte eu já estava sentindo o gosto de diferentes tipos de café que temos disponíveis lá no escritório e decidindo os que realmente são do meu gosto.

No trabalho, que nos ocupa boa parte do tempo dentro de um ano, 2017 se mostrou estável. Continuo trabalhando como desenvolvedor na startup de legal tech Tikal Tech.

Com o lançamento de uma nova linha de produtos na empresa as coisas aconteceram rápido. Este foi o ano do ELI na Tikal Tech.

Graças ao desenvolvimento do ELI ICMS Energia tivemos uma experiência muito produtiva com arquitetura de microsserviços. Além de outras integrações interessantes como o Login Integrado do LegalNote para aplicativos ELI. Um sistema de gestão de acesso de usuários centralizado para diferentes aplicativos em Django.

Antes disso, mais pro início do ano, tive o prazer de participar da comunidade Chatbot Brasil. Até criei alguns chatbots e coloquei algum conteúdo por aqui sobre o assunto. Já na Tikal Tech implementamos o chatbot Corujinho na fanpage do SeuProcesso no Facebook. Foi uma experiência bem interessante.

Com o crescimento da empresa tivemos um aumento considerável no staff. Basta ver a  foto do pessoal na retrospectiva de 2015 e notar como as coisas mudaram! Veja a foto da equipe nesse ano.

Equipe Tikal Tech 2017

Falando em trabalho não posso esquecer das minhas férias. Este foi uma das grandes metas desse ano. Aproveitei  maravilhosos 30 dias de viagens e descanso merecido depois de muitos e muitos anos sem tirar férias.

O ponto alto foi a primeira semana em que eu e minha namorada passamos alguns dias em Paraty. Que lugar maravilhoso para aproveitar natureza, os locais históricos e, é claro, as praias e os passeios de barco. Que delícia!

Financeiramente 2017 também foi um ano muito bom para mim, pelo menos comparados aos últimos dez anos de perrengues e problemas para manter um orçamento estável. Graças à liberação do FGTS inativo consegui quitar algumas dívidas e até mobiliar um pouco minha vazia casa.

Mas o que realmente está fazendo a diferença é o estudo de finanças pessoais. Durante esse ano inteiro investi um bom tempo nesse tópico, seguindo canais de Youtube interessantes como o do Gustavo Cerbasi e o Me Poupe!, os quais indico muito a quem quer começar a sair do buraco.

Graças a isso, posso até começar a pensar em investir algum dinheiro para 2018. Nem que sejam apenas alguns trocados. A meta é montar uma reserva de emergência o quanto antes!

Para terminar, algo legal que voltei a fazer: desenhar.

Desenho desse ano! Yey!

Nesse ano de 2017 eu voltei a desenhar e até alimentei o meu canal que fala sobre criação de histórias em quadrinhos no Youtube. Separei os tópicos que falam sobre isso aqui no meu blog para um novo domínio separando assim os conteúdos.

Criei também um Instagram e voltei a alimentar a minha velha fanpage no Facebook.

Sempre adorei desenhar histórias em quadrinhos e manter um hobby divertido como esse é algo essencial para a qualidade de vida de qualquer um. Me fez um bem danado!

Participei pela primeira vez de um Inktober! Se quiser entender melhor o que é isso, é melhor dar uma lida na publicação que fiz no meu blog de desenho.

Bem, por cima esse foi o meu ano de 2017. Essa retrospecitva vale mais para quem escreve do que para quem lê, porque a parte mais legal é repassar o ano na sua cabeça. Rever o que foi feito e pensar em como melhorar no ano seguinte.

Se você leu até aqui, obrigado! Deixe seu comentário sobre como foi seu ano também!

Um abraço e até 2018!

Categorias
Tecnologia

Primeiros passos com o GIT

GIT é um software de controle de versão utilizado por muitos e muitos desenvolvedores e empresas no mercado de tecnologia.

Um controle de versão serve para manter o histórico do desenvolvimento do código e também para ajudar uma equipe de programadores trabalhando no mesmo código a não fazer besteira no meio do caminho.

Vamos à um exemplo bem simples.

João está fazendo alterações no arquivo index.html ao mesmo tempo em que Carlos. João altera as linhas 30 até 50 do arquivo e Carlos da 80 a 100. Em algum momento os dois precisam juntar esse código para ter a versão final do documento que vai para o site joaoecarlos.com.

Isso é bem fácil, basta que um dos dois pegue a parte do código que o outro alterou e cole na posição correta no arquivo index.html. Está pronto para subir para o servidor, certo? Certo.

Então para que eu preciso do Git para ajudar o João e o Carlos?

Bem, basta dizer que se o João estivesse alterando entre as linhas 80 e 100 do mesmo arquivo teríamos um conflito entre o que o João fez e o que o Carlos fez. Não bastaria colar as alterações do João sobre as do Carlos, seria preciso que se analisasse linha por linha do que cada um fez para ver qual deve entrar e qual deve sair. Basicamente os dois precisariam sentar juntos e reescrever o código. Trabalho dobrado.

Agora imagine que essa reescrita de código pudesse ser feita de forma automática? Não seria ótimo?! Sim. Seria.

Aí entra nosso querido software de controle de versão! No caso dessa publicação estamos falando de Git, mas ele não é o único.

Vamos rever o exemplo do site joaoecarlos.com agora utilizando o Git em todo o processo.

João modifica o arquivo em seu computador. Ele salva localmente suas alterações e faz o commit com o Git que salva no repositório local quais alterações foram feitas. No final do processo ele executa um push e essas alterações ficam salvas em no repositório remoto.

Carlos faz alterações no mesmo arquivo e executa seu commit localmente. Quando ele for executar o push para o repositório o Git vai avisá-lo que seu código local não está atualizado com o repositório. Então ele executa um pull e baixa as alterações que João fez e o Git se preocupa em reescrever seu código para escolher quais linhas devem ficar em quais posições. Depois disso, Carlos pode verificar se está tudo certo com seu novo código e mandá-lo para o repositório com mais um push.

Pronto. É assim que funciona o Git… da maneira mais básica o possível, é claro.

O Git é muito mais do que isso, mas primeiro é preciso entender o seu conceito básico para começar a trabalhar com ele.

Vamos ver o passo a passo do que o João e o Carlos fizeram.

Aviso: todos os exemplos vistos nesta publicação são comandos executados em um console/terminal de linha de comando de um sistema operacional com base em Unix (MacOS ou Linux, por exemplo). Eles consideram que o Git já está instalado no seu ambiente de trabalho. Para ver como instalar clique aqui.

Primeiro eles precisaram iniciar o repositório Git localmente no diretório em que seus códigos estavam. Acessando via linha de comando eles entraram na raiz do código.

cd /Project/joaoecarlos/

Foi lá que ele iniciaram seu novo repositório com o comando:

git init

Para verificar os arquivos que o Git vai rastrear eles usaram o comando git status e viram algo como o exemplo abaixo.

On branch master
Initial commit
Untracked files:
  (use "git add <file>..." to include in what will be committed)
index.html
nothing added to commit but untracked files present (use "git add" to track)

Eles notaram que está escrito Untracked files logo acima do nome do arquivo. Isso quer dizer que o Git não está “rastreando” esse arquivo.

Com o comando git add . eles adicionaram todos os arquivos do seu projeto na lista de arquivos a serem rastreados. O . representa todos os arquivos e diretórios presentes nesse diretório. Eles viram algo assim:

On branch master
Initial commit
Changes to be committed:
  (use "git rm --cached <file>..." to unstage)
new file:   index.html

Agora eles tem um ambiente preparado para fazer o seu primeiro commit. Eles adicionaram o arquivo index.html à lista de arquivos que serão gravados nesse commit.

Com a execução do comando git commit -m "Primeiro commit" eles finalmente gravaram sua primeira “versão” do site joaoecarlos.com no seu repositório local.

[master (root-commit) d8cbc79] Primeiro commit
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html

O atributo -m "Primeiro commit" é um encurtamento de uma parte do processo de commit que é muito importante: descrever o que foi alterado.

Todo commit precisa ter uma boa descrição do que foi feito. Isso facilita muito para o futuro, onde centenas ou milhares de commits foram executados em um repositório. Imagina se você precisa encontrar onde foi feita alguma alteração no passado?

Pode-se executar esse comando sem o atributo -m, mas em seguida o console irá abrir um editor de texto para que se escreva uma mensagem descrevendo o que foi alterado.

Bom, agora que nossos colegas do exemplo já tem um repositório local, precisam enviar isso para um repositório centralizado. Um exemplo de serviço muito bom (e bem conhecido) para criar um repositório é o GitHub.

Depois de criarem sua conta e seu repositório no Github, nossos desenvolvedores adicionaram esse repositório como remote nas suas configurações do Git.

git remote add origin https://github.com/user/repo.git

Esse origin que você vê no comando é um apelido que se dá para o repositório remoto em sua máquina. Por padrão estamos chamando de origin que é o mais comum que você vai encontrar por aí.

Adicionar o remote no seu repositório local serve para indicar de onde ele deve puxar o código atualizado e para onde ele deve enviar seus commits. É o repositório com o qual todos os desenvolvedores do projeto vão interagir e onde ficará registrado todas as informações sobre alterações e versões do código do seu projeto.

Agora nossos desenvolvedores de exemplo estão prontos para subir seus primeiros commits para o repositório no GitHub com o comando git push origin master.

git push origin master

Vamos analisar esse comando…

O git push é a parte que diz que queremos enviar o que temos de commitsna nossa máquina para o repositório remoto, GitHub por exemplo.

O origin master diz para onde enviar esses commits, como o apelido do repositório é origin isso significa que vamos enviar para o GitHub que adicionamos a pouco.

O master significa o branch que estamos usando. Mais para frente vou falar sobre branch, mas por enquanto vamos assumir que estamos trabalhando apenas com o branch padrão, que é chamado de master. Ele já foi criado quando o João ou o Carlos executou o git init lá no começo.

E voilá. O código dos nossos amigos está no repositório do GitHub.

Agora vamos dizer que o Carlos precise trazer as atualizações de lá. Ele executou os primeiros passos (git init, git remote, git add e git commit) na sua máquina local e agora quer atualizar o código com o que tem no repositório remoto.

git pull origin master

Assim como o git push nós estamos dizendo para o Git de onde queremos buscar as atualizações com o origin master.

Agora o Git já atualizou o código na máquina do Carlos.

Em outro momento vou falar sobre os conflitos, algo que pode acontecer nesse momento de sincronização (ou merge) quando se usa controle de versão.

Por enquanto é isso. Esses são os primeiríssimos passos para utilizar o Git como controle de versão em um projeto.

Esse texto foi produzido para quem nunca teve contato algum com controle de versão, para dar uma ideia geral de como é e para que serve.

Se você quer saber mais sobre Git, deixe um comentário que eu planejo mais publicações como essa, dando continuidade ao processo e explicando mais sobre outros fatores.

Postado originalmente no Medium.

Categorias
Tecnologia

Como utilizar Ajax no WordPress

Hoje vou dar uma dica de como utilizar ajax no WordPress.

Precisei fazer uma chamada assíncrona em uma página de template do WordPress em um projeto que estive trabalhando e fui pesquisar como funcionava. O WordPress tem seu jeitinho todo especial de executar requisições XHR.

O primeiro passo é escrever uma função (no arquivo functions.php) para executar o que você quiser que o backend faça nessa chamada Ajax. No caso do exemplo desta publicação estou enviando um email.

// Actions to send mail
add_action('wp_ajax_sendMyMail', 'sendMyMail');
add_action('wp_ajax_nopriv_sendMyMail', 'sendMyMail');

// Sending the email
function sendMyMail() {
  global $wpdb;

  $message = "Form data:\n\n Name: {$_POST['name']}";
  if (wp_mail('email@email.com', 
              'Title', 
              $message, 
              array('Cc:email@copy.com'), 
              array())) {
  	echo 'success';
  } else {
  	echo 'error';
  }

  die();
}

Linha por linha da função no functions.php

Usando o add_action do WordPress, registramos nossa função. No primeiro wp_ajax_sendMail estamos registrando a função para utilização no painel Admin do WordPress e com o wp_ajax_nopriv_sendMail registramos a função para utilização no frontend, onde o usuário não estará logado.

O formato desses dois tipos de actions específicas para ajax sempre devem começar com wp_ajax_(action) ou wp_ajax_nopriv_(action).

// Actions to send mail
add_action('wp_ajax_sendMyMail', 'sendMyMail'); 
add_action('wp_ajax_nopriv_sendMyMail', 'sendMyMail');

Depois vem a função em si, com as ações que você quiser. Como eu já disse, nesse exemplo é o envio de um email.

// Sending the email function 
sendMyMail() {
 global $wpdb;
 $message = "Form data:\n\n Name: {$_POST['name']}";

 if (wp_mail('email@email.com',
             'Title',
             $message,
             array('Cc:email@copy.com'),
             array())) {
  echo 'success';
 } else {
  echo 'error';
 }

No final usamos o die() do PHP para encerrar o processo.

 die();
}

A requisição Ajax

Agora vamos à chamada assíncrona no Javascript.

Fazemos uma chamada com o método $.ajax do jQuery normalmente, mas a diferença está na URL que utilizaremos nela e em um item que precisa ser adicionado nos dados enviados para o servidor.

$.ajax({
 type:"POST",
 url: "/wp-admin/admin-ajax.php",
 data: {
  action: 'sendMyMail',
  name: $('input[name=name]').val()  
 },  
 success: function(data){
  console.log(data)
 }
});

A URL deve ser sempre /wp-admin/admin-ajax.php e o nome da ação que você registrou no functions.php entra como um dado com o nome action junto com o resto dos dados que você irá mandar para o servidor.

url: "/wp-admin/admin-ajax.php",
data: {
 action: 'sendMyMail',
 name: $('input[name=name]').val() 
 }

E voilá!

Deixe suas dúvidas ou opiniões nos comentários abaixo.

Nos vemos na próxima.

Categorias
Carreira

Carreira Programador – Sou júnior, pleno ou sênior?

Trabalhar com desenvolvimento de software, ser um programador, requer muito mais do que conhecer uma linguagem de programação e alguns pacotes, exige diversas habilidades do ser humano. Agilidade, flexibilidade, criatividade e diversas outras. Isso não se consegue da noite para o dia.

O que tenho notado ultimamente em muitos profissionais é a pressa de chegar até o nível mais alto dos cargos. Se tornar um sênior o quanto antes, mesmo tendo apenas dois ou três anos de experiência no mercado de trabalho.

Em parte, isso é culpa das empresas que simplesmente estão desesperadas por programadores e oferecem cargos e salários super altos para pessoas com pouca experiência. Não que ter altos salários seja algo ruim ou que ter um nome bonito para o cargo no Linkedin seja um problema.

A verdadeira questão é a confusão que isso pode causar quando se tem alguém com poucos anos de experiência sendo a referência de uma equipe.

Sim, um programador sênior é uma referência para todos os outros membros de sua equipe. E o bom programador júnior é aquele que sabe que “ser o menos inteligente da mesa” é algo essencial para o seu crescimento.

Não existe uma regra para se definir quem é sênior ou quem é júnior, isso vai depender do plano de carreira de cada empresa.

O que existe é uma regra importantíssima para os programadores em qualquer nível de carreira, iniciantes ou experientes: Jamais pare de aprender!

“Tá, mas como eu vou saber que nível estou?” – Leitores

Como depende de cada empresa, fica complicado saber. Para dar uma ajuda vou mostrar uma listinha…

A lista

Aqui vai uma tradução de uma lista muito interessante que o DHH, criador do Rails e founder/CTO do Basecamp, publicou em uma conversa no twitter esta semana.

Essa lista faz parte do Basecamp Employee Handbook, o manual do funcionário do Basecamp, e clarifica um pouco sobre as competências que cada programador deve ter dentro da empresa para ser júnior, pleno ou sênior.

Lembrando que cada empresa define o que acredita ser o melhor para cada nível. Eu gostei e me identifico muito com o conceito deles. Por isso estou publicando aqui.

Programador(a) júnior

  • O trabalho é cuidadosamente revisado com substanciais idas e vindas.
  • Tem domínio dos recursos básicos da linguagem, mas pode ainda não ter familiaridade com algumas estruturas avançadas.
  • Tem problemas ocasionais para seguir padrões e compreender abordagens dentro das bases de código existentes.
  • Trabalha principalmente com escopos mais bem definidos e em problemas de rotina.
  • Costuma ter menos de 2 anos de experiência como programador profissional no domínio específico.

Programador(a) Pleno(a)

  • O trabalho é revisado com a necessidade ocasional de mudanças na implementação.
  • Compreende os padrões e abordagens estabelecidos nas bases de código existentes com facilidade.
  • Trabalha principalmente em funcionalidades ou problemas individuais com escopo claro e bem definido.
  • Costuma ter pelo menos 2-5 anos de experiência como programador profissional no domínio específico.

Programador(a) Sênior

  • O trabalho não precisa necessariamente ser revisado, mas a abordagem geral pode ser.
  • Totalmente capaz de desenvolver sozinho funcionalidades importantes do conceito inicial até a entrega (ao lado de um designer).
  • Pode fornecer feedbacks importantes sobre o trabalho de programadores plenos e juniores.
  • Especialização profunda dentro de pelo menos um ambiente de programação.
  • Proficiência básica em pelo menos um ambiente de programação adicional.
  • Costuma ter pelo menos 5-8 anos de experiência como programador profissional no domínio específico.

Eles ainda possuem um nível de Lead Programmer e um de Principal Programmer, que poderiam ser definidos como níveis de líder técnico, gerente de equipe e diretor(a) de departamento.

O que me chamou muito a atenção nesta lista é que o conhecimento técnico de uma linguagem faz diferença em cada nível, mas não é a única coisa a ser levada em conta. Lembre-se disso!

O que achou da lista? Deixe sua opinião nos comentários.

Nos vemos na próxima.

Categorias
Carreira

Carreira Programador – Quer trabalhar em uma startup?

Hoje em dia é comum ver pessoas interessadas em trabalhar nas empresas de tecnologia, principalmente nas startups dessa área.

Existe um certo glamour em trabalhar em uma empresa que tem como proposta mudar o jeito que as coisas são, a tal da “empresa diruptiva”. O conceito de inovação costuma partir de dentro da própria, a partir de sua cultura. Isso atrai profissionais com essas mesmas características.

Uma das coisas que chama a atenção nessas empresas é a liberdade de trabalhar em um ambiente menos engessado e mais focado em resultados do quem em como está o preenchimento do sua folha de ponto. Isso sem falar na menor burocracia interna e nos possíveis pequenos agrados, como doces e bebidas a vontade, além de jogos e outras coisas divertidas.

Ao mesmo tempo que tudo isso é muito atrativo existe também o outro lado da coisa. Nem todas as empresas são tão bem “estruturadas” quanto Facebooks e Googles por aí. Estou falando literalmente de grana. Bufunfa mesmo. A maioria não vai ter como pagar equipes enormes e especializadas.

Por isso o profissional que busca uma carreira em tecnologia, principalmente nesse tipo de empresa, precisa ser completo. Precisa ser um profissional “T” ou T-shaped skills.

Essa expressão se refere ao profissional que tem conhecimento em diversas áreas de maneira geral e em uma de maneira aprofundada. Por isso a letra T.

Eu não trago essa expressão da maneira convencional como recrutadores costumam falar, onde o profissional tem um monte de skills fora da área de tecnologia para ser um T. A trago pensando mais no conceito de desenvolvedor Full Stack, aquele que consegue lidar com diversas partes do desenvolvimento de software e não é apenas especializado em uma parte dele.

As equipes das startups costumam ser extremamente enxutas e por isso é preciso que os profissionais sejam muito flexíveis e saibam lidar com diversas partes do processo de desenvolvimento de software.

Conhecer uma linguagem de programação é algo que nem precisa ser dito, certo? Mas vou abordar algumas dicas sobre o tipo de conhecimento que poderia lhe ajudar a conseguir iniciar uma carreira nesse mercado.

1. Desenvolvimento web

A popularização da web deixou muito mais fácil para empreendedores tornarem suas ideias realidade e criarem startups. Conhecer sobre desenvolvimento para web pode facilitar muito a vida profissional de um programador.

Entender como funciona o frontend e o backend de uma aplicação web é indiscutivelmente uma das maiores vantagens para que um profissional possa trabalhar em boa parte das startups que existem por aí.

Conheça bem HTML e CSS. Brinque com o Bootstrap, que facilita muito o desenvolvimento da estrutura de um webapp. Mas não se esqueça que quase nada funciona na internet sem JavaScript.

Conheça bem JavaScript e só depois vá atrás de conhecer alguns frameworks como Angular e React.

2. Controle de versão

Os sistemas de controle de versão servem para gerenciar as versões do código que está sendo editado por um desenvolvedor ou uma equipe de desenvolvedores.

No caso da equipe é que ele se torna ainda mais imprescindível, pois cada membro da equipe pode trabalhar no mesmo código que outro e bagunçar a coisa toda. Eu apago uma linha aqui e você a modifica ao mesmo tempo… loucura!

Tenha familiaridade com o GIT e isso já lhe dará uma grande vantagem sobre outros candidatos.

3. Linha de comando

Ah! O famoso terminal… a tela preta com letras brancas (na verdade as cores são totalmente configuráveis).

Sem entender como funcionam os comandos Unix (Linux e MacOS) fica muito difícil trabalhar com a maioria dos frameworks e linguagens de script que temos no mercado.

Isso falando apenas de maneira geral, existem muitas tarefas que são muito mais fáceis sendo feitas pelo terminal, inclusive o uso do GIT!

Ter um conhecimento básico dos comandos do terminal não é difícil, basta praticar um pouco e eles passam a ser naturais. A medida que você precisar conhecer mais comandos para executar diferentes tarefas o seu repertório aumenta sozinho.

Se você aprender a escrever um ou outro shell script então… aí a coisa começa a ficar boa!

4. Já ter feito alguma coisa…

Ok, isso parece estranho. Afinal estou falando em começo de carreira por aqui.

O que quero dizer com “já ter feito alguma coisa” é ter participado de algum projeto ou ter um projeto pessoal concluído. Talvez em um freelance ou algo assim.

A ideia dessa “dica” é que você já tenha passado pela experiência de completar um projeto. Que tenha feito mais do que apenas estudar sobre o assunto. Que você tenha feito algo do começo ao “fim”. Algo que tenha lhe dado experiência em iniciar e terminar alguma coisa.

Conta ter feito um sistema para lembrar da lista do supermercado ou seu próprio blog, desde que você tenha conseguido começar, desenvolver e “entregar” (deploy). Isso faz muita diferença em um profissional.

Essa declaração pode parecer confusa, mas eu já trabalhei em muitos lugares e conheci muita gente dessa área. Em vários profissionais em início de carreira eu senti falta dessa saída da zona de conforto e da tentativa de fazer algo de verdade além dos exercícios de cursos ou tutoriais encontrados na internet.

E tem muito mais…

Eu poderia ficar escrevendo muito mais sobre cada um dos itens acima e ainda mais sobre outras coisas que ajudariam um profissional em início de carreira a se preparar para o trabalho em startups. Mas a ideia aqui é dar um rumo. Não adianta tentar aprender tudo de uma vez só!

Outro ponto importante é que ninguém nunca está preparado o suficiente. O que vai fazer diferença no futuro é a sua própria experiência. Então não tenha medo de concorrer à vagas e entrar com tudo no mercado.

Deixe um comentário se você acha que faltou alguma coisa ou se tem dúvidas sobre o assunto.

Nos vemos na próxima!

 

Categorias
Carreira

Carreira Programador – Quanto ganha um programador?

Essa é para quem está começando ou quer começar na área de desenvolvimento de software

Existe uma visão distorcida da realidade desse profissional de tecnologia da informação que escreve códigos e desenvolve sistemas.

Um Analista de Sistemas em início de carreira, por exemplo, tem salário médio de R$ 4,2 mil. Em três anos, sua média salarial pode chegar a R$ 7 mil. Com mais de dez anos de experiência, sua remuneração alcança R$ 17 mil. Isso sem falar nas possibilidades de especialização: um profissional de TI no Brasil com mestrado recebe o piso salarial médio de R$ 9,2 mil e um Diretor Técnico e de Operações do mercado de tecnologia pode ganhar até R$ 50 mil. Fonte: Terra em 22/12/2016

Início de carreira com mais de quatro mil reais e em apenas três anos já estar ganhando sete mil… essa não é a realidade da maioria dos profissionais de TI que conheço. Eu tenho mais de 10 anos de carreira e ainda não cheguei perto dos 17 mil… o que é uma pena!

Quem sabe essa matéria levou em conta apenas aqueles que trabalham em regime PJ e não os que tem carteira assinada… de qualquer forma, não me parece algo tão realista.

Pessoalmente me preocupa que essa visão seja disseminada e possa levar pessoas a buscar essa área apenas pela possibilidade de ganhar muito dinheiro, algo que não acontece com tanta frequência.

Vamos começar pelo começo: Não existe apenas “o programador”, assim como não há apenas “o médico” e “o advogado”.

Existem diversas áreas de programação como desenvolvimento mobile, backend, frontend, o faz-tudo (chamado de full stack por quem quer ser chique), etc.

Além das áreas, ainda existem as tecnologias específicas. As linguagens de programação, os sistemas operacionais, os frameworks, as metodologias de desenvolvimento… tudo isso conta para saber quanto vai faturar um desenvolvedor.

Outro ponto importante é em qual cidade você vai trabalhar. Existe uma probabilidade maior para o programador ganhar mais se morar em alguns polos de tecnologia do país, principalmente em São Paulo, graças à lei da oferta/demanda. Muitas empresas precisando de profissionais e nem tantos disponíveis. Isso não quer dizer que não existam programadores ganhando pouco nessas cidades…

Para finalizar, mas não se limitando a isso, o tipo de empresa em que o programador trabalha também influencia, e muito, no seu salário. Startups, fábricas de software, pequenas empresas de desenvolvimento, agências, grandes bancos, etc.

Que tal alguns “estudos de caso” para exemplificar. Começando pelo mais comum…

Um programador júnior trabalhando em uma startup, provavelmente um full-stack, ganha um salário mediano ou até abaixo do mercado.

E um de quem pode estar faturando legal.

Uma empresa em que o produto é um aplicativo, por exemplo, que tem uma VC investindo milhões. Sendo um sênior em uma equipe de desenvolvimento iOS… Sim, esse daí deve estar ganhando muito bem, para os padrões brasileiros.

Esses são alguns pontos que gosto de levantar toda vez que alguém me pergunta quanto ganha um desenvolvedor de software.

Obviamente estes são pontos de vista que obtive durante anos como andarilho nesse mercado e podem diferir de outros profissionais tão ou mais experientes.

Qual o seu ponto de vista? Deixe seu comentário.

Publicado originalmente no Medium.

Categorias
Tecnologia

Essa nova tecnologia vai acabar com o que você usa hoje

Para entusiastas de martelo tudo é prego

Eu adoro ler sobre tecnologia e sua indústria pela internet a fora. É muito bom para descobrir algumas tendências e aprender sobre minha área de atuação.

Mas eu tenho notado um certo exagero em algumas publicações de nicho.

Alguns autores parecem querer reforçar que você precisa aprender essa ou aquela tecnologia porque é a única coisa que vai existir no futuro!

“Essa é a tecnologia que irá acabar com/substituir o que você usa hoje. Esteja pronto!”

Para ilustrar melhor o que quero dizer vou dar alguns exemplos.

Quando comecei a me informar sobre chatbots a primeira coisa que li nos textos do pessoal que já estava envolvido com isso é que os bots tomariam o lugar dos aplicativos mobile e até mesmo dos sites.

Afirmam isso com base em informações relevantes mesmo, como pesquisas que mostram que nos EUA as pessoas não estão mais baixando novos apps. Não é uma invenção, me parece apenas uma interpretação exagerada dessas informações.

Um tempo depois eu achei uma publicação que falava sobre arquitetura serverless. Lá o discurso era que em cinco anos ninguém mais estaria usando servidores.

Quando você faz parte de um nicho é muito fácil se deixar levar por opiniões exageradas em favor do que você está envolvido. Entretanto é preciso ser mais objetivo.

É claro que os chatbots podem assumir uma boa fatia de mercado dos aplicativos nativos (e vão, afinal eu sou um entusiasta ;D), mas não vão simplesmente acabar com eles do dia para a noite.

A mesma coisa para a arquitetura serverless… ninguém mais usando servidores em cinco anos? Um pouco exagerado, não acha?

Esses são apenas alguns exemplos, mas ainda podemos voltar um pouco no tempo e lembrar de algumas ondas que diziam que os aplicativos nativos seriam totalmente substituídos pelos híbridos e, já hoje em dia, substituídos pelos progressive webapps ou chatbots…

Que tal voltar ainda mais, lá no começo da minha carreira nos grupos de Software Livre, onde achávamos que em breve os computadores com Windows seriam minoria perto dos usuários Linux… E quinze anos depois:

Market share de sistemas operacionais

Mesmo que a tecnologia seja muito rápida em sua evolução, dificilmente uma coisa mata outra tão rápido quanto as postagens que geram o hype afirmam.

Isso acontece porque cada negócio tem uma necessidade diferente, então cada tecnologia pode ser a melhor opção para cada tipo de necessidade. Uma não necessariamente mata outra. E não precisa matar!

Para que uma coisa seja boa ela não tem que destruir outra. Existe espaço, e até a necessidade, para tudo!

Eu escrevi o rascunho deste texto dentro de um Cabify, uso Uber com frequência e adivinha só: ainda existem muitos táxis por aí.

Se você gosta de algo e participa de um grupo sobre isso, como eu com chatbots por exemplo, seja um entusiasta sim! Discuta sobre, aposte nisso, mas mantenha os pés no chão. Entenda que o que você faz/gosta pode ser um ótimo martelo, mas nem tudo é prego.

Publicado originalmente no Medium.

Categorias
Tecnologia

Você não precisa de inteligência artificial para criar um chatbot

Nem Machine Learning e Processamento de Linguagem Natural

Todo mundo que trabalha com desenvolvimento de software sabe que, cada vez mais, existem as “expressões do momento” no mercado. É por isso que eu adoro o texto Hype Driven Development…

Uma das mais faladas “expressões do momento” é a inteligência artificial. Ela está em todo lugar, em todas as matérias nas mídias e diversos artigos acadêmicos e começou a ficar extremamente popular no último ano.

Cuidado! Inteligência artificial vai roubar seu emprego!

Depois que o Facebook resolveu liberar os chatbots para sua plataforma de mensagens, chatbot também virou uma expressão do momento. Eu mesmo gostava do assunto antes, mas a partir do ano passado comecei a estudar e aprender ainda mais sobre esse tipo de software.

A partir daí todo lugar onde se vê a palavra chatbot também se vê inteligência artificial. É uma questão bem óbvia, afinal para um robô falar com um humano, ele precisa ter o mínimo de inteligência…

Mas será mesmo que preciso saber criar inteligência artificial para criar um chatbot?

Citando um ótimo texto do Caio Calado que explica o que são chatbots:

Chatbots são serviços baseados em regras e (às vezes) inteligência artificial, onde você pode conversar e interagir através de aplicações/aplicativos de mensagens.

A parte importante dessa citação são as palavras entre parênteses: às vezes.

Como ele explica no texto, existem dois tipos de chatbots. Os baseados em regras e os baseados em inteligência artificial. A maioria dos bots que encontramos por aí é puramente baseado em regras e eles não são ruins por causa disso.

As plataformas de mensagens oferecem diversas maneiras para que o usuário posso interagir com o bot. São botões, listas com links, webviews que abrem uma página externa, etc. Utilizando essas interações fica muito fácil saber o que o usuário quer fazer, sem necessidade de inteligência artificial.

Você não precisa fazer com que o bot tenha um entendimento profundo da lingua portuguesa e entenda cada detalhe de tudo que o usuário está falando para que ele cumpra o que propõe.

Um bot tem que ter uma naturalidade na interação, mas isso depende muito mais do design da conversação do que de inteligência artificial.

Um chatbot é um software. A tecnologia que você vai usar no seu desenvolvimento precisa ser compatível com as necessidades das funcionalidades dele.

Machine Learning, Processamento de Linguagem Natural (NLP) e Inteligência Artificial (AI) são importantes para os mais diversos tipos de aplicações, mas para aquelas que realmente necessitam dessas tecnologias.

Se o bot precisa aprender com dados e interações para melhor atender o usuário e cumprir o objetivo proposto, então Machine Learning é necessário. Se ele precisa classificar textos que o usuário venha a enviar, você vai precisar de NLP… e assim por diante.

Agora se ele fala informações sobre o clima, não precisa ser “inteligente” para bater papo com o usuário ou aprender com as interações. Afinal o objetivo dele é previsão do tempo! Ele só precisa saber onde o usuário está ou de onde ele quer saber a previsão.

Outro grande problema desse hype todo é que essas expressões técnicas assustam quem não conhece e podem acabar afastando pessoas interessadas na construção de chatbots por acharem que é um impeditivo não saber essas tecnologias.

O hype é algo que sempre existirá, mas não devemos nos guiar por ele. Pense no objetivo que o seu chatbot terá e nas funcionalidades que serão necessárias para atingí-lo. Se ele realmente precisar de Inteligência Artificial, então pare de ler e vá estudar matemática agora!

Publicado originalmente no Medium.

Categorias
Tecnologia

O que aprendi publicando um chatbot

A importância do feedback dos usuários

Um tempo atrás eu quis falar sobre chatbots na empresa onde trabalho. Temos um evento interno para compartilhar conhecimento, que começou há pouco tempo por aqui, e aproveitei a chance para mostrar para meus colegas como desenvolver e quais eram as ferramentas que o Messenger do Facebook oferece para a criação de um robô de conversa. Para meu lightning talk resolvi criar um chatbot experimental chamado Climão.

O Climão é um bot bem simples e apenas recebe a localização da pessoa e informa como está o clima no local.

Para isso eu usei um dos templates do Facebook Messenger que cria um botão para o usuário enviar a localização e fiz uma busca em uma API aberta de informações meteorológicas.

Publiquei o bot no Facebook Messenger e aproveitei o que apresentei na empresa para escrever um tutorial.

Após a publicação, algumas pessoas começaram a usá-lo, provavelmente porque leram o tutorial e resolveram testar o bot para ver como funcionava.

Foi aí que comecei a perceber que o Climão precisava de algumas melhorias…

Aprendendo com a experiência do usuário

A primeira pessoa que usou o meu chatbot acessou através de um link que enviei no WhatsApp. Esse link abriu o navegador no celular dela e a primeira coisa que ela me disse foi que o bot não estava funcionando.

Eu dei uma olhada no que ela estava fazendo e vi que ela não usou o botão de enviar localização e sim escreveu o nome da cidade. Pedi para que usasse o botão, mas ela reportou que ele não aparecia para ela.

Fiquei sem entender nada… mas pedi para que abrisse no aplicativo do Messenger e a partir daí tudo funcionou normalmente.

Acessando o histórico de mensagens da página do Climão percebi que mais algumas pessoas estavam tentando escrever o nome da cidade e não usando o botão de enviar localização. Isso era algo que eu não tinha previsto e portanto o bot não entendia e acabava reenviando o botão o tempo todo.

A primeira coisa que pensei foi que as pessoas não estão acostumadas a usar botões em chats, deve ser esse o problema.

Mas a realidade era outra.

Quando montei o bot para a apresentação, não dei atenção alguma para o texto que convidava o usuário à escolher a sua localização. Ele dizia: “De qual cidade você quer saber o clima?”. Isso fazia com que a pessoa pensasse que tinha que responder à pergunta.

Esse feedback veio da mesma pessoa que citei a cima. Algo que não havia me passado pela cabeça!

Isso podia mesmo ser um motivo, mas os dias passavam e eu via mais gente usando o Climão e escrevendo repetidamente o nome da cidade em vez de usar o botão.

Será mesmo que apenas a pergunta estava levando tanta gente à escrever a cidade? Por acaso, acabei descobrindo que não.

Lendo outro texto do Medium que falava sobre um chatbot, resolvi clicar no link para experimentá-lo. Foi então que o mistério se resolveu.

As pessoas estavam acessando o Climão pelo texto do Medium, assim como eu, provavelmente pelo celular, assim com eu, e estavam caindo direto no navegador, assim como eu.

Abrindo a página do Facebook pelo navegador do celular e clicando em “Enviar mensagem” você entra em uma página terrível de mensagem que não tem nenhuma das funcionalidades dos bots do Messenger. Nela você pode interagir com o bot apenas por texto!

No lado esquerdo a versão do navegador mobile e na direita o aplicativo do Facebook Messenger.

Isso poderia ser mais um motivo, além do “texto-pergunta”, que estava fazendo as pessoas digitarem ao invés de enviarem sua localização pelo botão.

Foi então que resolvi melhorar o bot, mesmo ele sendo apenas um experimento para um tutorial, achei que valia a pena a experiência de aprender com a interação de usuários.

Gastei um tempinho nele e fiz com que também aceitasse o nome da cidade escrita. Mudei a frase que pede a localização. Agora ele escolhe aleatoriamente entre algumas opções de texto que indicam ao usuário que pode digitar uma cidade ou apertar o botão de envio de localização.

Aproveitei para dar um tapa no visual da apresentação dos dados também. Ao invés de enviar apenas um texto, resolvi utilizar o template de lista que a API de envio do Messenger proporciona.

Interações “fora do contexto”

Um outro fato que me chamou a atenção quando analisei as mensagens enviadas pelos usuários foram as mensagens que estavam “fora do contexto” das funcionalidades do Climão.

Com “fora do contexto” eu quero dizer interações que eu não previ.

Coisas simples como um “Olá” e um “Obrigado” não eram tratadas, deixando o bot muito “robótico” e pouco natural na conversação. O Climão era antipático!

Dei uma atenção para o tratamento desse tipo de interação, mas não gastei muito tempo com isso ainda, afinal ele é apenas um experimento. Podemos dizer agora que ele não é muito simpático, mas pelo menos já é educado.

Algumas coisas ele responde, mas não chega a ser tão esperto assim…

Conclusão

Esse bot tem sido um experimento incrível. Além de ter aprendido muita coisa com um chatbot tão simples, ainda tenho ganhado uma experiência importante sobre como evoluí-lo para melhor se adaptar às interações com os usuários.

O feedback é a melhor maneira de se aprender. Saber onde você errou ou o que deixou passar depende muito dessa interação com diferentes pessoas. Por isso foi tão importante tirar esse bot do “desenvolvimento” e deixá-lo disponível para o público em geral.

Se você leitor tiver alguma sugestão para melhorar o Climão, deixe sua resposta abaixo. E se quiser ver o código-fonte, acesse o repositório no Github. Quer saber o clima atual em algum lugar? Mande uma mensagem pro Climão!

Publicado originalmente no Medium.