Žiniatinklio kūrimo trikampis

Visos mūsų sutartys su klientais yra nuolatinės mėnesio užduotys. Labai retai mes vykdome fiksuotą projektą ir beveik niekada negarantuojame laiko juostos. Tai kai kam gali pasirodyti baisu, tačiau problema yra ta, kad tikslas turėtų būti ne išleidimo data, o verslo rezultatai. Mūsų darbas yra pasiekti, kad klientai gautų verslo rezultatus, o ne spartieji klavišai, kad nustatytumėte paleidimo datas. Kaip „Healthcare.gov“ mokosi, tai kelias, kuris privers praleisti lūkesčius.

Pabandyti išlaikyti klientų projektus laiku, mes atskiriame reikalavimus, kurie turi būti (atitikti verslo rezultatus) ir malonu turėti (neprivalomi patobulinimai). Mes taip pat niekada neplanuojame užbaigti jų išleidimo metu, nes žinome, kad visada reikės tam tikrų pakeitimų.

Robertas Patrickas yra bendrovės generalinis direktorius Daktaro laboratorijos, agentūra, kuri kuria, kuria ir kuria svetaines daugeliui geriausių „Fortune 500“ kompanijų. Robertas nuolat stebi sunkumus, su kuriais susidūrė „Healthcare.gov“, ir pateikė 5 pagrindines nesėkmingo paleidimo priežastis.

  1. Niekada, niekada nepažeiskite Laikas, kaina ir ypatumai Nustatykite taisyklę. Pagalvokite apie tai kaip apie trikampį, todėl turite pasirinkti vieną tašką nustatyta o kiti du kintamieji. Šiame pasaulyje galima sukurti beveik viską, jei tik pakanka laiko ir pinigų. Tačiau kiekvienas, kuriantis interneto programą, turėtų pasirinkti iš anksto, o tai yra didžiausias prioritetas. Tai nustato toną ir dėmesį tam, kaip projektas turėtų būti pradėtas. Pavyzdžiui,
    • Ar jis turėtų būti paleistas tik atlikus specifines savybes (pinigai ir laikas kinta).
    • Ar jis turėtų būti paleistas greitai (pinigai ir funkcijos yra skirtingi).
    • Ar jis turėtų būti pradėtas turint omenyje biudžetą (laikas ir funkcijos kinta).
  2. Paleidimas su finišo linija galvoje vietoj starto linijos. Interneto programos turėtų būti vertinamos kaip projektas, kuris tai padarys pradžia ir tada evoliucionuoti. Statyti tai, kas šiandien yra svarbu ir privaloma, turint galvoje augimą ir evoliuciją, visada yra geriau nei statyti ketinant pabaigti pradiniame taške.
  3. Per daug pardavėjų dalyvauja. Pranešama, kad „Obamacare“ svetainėje dalyvavo beveik 55 pardavėjai. Kelių pardavėjų pridėjimas prie bet kurio projekto gali būti slidus. Galite beveik garantuoti, kad kils problemų su failų versijomis, meno failų neatitikimais, meno nuomonių neatitikimais, projekto atsisakymu ir sąrašas tęsiasi. Įsivaizduokite, jei mes turėtume po 55 senatus, kuriems pavesta išspręsti dalį visos problemos.
  4. Informacija Architektūra nežiūrima rimtai. Dažnai didelės agentūros paprašys pardavėjų pateikti pasiūlymą dėl RFP ir visiškai praleisti informacinės architektūros procesą, pereinantį tiesiai į plėtrą, nesuprantant ir nesusitarus dėl taikymo srities. Tai yra didžiulė, negraži, laiko gaišimas, pinigų praradimas, klaida. Tai nepaprastai vertinga architektams tiek, kiek galite iš anksto, ir būkite pasirengę būti judrūs ir lankstūs tiems dalykams, kurių nebuvo galima gerai numatyti prieš pradedant programuoti (tai yra tarsi namo statyba be brėžinių). Pardavėjams lemia baigti biudžetą ir pradėti karpyti kampus, jei tai nėra padaryta teisingai.
  5. Nepakanka laiko kokybės užtikrinimas. Akivaizdu, kad tai buvo didelis žlugimas paleidus „HealthCare.Gov“. Jie dirbo sunkią paleidimo datą (šiuo atveju laikas yra fiksuotas trikampio kintamasis), o savybės ir biudžetas turėjo būti pakeisti, kad atitiktų paleidimo datą, kad laikas būtų tinkamas kokybės užtikrinimui, numatytam plane. Tai yra esminė klaida ir tikriausiai daugeliui žmonių kainuoja jų darbą.

Ką manote?

Ši svetainė naudoja "Akismet", kad sumažintų šlamštą. Sužinokite, kaip apdorojamas jūsų komentaras.