Fer pressuposts
Una de les tasques que hem de fer la gent que ens dedicam a la programació d'aplciacions a mida és la de tenir que dir què costarà fer l'aplicació, és a dir, fer un pressupost, i d'això tractarà aquest apunt, de com entenc jo que ha de ser un pressupost de programari, de les dificultats de fer-ho, del tipus de pressupost que es demanen. Com sempre, esper no avorrir-vos molt.
Què hem de posar a un pressupost?
Això és una de les qüestions més delicades. El més habitual en el nostre sector és que els pressupots no es cobren, per tant hi ha dues visions contraposades: la de dedicar el mínim temps possible a fer el pressupots i la de fer un pressupost amb cara i ulls, de manera que les xifres que es posin allà estiguin justificades amb la feina que s'han de fer.
Particularment sóc partidari de la segona opció. Pensau que la feina final no és el pressupost en sí, sinó el projecte que sortirà d'aquest pressupost. Per això és important que el pressupost defineixi ja l'abast de la feina, els objectius del projecte, el seu abast i les condicions en que es durà la feina.
Per això és necessari tenir força informació del projecte, saber què s'ha de fer en línies generals. Vull dir, no es tracta de saber-ho al detall tot, però sí de ser molt conscient de què és el que cerca el client amb l'aplicació i quines són les feines fonamentals que ha de fer.
En aplicacions web normals això pot ser tan simple com pensar el sitemap de l'aplicació i anar posant-ho damunt el pressupost. "La plana home mostrarà les ofertes principals, amb les imatges dels productes que es motraran de manera aleatòria, ..."
En altres tipus d'aplicacions molt més orientades a la gestió el sitemap de l'aplicació encara no està clar en aquesta etapa i llavors convé fer una mica d'anàlis dels casos d'ús que hi ha implicats.
Una vegada hem redactat el que es farà a mi m'agrada posar també amb quines condicions es farà. És a dir, que el client sàpiga que un projecte web és cosa de les dues parts, que hi ha feines que ha de fer l'empresa de desenvolupament, però que l'èxit del projecte també pot dependre de la seva pròpia implicació i dels tercers involucrats en el projecte.
Després d'això les xifres econòmiques. Jo he estat a les dues bandes, i no m'agradava gent tenir sols una xifra final sense cap tipus de suport lògic. Per això m'agrada sempre indicar el perquè de la xifra i si és possible desglossar-la per tal que el client pugui veure les implicacions de feina de cada concepte.
No es tracta d'anar al detall fi i tancar-ho tot, però sí que s'ha de ser conscient de que per exemple hi ha una feina de sistemes en el projecte, que hi ha feina de gestió, de maquetació, ...
Finalment la part de parrafada de les condicions: fins quan dura el pressupost, quan es dona per començat, com seran els pagaments, com es gestionaran les modificacions, quines garanties hi ha.
Aquesta darrera part és bastant aprofitable entre diferents projectes, però sempre hi ha condicions particulars per a un pressupost concret.
Fet i fent, doncs un pressupost pot dur força feina, entre mig dia per a un projecte senzill, de posem un mes de feina, a varis dies per projectes més complexes.
Cada un ha de tenir el seu límit personal que separa el que és un pressupost i el que és un anàlisi complet. Si la feina de pressupostar requereix d'un anàlisi complet i investigació, crec que és una feina que va més enllà del que és fer el pressupost i que s'han de cobrar com a feina de consultoria.
Jo he vist pressupots d'una plana!
I jo també, i fins i tot hi ha clients que agafen aquests pressuposts, però després tots ja sabem com solen acabar aquestes coses.
Pens que hem de ser molt transparents en la feina que fem i donar sols una xifra sense explicar la feina no és bo ni per al professional ni per al client.
Per al professional perquè pot donar l'impressió que s'està inventant la xifra, perquè no està dient què farà i això a la llarga pot causar molts problemes i perquè si li accepten un pressupost així acabarà amb clients que no valoren la feina feta sinó que simplement van a un preu final sense saber què hi ha al darrera.
Fer pressuposts a alguna gent li pot parèixer que es perdre el temps, però jo no ho veig així. Força al programador i al client a pensar en el que volen, a definir unes regles del joc.
Pensau que no és gens habitual passar de pressupost a contracte, així que normalment el que defineix l'abast de la feina és el pressupost i per tant aquest és el document que fixa la filosofia de feina de l'empresa.
Fer un pressupost i el desenvolupament àgil
L'altra dia vaig fer un twitt dient que havia entregat un pressupots de gairebé 20 planes i un seguidor em deia que això no seria molt àgil. No té res a veure. Un pressupost aixì indica que l'apliació és complexa, que durà mesos de feina, però no és un anàlis "en cascada".
El manifest àgil no diu res de fer pressupots, ens diu que hem de donar prioritat als indivíduu front als processos, al programari front a la documentació, a la col·laboració amb l'usuari davant la negociació de contractes i a respondre als canvis.
I hem de poder fer això donant una xifra al client. El manifest no diu res de "no te diré què costa fins que estigui acabat", sinó que la idea que hi ha al darrera és que sempre es procurarà que el programa que entregui respongui a les teves necessitats, encara que no siguin las mateixes que quan començarem el projecte.
Un pressupost és el punt de partida, el que diu què volem fer i estableix el llenguatge comú del projecte. El que les dues parts pensen que s'ha de fer. La col·laboració amb el client i la resposta a canvis es té quan fas que el pressupost no sigui inamobible, sinó que es puguin anar afegint o llevant funcionalitats segons siguin les necessitats del projecte.
Quan el client coneix les regles del joc, sap que la xifra que li has donat és una estimació, però que els canvis no se li cobraran sempre, sinó que si un canvi implica que una altra funcionalitat no es fa, es probable que les xifres es compensin, i és més, com que té el pressupost on hi ha les tasques i la seva complexitat, pot avaluar per sí mateix l'impacte dels seus canvis en el cost final de l'aplicació.
El pressupost estableix els supòsits de partida, és la validació que s'ha entès la feina que s'ha de fer, però en cap caps significa que una vegada acceptat impliqui que allò és just el que s'ha de fer i que "ja ens veurem quan t'ho acabi". Estam complint un dels principis del manifest àgil, valorant més la col·laboració i la implicació del client que signar el contracte final. i informant-lo al mateix temps de la flexibilitat que té per anar canviant el projecte així com vagi veient la seva evolució.
Posant preu
Si heu anat aquí directament millor tornau enrera :) Als paràgrefs anteriors estava dient que per posar preu hem de conèixer el projecte i establir com col·laborarem amb el client.
Posar preu és complicat. Se'ns demana que adivinem quina feina durà fer un projecte que no hem fet mai, que anticipem problemes, ho valorem en temps i esforç i que al final posem una xifra.
Si no hem definit abans quin és el significat d'aquesta xifra i el client enten que la xifra és el projecte anam malament.
En el proper article mirarem de veure com posam preu, si convé tirar de bolla de vidre o podem fer alguna cosa més a l'hora de definir un preu per al projecte.
Ens llegim aviat!
