5 Conceitos Técnicos Que Todo PM Deve Saber

É um erro de muitas pessoas que não estão familiarizadas com a área de produto acreditarem que é necessário saber programação em um nível muito detalhado ou ter uma formação na área de tecnologia para se tornar um Product Manager. Para gerenciar produtos de tecnologia não é necessário um conhecimento extremamente técnico sobre linguagens de programação ou arquitetura de sistemas, porém como tecnologia ainda é um ponto principal do seu produto (claro, se você trabalha com produtos digitais) é esperado que você conheça alguns conceitos.

Dizem que um PM deve lidar com 3 áreas (negócio, UX e Tecnologia), ser muito bom em uma e apaixonado por todas. Pessoalmente eu sempre tive muita familiaridade com a parte de tecnologia, apesar de ter me formado em administração de empresas eu comecei a programar desde cedo na minha carreira, habilidade que acabei levando para faculdade onde acabei desenvolvendo o hábito de explicar conceitos técnicos para pessoas focadas mais em negócios. Esses são os que considero principais para todos que trabalham em áreas fortemente ligadas a tecnologia:

1. Front-end e Back-end

São termos utilizados para designar partes específicas de uma aplicação, sendo o front-end a parte que contém a interface pelo qual o usuário interage, e o back-end a parte responsável por lidar com a base de dados e executar as regras de negócio. Geralmente também são termos utilizados para nomear desenvolvedores que se especializam em trabalhar em uma parte específica do sistema.

O front-end não deve ser confundido com a interface de usuário (UI), que por sua vez costuma ser definida por um profissional de design e não um desenvolvedor. Front-end sempre envolve código, e não necessariamente cabe ao desenvolvedor definir a interface (embora isso possa acontecer em algumas empresas). Geralmente é a parte do desenvolvimento que é mais ligada com a experiência do usuário, sendo responsável por garantir experiências otimizadas para o usuário. É importante que o desenvolvedor de front-end esteja em sintonia com os objetivos de UX do produto, garantindo assim que o produto esteja devidamente otimizado para a utilização do cliente. Algumas linguagens que são normalmente utilizadas na programação front-end são HTML, CSS e JavaScript (sendo que normalmente são utilizadas frameworks como JQuery, Angular ou React no JavaScript).

Com relação ao back-end, normalmente é onde se encontram os cálculos mais complexos e onde ficam determinadas as regras de negócio do sistema. Funcionalidades de back-end costumam ser mais difíceis de serem testadas por pessoas com menos conhecimento técnico, por isso é importante que sejam muito bem alinhadas com todos os stakeholders e com o time de desenvolvimento. Ferramentas como critérios de aceitação bem definidos e BDD costumam reduzir os problemas que surgem da comunicação entre negócio e desenvolvimento. São exemplos de linguagens back-end: Ruby, NodeJS, Java e PHP.

2. Débito/Dívida Técnica

Nem sempre desenvolvedores tem o conhecimento ideal ou o tempo necessário para executar uma tarefa da melhor maneira possível. Quando o trabalho é executado de maneira que não é a ideal, ele acaba gerando o que chamamos de dívida técnica (tech debt em inglês). O que acontece é que um código mal feito dificulta que novas funcionalidades e alterações sejam feitas em cima dele. Assim o tempo que foi ganho inicialmente por criar a funcionalidade e modo rápido acaba sendo perdido no longo prazo, conforme as funcionalidades vão ficando cada vez mais difíceis de serem implementadas e a produtividade do time acaba sendo reduzida.

O nível de dívida técnica costuma variar de projeto para projeto, as vezes até mesmo dentro da mesma empresa. Costuma ser algo complexo de se lidar por envolver uma grande parte de retrabalho por parte dos desenvolvedores e também por não gerar resultados que são imediatamente vistos pelos stakeholders. Embora seja o caso, abordar dívida técnica tem grandes benefícios a longo prazo para o produto, aumentando drasticamente a eficiência do time de tecnologia e consequentemente melhorando a frequência e a qualidade das releases. Assim, devemos considerar dívida técnica como um investimento a longo prazo que tende a pagar amplos dividendos.

