Orzamentar unha web: por que o primeiro número case nunca é o bo
Hai un par de anos pechei un orzamento cun cliente do sector inmobiliario en corenta horas de desenvolvemento. Ao final do proxecto tiñamos facturadas setenta e dúas. Non foi porque pedisen cousas novas cada semana, que tamén, senón porque o orzamento orixinal non tiña nin unha hora reservada para o que eu chamo “cousas que non sabemos que non sabemos”: neste caso, que o seu CRM tiña unha API sen documentar e que conectar o formulario de contacto con iso nos custou case tres semanas de idas e voltas co seu provedor.
Dende entón orzamento distinto. Non mellor no sentido de “máis barato” nin “máis rápido”: distinto na estrutura. Antes poñía un número por funcionalidade e sumaba. Agora separo tres bloques: o que sei facer porque o fixen quince veces (login, blog, formularios, un carriño sinxelo), o que depende dun terceiro que non controlo (pasarelas de pago, CRMs alleos, APIs de provedores do propio cliente) e o que é directamente incerteza de deseño, é dicir, decisións que o cliente aínda non tomou aínda que crea que si.
O segundo bloque é o que máis orzamentos me reventou. Cando alguén di “só hai que conectalo co noso ERP” eu xa sei, por experiencia, que esa frase agocha entre cero e corenta horas de traballo e que non o vou saber ata que vexa a documentación, se é que existe. Agora cotizo esa parte á parte, cun rango, e deixo claro por escrito que o número final depende do que atopemos. Algúns clientes incomódanse con esa ambigüidade. Prefiro que se incomoden na proposta a que se incomoden na factura final.
Hai outra cousa que cambiei: deixei de orzamentar en horas soltas por tarefa e empecei a orzamentar por semanas de dedicación real. Dá igual que unha tarefa “debería” levar seis horas se na práctica un desenvolvedor ten reunións, outros proxectos e o cliente tarda catro días en responder un correo cunha dúbida dunha liña. Un proxecto de “seis semanas de traballo” na práctica dura dez ou doce en calendario, e se o orzamento non o reflicte, o cliente lévase a sorpresa a metade de camiño, que é o peor momento posible para dala.
O que non conseguín resolver, nin creo que se resolva de todo, é o orzamento pechado con alcance aberto. Un cliente quere saber o número final antes de asinar, e ao mesmo tempo aínda non sabe exactamente que quere. Eu podo axustar o proceso, meter fases, cobrar unha fase de descubrimento previa dunha semana antes de dar cifra en firme, pero ao final alguén ten que decidir con información incompleta, e ese alguén case sempre son eu. A última vez que o intentei sen fase de descubrimento previa, nun proxecto dun comercio online mediano, acabei comendo oito horas da miña marxe só por non ter a conversa incómoda de subir o prezo a metade de proxecto. Non sei se fixen ben. Sei que a próxima vez a fase de descubrimento vai estar no contrato, úsese ou non se use.