Olá, pessoas de produto! Vamos bater um papo sobre o que é interessante saber de TI para se dar bem em Produto?

Numa escala de 0 a saber codar?

É inegável a importância do software em nossa vida devido à multiplicidade de serviços digitais que eles fornecem na sociedade da informação. Percebemos que os “Produtos de Software”, também conhecidos como “aplicações” ou “aplicativos”, são projetados com as melhores práticas de engenharia para atender às nossas necessidades de forma segura e com qualidade.

Cada programa ou aplicativo em seu computador, smartphone, smart TV, console de videogame, etc. é um software, seja um editor de texto ou foto, navegador, jogo, app de compras ou de streaming e assim por diante.

Para isso, existe a disciplina de engenharia de software, que trata dos aspectos técnicos que permitem a produção desses produtos.

Mas você precisa saber codar para ser Product Manager (PM) ou pessoa de Produto em geral?

A resposta é: não.

Entretanto, aprender os fundamentos do funcionamento de software pode ajudar bastante a entender, por exemplo, os tempos de desenvolvimento, os requisitos e regras de negócio, como priorizar seu roadmap e como definir as expectativas de seus stakeholders (pessoas envolvidas no seu trabalho). Outro benefício é a visão mais precisa do que será necessário para construir seu produto de acordo com o plano estratégico que você definiu no roadmap.

Nesse sentido, estar familiarizado com alguns conceitos do lado da engenharia pode beneficiar sua carreira como PM. Para isso, abordamos alguns tópicos da área que valem a pena ter um conhecimento básico.

Não se preocupe, não defenderemos aqui que você saiba codar, nem abordaremos isso. Trataremos somente alguns conhecimentos generalistas sobre a tecnologia que podem ajudar na jornada de desenvolvimento de uma pessoa de produto durante sua carreira. Ou seja, não é necessário dominar tudo que está neste artigo para ENTRAR na área de Produto - mas é interessante buscar esses conhecimentos durante sua trajetória profissional.

Funcionamento da Internet

A arquitetura da operação da Internet controla a maioria das decisões tomadas pela equipe de engenharia.

Embora isso pareça um tópico complicado, o básico é bastante simples:

Lado do cliente vs. lado do servidor

À medida em que a internet se tornou essa rede crescente de computadores interconectados, algumas máquinas precisaram ser dedicadas a fornecer serviços à rede (internet) para que outros computadores pudessem acessar esses serviços. Portanto, esses computadores que fornecem o serviço são chamados de servidores e os computadores que acessam os serviços são chamados de clientes.

Pode ser que você escute do lado da engenharia que algo esteja acontecendo no lado do cliente ou no lado do servidor.

O que significa isso?

O cliente é o seu navegador, ou seja, o computador ou smartphone que você está usando agora, que está fazendo uma solicitação a um servidor em algum lugar para acessar o blog admina. Então, por exemplo, quando você digitou https://www.admina.com.br/, sua máquina fez uma solicitação ao servidor que hospeda o site. O servidor respondeu à sua solicitação e indicou a direção correta - visto que você está lendo esta publicação. Chamamos essas solicitações de solicitações HTTP - que é um protocolo de comunicação na internet. Uma solicitação HTTP envia uma solicitação a um servidor e o servidor responde com um código de resposta para informar ao navegador se está tudo bem com a solicitação. As APIs também usam as mesmas solicitações HTTP ao processar chamadas de API, falaremos mais sobre isso daqui a pouco.

Um servidor, em termos simples, é um computador, localizado em algum lugar, que está sempre ligado, fornecendo algum serviço (por exemplo, o back-end de uma aplicação web) para o cliente.

A lição mais importante aqui é entender que algumas tecnologias serão executadas no lado do cliente (como HTML, CSS e Javascript) e outras no lado do servidor (como PHP e ASP).

Tecnologias do lado do cliente

Em termos gerais, front-end se refere ao código escrito por dev front-end que é executado no navegador de cada usuário (o cliente) e à interface de usuário associada com a qual o usuário interage (visual).

Aqui está um pouco sobre o que cada uma dessas tecnologias:

• HTML – estrutura da página
• CSS – estilos e posicionamento dos objetos
• Javascript – Interatividade e dinâmica dos objetos

