Desenvolupament de software a mida: quan compensa i quan no

La pregunta que arriba a serpixel gairebé mai no és “em faig un software a mida?”. Acostuma a ser una altra: fa mesos que ens barallem amb un full de càlcul i ja no dona més de si. El desenvolupament de software a mida és una resposta possible a això, però no sempre és la correcta, i distingir els dos casos abans de gastar res és el que separa un projecte que es fa servir d’un que s’abandona al cap de tres mesos.

Aquest article no intenta convèncer-te de construir res. Intenta donar-te el criteri per decidir-ho tu.

Què és exactament el desenvolupament de software a mida

El desenvolupament de software a mida consisteix a construir una eina específica per al procés d’una empresa concreta, en lloc d’adaptar aquell procés a un programa que ja existeix. La diferència pràctica no és a la tecnologia. És a qui s’adapta a qui.

Amb un producte estàndard de subscripció, pagues una quota per accedir a un programa que fan servir milers d’empreses. Les funcions ja estan definides. Si el teu procés encaixa en la major part del que fa, funciona bé. La resta ho acabes resolent amb fulls de càlcul paral·lels, correus i trucades, que és exactament el punt en què la majoria d’empreses comencen a plantejar-se una altra cosa.

Amb desenvolupament a mida, defineixes tu què ha de fer l’eina, el codi s’escriu per al teu cas i el resultat és teu. No pagues per usuari ni per funcions que no faràs servir. A canvi, assumeixes un projecte de construcció, amb el seu abast, el seu termini i el seu manteniment.

Cap de les dues opcions no és millor en abstracte. El que cal esbrinar és en quina de les dues situacions ets.

Les tres preguntes que decideixen, abans de comparar pressupostos

Abans de demanar ni una sola oferta, contesta aquestes tres. Si totes tres tenen resposta clara, ja saps cap on vas.

Quantes vegades al mes passa el procés? Un procés que passa cinc vegades al mes es gestiona bé a mà, per incòmode que sigui. Un que passa dues-centes vegades es menja una persona sencera. El volum és el que converteix una molèstia en un cost.

Quant costa un error dins d’aquest procés? No és el mateix equivocar-se apuntant una reserva que es corregeix amb una trucada, que equivocar-se en un pressupost que s’envia a un client amb un preu mal calculat. Com més car és l’error, més valor té que el procés deixi de dependre de la memòria d’algú.

El procés està documentat? Aquesta és la que enfonsa més projectes. Si ningú no ha escrit mai com funciona, el que hi ha no és un procés sinó un costum. Hi tornarem al final, perquè és l’error més car de tots.

Quan NO compensa un desenvolupament a mida

Aquesta és la part que les pàgines d’agències no acostumen a escriure. Hi ha cinc casos en què la resposta honesta és que no construeixis res.

1. Quan un producte estàndard cobreix el procés tal com és. Ningú no s’hauria de construir un programa de facturació, de comptabilitat o de nòmines. Són processos regulats, iguals a totes les empreses i resolts des de fa anys per productes madurs i barats. Construir aquí és pagar per reinventar una cosa que ja funciona.

2. Quan el procés encara canvia cada mes. Si l’empresa és jove o el model està en proves, el procés d’avui no és el d’aquí a mig any. Convertir en software un procés inestable no l’ordena: el congela. Primer s’estabilitza, després es construeix.

3. Quan ningú no se’n farà responsable. Una eina a mida necessita una persona dins de l’empresa que la conegui, que decideixi què canvia i que reculli el que l’equip demana. Si aquesta persona no existeix, el projecte s’entrega, es fa servir dues setmanes i torna el full de càlcul.

4. Quan el volum no justifica el projecte. Si la feina manual són dues hores al mes, no surt cap compte. El desenvolupament a mida es paga amb temps recuperat o amb ingressos que avui es perden, i si no hi ha ni l’una cosa ni l’altra, no hi ha cas.

5. Quan el criteri principal és el preu. Un producte de subscripció reparteix el seu cost de desenvolupament entre milers d’empreses. Competir contra això en preu no té sentit i ningú no ho hauria d’intentar. El desenvolupament a mida es justifica per encaix amb el procés i per propietat del resultat, mai per ser l’opció més barata. Si el que busques és el més barat, el producte estàndard guanya, i dir-t’ho forma part de la feina.

Quan sí que compensa

El desenvolupament a mida comença a tenir sentit quan es compleixen dues o més d’aquestes condicions.

El procés és part del que et fa competitiu. Si la manera com gestiones reserves, pressupostos o comandes és una de les raons per les quals els teus clients t’escullen, ficar-la dins d’un programa genèric la iguala a la de tots els altres.

Ja pagues el cost, però en hores. El procés manual no és gratis. Està pagat amb el temps de persones que podrien estar fent la feina que només elles saben fer: atendre bé un client, decidir un cas ambigu, tancar una venda.

Els sistemes no es parlen entre ells. Quan la mateixa dada es pica tres vegades, al web, al full de càlcul i a la facturació, el problema no s’arregla amb un producte més. S’arregla connectant el que ja hi ha.

L’estàndard t’obliga a treballar pitjor. És el símptoma més clar: has adaptat la teva manera de treballar al programa, no al revés, i l’equip ha desenvolupat rutines per esquivar-ne les limitacions.

Tres exemples de feina entregada per serpixel, descrits sense noms perquè el rellevant és el procés:

• Una granja escola ven reserves i vals regal des del seu web. L’equip valida l’accés amb lector de codi QR a l’entrada i les vendes es comuniquen a la seva facturació.
• Un instal·lador solar ofereix un pressupost orientatiu a l’instant des del seu web, i cada sol·licitud entra al seu CRM amb les dades del càlcul.
• Un restaurant de muntanya gestiona reserves pagades per avançat en línia, amb carta en quatre idiomes i un resum diari per a cuina.

Cap dels tres no va trobar un producte del mercat que cobrís el seu cas sense obligar-los a treballar pitjor. Pots veure com plantegem aquest tipus de projectes a software a mida.

El que gairebé ningú no t’explica del cost

Quan una empresa compara dos pressupostos de desenvolupament, acostuma a comparar la part visible: les pantalles. El cost real és en un altre lloc.

Les integracions. Connectar l’eina amb la facturació, el CRM o la passarel·la de pagament porta habitualment més feina que construir la interfície. Cada sistema té les seves regles, els seus errors i els seus casos rars, i aquí és on se’n va el temps.

La migració de dades. El que avui viu en fulls de càlcul, llibretes i correus ha d’entrar al sistema nou, i gairebé mai no està tan net com es recorda. Netejar i migrar és un projecte en si mateix.

El manteniment. El software que ningú no manté deixa de funcionar: canvien les passarel·les de pagament, canvien les versions, canvien els requisits legals. Un desenvolupament entregat i abandonat té data de caducitat.

Un pressupost que no esmenta aquestes tres partides no és més barat. És que no les ha comptat.

Què exigir per escrit abans de signar

Cinc punts. Si en falta algun a la proposta, demana’l abans d’avançar.

1. Abast funcional tancat: què fa la primera versió i, sobretot, què queda fora expressament.
2. Codi i comptes a nom teu: repositori, servidor, domini i passarel·la de pagament. Si aquests comptes són del proveïdor, no tens un software propi, tens un lloguer amb un altre nom.
3. Documentació d’ús i d’operació: com es fa servir l’eina i com s’opera quan alguna cosa falla.
4. Condicions de traspàs: què passa i en quant de temps si deixeu de treballar junts.
5. Cadència de manteniment per escrit: què es revisa, cada quant i qui respon quan alguna cosa es trenca.

L’error més car: construir sobre un procés que ningú no ha escrit

De tots els motius pels quals un desenvolupament a mida acaba sense fer-se servir, aquest és el més freqüent i el més car.

Quan el procés no està documentat, cada persona de l’equip en té la seva versió. El software acaba recollint la de qui va ser a més reunions, i la resta de l’equip el percep com una imposició que no reflecteix com treballen de debò. L’eina no falla tècnicament. Falla perquè descriu un procés que no existeix.

La prova és senzilla: escriu el procés tal com el fa avui una persona, amb les seves excepcions. Si no cap en dues pàgines, encara no està a punt per convertir-se en software. Aquesta feina d’escriptura no és burocràcia prèvia: gairebé sempre revela que una part del procés sobra, i això és més barat descobrir-ho en un document que en un desenvolupament.

És també on es decideix quina part de la feina pot assumir una eina i quina part necessita criteri humà. La capa mecànica (calcular, registrar, avisar, repetir) és la que s’automatitza. La decisió ambigua, la relació amb el client i el cas rar continuen sent de l’equip, i és on el seu temps val més.

Com decidir-ho sense gastar de més

Si has arribat fins aquí, ja tens el criteri: volum, cost de l’error, documentació i encaix amb el que et fa competitiu. Amb aquestes quatre respostes, la decisió acostuma a ser evident en una conversa de mitja hora.

A serpixel el punt de partida és sempre aquesta conversa: una sessió de descobriment de 30 minuts per entendre el procés abans de parlar de res més. Si la resposta honesta és que un producte del mercat et serveix, t’ho diem. I si el problema no és construir una eina nova sinó connectar les que ja tens, això es diu automatització de processos i és un projecte diferent, normalment més curt.