Front-end e back-end em produtos digitais

A área de desenvolvimento de software aborda tantos termos e nomenclaturas que acaba sendo difícil compreender tudo, principalmente as pessoas de Produto que não tem formação em nenhuma área relacionada a tecnologia. Um bom exemplo disso são os termos front-end e back-end.

É fundamental que os profissionais que estão trabalhando com o time de desenvolvimento entendam bem esses e outros conceitos. Isso porque, como mencionei nesse artigo, ter um mínimo de entendimento de termos técnicos e de como algumas coisas funcionam nesse universo vai te trazer mais confiança e segurança no dia a dia como Product Manager. Além disso, você vai ter um diferencial, por conseguir compreender as discussões do time de engenharia e levar isso para sua cliente traduzidas em valor de negócio.

Neste artigo vou abordar outros termos que são populares na área mas que, ainda geram dúvidas em relação ao significado e funcionalidade. São conceitos centrais quando falamos de produtos digitais, por isso, é tão relevante seu entendimento.

Então vamos falar de front-end e back-end. Sem dúvidas vocês estão familiarizados com esses dois termos, mas vocês sabem como funcionam? Como interagem entre si? Qual sua principal função em um produto digital dependendo do contexto e produto a ser desenvolvido?

O que é back-end e front-end?

Em linhas gerais o front-end é o desenvolvimento da interface onde o usuário tem interação direta, enquanto o back-end se preocupa com o funcionamento estrutural, gerenciando o envio de dados ao servidor entre muitas outras funções que o usuário não vê.

Ou seja, quando o usuário interage com uma interface (front-end), que pode ser um site por exemplo, qualquer ação que ele fizer, como um cadastro, os bastidores (back-end) é responsável por manipular esses dados salvando de forma correta em uma base de dados.

Mas vamos aprofundar um pouco mais nesses 2 termos e entender como eles impactam nosso dia a dia de Product Managers.

Desenvolvimento front-end

A pessoa desenvolvedora front-end é responsável pela construção de todo o aspecto visual do produto, garantindo que o usuário tenha uma experiência de navegação agradável e fácil.

Por isso é importante que este profissional domine conceitos e tendências do design, identidade visual, entendimento de padrões de cores, usabilidade, ferramentas de edição visual, fontes de letras, alocação de imagens, acessibilidade, certifica se um site é responsivo e funciona perfeitamente em todas as telas de variados dispositivos, entre outros.

Tá, mas isso não é papel de quem ocupa a função de designer? Sem dúvida é um trabalho conjunto. O designer tem as skills necessárias para trazer os pontos de experiência do usuário que são mais relevantes, mas a pessoa desenvolvedora front-end é quem consegue dizer se é possível desenvolver aquilo ou não no quesito técnico, pois ela é quem implementará as ideias por meio de códigos de programação e de outros recursos. É responsabilidade desse profissional realizar testes na plataforma antes de colocar na mão de usuários, além de cuidar da parte de manutenção e reparos.

Por isso é importante também que essa desenvolvedora tenha esse entendimento e esteja sempre alinhada com as designers quando houver esse papel no time.

Um ponto a destacar aqui é que, quando não tem pessoas designers/UX no time, a pessoa PM fica responsável de trazer mais ainda esse trabalho de experiência do usuário com dados de pesquisa para perto do time.

Resumidamente, o front-end trabalha para criar uma arquitetura que fornecerá uma boa experiência às pessoas, não só em termos de aspecto visual, mas também de experiência de navegação e execução de ações.

Portanto, podemos dizer que algumas das responsabilidades/atividades da pessoa que implementa o front-end do produto, são:

Utilizar linguagens de marcação (que é diferente de linguagem de programação) para o desenvolvimento web (HTML, CSS, JavaScript) ou utilização de frameworks que utilizam essas linguagens como base, ex: ReactJS, VueJS, Angular;
Deve ser tecnicamente proficiente e ter um olho aguçado para o design e UI/UX;
Em conjunto com a área de design, produz materiais de acordo com o planejamento de marca da empresa;
Executa testes durante o processo de desenvolvimento e corrige possíveis falhas que possam prejudicar a eficiência/performance do produto;
Cria protótipos de qualidade;
Colaborar com desenvolvedores back-end e designers para melhorar a usabilidade do produto;
Mesmo podendo trabalhar de forma independente de outros times, precisam estar sempre alinhados com o time de back-end garantindo que as funcionalidades desenvolvidas façam sentido e se integrem no final;
Implementa novas funcionalidades e ou mantém as existentes.

