Webový vývojový trojúhelník

Všechny naše smlouvy s našimi klienty jsou průběžné měsíční smlouvy. Velmi zřídka sledujeme pevný projekt a zřídka garantujeme časovou osu. Pro někoho to může znít děsivě, ale problém je v tom, že cílem by nemělo být datum vydání, ale obchodní výsledky. Naším úkolem je přinášet našim klientům obchodní výsledky, nikoli používat zkratky pro stanovení dat spuštění. Jak se Healthcare.gov učí, tato cesta povede ke zmeškaným očekáváním.

Abychom se pokusili udržet projekty klientů včas, rozdělujeme požadavky na požadavky, které musíte mít (splnění obchodních výsledků) a hezké (nepovinná vylepšení). Také nikdy neplánujeme dokončení v době vydání, protože víme, že vždy budou potřeba nějaké změny.

Robert Patrick je generálním ředitelem společnosti PhD laboratoře, agentura, která navrhuje, vytváří a spouští webové stránky pro mnoho předních společností z Fortune 500. Robert sleduje potíže, do kterých Healthcare.gov narazil, a uvedl pět klíčových důvodů neúspěšného spuštění.

1. Nikdy nikdy neporušujte Čas, náklady a funkce Nastavit pravidlo. Představte si to jako trojúhelník; musíte vybrat jeden bod, který má být fixován, a další dvě proměnné. V tomto světě lze vytvořit téměř cokoliv, pokud je dostatek času a peněz. Každý, kdo vytváří webovou aplikaci, by si však měl předem vybrat, co je nejvyšší prioritou. To udává tón a zaměření pro to, jak by měl být projekt spuštěn. Například,
   • Mělo by být spuštěno pouze po dokončení konkrétních funkcí (peníze a čas jsou proměnlivé).
   • Mělo by být spuštěno rychle (peníze a funkce jsou variabilní).
   • Mělo by být spuštěno s ohledem na rozpočet (čas a funkce jsou variabilní).
2. Spouštění s cílová čára na mysli místo startovní čáry. Webové aplikace by měly být vnímány jako projekt, který bude Začít a vyvíjet se. Budování toho, co je pro dnešek nezbytné a povinné s ohledem na růst a vývoj, je vždy lepší.
3. Příliš mnoho prodejců jsou zapojeny. Bylo hlášeno, že na webu Obamacare bylo zapojeno téměř 55 prodejců. Přidání více dodavatelů k jakémukoli projektu může být skluzavka. Můžete téměř zaručit, že budou problémy s verzováním souborů, nesrovnalosti v uměleckých souborech, nesrovnalosti v názorech na umění, opuštění projektu atd. Představte si, že bychom měli 55 senátů, z nichž každý by měl za úkol vyřešit část problému.
4. Informační architektura se nebere vážně. Velké agentury často požádají dodavatele, aby předložili nabídku na RFP a úplně přeskočili proces informační architektury, který skočí přímo do vývoje, aniž by rozuměli nebo se dohodli na rozsahu. To je obrovská, ošklivá, časová ztráta, ztráta peněz, chyba. Je nesmírně cenné pro architekty co největší části aplikace předem a buďte připraveni být agilní a flexibilní ve věcech, které nebylo možné předvídat dříve, než ji začnete programovat (je to jako stavět dům bez plánů). Prodejci jsou předurčeni k vyčerpání rozpočtu a začnou škrtat, pokud to není provedeno správně.
5. Nedostatek času na Quality Assurance. To byl velký pád při spuštění HealthCare.Gov. Pracovali na pevném datu spuštění (čas je v tomto případě pevnou proměnnou trojúhelníku) a funkce a rozpočet měly být upraveny tak, aby odpovídaly datu spuštění s časem pro řádné zajištění kvality zabudované do plánu. To je zásadní chyba a pravděpodobně stojí spoustu lidí práci.