Sem JavaScript, por exemplo, no Google Docs seria impossível criar documentos interativos em tempo real por meio do navegador. Imagine se você tivesse que recarregar a página toda vez que digitasse uma nova letra?

Função: Dev front-end

A pessoa desenvolvedora - ou dev - front-end trabalha o visual da aplicação, sua “frente”, desenvolvendo as telas que vão interagir com as pessoas usuárias se importando com a sua experiência.

Algo importante para se destacar aqui que envolve o trabalho entre devs front-end e pessoa de produto está relacionado com a decisão e construção do Design System junto com UX Designer.

Um Design System é uma coleção de componentes reutilizáveis, padronizados para o visual da tela do produto digital ser unificada em uma única linguagem. A pessoa UI/UX Designer define esses componentes e a pessoa dev front-end coda.

Portanto, é importante sempre alinhar as expectativas com a equipe de front-end, que materializará esses componentes, codificando e definindo questões técnicas para seu compartilhamento.

Tecnologias do lado do servidor

Incluímos aqui as tecnologias que atuam nas estruturas de back-end do lado do servidor.

O back-end é o “por detrás na tela”: o código-fonte escrito por devs back-end que roda nos servidores controlados pela empresa. É aqui que acontece a maior parte da lógica do negócio.

Função: Dev back-end

É quem trabalha na parte de trás da aplicação, geralmente responsável pela codificação de grande parte das Regras de Negócio. Atuando muito pouco na parte visual. Algumas linguagens de programação dessa área são Java, C#, Go, PHP, Python, Ruby e outras mais.

Se é você Product Manager - em outros casos, Product Owner ou até Analista de Negócios - e escreve a user story e os critérios de aceite, será também sua responsabilidade repassar as regras de negócio (ou critérios de aceitação) para o time de dev (desenvolvimento) trabalhar em cima delas.

Função: Dev full stack

Desempenha tanto a função de back-end como front-end. Em geral, são as pessoas desenvolvedoras mais seniores, procuradas e bem pagas do mercado.

Função: SysAdmin (Administrador de Sistemas)

Essa função é algo bem abrangente, mas normalmente é responsável por instalar, suportar e manter os servidores e sistema da organização junto ao time de desenvolvimento.

Banco de dados

Uma linguagem do lado servidor é necessária, por exemplo, quando precisamos interagir com um banco de dados - que está sempre no servidor. Vamos usar como exemplo o nosso caso: quando você acessa o blog admina, este site armazena as postagens em um banco de dados e uma linguagem do lado servidor é utilizada para recuperar esses dados e gerar uma página de visualização para você.

A partir desse ponto, é super útil entender qual o papel que os bancos de dados desempenham em seu produto. Em resumo, banco de dados se refere à tecnologia que armazena todos os dados da aplicação e roda em um servidor controlado pelo time de engenharia de software.

SQL é a linguagem de programação que devs utilizam para gerenciar e interagir com bancos de dados relacionais, como Oracle, Microsoft SQL Server, Postgre etc. Geralmente, devs definem estruturas de tabelas, índices para consultas rápidas e qualquer número de procedimentos para inserir, ler, atualizar e excluir dados do sistema.

Para pessoas de produto muito focadas em dados, pode ser interessante aprender os fundamentos do SQL para gerar relatórios e dashboards de indicadores, por exemplo. Porém, hoje em dia já há ótimas ferramentas para fazer isso sem precisar de código SQL, como PowerBI e Looker. Também, em geral, empresas de produtos digitais tem um time que para gerar esses relatórios. Portanto, o mais importante é que você conheça os dados que seu produto coleta, como os usa - seus regras de negócio - e como analisá-los estrategicamente para alavancar os objetivos e a visão do seu produto.

Função: Analista de Dados (AD) / Administrador de Banco de Dados (DBA)

Existem duas funções que atuam nessa área. DBA responsável por gerenciar, instalar, configurar, atualizar e monitorar um banco de dados. O AD é responsável por coletar, compilar, analisar e interpretar os dados do banco. Em suma, o DBA acaba atuando mais no nível de hardware e software, e o AD no nível de dados e negócio.

Cloud - Nuvem

