Porque cobramos por sprint, não por hora
Três modelos de pricing. Um único resultado que importa. Vejamos os incentivos.
À hora
Facturação à hora paga-te por gastar horas. Cada hora é receita. O developer lento ganha o mesmo por hora que o rápido — e ao longo do projecto, o lento ganha mais. Pior, o cliente paga pelo tempo a pensar, a debugar, a aprender, a estar em reuniões. A maior parte do qual não devia estar a subsidiar.
Preço fixo
Preço por projecto inverte o problema: agora o estúdio quer entregar o mais rápido possível, mesmo que a qualidade sofra. A primeira coisa a sair são os testes. A segunda é a documentação. A terceira são as partes que o cliente não pediu explicitamente mas precisava mesmo.
Os dois modelos põem cliente e estúdio em lados opostos da mesa.
Sprint
Vendemos sprints de duas semanas a uma taxa fixa de equipa sénior. Cada sprint, o cliente recebe: um scope acordado à entrada, uma entrega à saída, e uma retro escrita que lista o que queremos fazer no próximo sprint e o que cortávamos.
Ao fim de cada sprint, o cliente pode parar. Vai-se embora. Leva o que construímos, o código, a marca, as entregas. Não trancamos nada.
Porque funciona
Duas razões. Primeira, o cliente vê velocidade semanalmente. Sabe pelo que está a pagar. Segunda, o nosso incentivo é entregar limpo o suficiente para o próximo sprint correr mais depressa — não esticar trabalho por receita.
O modelo também nos força a fazer scope sem dó. Um sprint de duas semanas não esconde um build de seis semanas. Dizemos não a scope creep na reunião de planeamento, não no prazo.
A parte honesta
Isto não é certo para toda a gente. Clientes que querem preço fixo para uma coisa totalmente especificada — mandamo-los para uma agência de preço fixo. Clientes que querem developers contratados à hora — o mesmo. Trabalhamos com founders que querem entregar algo de duas em duas semanas e confiam no processo. Forma diferente.
Perguntas frequentes
Como funciona o modelo de preço por sprint?
Vendemos sprints de duas semanas a uma tarifa fixa de equipa sénior. Cada sprint recebe um âmbito acordado à entrada e produz um entregável colocado em produção, mais uma retrospetiva escrita sobre o que vem a seguir e o que cortaríamos.
Porque é que cobrar por sprint é melhor do que cobrar à hora?
A cobrança à hora paga ao estúdio para gastar horas, por isso um desenvolvimento lento rende mais e o cliente paga tempo de pensar, depurar, aprender e reunir. Uma tarifa fixa por sprint elimina esse incentivo, já que o nosso objetivo passa a ser entregar de forma limpa para que o sprint seguinte corra mais depressa.
Qual é o problema de um contrato de preço fechado?
O preço fechado empurra o estúdio a entregar depressa mesmo que a qualidade sofra, por isso as primeiras coisas a cair são os testes, depois a documentação, e depois as partes de que o cliente precisava mas não pediu explicitamente. Tal como à hora, coloca o cliente e o estúdio em lados opostos.
Fico preso se quiser parar?
Não. No fim de cada sprint pode parar e ir embora com o código, a marca e os entregáveis, sem nada bloqueado.
O modelo por sprint serve para toda a gente?
Não. Quem quer um preço fixo para algo totalmente especificado é melhor servido por uma agência de preço fechado, e quem procura programadores à hora deve ir a outro lado. Trabalhamos com founders que entregam algo a cada duas semanas e confiam no processo.