# Produto & Engenharia
## Overview
Missão da Área
Construir e manter a plataforma Rise de forma segura, estável e simples de usar, para Risers, Makers e o time interno.
O que fazemos no dia a dia?
* Planejamos e desenvolvemos novas funcionalidades da plataforma.
* Mantemos e melhoramos o que já existe (performance, UX, segurança, estabilidade).
* Integramos sistemas de parceiros (Avenia, DexCap, KYC, entre outros).
* Monitoramos erros, logs, métricas e atendemos incidentes.
Rituais
* Cerimônias de desenvolvimento: planning, daily, review e retro.
* Reunião semanal com Operações para entender dores e priorizar melhorias.
* Sessão quinzenal com Comercial e Marketing para entender necessidades de campo.
Como medimos sucesso
* Estabilidade da plataforma (disponibilidade e poucos incidentes).
* Entregas realizadas versus entregas planejadas no ciclo.
* Menos bugs críticos reportados por clientes e pelo time interno.
Boas práticas
* Nada vai para produção sem um teste básico (fluxo feliz e principais erros).
* Decisões técnicas relevantes são registradas em texto curto no GitBook.
* Quando houver dúvida entre “complexo” e “simples”, começar pelo simples bem feito.
## Processos
> **Área:** Tech Lead, Dev Full-Stack, Hous3, Product Designer
>
> **Objetivo:** ter um jeito simples e organizado de planejar, desenvolver, testar e melhorar a plataforma da Rise.
***
Planejamento de Sprint / Ciclo de Desenvolvimento
#### Objetivo
Definir o que será entregue no próximo ciclo de forma realista, alinhada às prioridades da empresa.
#### Responsáveis
* **Owner:** Tech Lead
* **Consultados:** CEO/CTO, Product Designer, Dev, Hous3, Operações, Comercial/Marketing (quando impactados)
#### Passo a passo (V1)
1. **Coletar demandas**
* Entradas de: Estratégia/Tech, Operações, Comercial, Marketing, Jurídico/Compliance.
* Incluir bugs críticos e débitos técnicos importantes.
2. **Detalhar rapidamente as histórias**
* Escrever uma descrição simples do que precisa ser feito (história/tarefa).
* Definir critério de pronto (ex.: “consideramos pronto quando o cliente consegue fazer X sem erro Y”).
3. **Estimar esforço**
* Dev + Hous3 dão uma estimativa simples (baixo / médio / alto e/ou pontos).
4. **Montar o pacote do ciclo**
* Priorizar, junto ao CEO/CTO, quais itens entram (com base em impacto x esforço).
* Verificar se o volume total cabe na capacidade estimada da equipe.
5. **Registrar e comunicar**
* Colocar tudo no quadro (Jira/Linear/Trello).
* Compartilhar o resumo no Lark/GitBook: “Foco do ciclo = X, Y e Z”.
**Saída esperada:**\
Backlog do ciclo claro, visível para todo mundo e factível de ser entregue.
Desenvolvimento e Code Review
#### Objetivo
Garantir que o código entregue tenha qualidade mínima, seja legível, testado e alinhado aos padrões da Rise.
#### Responsáveis
* Owner: Tech Lead
* Atores: Dev Full-Stack, Devs da Hous3
#### Passo a passo (V1)
1. **Puxar tarefa priorizada**
* O dev sempre puxa tarefas do topo da fila (segundo prioridade definida no planejamento).
2. **Desenvolver a solução**
* Escrever código limpo, seguindo padrões de estilo e arquitetura definidos.
* Adicionar logs básicos e, quando fizer sentido, métricas (para observabilidade).
3. **Escrever testes mínimos**
* Pelo menos teste do “fluxo feliz” e casos de erro principais.
* Conferir se a funcionalidade roda localmente ou em ambiente de teste.
4. **Abrir Pull Request (PR)**
* Descrever, em linguagem simples, o que foi feito e como testar.
* Marcar o Tech Lead (ou outro dev) para revisão.
5. **Revisar e ajustar**
* Revisor aponta pontos de melhoria (claridade, padrão, segurança, performance).
* Autor ajusta o código e responde os comentários.
6. **Aprovar e mesclar**
* Após aprovação, PR é mesclado na branch principal (seguindo fluxo da esteira CI/CD).
**Saída esperada:**\
Código revisado, com testes básicos, seguindo padrões de arquitetura e pronto para ser liberado.
Gestão de Bugs e Débitos Técnicos
#### Objetivo
Evitar que bugs e “gambiarras” se acumulem, afetando a qualidade da plataforma.
#### Responsáveis
* Owner: Tech Lead
* Atores: Dev Full-Stack, Hous3, Operações (como fonte de feedback)
#### Passo a passo (V1)
1. **Registrar tudo**
* Todo bug reportado por cliente ou time interno vira ticket no sistema.
* Débitos técnicos identificados (ex.: “temos uma solução provisória aqui”) também viram ticket.
2. **Classificar**
* Prioridade Alta: causa erro para muitos usuários ou risco relevante.
* Média: atrapalha, mas tem contorno.
* Baixa: incômodo menor ou melhoria futura.
3. **Tratar bugs críticos imediatamente**
* Bugs de prioridade alta entram antes de novas features, sempre que possível.
* Se for necessário, abrir incidente com apoio de Tech/Operações.
4. **Reservar capacidade no ciclo**
* Em todo ciclo, reservar uma parte da capacidade para correção de bugs e débitos técnicos (ex.: 20–30%).
5. **Fechar e documentar**
* Ao resolver um bug, registrar a causa e a correção de forma simples.
* Avisar Operações quando o bug impactava clientes.
**Saída esperada:**\
Bugs e débitos técnicos visíveis, priorizados e tratados de forma contínua — sem “bola de neve”.
Integrações com Parceiros (Avenia, DexCap, KYC etc.)
#### Objetivo
Implementar e manter integrações com parceiros críticos de forma segura, estável e bem documentada.
#### Responsáveis
* Owner: Tech Lead
* Atores: Dev Full-Stack, Hous3
* Consultados: Head de Operações, CFO, CBA, DexCap (quando aplicável), Avenia e outros parceiros
#### Passo a passo (V1)
1. **Entender o fluxo de negócio**
* Operações e/ou Comercial explicam o fluxo desejado com o parceiro (ex.: pagamentos, emissão, KYC).
* Definir claramente o que deve acontecer de ponta a ponta.
2. **Mapear APIs e requisitos**
* Coletar documentação técnica do parceiro.
* Identificar endpoints, autenticação, limites, callbacks, webhooks etc.
3. **Desenhar a integração (alto nível)**
* Fazer diagrama simples: sistemas envolvidos, dados que trafegam, pontos de falha possíveis.
* Validar com Tech Lead e CEO/CTO.
4. **Implementar e testar**
* Implementar chamadas, tratamentos de erro e logs.
* Criar ambiente de teste/staging, se disponível.
* Rodar testes de ponta a ponta com o parceiro.
5. **Documentar**
* Escrever resumo da integração no GitBook: quais endpoints usamos, que dados trocamos, quem é responsável.
6. **Monitorar após o go-live**
* Verificar logs e métricas nas primeiras semanas.
* Ajustar rapidamente se aparecerem problemas recorrentes.
**Saída esperada:**\
Integrações que o time entende, consegue monitorar e ajustar, sem dependência de uma pessoa só.
Monitoramento & Suporte a Incidentes (Nível Técnico)
#### **Objetivo**
Detectar problemas técnicos rapidamente e apoiar Operações na resolução de incidentes.
**Obs:** complementa o processo de incidentes já descrito no Playbook de Estratégia & Produto/Tech, olhando aqui do ponto de vista da execução.
#### Responsáveis
* Owner: Tech Lead
* Atores: Dev Full-Stack, Hous3
* Parceiros: Head de Operações, CEO/CTO
#### Passo a passo (V1)
1. **Configurar monitoria básica**
* Logs de erro, métricas de uso, tempo de resposta, uso de recursos.
* Alertas simples por e-mail/Lark para falhas críticas (ex.: quedas de serviço, aumento brusco de erros).
2. **Receber alerta ou chamado**
* Alerta automático da monitoração ou aviso vindo de Operações/CX.
3. **Diagnosticar rapidamente**
* Verificar logs, métricas, últimos deploys.
* Tentar reproduzir o problema em ambiente de teste.
4. **Mitigar**
* Se for possível: rollback, desligar feature flag, aplicar correção rápida.
* Reduzir impacto para cliente o mais rápido possível.
5. **Registrar**
* Escrever um resumo curto do que aconteceu, causa provável e correção aplicada.
* Compartilhar com CEO/CTO e Operações.
**Saída esperada:**\
Respostas mais rápidas a problemas técnicos, com histórico de incidentes registrado e aprendizado acumulado.
Handoff Produto/Engenharia ↔ Operações & Comercial
#### Objetivo
Evitar que features e mudanças cheguem em produção sem que Operações e Comercial estejam preparados.
#### Responsáveis
* Owner: Tech Lead
* Co-owner: Head de Operações
* Consultados: CRO, Head Comercial, Marketing, CEO/CTO
#### Passo a passo (V1)
1. **Informar mudanças relevantes antecipadamente**
* Antes do go-live de uma nova funcionalidade que impacte cliente ou operação, avisar Operações e Comercial.
2. **Explicar o que muda**
* O que o usuário passa a ver/fazer.
* O que muda no fluxo interno (ex.: novas etapas, telas ou informações).
3. **Fornecer materiais de apoio**
* Prints, mini-guia ou vídeo rápido mostrando o fluxo.
* Atualizar, quando necessário, FAQ interno.
4. **Coletar feedback após o lançamento**
* Perguntar a Operações e Comercial como foi a experiência nos primeiros dias.
* Ajustar o que estiver causando confusão.
**Saída esperada:**\
Menos surpresa na ponta, times sabendo como a funcionalidade funciona e conseguindo ajudar o cliente.
### Rituais da Área de Produto & Engenharia
Planning (Início de ciclo)
* Participantes: Tech Lead, Dev, Hous3, Product Designer, eventualmente CEO/CTO.
* Agenda:
* Rever prioridades decididas com Estratégia.
* Definir as tarefas que entram no ciclo.
* Estimar esforço e alinhar expectativas.
Daily (Diário)
* Participantes: Tech Lead, Dev, Hous3.
* Agenda rápida (10–15 min):
* O que foi feito ontem.
* O que será feito hoje.
* Bloqueios.
Review (Fim do ciclo)
* Participantes: Tech Lead, Dev, Hous3, CEO/CTO, Operações, Comercial/Marketing (quando fizer sentido).
* Agenda:
* Mostrar o que foi entregue.
* Comparar com o planejado.
* Coletar feedback imediato.
Retro (Fim do ciclo)
* Participantes: time de Produto & Engenharia.
* Agenda:
* O que funcionou bem.
* O que não funcionou.
* 2–3 ações simples para melhorar no próximo ciclo.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://rise-finance-2.gitbook.io/internal/playbook/produto-and-engenharia.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.