“Para ser Product Manager eu preciso saber programar?”
Com a onda de transição de carreira para a área de produtos digitais – que vem crescendo a cada dia por não exigir uma formação antes de começar a atuar – tenho visto por aí que essa é uma das maiores dúvidas da galera. Por isso estou aqui para dar um empurrãozinho, esclarecendo um pouco mais esse assunto.
Primeiramente, respondendo a pergunta: não, você não precisa saber programar para assumir o cargo de Product Manager. Porém, uma coisa que posso garantir, é que ter o mínimo de entendimento de termos técnicos e de como algumas coisas funcionam nesse universo vai te ajudar a:
- Ter mais confiança e segurança na rotina como PM;
- Te destacar por conseguir compreender as discussões do time de Engenharia e levar isso para o seu cliente, traduzindo tudo em valor para o negócio.
Bom, tendo isso em mente, vou tentar trazer neste artigo um pouco sobre os principais conhecimentos que considero importante uma pessoa PM conhecer da parte técnica, com base na minha experiência – da forma mais didática possível.
Claro, isso também vai depender muito do contexto do seu time. O que eu trouxer aqui vai ser para te ajudar a compreender esses assuntos, e talvez nem todos estejam relacionados ao que você está vivendo. Sempre converse com seu time de Engenharia e tente entender mais sobre com o que eles têm trabalhado se você considerar isso necessário para desempenhar seu papel.
Serviço/Plataforma/Infraestrutura
Antes de tudo vamos entender sobre 3 tipos de serviços/aplicações mais usados e a diferença entre eles.
SaaS (Software as a Service)
Basicamente é um produto oferecido a seus clientes como serviço, no qual a sua principal vantagem é não precisar instalar ou atualizar software no seu computador – isso porque a maioria desses serviços ficam em nuvem e você os acessa online.
Sendo assim, em vez de comprar a licença para usar um software específico de seu interesse, você pode contratá-lo como um serviço e pagar por ele conforme o uso.
Alguns exemplos desses serviços e que eu tenho certeza que você deve usar alguns desses são:
- Dropbox;
- Google Drive;
- Netflix;
- Paypal;
- Zoom;
- Slack;
- Canva;
- Spotify.
PaaS (Platform as a Service)
É um modelo onde poucas pessoas de negócio irão interagir com ele por ser bem voltado para as pessoas desenvolvedoras.
O modelo PaaS permite evitar os gastos e a complexidade de comprar licenças de software e infraestrutura. É possível gerenciar os aplicativos e serviços utilizando as ferramentas e bibliotecas oferecidas pelo provedor. Isso dá muita flexibilidade na utilização de softwares.
A infraestrutura é invisível para as pessoas desenvolvedoras, mas elas podem configurar as aplicações e, eventualmente, aspectos referentes ao ambiente utilizado por elas.
Os principais componentes envolvidos nessa estrutura são:
- Servidores;
- Banco de dados;
- Sistemas operacionais;
- Ferramentas de desenvolvimento.
Alguns exemplos desses serviços no mercado são:
- SAP Cloud;
- Microsoft Azure;
- Heroku;
- AWS Lambda;
- Google App Engine;
- Pivotal Cloud Foundry;
- Salesforce Lightning;
- IBM Cloud Foundry;
- Red Hat OpenShift;
- Oracle Cloud Platform.
IaaS (Infrastructure as a Service)
Funciona de maneira bastante similar aos demais modelos de serviços na nuvem. Porém, o que se contrata é a infraestrutura, o mecanismo físico necessário para o bom funcionamento de um software ou sistema empresarial.
Em relação aos modelos tradicionais, onde é necessário investir em infraestrutura local, nesse modelo toda a estrutura fica sob a responsabilidade do provedor, o que elimina custos consideráveis com a aquisição de equipamentos.
O provedor do serviço de nuvem, por exemplo, permite a contratação de servidores virtuais, além de todos os equipamentos auxiliares necessários para atender a demanda da empresa contratante. Assim, em vez de se investir na compra de servidores locais, roteadores, racks e demais hardwares, contrata-se toda essa infraestrutura, pagando um valor fixo, a depender da quantidade de recursos disponibilizados, pois o valor cobrado é de acordo com alguns fatores, como o número de servidores virtuais, performance do hardware, quantidade de dados trafegados, dados armazenados e outros itens.
Alguns exemplos de IaaS são:
- DigitalOcean;
- Amazon Web Services (AWS);
- Microsoft Azure;
- Google Compute Engine (GCE);
- IBM Cloud;
- Rackspace Open Cloud;
Pode ser que algumas coisas aqui tenham ficado um pouquinho confusas, eu sei, mas todos esses 3 serviços conseguem se conectar de alguma forma, e considero importante você entender essa relação entre eles antes de prosseguir. Veja a imagem a seguir:
APIs (Application Programming Interfaces)
As APIs são interfaces que funcionam como pontes, transportando dados entre um cliente e um servidor. Sem que esse processo seja sequer percebido pelo usuário, elas estão presentes por trás do funcionamento de diversos programas e aplicativos.
Veja a imagem a seguir como exemplo em alto nível:
Exemplos
Você pode pensar quando você vai em um restaurante e pede ao garçom o que você gostaria de comer. O garçom leva seu pedido para a cozinha e algum tempo depois ele retorna com seu prato pronto. Você não precisou saber o passo a passo de como esse prato foi preparado, você só fez o pedido e esperou o resultado. O garçom foi o intermediário dessa comunicação, função que seria da nossa API.
Agora um exemplo para ficar um pouco mais tangível esse entendimento. Na prática, isso acontece quando você acessa um marketplace (loja online que conecta vários vendedores em um mesmo local) e filtra por um produto que você deseja. Nesse momento é feito um pedido para a API, que vai buscar produtos nessas lojas e te retornar com o resultado de várias opções e preços.
Um outro exemplo similar é quando você procura por um voo em algum site, colocando data e local de origem e destino. A API integrada vai buscar todos os tipos de voos com essa data e local e retornar para você.
Isso acontece porque a API tem acesso a esses dados.
Tipos de APIs
Um outro ponto importante de mencionar é que existem alguns tipos de APIs, como pública/aberta e privada.
A API pública pode ser usada por qualquer empresa ou desenvolvedores, e isso pode facilitar quando você precisa de uma funcionalidade para o seu produto que já existe no mercado, você pode encontrar através de Discovery e integrar essa API no seu produto ganhando tempo na entrega de valor.
Já as APIs privadas são de uso interno das organizações dando acesso a dados internos da empresa.
Como funciona a comunicação entre esses serviços?
Antes de continuar, gostaria de mencionar que vou trazer aqui o que é mais usado no mercado, ou seja, não se limita unicamente nesses exemplos, existe um universo de possibilidades, mas tendo a noção do mais comum ficará fácil compreender outros tipos que surgirem ou que você esteja vivenciando na sua empresa.
Protocolo HTTP
Uma das formas de comunicação é através do protocolo HTTP (esse que aparece no início do link na url quando você acessa algum site, por exemplo). Através dele, cliente e servidor conseguem se comunicar, seguindo um conjunto de regras.
Por exemplo, se estivermos falando de uma aplicação web, o cliente é o navegador, ele envia um pedido para o servidor web usando o protocolo HTTP, com base nesse pedido, se tudo estiver correto, o servidor responde também usando o mesmo protocolo do conteúdo solicitado.
Voltando ao nosso exemplo do início, do restaurante, quando você faz o pedido para o garçom você está fazendo um request (requisição). Esse pedido vai conter todos os dados que descrevem exatamente o que o cliente precisa (deseja comer). No universo tech isso seria, toda vez que trocamos de página ou apertamos enter na barra de endereço uma nova request é feita. Independente se estamos apenas pedindo a exibição de uma página, cadastrando um novo recurso, atualizando ou excluindo.
Mas onde entra o protocolo HTTP?
Quando você usa esse protocolo existem métodos a serem utilizados em um request, o mais comum é o POST e o GET, eles indicam para o servidor qual a ação que o cliente deseja realizar. Quando realizamos uma requisição obrigatoriamente precisamos informar um método.
- GET – é usado quando o cliente deseja obter recursos do servidor;
- POST – é usado quando o cliente deseja enviar dados para processamento ao servidor, como os dados de um formulário, por exemplo.
Para o seu conhecimento os outros tipos de métodos que existem são: PUT, DELETE, TRACE, OPTIONS, PATCH, CONNECT, HEAD.
Agora que vimos a parte em que um cliente envia um tipo de request com as informações necessárias(pedido ao garçom), ele espera uma resposta, e aí entra a response. Nessa response (resposta) contém os dados que o cliente espera receber(ex: status do pedido) ou uma resposta informando que algo deu errado.
Então vamos ao nosso exemplo, o garçom(nossa API) recebeu sua request do tipo POST com todas as informações para fazer seu pedido, e levou até a cozinha, nesse momento a cozinha analisa essas informações e começa a preparação, a response nesse momento é o status do pedido (em andamento/produção). Ou seja, seria o mesmo que dizer “recebemos aqui sua solicitação e vamos iniciar o preparo”.
Mas e se algo desse errado? Bom, no momento que o garçom levou seu request (POST) para a cozinha, os cozinheiros poderiam dizer que faltava algum ingrediente e não poderiam preparar seu prato. Ou ainda, o gás poderia ter acabado e o pedido ia demorar além do previsto.
Em qualquer um desses casos, o garçom teria que voltar até você e informar (response) que não poderia preparar o seu pedido no momento naquele momento. Voltando ao mundo real sem a analogia, essa resposta seria em formato de códigos, os chamados códigos de status HTTP.
Quando o cliente faz uma requisição ele espera uma resposta. O servidor pode realmente responder o que o cliente esperava ou devolver outra informação, como os famosos códigos 200, 400, 500 entre outros.
Tráfego entre serviços
Aprofundando um pouco mais nessa comunicação, é importante trazer também a forma que esses dados trafegam entre os serviços, e isso acontece chamando um endpoint ou rota, em português, (Um endpoint de um web service é a URL onde seu serviço pode ser acessado por uma aplicação cliente).
Uma API pode ter vários endpoints e cada um com funções específicas. Por exemplo, o nosso garçom (API) vai ter algumas funções além de tirar pedidos, você pode chamar ele para limpar sua mesa, ou para trazer a conta. para cada uma dessas funções você acionaria um endpoint, se você quer que ele limpe a mesa você chama ele através do endpoint que fará esse serviço específico.
Porém para essas requisições você precisa fazê-las em um formato respeitando os parâmetros pré-definidos no contrato da API, e aqui vou abordar um deles. Existem formas diferentes de fazer isso, o que é chamado de payload. Esse payload contém as informações necessárias sobre o que é esperado para que a comunicação funcione e seja compreendida.
Esse contrato pode exigir preenchimento obrigatório ou não de algum parâmetro, aceitar apenas número ou letra nos campos, apenas palavras dentro de uma lista, etc. Caso esse formato do contrato não siga as especificações, a API retornará algum erro e não realizará sua função.
E é nesse momento que um Product Manager pode apoiar com a definição desse contrato, pois isso envolve ter entendimento do negócio, que impacta diretamente como o produto deve se comportar na jornada que está sendo mapeada. Sendo assim, o contrato exige ter informações claras e que faça sentido para o negócio, e a partir disso você pode orientar para que muitas coisas sejam executadas com esses dados que estão trafegando entre os sistemas. Por isso é muito importante ter uma análise junto ao time de Engenharia.
No retorno dessa requisição a response poderá ser um payload contendo os parâmetros de uma mensagem, ou um código de erro, código de sucesso ou outra informação pertinente solicitada, mais uma vez isso vai depender da forma que foi definido o contrato.
No nosso exemplo hipotético o response seria um status do pedido, que pode ser, pedido iniciado ou erro no pedido. Para a response ser o prato pronto, a request precisa ser do tipo GET.
Quando os times de Engenharia criam APIs, eles são responsáveis por também mantê-las. Por isso, é muito importante que ela seja documentada com uma explicação de como utilizá-la, seja ela externa ou interna.
No caso de uma API externa, você vai sempre olhar a documentação antes de implementar/integrar qualquer coisa, pois o time de Engenharia precisa entender os requisitos, parâmetros (mencionados anteriormente), quais funções ela realiza, que tipo de variáveis são usadas e como devem ser feito as chamadas.
Comunicação síncrona e assíncrona
Durante essa comunicação que não vemos, também temos dois tipos diferentes de interação entre eles:
- Síncrona: que é quando o contato é imediato entre o emissor da informação e o receptor da informação;
- Assíncrona: quando o emissor envia uma mensagem mas o receptor não irá receber na mesma hora.
Ou seja, continuando no nosso exemplo de APIs, quando a comunicação é síncrona, o momento que é feito um request, eu estou esperando uma resposta imediata para poder iniciar uma nova ação. Já quando a comunicação é assíncrona, o meu e demais requests podem ser executados paralelamente enquanto esperamos uma resposta.
Exemplo Expensify
Agora vou tentar tangibilizar essa comunicação olhando para um aplicativo móvel, e para esse exemplo vou usar o Expensify, que é um aplicativo para criação de relatório de despesas, através da câmera do celular. A ferramenta captura recibos e identifica automaticamente o nome da loja, a data e o valor da compra, geralmente ele também é usado por organizações para os colaboradores solicitarem reembolsos, por conta dessas funcionalidades.
Essa funcionalidade onde você consegue capturar um recibo através da câmera do celular para coletar todos os dados sem precisar preencher de forma manual funciona de forma assíncrona, isso porque você pode escanear vários recibos em paralelo enquanto o aplicativo vai fazendo a leitura um a um e trazendo os resultados.
Ou seja, você não precisa esperar o tempo que o scanner leva para concluir essa atividade para iniciar o escaneamento de outro recibo (porque isso seria frustrante, certo?);
Já a funcionalidade desse mesmo app para criação de relatórios, que é quando você já tem todos os recibos escaneados e agora você seleciona todos eles para solicitar reembolso, a comunicação é síncrona, neste momento você já recebe um status imediato da sua solicitação que pode ser: processando, aprovado ou reembolsado.
Se o usuário não tivesse nenhuma resposta imediata sobre o status de sua solicitação seria muito fácil pensar que algo deu errado.
No caso do pedido ao garçom podemos considerar uma comunicação assíncrona, pois enquanto eu aguardo meu pedido ser preparado, o garçom pode ir em outras mesas pegar outros pedidos.
Autenticação e autorização
Acredito que até aqui as coisas devem estar mais claras sobre como essas comunicações funcionam. Porém, ainda tem um ponto bem importante sobre a comunicação entre sistemas.
Para você usar de forma íntegra e segura essas APIs, você precisa fazer uma autenticação que, se for aprovada, te concede uma autorização. Isso porque devemos proteger esses serviços de acessos indevidos e garantir que quem está consumindo é confiável provando sua identidade.
Mas basicamente o funcionamento da autenticação se dá através do envio de credenciais do usuário (e-mail e senha), de um Token (ou chaves de acesso), ou de mensagens criptografadas. Assim, o serviço que você está tentando acessar reconhece um desses com base nas suas especificações de uso e, a partir da informação obtida, autoriza o acesso ou não.
Quando o serviço autoriza o acesso, a partir desse momento, o consumidor será habilitado a realizar ações que estejam disponíveis para ele. Isso porque quem está acessando pode ter permissão reduzida, somente para ler alguns dados, por exemplo.
Arquitetura orientada a eventos
O que é isso? É o famoso “depende”! Pois essa arquitetura vai depender muito do contexto, ou seja, do modelo de negócio a ser desenvolvido.
Um evento é qualquer ocorrência ou mudança de estado significativa no software ou hardware de um sistema. Uma notificação de evento é uma mensagem enviada pelo sistema para avisar outra parte do mesmo ou outro sistema que algo ocorreu.
Tendo isso em mente, os eventos são bem relevantes para o negócio da empresa, podendo ser: a ocorrência de um novo cadastro, a assinatura de um serviço ou um novo pedido, por exemplo. Aqui as possibilidades são infinitas, por isso depende muito do que é importante para o negócio.
Quando a hipótese do problema foi validada e inicia o estágio de execução do produto, o time de Engenharia começa a análise. Esse é o processo que vai definir o melhor modelo de arquitetura para o produto, respeitando restrições existentes (podem ser escopo, prazo, dinheiro investido, etc..).
Nesse momento, o papel da pessoa Product Manager também é bem importante. Essa figura pode contribuir trazendo o time a jornada do usuário para discussão, observando os principais pontos em que se espera uma resposta, por exemplo, ou quando há a execução de uma ação e o time pode prover a a melhor proposta de solução arquitetural.
Exemplo
Vamos imaginar nosso exemplo usando essa arquitetura. Supondo que a comunicação é assíncrona, o cliente faz um pedido ao garçom (API), que leva esse pedido para a cozinha para ser preparado. Enquanto o prato não fica pronto, o garçom realiza outras ações em paralelo como, limpar algumas mesas e coletar novos pedidos.
Quando o pedido na cozinha fica pronto, alguém na cozinha coloca o prato disponível para entrega. Essa ação pode ser apenas deixar o prato na bancada, ou ir além, tocando ainda uma sineta como notificação sonora. Essa ação do cozinheiro seria: a publicação de um evento com a resposta da requisição (pedido) de forma que possa ser acessado no futuro (garçom indo buscar o prato).
Apesar do exemplo didático para ajudar no entendimento, é importante ressaltar que geralmente esses eventos podem ser utilizados por vários sistemas distintos, que podem precisar da mesma informação para ações diferentes.
Quando um evento é criado para sinalizar que algo aconteceu, outros serviços podem se inscrever nesse evento. Dessa forma, eles vão ficar escutando quando esse evento emitir algum disparo de informação e assim esses sistemas inscritos podem prosseguir com suas ações. Sistemas que não se inscrevem nesses eventos consequentemente não vão ficar sabendo quando alguma ação acontece. Isso faz parte desse processo de modelagem das arquiteturas.
A transmissão entre emissor e consumidor do evento ocorre através de canais onde é usado uma plataforma para processar essa comunicação assíncrona. Duas dessas plataformas bem conhecidas são o Apache Kafka e Redis Stream. Em ambas é possível fazer publicações e subscrições, além de acompanhar o armazenamento e processamento de fluxos de eventos em tempo real.
Conclusão
Mesmo que a função de Product Manager não exija que você conheça profundamente o universo do time de Engenharia, vão existir muitos momentos em que você vai se deparar com alguns desses termos em discussões bem importantes. Se você não souber o básico de comunicação entre sistemas vai se sentir um peixe fora d’água, causando insegurança, ansiedade e frustração.
Você realmente não precisa ir afundo nos mínimos detalhes, mas compreender como tudo se relaciona nos bastidores vai evitar não só esse sentimento de estar perdido no assunto como também proporcionar a você segurança para questionar e trazer reflexões antes de tomar decisões.
Em outras palavras, você deixa de ser a pessoa que concorda com tudo o que o time diz porque você não entende, para pessoa que consegue dialogar e apoiar o time, além de conseguir demonstrar empatia e compreensão com quem trabalha diretamente nessa parte mais técnica.
Espero ter facilitado seu entendimento sobre comunicação entre sistemas e os seus respectivos termos, mas pretendo aprofundar mais nesses tópicos nos próximos artigos. Até a próxima!
Leia também:
