Trikotnik spletnega razvoja

Vse naše pogodbe z našimi strankami so stalne mesečne pogodbe. Zelo redko se ukvarjamo s fiksnim projektom in skoraj nikoli ne zagotovimo časovnice. Nekaterim se to morda zdi zastrašujoče, vprašanje pa je, da cilj ne sme biti datum izdaje, temveč poslovni rezultati. Naša naloga je, da našim strankam zagotovimo poslovne rezultate, ne pa da uporabljamo bližnjice do datumov uvedbe. Ko se Healthcare.gov uči, je to pot, ki bo vodila do zgrešenih pričakovanj.

Poskusiti obdržati projekte strank pravočasno, zahteve ločimo na must have (izpolnjevanje poslovnih rezultatov) in lepo, da jih imamo (neobvezne izboljšave). Prav tako nikoli ne načrtujemo zaključka v času izdaje, saj vemo, da bodo vedno potrebne nekatere spremembe.

Robert Patrick je izvršni direktor družbe Doktorski laboratoriji, agencija, ki načrtuje, gradi in uvaja spletna mesta za številna najboljša podjetja Fortune 500. Robert je spremljal težave, s katerimi se je srečal Healthcare.gov, in navedel 5 ključnih razlogov za neuspešen zagon.

  1. Nikoli, nikoli ne krši Čas, stroški in značilnosti Nastavite pravilo. Pomislite na to kot na trikotnik, izbrati morate eno točko Všita in drugi dve spremenljivki. Na tem svetu je mogoče ustvariti skoraj vse, če je dovolj časa in denarja. Vendar bi moral vsak, ki gradi spletno aplikacijo, vnaprej izbrati, kar je največja prednost. To določa ton in osredotočenost na začetek projekta. Na primer
    • Če bi ga bilo mogoče zagnati šele, ko se izvedejo določene funkcije (denar in čas sta različna).
    • Bi ga bilo treba hitro zagnati (denar in funkcije so različni).
    • Ali bi ga bilo treba začeti z mislijo na proračun (čas in funkcije so različni).
  2. Zagon z ciljna črta namesto štartne črte. Na spletne aplikacije je treba gledati kot na projekt, ki bo Začetek in nato razvijajo. Graditi tisto, kar je danes pomembno in obvezno z mislijo na rast in razvoj, je vedno boljše kot graditi z namenom, da zaključimo na izhodišču.
  3. Preveč prodajalcev vključeni. Poročali so, da je na spletnem mestu Obamacare sodelovalo blizu 55 prodajalcev. Dodajanje več prodajalcev kateremu koli projektu je lahko drsanje. Skoraj lahko zagotovite, da bodo prišlo do težav z različicami datotek, neskladji z umetniškimi datotekami, neskladji z umetniškimi mnenji, opuščanjem projekta in seznam se lahko nadaljuje. Predstavljajte si, če bi imeli po 55 senatov nalogo, da rešijo del celotnega problema.
  4. Informacijska arhitektura ne jemlje resno. Velike agencije pogosto prodajalce prosijo, naj oddajo ponudbo za RFP in popolnoma preskočijo postopek informacijske arhitekture, ki skoči naravnost v razvoj, ne da bi se razumeli ali dogovorili o obsegu. To je ogromno, grdo, zapravljanje časa, izguba denarja, napaka. Izjemno dragoceno je, da vnaprej oblikujete čim več aplikacij in ste pripravljeni na gibčnost in prilagodljivost pri stvareh, ki jih ni mogoče dobro napovedati, preden jih začnete programirati (to je kot gradnja hiše brez načrtov). Prodajalcem je namenjeno, da jim zmanjka proračuna in začnejo rezati vogale, če to ni storjeno pravilno.
  5. Ni dovolj časa za Zagotavljanje kakovosti. Očitno je, da je bil to velik propad ob uvedbi HealthCare.Gov. Delali so na datum trdega zagona (v tem primeru je čas fiksna spremenljivka trikotnika), funkcije in proračun pa bi morali spremeniti tako, da bo datum zagona časovno ustrezen za pravilno zagotavljanje kakovosti, vgrajeno v načrt. To je ključna napaka in verjetno veliko ljudi stane službe.

Kaj menite?

Ta stran uporablja Akismet za zmanjšanje nezaželene pošte. Preberite, kako se vaš komentar obravnava.