3. Code Review

Provavelmente logo depois que eu terminar de escrever este artigo eu vou pedir para alguém revisar o meu trabalho. Escrever código não é diferente. Para garantir que as melhores práticas sejam cumpridas e que o código possua a funcionalidade desejada, ele deve passar pela etapa de Code Review. Nessa outro programador que não estava diretamente envolvido na elaboração da funcionalidade revisa o que foi escrito em busca de pontos de melhoria ou inconsistências. Essa etapa também deve ser usada como oportunidade de aprendizado entre o time de desenvolvimento, pois é o momento em que recebem feedback uns dos outros.

Normalmente a etapa de Code Review é atrelada a um “Pull Request”. Esse nada mais é do que uma solicitação de um desenvolvedor para o seu código novo ser acrescentado a outra base de código (vou entrar em mais detalhes com relação a isso nos próximos 2 pontos deste artigo). Assim uma tarefa só deve afetar outro ambiente com a aprovação de outros desenvolvedores, reduzindo assim a chance de falhas e bugs chegarem no usuário final.

4. Git

Git é uma ferramenta utilizada para rastrear mudanças realizadas em um determinado arquivo ou conjunto de arquivos. Imagine que você está escrevendo um texto junto com outros autores, e todos tem a possibilidade de alterar o texto ao mesmo tempo. Neste caso, é possível que muita informação acabe sendo perdida conforme as alterações são feitas e erros acabem por acontecer com mais frequência. O Git serve então para garantir que toda modificação no código esteja devidamente catalogada, podendo ver as diferentes versões do código existentes em cada momento do tempo de sua existência. Assim, no caso de um erro é muito simples voltar para a versão anterior.

Outra vantagem de se utilizar o git para controle das mudanças é a possibilidade de se criar “branches” no código. Normalmente não é ideal fazer modificações que podem impactar diretamente os seus usuários e talvez quebrar funcionalidades que antes estavam funcionando. Assim, criamos ramificações do código para poder trabalhar sem afetar o código principal, e quando estamos prontos para juntarmos as branches criamos uma solicitação que mostra as mudanças que irão ocorrer (a solicitação chama “pull request" ou “PR") e quando a solicitação é aprovada acontece a junção dos dois códigos (ou “Merge" como é normalmente chamado).

5. Ambiente de Produção vs Homologação vs Desenvolvimento

A gravidade de um erro costuma estar diretamente ligada com o número de pessoas que ele afeta. Por isso fazer testes e adicionar novas funcionalidades diretamente onde todos os seus usuários serão afetados nunca costuma ser uma boa ideia. Assim, existem ambientes em que os desenvolvedores tem a possibilidade de errar e testar o quanto for necessário, como no caso do ambiente de desenvolvimento, onde as únicas pessoas afetadas pelos testes são os próprios desenvolvedores.

Agora supondo que depois de diversos testes o desenvolvedor se sente confiante que seu código está funcionando da maneira que deveria. Ele pode se sentir tentado a colocar diretamente no ambiente de produção para que todos os usuários possam usufruir da nova funcionalidade, mas isso não seria o ideal. Nesse caso o melhor a se fazer é usar um ambiente de homologação, que nada mais é que um ambiente que deve ser o mais próximo possível do de produção, mas que apenas as pessoas diretamente envolvidas no projeto tem acesso. Assim todos os stakeholders podem avaliar se todos os requisitos da tarefa foram devidamente cumpridos. Em caso positivo, então se torna seguro subir as funcionalidades para o ambiente de produção onde poderá ser utilizada por todos os usuários.

Sobre o autor: Eu sou um Product Manager acostumado a lida com projetos digitais. Eu já gerenciei equipes de até 17 engenheiros e já ajudei diversas empresas criarem produtos que atingiram product market fit. Eu me formei em administração de empresas e aprendi a programar desde cedo. Se você precisa de ajuda com o desenvolvimento de um produto de tecnologia, ou simplesmente quer conversar, fale comigo no LinkedIn: https://www.linkedin.com/in/sergio-cleto-837572a0/