Tīmekļa izstrādes trijstūris

Visi mūsu līgumi ar klientiem ir ikmēneša līgumi. Ļoti reti mēs īstenojam noteiktu projektu un gandrīz nekad negarantējam laika grafiku. Dažiem tas var likties biedējoši, taču jautājums ir tāds, ka mērķim nevajadzētu būt izlaišanas datumam, bet gan biznesa rezultātiem. Mūsu uzdevums ir gūt klientu biznesa rezultātus, nevis veikt īsceļus, lai noteiktu izlaišanas datumus. Tā kā Healthcare.gov mācās, tas ir ceļš, kas novedīs pie cerību zaudēšanas.

Lai mēģinātu saglabāt klientu projektus laikā, mēs nošķiram prasības (jābūt biznesa rezultātiem) un jauki (izvēles papildinājumi). Mēs arī nekad neplānojam pabeigt izlaišanas laiku, jo mēs zinām, ka vienmēr būs nepieciešamas dažas izmaiņas.

Roberts Patriks ir uzņēmuma vadītājs PhD laboratorijas, aģentūra, kas izstrādā, izveido un izlaiž vietnes daudziem labākajiem Fortune 500 uzņēmumiem. Roberts seko līdzi grūtībām, ar kurām saskārās Healthcare.gov, un ir norādījis 5 galvenos neveiksmīgās palaišanas iemeslus.

  1. Nekad, nekad nepārkāpiet Laiks, izmaksas un funkcijas Iestatīt kārtulu. Iedomājieties to kā trīsstūri, jums jāizvēlas viens punkts noteikts un pārējie divi mainīgie. Šajā pasaulē var izveidot gandrīz visu, ja vien ir pietiekami daudz laika un naudas. Tomēr ikvienam, kurš būvē tīmekļa lietojumprogrammu, vajadzētu izvēlēties priekšā, kas ir augstākā prioritāte. Tas nosaka toni un uzmanību tam, kā projekts jāuzsāk. Piemēram,
    • Vai tas jāuzsāk tikai pēc tam, kad ir veiktas noteiktas funkcijas (nauda un laiks ir mainīgi).
    • Vai to vajadzētu sākt ātri (nauda un funkcijas ir mainīgas).
    • Vai tas jāuzsāk, ņemot vērā budžetu (laiks un funkcijas ir mainīgi).
  2. Uzsākšana ar finiša līnija sākuma līnijas vietā. Tīmekļa lietojumprogrammas jāuzskata par projektu, kas to darīs sākums un tad attīstīties. Veidot to, kas šodien ir svarīgs un obligāts, paturot prātā izaugsmi un evolūciju, vienmēr ir labāk, nekā celt ar nodomu pabeigt sākuma punktā.
  3. Pārāk daudz pārdevēju iesaistīti. Tiek ziņots, ka Obamacare vietnē bija iesaistīti gandrīz 55 pārdevēji. Vairāku piegādātāju pievienošana jebkuram projektam var būt slidena. Jūs gandrīz varat garantēt, ka būs problēmas ar failu versiju, mākslas failu neatbilstībām, mākslas viedokļu neatbilstībām, projekta atteikšanos, un sarakstu var turpināt. Iedomājieties, ja mums katram būtu 55 senāti, kuru uzdevums būtu atrisināt daļu no kopējās problēmas.
  4. Informācija Arhitektūra neuztver nopietni. Bieži vien lielas aģentūras lūdz pārdevējus iesniegt piedāvājumu par RFP un pilnībā izlaist Informācijas arhitektūras procesu, pārejot tieši uz attīstību, nesaprotot vai nevienojoties par darbības jomu. Tā ir milzīga, neglīta, laika izšķiešana, naudas zaudēšana, kļūda. Tas ir ārkārtīgi vērtīgi tik daudzai lietojumprogrammas arhitektūrai, cik ātri vien iespējams, un esiet gatavs būt veikls un elastīgs attiecībā uz lietām, kuras nevarēja labi prognozēt, pirms sākat to programmēt (tas ir tāpat, kā būvēt māju bez rasējumiem). Pārdevējiem ir paredzēts iztukšot budžetu un sākt griezt stūrus, ja tas netiek izdarīts pareizi.
  5. Nepietiek laika Kvalitātes nodrošināšana. Ir skaidrs, ka tas bija liels kritums, lai palaistu HealthCare.Gov. Viņi strādāja pie stingra palaišanas datuma (šajā gadījumā laiks ir trijstūra fiksētais mainīgais), un funkcijas un budžets bija jāmaina, lai laikus atbilstu palaišanas datumam, lai plānā iekļautu pareizu kvalitātes nodrošināšanu. Šī ir būtiska kļūda un, iespējams, daudziem cilvēkiem maksā darbu.

Ko jūs domājat?

Šī vietne izmanto Akismet, lai samazinātu surogātpastu. Uzziniet, kā tiek apstrādāts jūsu komentārs.