Ja fa temps que hi ha moltes coses relacionades amb la meva feina que no em quadren. Algunes d'elles es poden fer extensives a altres feines, mentre que altres potser son més exclusives de la informàtica. He provat alguns cops d'escriure-ho, en part per compartir-ho, en part per posar en ordre les idees. Però sempre m'he acabat embolicant, perquè hi ha diversos factors que es van entrecreuant i em disperso a l'abordar-los. Avui intento una aproximació diferent, centrant-me en aspectes més concrets i tirant endavant, encara que sigui amb simplificacions. Potser, si ho vull deixar tot ben lligat d'un cop em quedaré a mitges altra vegada. Si algú que no soc jo llegeix això, voldrà dir que he quedat prou satisfet del resultat (o que m'han piratejat la clau del bloc).
El tema d'aquesta entrada és l'antiga tensió entre artesania i industrialització, aplicada a la informàtica a mida. Entenc per informàtica a mida els desenvolupaments personalitzats que es fan per a que una empresa en concret (o institució, entitat, organització, etc.) millori alguns dels seus processos. Així doncs, deixo de banda els productes estàndard que no es desenvolupen per un client concret, encara que, segurament, molts d'ells s'acabaran utilitzant per desenvolupar els esmentats sistemes.
En aquest context, l'artesania la representa el que podríem denominar la informàtica de capçalera. Es tracta d'un model en el que els informàtics formen part de l'estructura a la que cal donar suport (empresa, organització, etc.). Evidentment, els usuaris corresponents fan la feina, però els que desenvolupen estan en contacte directe amb ells, coneixen quina és la seva manera de treballar i quins són els seus problemes quotidians.
La banda de la industrialització la representen les fàbriques de software. Els usuaris tenen una necessitat i criden a un especialista que els farà l'eina adequada. Per fer-la, es usuaris descriuen el que necessiten i el proveïdor els retorna una descripció del que els proposa com a solució, junt amb un preu tancat del que costarà i un termini d'entrega. El proveïdor atén peticions de molts clients diferents i crea el que s'ha especificat per a cada un d'ells, entregant el producte que es correspon al que s'ha acordat.
Quan jo vaig aterrar en aquest món (i ja ha plogut força des de llavors), la balança s'inclinava cap a la informàtica de capçalera. Jo he estat sempre en una empresa de serveis, però estava integrat en l'estructura del client. Els departaments d'informàtica eren grans i tenies tracte amb els qui utilitzaven els sistemes que es desenvolupaven. Podies acabar ajudant a configurar la impressora d'un usuari de l'altra punta del país, encara que no tingués res a veure amb el que era pròpiament la teva feina.
Un usuari capriciós podia fer ballar el cap als desenvolupadors, perquè podien no tancar-se mai els requeriments. Com que no hi havia una percepció clara de que allò estava suposant un cost, s'anava tirant de veta sense un control excessiu. El resultat final depenia molt del sentit comú del qui demanava la feina i de la perícia i experiència de qui l'executava. En aquestes condicions, la documentació del que hi havia era molt difícil ja que els sistemes canviaven massa ràpid. Per això, el coneixement dels components d'un equip era difícil de substituir.
Ara la balança ha caigut cap al costat oposat. Es parteix de la base de que una aplicació informàtica es pot tractar com un conjunt de peces mecàniques que s'acoblen per cobrir les necessitats del client, o com un vestit que depèn només de les mides de qui l'ha de dur i del teixit i color que vulgui. Una persona del proveïdor s'encarrega d'examinar totes els requeriments que presenta el client i de presentar una descripció del que s'obtindrà, amb un pressupost i uns terminis tancats. Un cop aprovada la comanda, uns operaris qualificats creen o adapten les peces existents en el mercat per obtenir el producte contractat, que s'entrega amb tota la documentació necessària. Com que tot està estandarditzat, qualsevol fàbrica és equivalent a una altra i es pot escollir la més barata en cada ocasió, perquè són perfectament bescanviables.
Vist sobre el paper, és molt més eficient el plantejament industrial que l'artesanal. Pel proveïdor, la fàbrica atendrà les necessitats de molts clients diferents, de forma que li serà més fàcil mantenir un ritme estable de feina. Si alguna "peça" es necessita per més d'un client, es podrà reaprofitar part de la feina, permetent abaratir el resultat final.
Des del punt de vista de qui s'encarrega de comprar dins el client, com que el que s'encomana és quelcom tancat, no s'anirà fent sobre la marxa i eternitzant sota els capricis del sol·licitant, que serà molt conscient que demanar alguna cosa més tindrà un cost addicional, sobretot si no ho demana a temps. Tampoc estarà lligat a un proveïdor concret, ja que l'impacte del canvi serà mínim.
A la pràctica, quan hom es compra un vestit, sap perfectament per a que el vol i, el més probable, és que l'usi sempre per vestir-se. Com a molt se'ls haurà de pujar la vora o eixamplar la cintura. En el cas de les aplicacions informàtiques, sovint el llenguatge dels qui descriuen els requeriments i dels qui l'interpreten són diferents. Tampoc és estrany que l'usuari no tingui una idea clara del que vol, sinó només dels problemes amb que es troba, sense saber ben bé quines solucions poden ser tècnicament millors o, simplement viables. Així, es freqüent que a l'elaborar la solució sorgeixin dubtes i, coses que en un principi semblaven d'una manera, acabin sent d'una altra, de forma que el producte no sigui exactament el que es va descriure. O, pitjor encara, que enlloc de dubtes hi hagi malentesos i el producte sigui el que es va descriure, però que no serveixi per al que es volia. Llavors és quan apareixen els canvis d'abast i les reclamacions sobre si el que s'ha fet és el que es va vendre o no.
D'altra banda, en molts casos les necessitats que han de cobrir les aplicacions a mida van canviant, ja sigui per adaptacions del negoci, perquè tecnològicament són possibles més coses, perquè l'experiència fa veure que el què podia semblar molt útil no ho és tant i, en canvi altres funcionalitats que no s'havien tingut en compte sí que millorarien molt els processos, etc. L'explicació d'aquestes petites adaptacions sol partir de la base de que ja se sap com funcionen l'usuari i el sistema, per la qual cosa, la possibilitat de malentesos és encara més gran.
Per tots aquests motius, és molt difícil trobar on és la línia entre el que és un canvi o el que és un error. Si el model és el de l'informàtic de capçalera, un cop detectat el problema el que es farà serà mirar la manera més ràpida i segura d'arreglar-ho, passant fins a cert punt a segon pla el veure qui tenia la raó. I això serà així perquè el cap de tots plegats acabarà sent el mateix i el que voldrà es que tot s'arregli com abans millor. En canvi, una fàbrica de software és un negoci diferent. Cobra per feina feta i, si el que s'ha de fer és una altra feina, ho voldrà cobrar apart. Així doncs, prenen molta importància les justificacions i el recull de proves per les dues parts, de cara a dilucidar de qui és la responsabilitat de que hagi aparegut el problema.
Aquest plantejament obliga al client i al proveïdor a muntar estructures dedicades a gestionar aquestes diferències. Molt sovint un objectiu principal d'aquestes estructures és obtenir el major marge en el cas del proveïdor i estalviar el màxim possible en el client. Donat que les xifres són faves comptades i la satisfacció del client és més difícil d'objectivar, aquesta darrera pot quedar en un segon pla. En un altre moment caldria veure també com afecta a tot plegat el tractament actual dels objectius, però ho deixo per una altra entrada del bloc.
Portant les coses a l'extrem, de banda del proveïdor es pot arribar a treballar suposant que qualsevol desenvolupador és bescanviable. Com que el marge és important i el model parteix de la premissa de que representa un estalvi, es contracta cada cop personal amb sous més baixos per fer la feina, deslocalitzant si cal a llocs amb nivells de vida més baixos. Això fa que qui desenvolupa tingui menys perspectiva de la finalitat del que està fent, tant pel sou baix, que sol implicar una menor experiència, com per la pèrdua total de contacte amb l'usuari. Tampoc té una clara consciència del que pot representar una equivocació. De fet, se l'avaluarà per si ha fet el que estava estipulat en el menor temps possible, passant a un segon pla si s'adapta totalment a les necessitats de l'usuari. Quan quelcom va malament, és posa més èmfasi la justificació de que responsabilitat és d'altri que en la solució del problema.
L'extrem en la banda del client el representa, de forma semblant, una capa de control del proveïdor que tingui com a objectiu principal reduir costos, i no tant centrada en les necessitats concretes de l'usuari. Sobre el paper, només cal vetllar pel seguiment dels procediments i marcar tota una sèrie d'indicadors que mesurin el que es fa. I, a partir d'aquí, apareixen les penalitzacions, que rebaixen el que es paga si no s'assoleixen certs requisits preestablerts. La mesura del paràmetres que estableixen les penalitzacions implica tenir tota una sèrie de regles del joc, i d'eines de seguiment, que permetin controlar si les condicions estipulades s'aconsegueixen. Es podria donar el cas de que una fita s'hagi complert, però que, per no haver seguit correctament el procediment de notificació corresponent, s'apliqui igualment la penalització, passant les del regles de joc per sobre de l'objectiu que pretenen cobrir.
Com ja he dit al principi, he anat fent moltes simplificacions. El millor, sens dubte, és trobar un punt intermedi entre ambdós models. Però crec que la base hauria de ser la informàtica de capçalera, afegint-hi el rigor d'unes especificacions ben fetes, però mantenint-la sempre dins l'estructura a la que dóna suport.
És cert que el temps tendeix a fer-nos oblidar els aspectes negatius i a fer prevaldre el positius. L'informàtic de capçalera pot ser que doni moltes voltes abans d'arribar a bon port. Les voltes que doni dependran, a més, de la seva perícia i del sentit comú del destinatari de la feina. I segurament tindrà ineficiències, perquè es possible que perdi el temps en floritures que no seran imprescindibles, per posar-se massa en el lloc d'un usuari que li és més o menys proper. Però, si va bé, coneixerà el negoci, anticiparà problemes i tindrà molta més capacitat de reacció, segurament amb un temps de resposta molt més baix.
De tota manera, el que per mi decanta la balança és el fet de que, en el model de fàbrica de software, cada un dels actors té un objectiu diferent i el sistema funciona mitjançant un equilibri de forces que es van contrarestant. Això fa que s'hagin d'esmerçar molts esforços en les tasques provocades per les tensions generades. I aquest temps és intrínsec al model, hi serà encara que tot vagi bé. A més, posats a dedicar més temps del necessari, li veig més la utilitat si és en refer coses o atendre capricis de l'usuari, que en anar justificant tot el que es va fent.
El tema d'aquesta entrada és l'antiga tensió entre artesania i industrialització, aplicada a la informàtica a mida. Entenc per informàtica a mida els desenvolupaments personalitzats que es fan per a que una empresa en concret (o institució, entitat, organització, etc.) millori alguns dels seus processos. Així doncs, deixo de banda els productes estàndard que no es desenvolupen per un client concret, encara que, segurament, molts d'ells s'acabaran utilitzant per desenvolupar els esmentats sistemes.
En aquest context, l'artesania la representa el que podríem denominar la informàtica de capçalera. Es tracta d'un model en el que els informàtics formen part de l'estructura a la que cal donar suport (empresa, organització, etc.). Evidentment, els usuaris corresponents fan la feina, però els que desenvolupen estan en contacte directe amb ells, coneixen quina és la seva manera de treballar i quins són els seus problemes quotidians.
La banda de la industrialització la representen les fàbriques de software. Els usuaris tenen una necessitat i criden a un especialista que els farà l'eina adequada. Per fer-la, es usuaris descriuen el que necessiten i el proveïdor els retorna una descripció del que els proposa com a solució, junt amb un preu tancat del que costarà i un termini d'entrega. El proveïdor atén peticions de molts clients diferents i crea el que s'ha especificat per a cada un d'ells, entregant el producte que es correspon al que s'ha acordat.
Quan jo vaig aterrar en aquest món (i ja ha plogut força des de llavors), la balança s'inclinava cap a la informàtica de capçalera. Jo he estat sempre en una empresa de serveis, però estava integrat en l'estructura del client. Els departaments d'informàtica eren grans i tenies tracte amb els qui utilitzaven els sistemes que es desenvolupaven. Podies acabar ajudant a configurar la impressora d'un usuari de l'altra punta del país, encara que no tingués res a veure amb el que era pròpiament la teva feina.
Un usuari capriciós podia fer ballar el cap als desenvolupadors, perquè podien no tancar-se mai els requeriments. Com que no hi havia una percepció clara de que allò estava suposant un cost, s'anava tirant de veta sense un control excessiu. El resultat final depenia molt del sentit comú del qui demanava la feina i de la perícia i experiència de qui l'executava. En aquestes condicions, la documentació del que hi havia era molt difícil ja que els sistemes canviaven massa ràpid. Per això, el coneixement dels components d'un equip era difícil de substituir.
Ara la balança ha caigut cap al costat oposat. Es parteix de la base de que una aplicació informàtica es pot tractar com un conjunt de peces mecàniques que s'acoblen per cobrir les necessitats del client, o com un vestit que depèn només de les mides de qui l'ha de dur i del teixit i color que vulgui. Una persona del proveïdor s'encarrega d'examinar totes els requeriments que presenta el client i de presentar una descripció del que s'obtindrà, amb un pressupost i uns terminis tancats. Un cop aprovada la comanda, uns operaris qualificats creen o adapten les peces existents en el mercat per obtenir el producte contractat, que s'entrega amb tota la documentació necessària. Com que tot està estandarditzat, qualsevol fàbrica és equivalent a una altra i es pot escollir la més barata en cada ocasió, perquè són perfectament bescanviables.
Vist sobre el paper, és molt més eficient el plantejament industrial que l'artesanal. Pel proveïdor, la fàbrica atendrà les necessitats de molts clients diferents, de forma que li serà més fàcil mantenir un ritme estable de feina. Si alguna "peça" es necessita per més d'un client, es podrà reaprofitar part de la feina, permetent abaratir el resultat final.
Des del punt de vista de qui s'encarrega de comprar dins el client, com que el que s'encomana és quelcom tancat, no s'anirà fent sobre la marxa i eternitzant sota els capricis del sol·licitant, que serà molt conscient que demanar alguna cosa més tindrà un cost addicional, sobretot si no ho demana a temps. Tampoc estarà lligat a un proveïdor concret, ja que l'impacte del canvi serà mínim.
A la pràctica, quan hom es compra un vestit, sap perfectament per a que el vol i, el més probable, és que l'usi sempre per vestir-se. Com a molt se'ls haurà de pujar la vora o eixamplar la cintura. En el cas de les aplicacions informàtiques, sovint el llenguatge dels qui descriuen els requeriments i dels qui l'interpreten són diferents. Tampoc és estrany que l'usuari no tingui una idea clara del que vol, sinó només dels problemes amb que es troba, sense saber ben bé quines solucions poden ser tècnicament millors o, simplement viables. Així, es freqüent que a l'elaborar la solució sorgeixin dubtes i, coses que en un principi semblaven d'una manera, acabin sent d'una altra, de forma que el producte no sigui exactament el que es va descriure. O, pitjor encara, que enlloc de dubtes hi hagi malentesos i el producte sigui el que es va descriure, però que no serveixi per al que es volia. Llavors és quan apareixen els canvis d'abast i les reclamacions sobre si el que s'ha fet és el que es va vendre o no.
D'altra banda, en molts casos les necessitats que han de cobrir les aplicacions a mida van canviant, ja sigui per adaptacions del negoci, perquè tecnològicament són possibles més coses, perquè l'experiència fa veure que el què podia semblar molt útil no ho és tant i, en canvi altres funcionalitats que no s'havien tingut en compte sí que millorarien molt els processos, etc. L'explicació d'aquestes petites adaptacions sol partir de la base de que ja se sap com funcionen l'usuari i el sistema, per la qual cosa, la possibilitat de malentesos és encara més gran.
Per tots aquests motius, és molt difícil trobar on és la línia entre el que és un canvi o el que és un error. Si el model és el de l'informàtic de capçalera, un cop detectat el problema el que es farà serà mirar la manera més ràpida i segura d'arreglar-ho, passant fins a cert punt a segon pla el veure qui tenia la raó. I això serà així perquè el cap de tots plegats acabarà sent el mateix i el que voldrà es que tot s'arregli com abans millor. En canvi, una fàbrica de software és un negoci diferent. Cobra per feina feta i, si el que s'ha de fer és una altra feina, ho voldrà cobrar apart. Així doncs, prenen molta importància les justificacions i el recull de proves per les dues parts, de cara a dilucidar de qui és la responsabilitat de que hagi aparegut el problema.
Aquest plantejament obliga al client i al proveïdor a muntar estructures dedicades a gestionar aquestes diferències. Molt sovint un objectiu principal d'aquestes estructures és obtenir el major marge en el cas del proveïdor i estalviar el màxim possible en el client. Donat que les xifres són faves comptades i la satisfacció del client és més difícil d'objectivar, aquesta darrera pot quedar en un segon pla. En un altre moment caldria veure també com afecta a tot plegat el tractament actual dels objectius, però ho deixo per una altra entrada del bloc.
Portant les coses a l'extrem, de banda del proveïdor es pot arribar a treballar suposant que qualsevol desenvolupador és bescanviable. Com que el marge és important i el model parteix de la premissa de que representa un estalvi, es contracta cada cop personal amb sous més baixos per fer la feina, deslocalitzant si cal a llocs amb nivells de vida més baixos. Això fa que qui desenvolupa tingui menys perspectiva de la finalitat del que està fent, tant pel sou baix, que sol implicar una menor experiència, com per la pèrdua total de contacte amb l'usuari. Tampoc té una clara consciència del que pot representar una equivocació. De fet, se l'avaluarà per si ha fet el que estava estipulat en el menor temps possible, passant a un segon pla si s'adapta totalment a les necessitats de l'usuari. Quan quelcom va malament, és posa més èmfasi la justificació de que responsabilitat és d'altri que en la solució del problema.
L'extrem en la banda del client el representa, de forma semblant, una capa de control del proveïdor que tingui com a objectiu principal reduir costos, i no tant centrada en les necessitats concretes de l'usuari. Sobre el paper, només cal vetllar pel seguiment dels procediments i marcar tota una sèrie d'indicadors que mesurin el que es fa. I, a partir d'aquí, apareixen les penalitzacions, que rebaixen el que es paga si no s'assoleixen certs requisits preestablerts. La mesura del paràmetres que estableixen les penalitzacions implica tenir tota una sèrie de regles del joc, i d'eines de seguiment, que permetin controlar si les condicions estipulades s'aconsegueixen. Es podria donar el cas de que una fita s'hagi complert, però que, per no haver seguit correctament el procediment de notificació corresponent, s'apliqui igualment la penalització, passant les del regles de joc per sobre de l'objectiu que pretenen cobrir.
Com ja he dit al principi, he anat fent moltes simplificacions. El millor, sens dubte, és trobar un punt intermedi entre ambdós models. Però crec que la base hauria de ser la informàtica de capçalera, afegint-hi el rigor d'unes especificacions ben fetes, però mantenint-la sempre dins l'estructura a la que dóna suport.
És cert que el temps tendeix a fer-nos oblidar els aspectes negatius i a fer prevaldre el positius. L'informàtic de capçalera pot ser que doni moltes voltes abans d'arribar a bon port. Les voltes que doni dependran, a més, de la seva perícia i del sentit comú del destinatari de la feina. I segurament tindrà ineficiències, perquè es possible que perdi el temps en floritures que no seran imprescindibles, per posar-se massa en el lloc d'un usuari que li és més o menys proper. Però, si va bé, coneixerà el negoci, anticiparà problemes i tindrà molta més capacitat de reacció, segurament amb un temps de resposta molt més baix.
De tota manera, el que per mi decanta la balança és el fet de que, en el model de fàbrica de software, cada un dels actors té un objectiu diferent i el sistema funciona mitjançant un equilibri de forces que es van contrarestant. Això fa que s'hagin d'esmerçar molts esforços en les tasques provocades per les tensions generades. I aquest temps és intrínsec al model, hi serà encara que tot vagi bé. A més, posats a dedicar més temps del necessari, li veig més la utilitat si és en refer coses o atendre capricis de l'usuari, que en anar justificant tot el que es va fent.
Cap comentari:
Publica un comentari a l'entrada