5 MIN LEITURA · Pedro Thomaz

Porque cobramos por sprint, não por hora

Facturação à hora premeia quem é lento. Por projecto premeia quem promete demais. Sprints de duas semanas premeiam a única coisa que importa: entregar algo.
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.