Em termos muito simples, nuvem é apenas um ou vários computadores do tipo servidores, de outra pessoa, em uma ou mais localizações físicas e reais espalhadas pelo mundo - usados para armazenar e gerir dados. Nesse caso, essa “outra pessoa” seria nada mais que a Amazon, Oracle, Google, IBM e/ou Microsoft.

Com a nuvem, o armazenamento de dados é feito por meio de um serviço, e esses dados podem ser acessados a qualquer hora e em qualquer lugar do mundo. Tudo isso sem a necessidade de instalação de programas ou armazenamento de dados de forma física. O acesso remoto a programas, serviços e arquivos acontece via internet, por isso o termo “nuvem”.

Provedores de nuvem oferecem vários tipos de serviços, dependendo do tamanho e tipo da aplicação, tais como: Infraestrutura como serviço (IaaS); Plataforma como serviço (PaaS); Software como serviço (SaaS) e muitos outros. Tudo isso faz com que a armazenagem de gestão de dados seja muito mais simples hoje em dia, em comparação com 15 anos atrás, quando acessar um banco de dados significava usar vários protocolos, senhas e redes internas de difícil login.

Em termos mais simples, a nuvem é um banco de dados poderoso e avançado, mais seguro e com acesso bem mais simples.

Dívida técnica

A dívida técnica é o que chamamos quando tem um código mal estruturado ou simplesmente algo que foi codado de forma não-ótima e, por isso, um dia vai requerer tempo de desenvolvimento para refatorar, isto é, reescrever o código tornando-o mais simples e legível sem modificar o seu comportamento externo.

Pensando no conceito econômico de “empréstimo”, a dívida técnica funciona da mesma forma: você pega um “empréstimo” para entregar features (funcionalidades de produto) mais rapidamente, aumentando com isso a sua dívida técnica que será paga via refatoração (tempo de para reescrever o código novamente).

Mas por que você faria isso?

Bom, pela mesma razão que alguém toma um empréstimo na vida real. Às vezes, você precisa entregar uma funcionalidade o mais rápido possível para satisfazer as necessidades de um cliente ou fazer uma demonstração importante, e pode valer a pena acumular a dívida técnica em entregas futuras. Porém, cada caso é um caso, e esse tipo de decisão precisa ser avaliada com seu time de engenharia.

API - Application Programming Interface

No português “Interface de Programação de Aplicações”, as APIs representam uma forma de integrar sistemas, funcionando como uma “ponte” que conecta aplicações, possibilitando, assim, escalar o negócio.

As APIs têm se tornado cada vez mais importantes para quem trabalha como pessoa de produto, pois mais e mais produtos oferecem APIs que abrem novas oportunidades para o crescimento do negócio. Normalmente, as empresas utilizam APIs de três maneiras:

1. Integração com APIs de terceiros
2. Construindo suas próprias APIs para uso interno
3. Construindo e expondo suas próprias APIs para seus clientes

Vamos usar o Uber como exemplo de como várias APIs podem ser combinadas para criar propostas de valor para o cliente. O aplicativo mobile da Uber usa várias APIs:

• A API do Google Maps para exibir as informações do mapa.
• A API Braintree para processar pagamentos de clientes.
• A API Twiliio para enviar comunicações aos usuários, por exemplo, ‘seu motorista está a caminho’.

Para conhecer de fato o funcionamento das APIs, precisamos de um entendimento da dinâmica entre clientes, servidores e HTTP. Um outro artigo pode ser útil para aprofundarmos sobre isso.

Função: DevOps

É bem provável que você já tenha ouvido esse termo em algum lugar. Mas o que isso significa para quem lida com gestão de produto?

Com muitos produtos migrando para um modelo de serviço, o DevOps está se tornando uma tendência cada vez mais crescente em empresas que possuem produtos de software como serviço “Software as a service” (SaaS).

O DevOps pode variar de acordo com a empresa e seus produtos/serviços. No entanto, em sua forma mais básica, representa uma abordagem de cultura que prega a integração e união entre as pessoas, processos e ferramentas envolvidas no desenvolvimento e nas operações de TI. Essa integração é representada pela combinação dos termos pela qual se deriva a palavra “DevOps” - Desenvolvimento & Operações. Em outras palavras, isso significa que antes cada time fazia suas tarefas separadamente e quando dava tudo errado eles se encontravam em uma “War Room” para resolver o B.O.

