Programador orientado a entrega de valor — Como atrair atenção de startups em ascensão

É de comum conhecimento que na área tech nós temos algumas terminologias que são atribuídas a capacidade de cada desenvolvedor. Porém, por não existir uma bíblia do desenvolvedor onde se pode consultar exatamente o que se é necessário para cada "patamar", nós temos ficado cada vez mais com nossas próprias definições baseadas nas de pessoas mais influentes. Pois bem, nesse artigo você poderá ver mais uma opinião e levar(ou não) esse ponto de vista para sua definição própria de senioridade.

Se você está aqui correndo e não quer uma introdução delicada a essa nova perspectiva você pode pular o próximo capítulo e ir direto para o "Senioridade é só capacidade técnica?"

Mas porque diabos eu deveria repensar ou incrementar meu conceito de Sênior?

O princípio desse artigo é tratar sobre um tema cada vez mais falado e procurado por empresas do nicho tecnológico que tem descabelado e "puxado o pé” dos desenvolvedores "da antiga". A visão de negócio em um desenvolvedor.

A principio sua reação pode ser:

Se sua reação foi essa é completamente plausível, há muito tempo, desde os primórdios da humanidade se entende como desenvolvedor uma pessoa excluída, que tem pouco contato com outros bípedes, entre diversos outros adjetivos e pré-conceitos. E isso acabou se entranhando no coraçãozinho de muitos desenvolvedores.

Vamos por um momento esquecer que você, que teve a reação do nosso amigo acima, odeia contato com humanos e acredita que desenvolvedor só desenvolve e gestores fazem business. Abra seu coração, abra a janela do seu quarto que provavelmente está fechada há uma década e embarque nessa opinião.

Senioridade é só capacidade técnica?

As definições de capacidade técnica relacionadas a senioridade (junior, pleno e sênior) são faladas a torto e a direito por aí, e não vamos repetir tudo isso aqui. O ponto que precisamos talvez repensar seria:

Será que a senioridade de uma pessoa é estritamente vinculada a capacidade técnica?

Eu venho dizer que acredito que não. A senioridade técnica é muito importante claro, porém, só ela não faz um profissional com um nível superior. Cada vez mais com o crescimento e popularização de startups (e quando digo startups não me refiro a empresas com capital de 1 coxinha e uma coca 500ml) procuram por desenvolvedores com capacidades sociais, comunicativas, gestoras e visionárias. Tais características são colocadas dentro de uma categoria chamada de soft skills. Essas definições são muito importantes hoje em dia por não serem tão simples de serem adquiridas. E quando digo isso de maneira nenhuma aqui queremos tirar o mérito da dedicação técnica para um desenvolvedor alcançar um nível alto de conhecimento, mas, esse nível por empresas, pode ser interpretado como um patamar facilmente alcançável com o investimento certo no profissional correto. Já as softs skills não representam essa mesma facilidade. Elas são um misto de maturidade e alinhamento cultural que dificilmente pode ser aprendida por um profissional em um curto espaço de tempo ou por desalinhamento por traços de personalidade, criação, ambiente, condições de vida entre outros.

O que é esse pensamento em negócios?

O conceito é, na verdade, bem simples. Entregue Resultados mensuráveis.

É muito comum para desenvolvedores, nos mais variados níveis de senioridade, ao trabalharem em projetos, entenderem "o seu melhor" como um projeto rápido, com um stack atual, as melhores tecnologias, design pattern, design system e etc. E não que isso seja menos importante mas deveria representar apenas uma porcentagem da sua entrega. Esse pensamento em negócios pode ser melhor entendido quando ilustrado em um projeto real. Pois bem, vamos a um exemplo e seguiremos a partir dele.

Eu recentemente estive trabalhando em um projeto de uma checkout. Basicamente uma página de pagamentos que receberia uma quantidade razoável de pagamentos através da mesma. Esse será um novo projeto que dará uma nova "cara"a checkout antiga. Vale dizer que pontos como, não poder cair, precisar ser segura e etc já estão subentendidos. O momento que mais comecei a me questionar e refletir sobre essa prática de entrega de resultados foi justamente nesse projeto.

