De trijehoek foar webûntwikkeling

Al ús kontrakten mei ús kliïnten binne trochgeande moanneblêdingen. Hiel selden folgje wy in fêst projekt en garandearje wy hast de tiidsline. Dat klinkt foar guon eng, mar it probleem is dat it doel de datum fan frijlitting net wêze moat, it moatte de bedriuwsresultaten wêze. Us taak is om saaklike resultaten fan ús kliïnten te krijen, gjin fluchtoetsen te nimmen om startdatums te meitsjen. As Healthcare.gov leart, is dat in paad dat sil liede ta miste ferwachtingen.

Om kliïntenprojekten te besykjen en te hâlden op tiid, wy skiede easken yn moatte hawwe (foldogge oan de bedriuwsresultaten) en leuk om te hawwen (opsjoneel ferbetterings). Wy planne ek net altyd foltôging op 'e tiid fan frijlitting, om't wy witte dat d'r altyd wat feroaringen nedich binne.

Robert Patrick is CEO fan PhD Labs, in buro dat websides ûntwerpt, bout en lanseart foar in protte Fortune 500-bedriuwen. Robert hat tabblêden hâlden oer de swierrichheden dy't Healthcare.gov yn 'e slach west hat en hat 5 wichtige redenen levere foar de mislearre lansearring.

  1. Nea, oait oertrêdzje de Tiid, kosten en funksje Regel ynstelle. Tink oan dit as in trijehoek, jo moatte ien punt kieze om te wêzen fêst en de oare twa fariabelen. Yn dizze wrâld kin sawat alles oanmakke wurde salang't der genôch tiid en jild is. Wa't in webapplikaasje bout, moat lykwols kieze foarút, dat is de heechste prioriteit. Dit stelt de toan en fokus foar hoe't in projekt moat wurde lansearre. Bygelyks,
    • Mocht it mar lansearre wurde as ienris spesifike funksjes binne dien (jild en tiid binne fariabel).
    • Mocht it fluch wurde lansearre (jild en funksjes binne fariabel).
    • Mocht it wurde lansearre mei in budzjet yn gedachten (tiid en funksjes binne fariabel).
  2. Launching mei de einstreep yn gedachten yn plak fan de startline. Webapplikaasjes moatte wurde sjoen as in projekt dat wol start en doe him ûntjout, Bouwen wat wichtich is en ferplicht foar hjoed mei groei en evolúsje yn gedachten is altyd better dan bouwe mei de bedoeling om te finishen op it begjinpunt.
  3. Tefolle ferkeapers belutsen. It is rapporteare dat de Obamacare-webside tichtby 55 belutsen ferkeaper hie. It tafoegjen fan meardere leveransiers oan elk projekt kin in glide helling wêze. Jo kinne hast garandearje dat d'r problemen binne mei bestânferzje, ôfwikingen fan art-bestannen, ôfwikingen fan art-opiny, ferlitten fan projekt, en de list giet oan en oan. Stel jo foar as wy 55 senaten hienen dy't elk taak hawwe om in diel fan it algemiene probleem op te lossen.
  4. Ynformaasje arsjitektuer net serieus nommen. Faak sille grutte ynstânsjes ferkeapers freegje in bod yn te tsjinjen op in RFP en folslein oerslaan oer it Ynformaasjearkitektuerproses dat direkt yn ûntwikkeling springt sûnder in omfang te begripen of yn te stimmen. Dit is in enoarme, ûnsjogge, tiidfergriemen, jildferlies, flater. It is heul weardefol foar arsjitekt safolle fan 'e applikaasje as jo kinne foarôfgeand wêze en ree wêze om wendber en fleksibel te wêzen op' e dingen dy't net goed kinne wurde foarsjoen foardat jo begjinne mei it programmearjen (dit is lykas it bouwen fan in hûs sûnder tekeningen). Oanbieders binne ornearre om sûnder budzjet te rinnen en hoeken te besunigjen as dit net goed wurdt dien.
  5. Net genôch tiid foar Kwaliteitssoarch, It is fanselssprekkend dat dit in grutte ûndergong wie foar de lansearring fan HealthCare.Gov. Se wurken oan in hurde lanseardatum (tiid is yn dit gefal de fêste fariabele fan 'e trijehoek) en de funksjes en budzjet soene moatte wizige wêze om te foldwaan oan de startdatum mei tiid foar juste kwaliteitssoarch ynboud yn it plan. Dit is in krúsjale flater en kostet wierskynlik in soad minsken har baan.

Wat tinksto?

Dizze side brûkt Akismet om spam te ferleegjen. Learje hoe't jo kommentaargegevens ferwurke wurde.