Com certeza essa pessoa tem muito mais atividades do que as que mencionei aqui, porém o foco deste artigo é trazer uma compreensão e entendimento do impacto que esse trabalho gera nos produtos que criamos.

Como você pode perceber, o desenvolvedor front-end é quase que uma ponte entre o designer e o desenvolvedor back-end, contribuindo para uma das etapas mais importantes desse processo.

Já que o visual e a usabilidade de um produto dizem muito sobre uma empresa, construímos produtos pensando não só em resolver os problemas ,mas também em como conquistar a satisfação do cliente (e isso se dá através de: acesso fácil, sistemas inteligentes e feedback rápido).

Desenvolvimento back-end

A pessoa desenvolvedora back-end trabalhará com linguagens de programação específicas a depender do produto a ser desenvolvido. Esse profissional possui principalmente capacidade de interpretar algoritmos tem conhecimento aprofundado sobre a lógica de programação, além de possuir pleno conhecimento sobre o funcionamento de bancos de dados, servidores, arquitetura e aplicações, assim como de construir e manusear todas as comunicações entre os sistemas.

Desta forma, o desenvolvedor back-end fica responsável por construir e manter estruturas sólidas para que as informações sejam organizadas corretamente, o que permite que cada parte do produto funcione bem, de maneira segura e se mantenha no ar para os usuários acessarem.

Por exemplo, quando você acessa um website, o servidor da página acessada envia todas as informações necessárias para que ela se torne visível ao usuário e ele consiga interagir com a mesma. Além disso, o back-end também é responsável por armazenar dados e garantir a segurança do produto como um todo.

O trabalho do desenvolvedor back-end pode ser abstrato, mas em resumo, podemos entender que algumas de suas tarefas e responsabilidades são:

Utiliza frameworks para desenvolver softwares e aplicativos;
Possui conhecimento em linguagens de programação como, Python, Java, Ruby, Go, PHP, .NET entre outras. Uma pessoa desenvolvedora pode ter habilidades e conhecimentos em mais de uma linguagem de programação, porém não é obrigatório saber todas para trabalhar em algum lugar pois a quantidade de linguagens é grande hoje em dia;
Cria arquitetura do produto;
Trabalha na crianção de digramas de UML (que descrevem o limite, a estrutura e o comportamento do sistema e os objetos nele contidos);
Criação e modelagem do banco de dados, que consiste em construir as estruturas de dados que possibilitam o armazenamento e a recuperação de informações em pesquisas para contextos específicos;
Implementa features através de códigos com a linguagem de programação escolhida (no contexto do produto), bem como implementa testes para validar o funcionamento;
Faz a ponte entre os dados da interface e o banco de dados;
Inclui validações para garantir que a aplicação fique em segurança;
Previne e/ou corrige bugs;
Mantém o produto com boa performance e rápido tempo de resposta para evitar taxas de rejeição;
Responsável pelas documentações do sistema desenvolvido, explicando como é o fluxo da aplicação, arquitetura, rotas, formas de integração e tudo mais que facilite o entendimento de todas as pessoas desenvolvedoras que vão ter contato com esse sistema.

Exemplos

Quando você cria uma conta em um produto específico, como um app ou website, o back-end cadastra seus dados em um banco de dados, e isso não é visível para você. Quando você faz login, o back-end fica responsável por validar se o seu nome de usuário e sua senha estão corretos e permite você acessar sua conta em caso positivo.

Em transações online, como efetuar uma compra, onde os seus dados de cartão de crédito são enviados de forma criptografada para um sistema de pagamentos, como o PagSeguro ou EBANX por exemplo, o back–end está por trás de fazer isso da forma mais segura possível.

Falando agora do lado da pessoa que possui um negócio como uma loja física e precisa ter alto controle de informações de seus produtos (como quantidade em estoque, faturamento, informações de clientes, etc.). Tudo isso é acessível através do back-end, que retorna esses dados que estão salvos em uma base de dados para a interface que a cliente esteja usando para interagir.