O ínicio: Checkout

Pense da seguinte maneira, a sua primeira vontade pode e provavelmente será pensar ao ser inserido em um projeto como esse em XSS, CSRF, gerenciamento de credenciais, Sanitize entre outros aspectos técnicos que garantam que se alguém pagar um carro por R$ 1,99 na sua checkout você não seja demitido. E por favor, não pule essas etapas, mas o questionamento aqui é que nesse ponto você deveria também se preocupar em entender qual a necessidade dessa nova checkout? Já não existia uma checkout? Porque ela não atendia as expectativas? Qual hipótese estamos tentando validar com essa nova checkout?

Todas essas perguntas são muito importantes de começo para uma aproximação do desenvolvedor com a solução esperada por pessoas que desconhecem códigos e para adaptar uma solução ao problema e não o problema à solução. Se ficou confuso nessa frase vamos chamar o "dexter" e dissecar um pouco mais a fundo ela:

Quando atingimos um certo tempo de estudo e de prática, geralmente temos um conjunto de tecnologias com a gente. E essas tecnologias na nossa cabeça, magicamente fazem sentido em diversos cenários, mesmo que fora da nossa cabeça não façam sentido algum. Isso é porque alguns desenvolvedores tem o costume de conhecer tão a fundo um conjunto de tecnologias que bem provavelmente ele se torna um pregador da palavra desta tecnologia. Mas essa prática na minha opinião é errada, e deve ser evitada para trazer benefícios não só para você como desenvolvedor mas para a empresa. Primeiramente para você que já se considera com um nível de senioridade técnica elevada, você não precisa ter medo algum de se arriscar em novas tecnologias, linguagens e etc. É claro que em seu primeiro contato você irá precisar considerar uma curva de aprendizado, mas uma vez que você já aprendeu a desenvolver, usar diferentes linguagens não deve ser nenhum mistério. E sendo assim, para a empresa, ela não ficará presa a uma stack eternamente e daqui há 50 anos quando programadores em javascript forem apenas humanos de 90 anos para cima, não será necessário oferecer valsa e dominó como parte do plano de benefícios da empresa.

Quando se tem essa noção se torna muito mais simples entender quando dizem: não existe uma linguagem melhor que a outra.

Tudo que você vai fazer deste ponto em diante é estudar os prós e contras das tecnologias disponíveis e o problema vai praticamente pedir a sua solução ao invés de forçarmos as regras de negócio goela a baixo da tecnologia.

Então quer dizer que eu preciso saber programar em tudo!?

Não foi isso que o amiguinho disse, o que estou dizendo é: esteja mais aberto a entender o problema e criar uma solução baseada na dor do seu cliente. Não necessariamente você precisa desbravar os 4 cantos das linguagens, apenas esteja aberto.

O Planejamento: Checkout

Assumindo essa postura, o próximo passo passa a ser mais intuitivo. Como aqui, já temos uma noção de quais hipóteses esse projeto quer validar, e quando digo isso pode se entender como: O que é esperado desse projeto?

Sabendo a resposta para essa, e outras perguntas que forem surgindo, você sentirá uma segurança muito grande e quase que uma necessidade em desenvolver POCs, Estudos de caso, MVPs entre outros preparativos para garantirem que o que você planejou como solução é a melhor opção. Bem como refletir sobre o que pode ser feito em relação a sua construção de solução que agregue resultado a esse projeto. Falaremos um pouco mais desse ponto no próximo capítulo.

O Desenvolvimento: Checkout

