Web garapenerako triangelua

Gure bezeroekin ditugun kontratu guztiak hileko konpromiso etengabeak dira. Oso gutxitan egiten dugu proiektu finko bat eta ia inoiz ez dugu denbora-lerroa bermatzen. Batzuentzat beldurgarria suerta daiteke baina arazoa da helburua ez dela kaleratze data izan behar, negozioaren emaitzak izan behar lirateke. Gure lana bezeroen negozioen emaitzak lortzea da, ez lasterbideak abiarazteko datak egiteko. Healthcare.gov ikasten ari den heinean, galdutako itxaropenak ekarriko dituen bidea da.

Bezeroen proiektuak mantentzen saiatzeko garaiz, baldintzak must have (negozioaren emaitzak betetzea) eta nice have (aukerako hobekuntzak) bereizten ditugu. Era berean, ez dugu inolako programaziorik egin behar oharraren unean, badakigulako beti beharko direla aldaketa batzuk.

Robert Patrick-eko zuzendari nagusia da Doktorego laborategiak, Fortune 500 enpresa garrantzitsuenentzako webguneak diseinatu, eraiki eta abiarazten dituen agentzia. Robertek Healthcare.gov-ek izan dituen zailtasunak aztertzen aritu da eta huts egin duen 5 arrazoi nagusiak eman ditu.

  1. Inoiz, inoiz urratu Denbora, kostua eta funtzioa Ezarri araua. Pentsa ezazu triangelu bat dela, izan beharreko puntu bat aukeratu behar duzu konpondu eta beste bi aldagaia. Mundu honetan, ia edozer gauza sor daiteke, denbora eta diru nahikoa badago. Hala ere, web aplikazio bat eraikitzen duen edonork aukeratu beharko luke aurrez lehentasun handiena. Horrek proiektu bat abiarazteko modua eta ardatza ezartzen ditu. Adibidez,
    • Ezaugarri zehatzak egin ondoren bakarrik abiarazi beharko litzateke (dirua eta denbora aldakorrak dira).
    • Azkar abiaraziko balitz (dirua eta ezaugarriak aldakorrak dira).
    • Aurrekontua kontuan hartuta abiarazi behar da (denbora eta ezaugarriak aldakorrak dira).
  2. Rekin abian jartzea helmuga gogoan hasierako lerroaren ordez. Web aplikazioak egingo duten proiektu gisa ikusi beharko lirateke Hasi eta gero eboluzionatu. Gaur egun garrantzitsua eta nahitaezkoa dena eraikitzea hazkundea eta eboluzioa kontuan hartuta eraikitzea baino hobea da abiapuntuan amaitzeko asmoarekin eraikitzea baino.
  3. Saltzaile gehiegi inplikatuta. Jakinarazi dutenez, Obamacare webguneak 55 saltzaile inguru zituen. Edozein proiekturi saltzaile bat baino gehiago gehitzea labainkorra izan daiteke. Ia ziurtatu dezakezu fitxategien bertsioekin, artearen fitxategien desadostasunekin, artearen iritzien desadostasunekin, proiektuaren abandonuarekin arazoak egongo direla eta zerrenda aurrera jarraitzen du. Imajinatu arazo orokorraren zati bat ebazteko 55 senatu bagenituela bakoitza.
  4. Informazioaren arkitektura ez da serio hartu. Sarritan, agentzia handiek saltzaileei eskaera bat eskaintzea eskatuko diete eta Informazioaren Arkitektura prozesua erabat saltatuko dute garapenera jauzi egiteko esparrua ulertu edo adostu gabe. Hau denbora izugarria, itsusia da, denbora galtzen du, dirua galtzen du, akatsa da. Oso baliotsua da aplikazioa ahalik eta gehien diseinatu ahal izateko eta programatzen hasi aurretik ondo aurreikusi ezin ziren gauzetan arin eta malguak izateko prest egotea (plano bat gabeko etxea eraikitzea bezalakoa da). Saltzaileek aurrekontua agortu eta bazterrak mozten hasten dira hori behar bezala egiten ez bada.
  5. Ez dago denbora nahikoa Kalitatea ziurtatzea. Begi bistakoa da HealthCare.Gov abian jartzerakoan beherakada handia izan zela. Abiarazte data gogorrean ari ziren lanean (denbora triangeluaren aldagai finkoa da kasu honetan) eta ezaugarriak eta aurrekontua aldatu beharko lirateke abiarazte data betetzeko, planean txertatutako Kalitate Bermea egokia izan dadin. Akats funtsezkoa da eta ziurrenik jende askori kostatuko zaio bere lana.

Zer deritzozu?

Gune honek Akismet-ek spam erabiltzen du. Ikasi zure iruzkina nola prozesatu den.