Neurrirako software proiektu batek gaizki amaitzen duenean, gutxitan da zorte txarragatik. Normalean lehen kode lerroa idatzi aurretik hartutako erabaki batengatik izaten da: prezioaren arabera aukeratu zen, ez zen kodearen jabetza eskatu, bilerara ideia buruan zela joan zen paperean beharrean. Hauek dira neurrirako software garapena kontratatzean garestien ateratzen diren bederatzi akatsak, eta bakoitza sinatu aurretik saihesten duen galdera zehatza.
Zergatik den garrantzitsuagoa hemen oker egotea beste erosketetan baino
Neurrirako softwarea ez da erosten, hartu egiten da. Urteetan bizi da, zure eragiketaren erdigunean sartzen da eta hornitzailez aldatu nahi duzun egunean deskubritzen duzu hasieran hartu zenituen erabakiek zenbat pisatzen zuten. Horregatik kontratazio akatsak ez dira lehen fakturan nabaritzen: sei, hamabi edo hogeita lau hilabetera nabaritzen dira, konpontzeko garesti direnean jada. Berri ona da ia guztiak garaiz egindako galderekin saihesten direla.
Gehien errepikatzen diren bederatzi akatsak
1. Prezio baxuenaren arabera aukeratzea
Hiru aurrekonturen aurrean, tentazioa txikienera jotzea da. Arazoa da softwarean prezio baxua ia inoiz ez dela eraginkortasuna: oraindik ikusten ez duzun murrizketa bat da. Edo benetakoa baino proiektu txikiagoa ulertu dute eta aldea "gehigarri" gisa agertuko da obraren erdian, edo ikusten ez denean mozten dute —testak, dokumentazioa, segurtasuna— eta sistemak demoan funtzionatzen du eta produkzioan hausten da.
Axola duena ez da lehen faktura, jabetzaren kostu osoa baizik: garapena, gehi mantentzea, gehi behar den egunean hornitzailez aldatzeak kostatzen duena. Galdetu hornitzaileari: "Zer sartzen du prezio honek testetan, dokumentazioan eta segurtasunean, eta zer geratzen da kanpoan?". Merkeena hori guztia kentzen duelako bada, ez da merkeagoa: epeka garestiagoa da.
2. Kodearen jabetza ez eskatzea
Hau da garestien ateratzen den akatsa eta jende gutxienek egiaztatzen dutena sinatu aurretik. Kontratuak esplizituki esaten ez badu iturburu kodea zurea dela, agian jabetzen ez zaren zerbait erabiltzeagatik ordaintzen ari zara. Emaitza betiko vendor lock-in-a da: haiek bakarrik ulertzen duten kodea, kontrolatzen ez duzun tokian ostatatua, hutsetik hasi gabe mugitzeko ezinezkoa.
Plantekian ñabardurarik gabe esaten dugu: kutxa beltzik gabe, vendor lock-in gabe. Kodea bezeroarena da, dokumentatuta eta eramangarria. Galdetu hornitzaileari: "Iturburu kodea nire jabetzakoa da, nik atzitzen dudan biltegi batean dago, eta beste talde batera eraman dezaket egunen batean nahi badut?". Jaso dadila idatziz.
3. Baldintza lausoekin iristea
"Eskaerak kudeatzeko zerbait nahi dugu" ez da baldintza bat, desio bat da. Zenbat eta lausoago iritsi, orduan eta gehiago imajinatzen du hornitzaile bakoitzak zerbait desberdina, orduan eta gehiago puzten dute batzuek eta mozten besteek, eta orduan eta konparagarriagoak dira gutxiago aurrekontuak. Anbiguotasuna ez da desagertzen: gero ordaintzen da, proiektuaren erdian irismen aldaketa gisa.
Ez da espezifikazio tekniko perfektu bat behar —hori taldearen lana da—, baina bai jakitea zein arazo konpontzen duzun, norentzat eta nola jakingo duzun konponduta dagoela. Galdetu zeure buruari bilera aurretik: "Bost esalditan deskriba dezaket sistemak zer egiten duen eta nori kentzen dion min zehatz bat?". Ezin baduzu, lehen entregagarria ez da kodea: diagnostiko bat da.
4. Dokumentaziorik eta testik ez eskatzea
Dokumentazioa eta testak dira norbaitek prezioa jaitsi nahi duenean mozten den lehen gauza, eta gero gehien faltako duzuna. Testik gabe, aldaketa bakoitza erruleta bat da: zerbait konpontzen duzu eta beste zerbait hausten duzu konturatu gabe. Dokumentaziorik gabe, ezagutza pertsona baten buruan bizi da, eta pertsona hori ez dagoen egunean, berriro eraiki zuenaren menpe zaude.
Uler, audita eta manten dezakezun kodea ez da luxu bat: aktibo bat izatearen eta mendekotasun bat izatearen arteko aldea da. Galdetu hornitzaileari: "Zein test estaldura entregatzen duzue eta zein dokumentazio geratzen zait beste talde batek zuek gabe jarraitu ahal izateko?".
5. Dena aurrez ordaintzea mugarririk gabe
Ehuneko ehun aurrez ordaintzeak zure kontrol puntu bakarra kentzen du. Eta azken mugarri bakar baten aurka ordaintzeak, alderantziz, arrisku osoa alde okerrean uzten du. Osasuntsua mugarrika ordaintzea da: ikusi, probatu eta onar ditzakezun entregagarri zehatzei lotutako zatiak hurrengo ordainketa askatu aurretik.
Horrek pizgarriak lerrokatzen ditu: hornitzaileak benetako aurrerapena frogatzen duenean kobratzen du, eta zuk zerbait bat ez badator gelditzeko gaitasuna mantentzen duzu. Galdetu hornitzaileari: "Nola egituratzen dira mugarrikako ordainketak, zein entregagarri zehatz dagokio bakoitzari eta zer gertatzen da mugarri batek adostutakoa betetzen ez badu?".
6. Eraiki aurretik ez diagnostikatzea
Software aurrekontua aurretiko diagnostikorik gabe eskatzea planorik gabe obra aurrekontua eskatzea bezalakoa da: hornitzaile bakoitzak zerbait desberdina imajinatzen du eta zenbakiak ez dira konparagarriak. Okerrago dena, batzuetan benetako arazoa ez da enkargatzera zindoazen softwarearekin konpontzen: prozesu bat antolatuz edo dagoeneko dituzun bi sistema integratuz konpontzen da.
Horregatik diagnostikatzen dugu proposatu aurretik. Diagnostiko labur batek eragiketa mapa, marruskadura non dagoen eta zerk duen benetako itzulkina jartzen ditu mahai gainean. Galdetu hornitzaileari: "Diagnostikorik egiten duzue aurrekontatu aurretik, ala zenbaki bat ematen didazue zuzenean?". Telefonoz emandako zenbaki bat, ezer galdetu gabe, bandera gorria da.
7. Demo eder bat produktu sendo batekin nahastea
Demo bat hamar minututan liluratzeko diseinatuta dago, gezurrezko datuekin eta bide zoriontsuarekin. Produkzioan dagoen produktu batek benetako datuei, erabiltzaile despistatuei, karga gailurrei, akatsei eta denboraren igarotzeari eutsi behar die. Gauza desberdinak dira, eta demoan ikusten dena da zehazki faltsutzeko errazena.
Produktu bat eusten duena interfazearen azpian dago: arkitektura, akatsen kudeaketa, segurtasuna, behagarritasuna. Galdetu hornitzaileari: "Zer gertatzen da honek gaizki eratutako datuak jasotzen dituenean, mila erabiltzaile aldi berean edo kanpo zerbitzu baten hutsegitea? Erakutsi iezadazu benetan martxan dagoen zerbait, ez prototipoa bakarrik".
8. Arrakasta nola neurtzen den ez definitzea
Hasieran inork ez badu adosten proiektua ondo atera dela zer den, amaieran alde bakoitzak bere bertsioa izango du eta elkarrizketa nork zer agindu zuenean amaituko da. "Funtziona dezala" ez da irizpide bat. "Eragiketa taldeak eskaerak denboraren erdian prozesa ditzala" edo "fakturazio akatsak %1etik behera murritz ditzala" bai.
Arrakasta termino neurgarrietan definitzeak lehentasunak ordenatzen ditu eta entrega objektibo bihurtzen du. Galdera bateratua abiaraztean: "Zein metrika zehatz mugitu behar da honek merezi izan duela esateko, eta nola neurtuko dugu?". Promesa magikorik gabe: benetako metrika bat, idatziz adostuta.
9. Gero sistema nork mantentzen duen ez galdetzea
Proiektua ez da entregatzen denean amaitzen: orduan hasten da bizitzen. Zuzendu beharreko akatsak egongo dira, eguneratu beharreko mendekotasunak, eskatu beharreko aldaketak. Hasieratik adosten ez baduzu nork mantentzen duen sistema, zein baldintzatan eta zein kostutan, arriskua duzu software bizi batekin eta hura zaintzen duen inorik gabe geratzeko, edo negoziatu ez zenituen baldintzetan egin zuenari lotuta.
Galdetu hornitzaileari: "Entregatu ondoren, nolakoa da mantentzea, zenbat kostatzen da, zein erantzun denbora dituzue eta zer gertatzen da beste talde batekin edo barnean mantentzea erabakitzen badut?". Erantzunak esaten dizu haien menpe egon zaitezen eraikitzen duten ala autonomoa izan zaitezen.
Lehen bilerara eramateko zerrenda laburra
Gauza bakar batekin geratzen bazara, izan bedi galdera multzo hau. Egin hornitzaileari sinatu aurretik eta zarata seinaletik oso azkar bereizten da:
- Jabetza: kodea nirea da, atzigarria eta eramangarria, idatziz?
- Kalitatea: zein test eta zein dokumentazio entregatzen dizkidazue?
- Ordainketak: nolakoak dira mugarriak eta zein entregagarri dagokio bakoitzari?
- Diagnostikoa: aurretiko analisirik dago ala zenbaki bat besterik ez didazue ematen?
- Errealitatea: produkzioan zerbait ikus dezaket, ez demo bat bakarrik?
- Arrakasta: zein metrika zehatzek neurtzen du honek funtzionatu duela?
- Ondoren: nola, zenbat kostatzen da eta norekin da mantentzea?
Galdera hauetako bat ere ez da erasokorra ez teknikoa. Bere eragiketaren barruan urteetan biziko den zerbait kontratatzen ari dela ulertzen duen edonork egingo lituzkeenak dira. Hornitzaile on batek eskertu egiten ditu, gaizki-ulertuak aurrezten dizkiotelako. Deseroso jartzen dituenak informazio baliotsua ematen dizu.
Antidotoa: proposatu aurretik diagnostikatzea
Akats hauetako ia guztiek sustrai bera dute: erabaki handiak informazio txikiarekin hartzea. Hornitzailea aukeratzen da zer nahi den jakin gabe, sinatzen da zer jabetzen den jakin gabe, eraikitzen da arrakasta nola neurtzen den jakin gabe. Antidotoa ez da teknikoa, metodozkoa baizik: gauzak mahai gainean jartzea konprometitu aurretik.
Horrela abiatzen dugu zehazki edozein neurrirako software garapen proiektu: proposatu aurretik diagnostikatzen dugu, kutxa beltzik eta vendor lock-in gabe, uler, audita eta manten dezakezun kodearekin. Kontratatzea balioesten ari bazara eta akats hauek hasieratik saihestu nahi badituzu, hitz egin dezagun zure eragiketaz eta benetan behar duzunaren —eta ez duzunaren— diagnostiko zintzo batetik hasiko gara.