‘Technês’: a linguagem não tão secreta dos desenvolvedores

Você não precisa ser fluente para entender o que é preciso para seguir em frente

“Mari, o back-end está a duas sprints à frente do front.” Disse o desenvolvedor, sorrindo. Senti que ele estava esperando alguma reação minha, qualquer uma que não fossem os olhos arregalados e a boca entreaberta. Finalmente, depois de segundos intermináveis, respondi. “Ótimo, bom trabalho!”. Ufa. Mas… O que ele quis dizer com isso?

Sou formada em Comunicação Social há anos e nunca pensei que chegaria a um momento da minha vida em que a capacidade de me comunicar seria tão posta à prova e logo no meu primeiro projeto como Product Owner. Quando decidi mudar de área, há quase dois anos, tinha plena consciência dos meus gaps de conhecimento, mas não sabia que eles eram tão profundos.

Naquele tempo eu tinha receio de tudo, desde como lidar no dia a dia com o framework (Scrum) em si, passando por como usar ferramentas como o Jira, até em como colocar em prática técnicas básicas — escrever uma user story, iniciar um backlog do zero –, mas o que mais me intimidava era o “technês”, linguagem da qual nem iniciante era.

Nunca havia me sentido tão insegura, nem mesmo quando era da Comunicação e tinha que editar textos sobre AWS Lambda, Kotlin, React, Node.js etc. Se bem que nessa época eu usava a aclamada técnica jornalística “dá uma lida aí e veja se foi isso o que você quis dizer”, mas como Product Owner sou cobrada por “escrever e editar”, então essa técnica não cola.

Quando estava no processo migratório Comunicação — Produto, me diziam que não precisava ser técnico para trabalhar como Product Owner e com o meu primeiro produto percebi que de fato, não precisa. O que precisa é conseguir disseminar o entendimento da técnica, porque como consultor a gente precisa passar o conhecimento também para o cliente. Ou seja, não precisamos ter background técnico, mas sim entender o processo de desenvolvimento do produto em si e, nesse caso, conhecer e estar familiarizado com os termos técnicos.

Assim como navegar bem na tríade Tecnologia, UX e Negócios, já que estamos no meio dela. Entendendo sobre negócios (talvez não sendo o melhor conhecedor de mercado), entendendo sobre UX (aplicando técnicas de pesquisa e trabalhando próximo aos designers) e entendendo sobre tecnologia (não tendo um conhecimento profundo, mas sabendo o porquê da necessidade técnica e do como ela vai ajudar) conseguiremos entregar um produto de valor, usável e viável tecnicamente e, dessa forma, estaremos exercendo o nosso papel.

Acredito que, na prática, para suprir ou minimizar esse gap técnico o jeito é investir em outras (soft) skills, principalmente, na humildade e na persistência. Humildade para utilizar, sem parcimônia, a “técnica do garçom” (confirme o pedido e pergunte ao cliente se quer algo mais), mesmo que uma dessas perguntas soe boba até para você; e persistência para conseguir aprender. E o aprendizado é diário.

Claro que aconselho a dar uma lida sobre GitHub, Json, Swagger, CI, CD, SQL, mas isso vai te dar apenas um cheiro do que ainda está por vir. Mesmo porque, um projeto é diferente do outro, tanto em exigência de conhecimento técnico, quanto em diferença de engenharia e arquitetura.

Por isso, quando um desenvolvedor fizer uma afirmação do tipo “o back-end está a duas sprints à frente do front”, ao invés de bancar a esperta, seja transparente (um dos pilares do Scrum): “eu sei que você deve ter feito um ótimo trabalho, mas traduz isso para mim, por favor.” Não sinta vergonha por não saber que quanto mais o back-end estiver à frente, menos chances de gerar retrabalho o front terá, porque ele vai poder trabalhar em cima de APIs reais e não em contratos baseados em suposições ou até em mock.

Esta, inclusive, é uma prática do Dual Track Scrum, recomendada pelo “guru” Marty Cagan, para que design e API estejam até duas sprints à frente do desenvolvimento front-end, para que as histórias estejam maduras o suficiente, validadas com usuários e para que o front não fique ocioso enquanto espera design e API ficarem prontos. Nem todos trabalham dessa forma, mas é bem comum em Times Scrum.

Ainda no meu primeiro produto, aprendi que não adianta saber o nome de uma API, se você não entendeu se a entrega dela tem dependência com aquele tal sistema legado ou de terceiros; não adianta decorar quantos e quais elementos existem em determinado array (arranjo), se não faz ideia se esse agrupamento traz todas as informações que o front precisa. Certa vez, vendo minha dificuldade, um grande gestor interveio:

“Nunca decore ou repita termos técnicos sem entender sobre o que está falando, porque vai vir uma pergunta que você não vai saber responder. Traduza o técnico para a linguagem de negócio, aí sim você vai conseguir passar a mensagem.”

Logo quando comecei a transferir para o meu repertório palavras e conceitos com os quais não tinha a mínima intimidade, o Scrum Master do time morria de rir com as metáforas, mas eu me fazia entender. De fato, não é preciso ser técnico para ser Product Owner, mas é essencial ser um comunicador. O importante é o entendimento do todo e como ele vai ser passado adiante, não ser fluente em “technês”.

Quer aprender essas e mais lições junto com o nosso time? Dá uma olhada aqui e candidate-se! E se tiver qualquer dúvida ou contribuição é só deixar um comentário. Até a próxima!