Essa abordagem foi projetada para agregar mais valor ao negócio e melhorar sua capacidade de resposta às mudanças por meio da entrega de serviços de maneira rápida e de alta qualidade. Ninguém queria esperar dar errado no final para depois ter que refazer tudo novamente, certo?

O pipeline de integração e implantação contínuas (CI/CD) é um dos resultados principais obtidos com a implementação dessa abordagem. E o que isso significa? Vamos voltar um pouco atrás.

Pipeline de CI/CD

DevOps está intimamente relacionado a metodologias de desenvolvimento ágil como Scrum ou Kanban. Antes da sua chegada, em 2008, era comum que o desenvolvimento de software acontecesse seguindo o modelo tradicional em cascata (Waterfall Model), isto é, um modelo de desenvolvimento de software sequencial que seguia um fluxo contínuo como mostra a imagem:

Fonte: Don’t Go Chasing Waterfall de Neil Tamplin

Imagina o processo de lavar a roupa:

1. você tira a roupa do cesto (processo 1)
2. coloca ela na máquina (processo 2)
3. com a roupa lavada, você dobra ela (processo 3)
4. por fim guarda ela no seu guarda-roupa (processo 4)

Tudo isso acontecendo de forma sequencial, consumindo seu tempo separadamente:

Com a implementação do DevOps, um dos principais resultados obtidos é o pipeline de integração e implantação contínuas (CI/CD). É muito comum as pessoas confundirem o que significa pipeline nesse processo, então vamos usar novamente o exemplo de lavar roupas:

Com a implementação da Pipeline (CI/CD), tudo acontece de forma automatizada, graças às ferramentas de automação e integração e comunicação entre times, sem necessidade da espera sequencial para começar um outro processo. Pipeline representa a implementação de processadores de modo a permitir a sobreposição temporal das variadas etapas de execução dos processos que compõem o desenvolvimento de software.

Ou seja, agora você pode colocar as suas roupas, as roupas de cama, os jogos de toalha, e todos os tecidos da sua casa quase que simultaneamente, tornando o processo “lavar roupa” muito mais rápida e facilmente. Essa automação ajuda a identificar e corrigir problemas e defeitos rapidamente, porque como tudo acontece ao mesmo tempo, feedbacks são obtidos rapidamente. Juntas, essas práticas relacionadas são conhecidas como “pipeline de CI/CD” e também estão muito em linha com a ótica de produto de testar rápido, errar rápido, aprender rápido para corrigir rápido.

Microsserviços

Microsserviços representam outra prática adotada nesse contexto, tornando a aplicação mais flexível e permitindo mudanças mais rápidas. Em suma, arquitetura de microsserviços divide sistemas grandes e complexos (antiga arquitetura monolítica) e os transforma em sistemas menores e independentes. Ao dividir um aplicativo monolítico em pequenos microsserviços, reduzimos a sobrecarga e facilitamos a engenharia ao não precisar ter que coordenar grandes atualizações do sistema.

Teste automatizado

São pequenos pedaços de código de software que testam a aplicação para garantir que ela funcione corretamente e sem bugs. O que um PM precisa levar em consideração é que: testes automatizados exigem esforço para serem criados e compensam com o tempo.

A automação vem para reforçar a ideia de que, em algum momento, será impossível testar manualmente todas as partes da sua aplicação, então processos automatizados vem para facilitar isso. Se por algum motivo isso não for possível por conta de um prazo, trate isso como dívida técnica: será trabalho que você sabe que precisará ser retomado mais cedo ou mais tarde.

Função: Analista de Qualidade - Quality Assurance (QA)

Profissional responsável por fazer testes de software, nas metodologias ágeis, a qualidade é responsabilidade de todos, mas o QA tem o papel de guardião desse processo.

Segurança de Aplicações (AppSec) e DevSecOps

Vimos até aqui que DevOps se preocupava bastante com a agilidade do processo de desenvolvimento, desde a sua qualidade e automação. Entretanto, a segurança da aplicação era um fator essencial que muitas vezes acabou ficando do lado de fora durante a implementação dessa cultura nas empresas.

