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.