Como Conversar Com Um Programador
Bom, este artigo é pra ser uma conversa super amistosa, pois eu quero te passar algumas percepções muito legais sobre como melhorar a sua comunicação com um programador, com alguém que trabalha com Engenharia de Software. Isso vale pra você que é da área de marketing, vendas, do time de produtos, ou qualquer outro que trabalhe numa empresa que conte com um time de programadores.
Já vou te adiantar que às vezes essa turma pode parecer meio dura na queda, mas é por um bom motivo… É sério! E essa é a parte mais importante dessa conversa. Inclusive, olha só que interessante: Sabe aquele ditado do Judô, que diz que se deve “utilizar a força do oponente para derrubar ele”? É exatamente isso. Usar a força dele, mas sem a parte de querer derrubar ele, obviamente…
Só que dai eu te pergunto:
"Então sem a parte do derrubar, o que sobra é a força… e você realmente sabe qual é a força dele (do programador)?"
Então eu vou abrir agora um espaço aqui para a gente revisar algumas opiniões comuns. A força de um programador é:
1 — Escrever código
Olha… vamos ser honestos, “escrever código” é um bom palpite, de fato. Mas você também escreve coisas no seu cargo correto? Por exemplo, você escreve emails! Será que daria para resumir seu cargo a isso, por mais importante que sejam os seus emails que você escreve?
Então vamos lá, sem problemas, vamos subir um nível de abstração e tentar de novo. A força do programador é:
2 — Resolver problemas
Olha, que massa! “Resolver problemas” de fato é algo bastante acima do que só escrever código não é mesmo? Mas sobre resolver problemas… você está deixando o programador resolver problemas, ou já está vindo com os problemas resolvidos?
É comum achar que para facilitar o trabalho do programador, você já chegar com o problema resolvido e ainda falar como tem que ser feito, basta!
Me desculpe, mas isso me dá dor de barriga!
Sabe porquê? Eu também sou programador essas coisas são tipo criptonita pra gente!
Faz sentido, não faz? Se a gente combinar que a força do programador é resolver problemas, quando você chega com o problema já "resolvido", adivinha só… você tirou a força dele! Assim como a criptonita tira a força do Super-Homem!
Não estou dizendo aqui que um programador é um Super-Homem, nem que você deveria dar um aumento pra ele, até porque caso você esteja deixando ele sem forças, sem conseguir mostrar o impacto bizarro de alavancagem e automatização que ele pode trazer pra sua empresa, como que ele deveria ser bem remunerado, não é mesmo? Não é mesmo?
Enfim, mas eu gostaria de propor essa conversa ir um passo além, subir ainda mais na abstração sobre qual a força de um programador dentro de uma empresa. E na minha visão, a real força de um programador é:
3 — Tomar decisões
Decisões sérias, decisões difíceis.Tomar decisões ao ponto de tanto você, quanto ele acreditarem que a decisão é de vocês dois. Porque pensa comigo… tomar uma decisão traz várias coisas novas para a mesa que fazem parte da mecânica do ser humano. Começando talvez pela mais forte, mas que entre você e eu, ninguém vai querer assumir, que é o Ego!
O Ego de não querer que aquela decisão de errado… Isso na medida certa tem seu valor e não me diga que você não tem ego nas suas decisões, fechado? Eu já passei por todas as posições dentro de uma empresa e eu já senti muita coisa na pele.
Outra coisa muito importante é o senso de responsabilidade que vem junto disso. Tudo faz parte de um mesmo pacote. Então, a minha sugestão para você conseguir se comunicar e usar realmente a força de um dos papéis que mais pode conseguir alavancar os resultados da sua empresa é bem simples:
Ao invés de trazer um problema resolvido, ou pior como deveria ser resolvido, traga esse problema como um inimigo em comum a todos vocês, um desafio real para o qual você precisa também do cérebro dos programadores para resolver, de um jeito brilhante e considerando todas as dívidas técnicas que foram criadas no passado.
Dívida técnica? Você não sabe o que é isso? Sem problemas… Querer que os programadores trabalhem rápido com um sistema repleto de dívidas técnicas é como você pedir para eles acelerarem um carro a 120km/h numa estrada completamente esburacada, sem sinalização ou sinalização errada, enquanto você está lá na arquibancada vendo o que vai acontecer.
O programador vai ou optar ir devagarinho desviando dos buracos, ou dar uma de louco, furar os pneus e ficar completamente parado na estrada. Às vezes, tapar os buracos dessa estrada seria um inimigo em comum para vocês dois, não é mesmo? Pois aí sim seria possível acelerar até a velocidade que você acha que deveria estar. Porque se não for dessa forma, com esse envolvimento, você vai acabar voltando nas camadas de abstração que a gente passou até chegar aqui nesta etapa desse artigo, e vai voltar a reduzir essa pessoa a apenas “escrever código”, ou um mero “escritor de email” ou um “apresentador de Power Point”.
Falando nisso… segure um pouco a onda no Power Point. Não dá para um programador pegar seus slides e compilar em código... Eu sei que isso seria um sonho, não é mesmo? E falando em Power Point, forneça dados concretos sobre um problema, evidências, coisas que façam os programadores visualizarem na cabeça deles o mesmo monstro que está na sua cabeça. Se eles visualizarem, você vai ver o poder que essas pessoas vão trazer para a empresa e a força que ela vai ganhar para os projetos saírem do papel.
Outra coisa que eu notei que atrapalha muito é não existir um real esforço para entender o trabalho dos programadores, o linguajar… Você fala em Java e JavaScript como se fossem a mesma coisa! Agora, o programador não tem escapatória a não ser entender tudo o que você está falando, nos detalhes, todas as variações e exceções, se não ele vai programar coisa errada, com bugs ou nem conseguirá terminar os projetos porque entrou numa rua sem saída.
Você precisa aprender o mínimo sobre a tecnologia que a sua empresa usa.
Se não, sabe o que vai acontecer e isso é só questão de tempo? Vai nascer um garotinho que sabe programar, entende e gosta do assunto principal da sua empresa, e ao invés de escolher trabalhar nela, ele vai abrir uma startup e vai ser a maior pedra no sapato da sua empresa.
Para garantir a sua utilidade num futuro que está bem próximo (e dá pra sentir até o calor da inteligência artificial chegando) você não precisa aprender a programar para exercer o ato de programar, mas para exercer o ato de se comunicar, fechado?
E agora duas coisas muito importantes. Agradeça o programador que enviou este artigo, ele não fez por mal, muito pelo contrário, ele quer o seu bem e da sua empresa. E diga pra ele, de uma forma bem sincera, que se ele quer continuar a melhorar o mercado nesse ponto, a melhor coisa que ele pode fazer é pegar o link desse artigo e passar pra outro colega, ou pra colocar no grupo da empresa. E também diga pra ele que ele não está imune a erros não! Ahh, de longe não está… Começando pelo fato de que ele não sabe dizer não e acaba falando sim para muita coisa e se perdendo completamente. Tem um artigo especial meu aqui no Medium sobre isso, sobre 4 hábitos que fazem ele ser um programador ruim e eu coloquei o link deste artigo aqui, fechado? Valeu!