Não vou entrar a fundo aqui nas linguagens de programação em back-end, pois considero mais importante vocês saberem as principais e mais usadas (como as quais mencionei anteriormente) do que o que difere uma da outra. Isso é muito mais relevante para as pessoas desenvolvedoras do que nós PMs, a não ser que você PM esteja querendo aprender a programar. Mas, de qualquer forma, sugiro pesquisar um pouco mais cada uma e você conseguirá entender com qual se sente mais confortável para trabalhar.

Mesmo que o propósito final seja construir o mesmo produto, cada linguagem tem especificidades que podem ajudar no seu dia a dia ou não, tudo depende do contexto.

E o que é full-stack?

Esse termo também aparece muito e está relacionado com esse assunto. Full-stack é o profissional que consegue trabalhar com essas 2 frentes, tanto no back-end como no front-end.

Geralmente esse é o caminho de muitos desenvolvedores que iniciam na área e, conforme vão ganhando experiência e evoluindo seus conhecimentos, tendem a decidir em qual parte se sentem mais confortáveis em atuar, optando pela jornada apenas no back-end ou no front-end.

Papel de front-end e back-end em produtos digitais

Apesar de hoje em dia já existirem formas de construir produtos sem código ou com pouco código (os conhecidos no code ou low code, viabilizados por ferramentas como o Bubble) e pessoas de outras áreas de conhecimento também executarem esse trabalho, isso não quer dizer que a área de desenvolvimento pode acabar.

Muito pelo contrário, muitos produtos desenvolvidos são complexos e as ferramentas mais básicas que viabilizam essa flexibilidade não possuem estrutura suficiente para suportar determinadas necessidades (ainda). Por conta disso, a demanda é cada vez maior por pessoas desenvolvedoras capacitadas e envolvidas na análise e construção desses produtos.

Lembrando que para conseguir o resultado esperado com um ótimo produto exige um conjunto de fatores e papéis que caminham juntos. Não é só visual bonito, facilidade de usar e resposta rápida (o front-end não trabalha sozinho). Nada disso vai adiantar se o time não estiver construindo o produto que resolve problemas e entrega a melhor experiência ao usuário.

Dessa forma, os conceitos que falei até aqui se tornam valiosos, tirando do papel todo nosso trabalho de pesquisa, discovery e validação para algo tangível de fato onde os usuários passarão a interagir.

Viabilidade técnica nas decisões de negócio

Assim como precisamos entender a viabilidade de negócio e de mercado em uma proposta de valor, a viabilidade técnica também é fundamental. Nesse caso, o objetivo principal é compreender a viabilidade do ponto de vista técnico e operacional na construção de um produto em termos de infraestrutura, custo, retorno financeiro do investimento, entre outros aspectos dentro das restrições existentes para o contexto do projeto.

O time de produto consegue ajudar e apoiar o time técnico nesse entendimento desenhando toda a jornada do produto, apresentando o objetivo principal e qual a proposta de valor esperada. Com isso, o time tem um direcionamento para iniciar um desenho de arquitetura, modelagem de banco de dados, fazer pesquisas de mercado de tecnologias, mapear automatizações e achar a melhor solução para o problema apresentado, ajudando a empresa a tomar decisões em relação ao novo possível produto.

Além de reunir informações técnicas, outro fator importante que tem impacto direto nessa questão é o mapeamento do time de desenvolvimento, quais os níveis de senioridade, suas skills e capacidades. Isso tem impacto também no custo e tempo de desenvolvimento, dependendo do time e da necessidade, é necessário incluir capacitação e/ou a contratação de novos desenvolvedores.

Algumas perguntas que ajudam no mapeamento da viabilidade técnica:

É viável desenvolver um novo sistema ou utilizar uma alternativa já disponível no mercado nesse primeiro MVP? Quais as vantagens do sistema proposto em relação ao que já existe no mercado?
Como o sistema/arquitetura proposta contribui para a organização?
Quais são os riscos envolvidos?
Analisando as condições econômicas, organizacionais e temporais é viável desenvolver o sistema?
Qual a quantidade de tráfego vs tempo esperado por dia/semana/mês?
Como serão utilizados os recursos para melhor eficiência de processamento?
Qual a acurácia do sistema? Oferece serviços confiáveis?
Como construir esse serviço para que seja escalável?
Quais estratégias de resiliência devemos implementar?
Quais serão as dependências (caso houver)?