Nessa etapa, você pode colocar em prática, pensando em entrega de valor, o que fazer para entregar mais resultado on time e on budget. Quando se pensa dessa maneira e se muda esse estigma na sua cabeça, ideias como testes automatizados, métricas, tracking passam a fazer muito mais sentido do ponto de vista técnico. Um exemplo básico desse comportamento pode ser o seguinte: Como estamos desenvolvendo uma checkout é comum que tenhamos campos, validações e máscaras. Quando juntamos essa santíssima trindade, muita gente já vai sentir emanando do fundo do coração as palavras: Formik + Yup. Caso você não esteja por dentro dessas tecnologias, elas são uma duplinha do mal utilizadas principalmente na área de React, para resolver problemas de formulários como validação de campos, controle de valores entre outros. Se você conhece e pensou nessa solução, tudo bem fazer essa associação, mas o que quero levantar aqui é: O que esse dueto pode trazer para nós pensando em entrega de valor?

Para chegar a essa conclusão, o primeiro passo que se precisa pensar é que para se entregar valor não precisa ser complexo, não precisa ser tecnologia de ponta e muito menos utilizado pela NASA. Um exemplo do que poderíamos pensar é: E se utilizarmos uma sessão para armazenar os values do formik para quando o usuário tentar efetuar um pagamento e receber algum erro o formulário já estar pré-preenchido e validado? Você já pensou em usar o formik assim?

Pois é, essas são funcionalidades que quando não olhamos com um olhar de negócios para uma tecnologia deixamos escapar. O Formik conta com enableReinitialize, isInitialValid, initialTouched e validateOnMount.

Esse conjunto de opções podem facilmente te ajudar a criar essa feature que pode, e deve, ser entregue como um esforço de diminuir a fricção por erros ou problemas de pagamento pelo usuário. Esse pensamento é nitidamente uma entrega de resultados vinda do desenvolvedor.

Resumo da prosa: Eu preciso mesmo disso?

Claramente existem mil outros exemplos e ideias que poderiam ser aplicadas, mas como eu falo muito e já me extendi demais vou encerrar esse questionamento e as exemplificações.

Em resumo, o que quero dizer com esse artigo é: você para ser um desenvolvedor com foco em entrega de resultados só precisa exercitar essa prática até conquistar a capacidade de entendimento da sua unidade de negócio. É muito importante para grandes empresas onde o processo de um produto passe por diversos núcleos que todas as etapas estejam atentas a entregarem um produto que traga resultados para a empresa. Cada profissional tende a ver com mais clareza como entregar resultado usando o seu próprio conhecimento e experiência. E essa prática se trata exatamente disso. Nós desenvolvedores, somos muitas das vezes a ponta da lança, podemos revolucionar ou derrubar um projeto com não mais que um commit.

Essa característica é dependente de tempo na empresa em questão?

Com certeza não. Muitos tem uma visão similar a que estamos falando aqui nesse âmbito. Onde por um profissional ter passado por exemplo 4 anos trabalhando em uma empresa de e-commerces se subentende que ele entende das regras de negócio e ao ser contratado por uma empresa do mesmo nicho, ele teria ou representaria um nível de senioridade maior.

Mas a prática que estamos falando aqui pode ser vista como um hack dessa linha de raciocínio. Quando o profissional demonstrar capacidade e essa linha analítica de negócio da ponta da lança, bem provavelmente a empresa se sentirá muito mais segura sabendo que lá no fim existe um gate keeper atento e pronto para inovar ou reprovar sempre que for necessário.

E se você não se sente confortável com isso, tente uma segunda vez. Hoje a área de desenvolvimento tem ficado cada vez mais inovadora e criteriosa. Para quem estava no mercado na crista da onda do react consegue se lembrar muito bem que vagas de emprego na área não exigiam mais do que saber react. Mas com o passar do tempo, e o aumento da demanda, a oferta fica cada vez mais exigente. Você ao dizer não para esse novo espectro de profissional deve se alertar a estar fadado a trabalhar em empresas tradicionais, com culturas de foco em dinheiro e não em profissionais entre outros. O que faz até sentido. Pense: Se você não se importa em entregar resultado, quem está lá em cima sim, e ele terá. Nem que sua felicidade profissional e boa estadia seja o custo para isso.