Modelos de trabalho

Como explicar sua ideia para quem vai desenvolver (e não pagar retrabalho depois)

Equipe iatize · · 9 min de leitura

Resumo

Retrabalho quase nunca nasce de má-fé: nasce de um pedido que cada lado entendeu de um jeito. O que resolve é uma página só, escrita por você antes de pedir orçamento, com cinco coisas — o problema (não a tela), quem usa, a jornada principal em passos, a lista do que NÃO entra na primeira versão e suas referências reais. Adjetivo como “moderno” ou “robusto” não é especificação: troque cada um por um exemplo ou por um número.

A cena se repete: você explicou a ideia por quarenta minutos, a pessoa do outro lado disse que entendeu perfeitamente, e três semanas depois chegou uma coisa que não é o que você imaginou. Ninguém mentiu. Você descreveu um filme que roda inteiro na sua cabeça; quem escutou recebeu a legenda, e preencheu o resto com o que já construiu antes.

Aviso de honestidade: a iatize recebe pedido de orçamento todo dia e ganha dinheiro construindo o que sai desses pedidos. Justamente por isso vamos falar do que quem vende raramente fala: boa parte do retrabalho que você pagaria começa antes de qualquer linha de código, num pedido que dava para escrever melhor em uma hora — e essa hora é sua, não custa nada e vale mais que qualquer negociação de preço.

Cada rodada de “não era bem isso” é escopo refeito e cronograma esticado. Duas ou três delas num projeto de R$5.000 mudam a natureza do investimento — e o pior nem é o dinheiro: a segunda versão sai pior, remendada em cima de uma estrutura pensada para outra coisa.

Peça o resultado, não a tela

Compare os dois pedidos: “quero uma tela com um calendário e um botão de confirmar” contra “quero que o cliente escolha sozinho um horário livre e que eu não precise mais confirmar no WhatsApp”. O primeiro comprou uma solução. O segundo comprou um problema — e deixou quem constrói propor três caminhos, sendo que um deles quase sempre é mais barato e mais rápido do que a tela que você imaginou. Quem especifica a solução também assume o risco dela: se a sua tela era a pior das três, você pagou pela pior e ninguém vai discutir.

A página única que você escreve antes de pedir orçamento

Uma página. Não um documento de trinta. Cinco blocos, nesta ordem:

  1. O problema em uma frase, com quem sofre e o custo. “Meu time perde duas horas por dia repassando pedido do WhatsApp para a planilha e erra o endereço três vezes por semana.” Custo e frequência dizem mais que a descrição do app.
  2. Quem usa, por função: cliente, atendente, gerente, entregador. Uma linha para cada — o que faz e o que não pode ver. Cada tipo de usuário a mais é dinheiro, e listar cedo evita descobrir isso na metade.
  3. A jornada principal em passos numerados, de quando a pessoa chega até o objetivo cumprido. Se não couber em cinco a sete passos, você colocou duas jornadas em uma.
  4. O que NÃO entra na primeira versão — a parte que quase ninguém escreve e a que mais economiza.
  5. Referências e seus dados reais: dois ou três produtos que você acha bons, com uma frase sobre o que gosta em cada um, e um print da planilha que hoje faz esse trabalho.

A lista do “não entra” é a parte que economiza dinheiro

Todo pedido descreve o que o produto vai fazer; quase nenhum descreve o que ele não vai fazer, e é por essa fresta que o orçamento vaza. Sem a lista, quem constrói ou imagina o que você quis dizer e embute no preço, ou faz o mínimo e cobra o resto como extra. Nos dois casos você paga. Escreva cinco a dez linhas começando com “nesta versão, não vai ter”:

  • Não vai ter pagamento dentro do app — mando o link de pagamento por fora.
  • Não vai ter aplicativo nas lojas — abre pelo navegador do celular.
  • Não vai ter perfil de gerente com aprovação — no começo eu mesmo aprovo.
  • Não vai ter integração com o sistema de nota — exporto uma planilha por semana.
  • Não vai ter notificação na hora — um e-mail resolve.

Duas coisas acontecem. As propostas ficam comparáveis, porque todo mundo precificou o mesmo recorte. E, escrevendo, você descobre que metade do que ia pedir não era da primeira versão — é aí que um projeto de R$15 mil às vezes vira um de R$5.000 sem perder o que interessa.

Adjetivo não é especificação

“Moderno”, “intuitivo”, “profissional”, “robusto”, “escalável”. Cada uma dessas palavras significa uma coisa diferente na cabeça de cada pessoa, nenhuma delas dá para orçar, e todas passam a sensação de que a conversa avançou. A tradução:

  • Em vez de “moderno”: mande dois ou três links e diga em uma frase o que gosta em cada um. Se não gosta de nada, mande o que acha feio — funciona igual.
  • Em vez de “intuitivo”: diga quem é a pessoa menos preparada que vai usar. “Minha tia de 68 anos tem que conseguir sozinha” é especificação de verdade.
  • Em vez de “escalável”: diga quantas pessoas você espera no primeiro ano e de onde elas vêm. Cem clientes de indicação e cinquenta mil de anúncio pedem decisões e preços diferentes.
  • Em vez de “robusto” ou “seguro”: diga o que não pode acontecer de jeito nenhum. “Um cliente não pode ver o pedido de outro” vira trabalho concreto; “seguro” não vira nada.
  • Em vez de “rápido”: diga o prazo e por quê. “No ar antes da feira de outubro” muda o que cortar.

O teste da devolução: peça para ele te contar o seu projeto

Antes de assinar, mande esta frase: “me manda por escrito, com suas palavras, o que você entendeu que vai construir e a lista do que ficou de fora”. Custa dois minutos e é o teste mais barato dessa relação.

O que voltar responde três coisas: se ele entendeu, se ele escuta ou só executa, e como ele escreve — porque é assim que o seu projeto vai ser documentado. Fornecedor bom devolve em horas, com lista e com dúvidas. Quem devolve “é isso mesmo, pode deixar comigo” só repetiu o seu texto.

Quando escrever mais atrapalha (a parte contra o nosso interesse)

Seria cômodo dizer que quanto mais detalhado o pedido, melhor. Não é verdade, e o exagero tem custo próprio:

  • Documento de trinta páginas antes da primeira conversa: você gasta semanas decidindo o que vai mudar na primeira semana de uso real. Uma página fecha o essencial.
  • Especificar campo por campo: transfere para você a parte do trabalho que é do fornecedor e ainda te prende à sua primeira ideia.
  • Se você não consegue escrever a jornada principal em cinco passos, a ideia não está pronta para virar orçamento. O dinheiro certo hoje é o de validar, que sai por bem menos.
  • Se você já está no meio de um projeto que azedou, o briefing ajuda mas não resolve sozinho. Ali a conversa é sobre o que já foi entregue, o que falta e, às vezes, sobre parar.

E o inverso: se depois de uma página clara e de uma devolução por escrito você continuar recebendo entregas fora do combinado, o problema deixou de ser o seu pedido.

Use o nosso diagnóstico como rascunho dessa página: cerca de 1 minuto de perguntas e você sai com o recorte do projeto por escrito e uma faixa de investimento. Leve o texto para quem quiser, inclusive para outro fornecedor.

Fazer meu diagnóstico gratuito

Perguntas frequentes

Como explicar minha ideia de app para um desenvolvedor?

Escreva uma página com cinco blocos antes de pedir orçamento: o problema em uma frase com o custo e a frequência dele, quem vai usar por tipo de usuário, a jornada principal em cinco a sete passos numerados, a lista do que NÃO entra na primeira versão, e referências reais — incluindo um print da planilha que hoje faz esse trabalho. Descreva o resultado que você quer, não a tela que imaginou.

O que precisa ter num briefing de aplicativo?

Problema, usuários, jornada principal, o que fica de fora da primeira versão e referências. O item que mais economiza é o que fica de fora: sem ele, cada fornecedor imagina um escopo diferente e as propostas ficam impossíveis de comparar. Restrições do mundo real — uso na rua, sem sinal, prazo amarrado a uma data — também mudam arquitetura e preço.

Preciso entender de tecnologia para pedir um aplicativo?

Não. Você precisa descrever o seu negócio com precisão: quem faz o quê, em que ordem, com que frequência e o que não pode acontecer. A parte técnica é justamente o que você está contratando. Se um fornecedor exige que você chegue com decisões técnicas prontas, ele está transferindo o risco para você.

Como evitar retrabalho no desenvolvimento de um aplicativo?

Três hábitos resolvem a maior parte: escrever o que NÃO entra na primeira versão, para ninguém precificar por imaginação; trocar adjetivos como moderno e escalável por exemplos e números; e, antes de assinar, pedir ao fornecedor que descreva por escrito o que entendeu que vai construir e o que ficou de fora. O que aparecer de diferente ali seria retrabalho pago depois.

E se eu ainda não souber todos os detalhes do que quero?

É normal, e não impede pedir orçamento — impede pedir orçamento fechado de tudo. Descreva bem a jornada principal, marque o resto como ainda não decidido e peça um recorte pequeno com preço fechado. Um MVP começa em R$5.000 exatamente por isso: existe para transformar dúvida em decisão com o produto na mão. Se nem a jornada você consegue escrever, o passo de hoje é validar, não contratar.