Outras questões técnicas a serem consideradas na construção de produtos novos ou features novas para produtos existentes são: entender sistemas legados e dívidas técnicas. Levar em consideração esses dois temas fazem uma enorme diferença e vou trazer um pouco da importância de ambos.

Sistemas legados

Conseguimos identificar um sistema legado quando ele é muito robusto e complexo. Mesmo que ele ainda funcione em alguns casos, é difícil manter seu crescimento e evolução, possuem hardware e/ou linguagem desatualizados, as pessoas que desenvolveram e detinham maior parte do conhecimento não trabalham mais na empresa, e por ser complexo e desatualizado se torna muito caro migrar para um novo sistema.

Isso ainda é uma realidade de muitas empresas, e um sistema legado não significa que ele seja ruim se ele funciona e entrega o que é preciso. Porém, encontrar profissionais que tenham conhecimento para mantê-los se torna um grande desafio, fazendo com que as empresas busquem formas de construir novos serviços para posteriormente realizar a migração.

Isso exige muita análise e entendimento do produto existente, suas tecnologias, mapeamento dos riscos envolvidos na migração, plano de migração, acompanhamento, entendimento das novas mudanças, viabilidade da reescrita do produto (mantendo as mesmas funcionalidades ou criando funcionalidades diferentes) e como elas passarão a impactar na estrutura do produto e experiência do usuário. Ou seja, isso exige muito trabalho em conjunto com time de Produto e time Técnico.

Dividas técnicas

Alguns diriam que dívida técnica é a “correção das gambiarras” no sistema (risos). Porém estou aqui para trazer uma visão diferente do que de fato elas são e seu impacto.

A medida que o tempo passa é normal que o produto passe a se tornar “antigo” (e legado depois de algum tempo, como vimos anteriormente) e em consequência disso aumenta sua complexidade de manutenção e evolução dependendo da tecnologia usada.

Com isso, algumas soluções desenvolvidas que funcionam passam a não ser mais ideais, gerando um impacto negativo com o passar do tempo quando não são refatoradas ou modificadas. Isso é o que abre espaço para as famosas dívidas técnicas.

E quanto mais dívidas técnicas se acumulam ao longo do tempo, maior a complexidade de manutenção e evolução do produto, podendo até mesmo ter que parar o desenvolvimento de novas funcionalidades (code freeze) só para planejar sprints de correções de dívidas técnicas. E acreditem: esse é o pior cenário para um time de desenvolvimento.

Algumas formas de mapear os pontos que podem gerar essas dívidas técnicas:

Se o time que vai desenvolver o produto for junior, é natural que surjam mais dívidas técnicas pela falta de experiência, por isso deve ser mapeado na viabilidade técnica os skills e o suporte que vão precisar;

Quando o prazo da entrega é apertado a primeira coisa a ser cortada é a qualidade, ou seja, os desenvolvedores precisam optar pelo que funciona no menor tempo, deixando a melhoria como dívida técnica para o futuro;

Falta de visão e objetivo do produto bem como a estratégia podem deixar os desenvolvedores no “escuro”, tomando decisões de implementação que não sabem se é a mais adequada, colocando em risco o crescimento, sustentabilidade e escalabilidade do produto;

No caso da não priorização das dívidas técnicas de maior impacto, elas vão gerar mais dívidas técnicas. É natural que elas existam (não conheço um produto perfeito que não exija melhoria contínua em código), o problema é quando você esquece que essas melhorias também tem um impacto muito grande se não executadas em algum momento;

Quando as mudanças de escopo, prazo e qualidade mudam, elas precisam ser alinhadas com o time de Engenharia antes de qualquer negociação, pois são eles que trarão mais informações sobre impactos no desenvolvimento do produto.

Lembrando que dívidas técnicas podem ser de ambos os lados, front-end e back-end. A construção do produto como um todo tem impacto significativo quando não mapeado esses pontos mencionados anteriormente.

Arquitetura dos produtos digitais