O DevSecOps expande o impacto do DevOps ao adicionar práticas de segurança ao processo de desenvolvimento e entrega de software de forma contínua. Em outras palavras, significa que a segurança passa a ser algo importante do início ao fim durante o ciclo de vida de desenvolvimento de software, por meio de uma mudança cultural da empresa e adoção de ferramentas de automação de segurança na pipeline (CI/CD).

Por que a Segurança de Aplicações é algo relevante para uma pessoa de produto?

Pesquisas mostram que tratar problemas de segurança custam 100 vezes mais do que preveni-los durante o início. Portanto, se um desenvolvedor demorar para realizar uma entrega por conta do processo de segurança, pense no retrabalho e no custo do impacto que é tratar ou remediar uma vulnerabilidade em seu produto se ele prezar por uma entrega rápida e insegura.

Mas nesse ponto você pode pensar, mas e o pessoal de segurança? Existem muitas vulnerabilidades que não são captadas por ferramentas e que são descobertas só no final por meio de uma análise manual (Pentest), sem falar em outras que são descobertas só quando já é tarde. De todas as formas, desenvolvedores são a linha de frente da segurança da sua aplicação e analistas de segurança estão ali para dar suporte e potencializar a segurança de todo o sistema.

Além disso, enfatizar os requisitos de segurança em user stories não é algo tão comum para o time de Produto, pois geralmente são considerados requisitos implícitos. As equipes de engenharia não podem resolver problemas de segurança sem incentivos e requisitos explícitos por parte das pessoas responsáveis pelo Produto. Sem isso, a segurança pode permanecer invisível e ignorada.

É importante destacar que tanto o PM quanto o PO devem articular claramente “Por que” a segurança é de grande importância na proteção de Dados, Sistemas e Pessoas da aplicação que está sendo desenvolvida. Para isso, é necessário muitas vezes contar com o auxílio de um analista de segurança. Lembrando que DevSecOps preza pela colaboração e comunicação entre diferentes equipes - Produto não fica de fora!

Função: Analista de Segurança

Com o propósito de observar a segurança em uma organização, os analistas de segurança são fundamentais para promover uma cultura DevSecOps e trazer os problemas de segurança para o início do fluxo de trabalho o mais rápido possível para identificar, proteger, detectar, responder e recuperar os pontos necessários acerca da segurança da aplicação.

Em suma: habilidades tecnológicas fortalecem a tomada de decisões

Existem milhares de conceitos e temáticas importantes que envolvem a construção de um software que você pode aprender. Além disso, por se tratar de uma área em constante inovação, vale sempre a pena lembrar-se de atualizar sobre os assuntos sobre os mais recentes em avanços tecnológicos.

Mas saber desses conceitos sem ter empatia com os times de desenvolvimento não te ajudará muito. Quanto mais você ouvir e entender a situação do outro lado, mais fácil será esse relacionamento para colaboração e entrega de qualidade.

Portanto, você não precisa ter uma formação técnica para ser um Product Manager bem-sucedido. Não, você não precisa saber codar. Porém, muitas vezes, será útil poder demonstrar alguma proeza um pouco mais técnica nos momentos de interação com esses times. E, mesmo que você não tenha nenhuma experiência técnica, você pode obter hoje com mais facilidade do que nunca graças aos diversos cursos e materiais gratuitos que existem pela internet.

Obrigado por ter lido até aqui, um abraço e até a próxima!

Referências e leituras que indico

o tradutor do navegador ajuda para quem não lê inglês :)

1. Para saber um pouco mais sobre desenvolvimento: Desenvolvimento de software: o guia completo sobre a área

2. Para saber um pouco mais sobre APIs: APIs Explained for Product Managers

3. Para saber um pouco mais sobre devops: DevOps 101 for Product Management – how it can empower you! e DecSecOps for Product Owner

4. E sobre IT para pessoas de produto: Quão técnico deve ser um Product Manager?, Product Owner: o quão programador preciso ser?, 5 Things Every Product Manager Should Know About Software Development, Does a Software Product Manager Need to be Technical?e How Technical Do Product Managers Need to Be?