Skills@joaoguirunas

SaaS Morreu — Service as a System

Aprenda a mapear um processo real da sua empresa e transformá-lo no ponto de partida de um sistema feito sob medida, não mais um SaaS genérico.

O que é

SaaS Morreu — Service as a System

Você vai mapear um processo real da sua empresa e transformá-lo no rascunho de um PRD — o documento que descreve o que construir. No fim do exercício, você terá em mãos o ponto de partida para um sistema feito sob medida para a sua operação, em vez de continuar encaixando o seu negócio em um software genérico.

Por 20 anos, a lógica foi uma só: você comprava um SaaS e moldava a sua empresa a ele. Com IA, a lógica inverte — agora o sistema se molda à empresa. Isso importa porque cada negócio perde tempo e dinheiro nas gambiarras que faz para caber num software que não foi pensado para ele. Quando o sistema nasce do seu processo, essas perdas somem.

O tutorial trabalha quatro conceitos centrais: SaaS (software genérico que a empresa serve) versus Service as a System (sistema sob medida que serve à empresa); PRD (Product Requirements Document), o documento que descreve o que construir em linguagem clara; e o Squad de Dev, o time de agentes que constrói o sistema a partir desse documento.

Nenhuma habilidade técnica é necessária — este é, antes de tudo, um exercício de raciocínio e documentação. Quando você estiver pronto para construir, o Claude Code e o repositório team-os são os recursos para dar o próximo passo.

Como funciona

Principais recursos

Descreva o processo real

Documente como a sua operação realmente funciona, com as palavras da sua equipe — sem tentar encaixar em nenhum formato de software.

Mapeie as dores operacionais

Identifique cada ponto em que a equipe perde tempo adaptando a operação a um software genérico. Cada gambiarra é uma oportunidade.

Escreva um PRD claro

Transforme o processo e as dores num documento de uma a duas páginas que descreve o que o sistema precisa fazer, para quem e por quê.

Construa com o Squad de Dev

Entregue o PRD ao squad de agentes do team-os e acompanhe a construção de um sistema que reflete a sua operação real.

Valide antes de construir

Use prompts prontos para que o Claude aponte ambiguidades e lacunas no PRD antes de qualquer linha de código ser escrita.

Nível: conceitual + prático · Tempo estimado: 40 min

Pré-requisitos

  • Nenhuma habilidade técnica — este é um exercício de raciocínio
  • Um processo real da sua empresa em mente (vendas, atendimento, onboarding, financeiro — qualquer um que dê trabalho hoje)
  • Papel e caneta, ou um documento em branco
  • Opcional, para quando você for construir: o Claude Code instalado (via npm) e o squad de Dev do repositório team-os

Conceitos-chave

01

SaaS (Software as a Service)

Software pronto e genérico que você aluga. A empresa se adapta a ele, moldando os seus processos à lógica do software.

02

Service as a System

Um sistema feito sob medida a partir do seu processo. Ele se adapta à empresa — não o contrário.

03

PRD (Product Requirements Document)

O documento que descreve, em linguagem clara, o que o sistema precisa fazer. É a ponte entre a sua ideia e a construção.

04

Squad de Dev

O time de agentes que constrói o sistema a partir do PRD, disponível no repositório team-os.

Passo a passo

01

Passo 1 — Descreva o seu processo real, do seu jeito

Escolha um processo da sua empresa e descreva-o exatamente como acontece hoje, com as palavras que a sua equipe usa no dia a dia — sem tentar padronizar para um software. O software genérico obriga você a traduzir o seu processo para a lógica dele; aqui é o contrário. Quanto mais fiel à operação real, melhor o sistema que nasce depois. O resultado esperado é um texto que parece bagunçado e específico demais — ótimo, é exatamente isso.

Meu processo de [nome]: 
1. Acontece [gatilho / quando começa].
2. Aí a equipe faz [ação], usando [ferramenta atual].
3. Depois [próxima etapa]...
Termina quando [resultado].
02

Passo 2 — Marque as dores onde a equipe perde tempo

Releia o processo e marque cada ponto em que a sua equipe perde tempo encaixando a operação num software que não foi feito para ela. Essas dores são o mapa de onde o Service as a System entrega mais valor — cada gambiarra é uma oportunidade. Espere encontrar de 3 a 8 dores marcadas; são elas que justificam construir um sistema próprio.

- "Aqui a gente exporta pro Excel porque o sistema não faz."
- "Esse campo a gente preenche num lugar e copia pra outro."
- "Todo mês alguém refaz esse relatório na mão."
- "O software obriga a fazer nessa ordem, mas na prática é o contrário."
03

Passo 3 — Transforme isso num PRD

Organize a descrição e as dores num PRD — um documento que diz o que o sistema precisa fazer, para quem e por quê. O PRD é a ponte: é o que a equipe (ou o squad de Dev) lê para construir a coisa certa. Sem PRD, você constrói no escuro. O resultado esperado é um documento de uma a duas páginas, sem jargão técnico.

1. Problema: qual dor este sistema resolve.
2. Quem usa: quem da equipe vai usar no dia a dia.
3. O que o sistema faz: as funções principais, em linguagem clara.
4. Como o processo flui: os passos, do início ao resultado.
5. O que NÃO faz: os limites, para não inchar o escopo.
04

Passo 4 — Construa com o squad de Dev

Entregue o PRD ao squad de Dev e deixe a equipe conduzir a construção a partir dele. O squad de Dev e o instalador estão no repositório team-os. Com o PRD claro, o squad tem tudo para construir um sistema que encaixa no seu processo — não um genérico que você teria que contornar. Espere um sistema que reflete a sua operação real, feito na fração do tempo e do custo de um software sob encomenda tradicional.

Descrever o processo com ajuda do Claude

Vou te descrever um processo da minha empresa do meu jeito, bagunçado. Sua tarefa é só me ajudar a organizar, sem simplificar demais nem forçar num formato de software genérico. Depois me ajuda a marcar onde minha equipe perde tempo. Aqui vai: [descreva o processo]

Transformar em PRD

Com base no processo e nas dores que marcamos, escreve um PRD de 1-2 páginas com: problema, quem usa, o que o sistema faz, como o processo flui e o que NÃO faz. Linguagem clara, sem jargão técnico.

Entregar o PRD ao squad de Dev e começar a construir

/team-os

Aqui está o PRD do sistema que quero construir (colado abaixo). Squad de Dev: leia, me faça as perguntas que faltam pra fechar o escopo e proponha um plano de construção em fases, começando pela função que resolve a maior dor. Não escreva código antes de eu aprovar o plano. PRD: [cole o PRD]

Validar o PRD antes de construir

Faz o papel de cético: leia esse PRD e aponta 5 pontos ambíguos ou faltando que fariam a construção sair diferente do que a empresa precisa. Pra cada ponto, sugere a pergunta que eu deveria responder. PRD: [cole o PRD]

Erros comuns

  • Descrever o processo "de manual": volte e descreva o real, com exceções e atalhos do dia a dia
  • PRD virando especificação técnica: foque no o quê e no porquê; deixe o como para a construção
  • Pular o PRD: sem ele, o sistema sai diferente do que a empresa precisa — sempre documente antes de construir
  • Marcar todas as dores como prioritárias: foque nas que custam mais tempo ou geram mais erro
Checklist final
  • Processo real descrito do seu jeito
  • Dores de "encaixar no software genérico" marcadas
  • PRD de 1-2 páginas escrito (problema, quem usa, o que faz, fluxo, limites)
  • PRD entregue ao squad de Dev
  • Entendeu a virada: o sistema se molda à empresa, não o contrário
  • Repositório team-os (Centro de Treinamento e squads, incluindo o squad de Dev) — https://github.com/joaoguirunas/team-os
  • Claude Code (instalação via npm) — https://www.npmjs.com/package/@anthropic-ai/claude-code

Vá além do tutorial

Quer dominar isso na prática?

Na Formação Gestor de IA você vai do zero ao site no ar comandando equipes de agentes, sem escrever uma linha de código.