A arquitetura de software de um produto digital engloba a forma como as partes são organizadas, incluindo o comportamento dessa estrutura e os componentes responsáveis por realizar funções específicas necessárias para o seu funcionamento.

A escolha de uma arquitetura influencia diretamente na performance, qualidade, facilidade de manutenção, flexibilidade e escalabilidade, fazendo com que a definição dessa arquitetura tenha um enorme impacto no sucesso do produto, principalmente a longo prazo.

Hoje, existem diversos padrões de arquitetura que são utilizados para apoiar nessa estruturação, podendo ser utilizadas em conjunto a depender do objetivo, como:

Layers (camadas);
Client-server (cliente-servidor);
Model-view-controller (MVC);
Microservices (microsserviços);
Pipes-and-filters (PF);
Peer-to-Peer (P2P);
Service-Oriented Architecture (SOA);
Publish-Subscribe (Pub/Sub).

Conforme um produto é desenvolvido, seu tamanho e complexidade crescem, aumentando cada vez mais a sua estrutura e dados trafegados. Com isso, projetar uma arquitetura que facilite a compreensão desses componentes se torna um caminho mais do que necessário.

O papel de Product Manager nisso tudo

Quando não temos uma organização e definições bem intencionais dos sistemas que vamos trabalhar, vamos gerar times pouco saudáveis. Isso, por sua vez, tem impacto direto não só no resultado final do produto como na motivação das pessoas envolvidas nessa construção.

É muito importante que consigamos proteger o nosso time de prazos e priorizações externas mal alinhadas, trazendo sempre a visão de futuro do produto e os principais objetivos a serem alcançados, sempre os envolvendo nas negociações quando necessário.

Não é somente sobre construir features

Como principais responsáveis pelo roadmap, é importante estar ciente que gerenciar um produto não é só construir features novas. Mas sim olhar para melhoria contínua e inclusão das dívidas técnicas durante o desenvolvimento, ajudando o time a dar visibilidade dessas dívidas e seus impactos.

O estudo de viabilidade técnica junto ao time de Engenharia ajuda você levar aos stakeholders da empresa informações importantes, para que eles tomem decisões muitas vezes difíceis em relação ao novo produto.

Isso inclui até mesmo se esse produto tem capacidade de se manter como um produto lucrativo, sem que rapidamente se torne um desperdício de recursos. Sem as informações necessárias obtidas através do time, poderá haver uma possibilidade muito maior de se investir em um projeto que apresenta retorno financeiro baixíssimo, ou mesmo a perda de dinheiro com a sua produção.

Portanto, é necessário que se tenha muita atenção ao planejamento e sempre envolver as pessoas desenvolvedoras no alinhamento e entendimento da tecnologia, para que não se tenha o desperdício de recursos, mão de obra e custos desnecessários.

Boas práticas de desenvolvimento também impactam no resultado

A definição de boas práticas e processos de trabalho junto aos times (de front-end e back-end), como integração contínua (Continuous integrations – CI), entrega contínua (Continuous Delivery – CD) e deploy contínuo (Continuous deployment – CD) vão garantir que tudo funcione e caminhe para a construção e a entrega do produto esperado. Isso porque tudo vai estar interligado, e é extremamente importante que todos entendam esse ecossistema.

Conclusão

Resumidamente, o papel de front-end e back-end em produtos digitais é fundamental e vai além da parte técnica operacional, impactando também em aspectos estratégicos de negócio.

A organização do trabalho conjunto com essas áreas depende do principal objetivo definido e do entendimento do problema que os times precisam resolver. Com isso em mãos, o próximo passo é o entendimento da aplicação e das suas características, do time envolvido no projeto, do tempo disponível para o desenvolvimento e até onde esse trabalho pode chegar.

Parece complexo, mas com tempo e experiência isso se torna natural no seu dia a dia. Você, como Product Manager, vai perceber que cada detalhe importa, mesmo não sendo seu escopo de trabalho direto.

A noção disso tudo te prepara para prever possíveis impedimentos, para se adaptar rapidamente, para manter conversas diretas com as pessoas certas. Ou seja, você vai saber o que fazer em cada momento durante todo o ciclo de desenvolvimento do produto, principalmente na tomada de decisões estratégicas.

Leia também: