El Blog de Trespams

Estam acostumats ja al terme "hipoteca tecnològica", s'aplica quan en el desenvolupament d'un programa has pres una sèrie de decisions que te condicionaran el futur. Sabem que és recomanable evitar en el possible les hipoteques d'aquesta mena, o al manco quan no les podem evitar hem de saber que hi són i gestionar-les, anarles tornant, com faríem amb una hipoteca real, sols que en el nostre cas, el tornar mota i intresessos reb el nom de refactorització.

Però n'hi ha altres d'hipoteques, hipoteques que no afecten al desenvolupador sinó a l'empresa i el pitjor és que són autoimposades, sense adonar-nos, en forma de programes virals que tene per objectiu fer-se imprescindibles, que faciliten les coses quan un comença i que es converteixen un una llosa quan l'empresa va creixent, que s'aprofiten de "l'hara ja et tenc agafat".

En el món de la informàtica és una pràctica habitual i perversa. Empreses que fan o venen programari a baix cost pensant que ja ho recuperaran quan el client demani la primera modificació, o l'actualització. Que sols presenten els costs actuals i amaguen els costs futurs de manteniment i de creixement. Vam fundar APSL ja fa un grapat d'any perquè aquesta mena de pràctiques no ens agradàven, perquè no volíem (i no volem) tenir clients captius. Fer feina i desenvolupar amb programari lliure, donar-los accés a les nostres mateixes eines de gestió de projectes forma part d'aquesta mateixa idea.

Vet aquí que l'altra dia Benjamí em presenta Slack, una eina que promet integrar tota la comunicació de la gestió d'un projecte a un mateix lloc. La vaig evaluar i tot d'una la vaig classificar com a hipoteca tecnològica per a l'empresa. No tenc res contra Slack, sols que no la faré servir en les condicions actuals per dur la comunicació dels projectes dins APSL, m'explicaré:

Cost inicial zero.

El cost inicial és 0, fina a 10.000 missatges. Això està bé, direu, 10.000 missatges són molts, veritat? Doncs depèn. Pensau que actualment dins el nostre gestor de projectes, Redmine, ja hem creat més de 21.200 tickets, cada ticket a més pot tenir vàries interaccions, i no sempre hem fet servir Redmine, abans gestionàvem els projectes fent servir Track.

Això vol dir que en un parell d'anys haurem de decidir entre perdre informació històrica o bé anar cap a la versió de pagament, que ens permetrà mantenir la informació i cercar-la. L'experiència demostra que perdre informació històrica és mala idea, forma part de la gestió dels projectes. Si el client no et paga pot servir per demostrar la relació que hi havia i com es feia la feina.

Així doncs, en un no res estareu pagant un mínim de 6 euros per usuari i més. Poquet, veritat? Doncs anem sumant ...

La viralitat de la comunicació

Si un fa feina amb una eina així és per a convertir-la en el focus de tota la comunicació, però clar si fas projectes amb altre gent hi ha una gran quantitat d'informació que directament ja no hi és, vendrà en forma de e-mail o xat amb el client o col·laborador. Si a més vols donar tota la transparència i comunicació al client, no pots limitar a tenir un compte de convidat (que a més està limitat en nombre segons la quantitat de comptes de pagament que tenguis). Així doncs, has de fer el que puguis per a que la gent que fa projectes amb tu o que t'ha comanat projectes faci servir Slack. Una vegada has fet el projecte el canal de comunicació sovint segueix obert: hi ha manteniment, consulta d'informació, ... Els 6 eur/mes per usuari ja no sols compten els empleats de l'empresa, ja han de començar a considerar que els clients hauran de tenir compte de pagament i que l'hauràs de pagar. Potser es podrà repercutir al projecte, però potser no.

Ja t'ho comences a pensar a l'hora de donar accés a la teva eina de comunicació. Tenir 100 clients implica pagar 600 €/mes, encara que no siguin actius. Una eina orientada a facilitar la comuniació t'està condicionant el poder comunicar-te sols per motius econòmics.

Hi ha pasta no problem

Però l'empresa va bé, i a més com que fem feina per empreses grans i solvents els hem convençut que es passin a Slack (a més ens donen una pasta per l'acció viral), de manera que ens pagaran el cost cada més i nosaltres refacturarem. Necessitam un compte per client, però no fa res, hi ha una cosa que es diu "Consolidated billing & administration", Amazon ho té i va beníssim per aquestes coses, et dius. Perfecte, fins que veis que és una opció premium i que tindrà un cost aproximat d'entre 49 i 99 dólars/mes per usuari. Si tens sort i no necessites això, el que segurament necessitaràs és el que diuen "compliance export", que és l'exportació de totes les comunicacions públiques i privades associades a un canal. Això sols et costarà uns 12 € per usuari i mes.

La hipoteca

Amb un res i no res entre que l'empresa creix i que creixen els projeces i els usuaris et veus en que o bé has de canviar l'estratègia de feina o bé has de començar a pagar, t'has hipotecat a 1000, 2000 €/mes, d'un moment a l'altra, d'un més a l'altra. Com et podies pensar que arribaries mai als 10.000 missatges o que per motius legals hauries de conservar la documentació del projecte?

La lletra petita

Quan signam un contracte sempre ens diuen que hem de llegir la lletra petita. En el nostre cas això es tradueix no sols en avaluar tècnicament el programa sinó en determinar els costs futurs si l'empresa creix. I pensem que el que una empesa cresqui normalment implica una etapa de ruptura, etapa en la qual els recursos s'han fet servir per crèixer. Si no pensam amb això el nostre creixement pot estar condicionat per les llicències d'un programa.

I si les coses van malament? Direm als nostres clients que els llevam accés al gestor de projectes? Això és un camí sense volta enrera. Hem de ser optimistes i pensar en els costs que tindrem si les coses van bé (i avaluar si ens convé pagar-los o no), però també ens hem de posar en el cas pitjor i veure com en podem sortir si les coses no van com suposàvem. Un conegut em contava com algunes empreses amigues seves van haver de tancar perquè entre altres coses no podien pagar les llicències de l'ERP que feien servir per dur la gestió.

Dir que no

És una feina ingrata. A tothom li agarada fer feina amb la darrera cosa de moda, amb el darrer gadget amb el darrer que ens ha de solucionar tots els problemes que tenim i fer-nos la vida més fàcil. Però hem de tenir el cap clar, hem d'avaluar, planificar i decidir. Fugir de les hipoteques!

Potser la combinació actual que fem servir ara: Redmine, Rhodecode, correu i telegram no estigui tan integrada, ni tengui aplicació móbil, però no ens condiciona la viabilitat actual ni futura de l'empresa, i això implica seguretat per als nostres clients no pagaran un sobrecost als projectes perquè nosaltres hem fet una tria que els condiciona i que l'empresa no tancarà si no pot pagar-se l'eina de moda.

I encara podem anar un poc més enllà? Què passa si les coses a ca'n Slack no vam bé? Tendràs tens de cercar-ne una alternativa? Què passarà amb les dades antigues?

Sóc passador de pena, i encara que hem de viure el present, la nostra obligació com a tècnics i consultors és aplicar-nos els mateixos consells que donaríem als nostres clients, i això vol dir intentar esbrinar un poc el futur.

Un futur condicionat per una llicència de programari on sóc un client captiu és un futur negre, que no recomanaria a un client o amic meu. Tot el que signifiqui aixo, es digui Slack o es digui qualsevol altra cosa, sí Atlassian t'estic mirant a tu, i a tu també GitHub, doncs és una opció que miraré d'evitar.

Gestió de riscs en diuen.