Az ügyfeleinkkel kötött összes szerződésünk havonta folyamatos. Nagyon ritkán folytatunk fix projektet, és szinte soha nem garantáljuk az idővonalat. Ez egyesek számára ijesztően hangozhat, de az a kérdés, hogy a célnak nem a megjelenés dátumának, hanem az üzleti eredményeknek kell lennie. A mi feladatunk, hogy ügyfeleink üzleti eredményeket érjünk el, ne pedig parancsikonok segítségével állítsuk be az indulási dátumokat. Ahogy a Healthcare.gov tanul, ez az út elveszett elvárásokhoz vezet.
Megpróbálni megtartani az ügyfelek projektjeit időben, különválasztjuk a követelményeket a must have (megfelel az üzleti eredményeknek) és a nice to have (opcionális fejlesztések) között. Azt sem tervezzük, hogy a kiadáskor mindig elkészülnénk, mivel tudjuk, hogy mindig szükség lesz néhány változtatásra.
Robert Patrick a vezérigazgatója PhD Labs, egy ügynökség, amely számos vezető Fortune 500 vállalat számára tervez, épít és indít weboldalakat. Robert folyamatosan figyelemmel kíséri a Healthcare.gov által tapasztalt nehézségeket, és 5 fő okot adott a sikertelen indításra.
- Soha, soha ne sértsd meg a Idő, költség és jellemző Szabály beállítása. Gondoljon erre, mint háromszögre, egy pontot kell választania rögzített és a másik két változó. Ebben a világban szinte bármi létrehozható, amíg van elegendő idő és pénz. Bárki, aki webalkalmazást épít, elölről válasszon, ami a legfontosabb. Ez adja meg a hangot és a hangsúlyt annak, hogyan kell egy projektet elindítani. Például,
- Csak akkor kell elindítani, ha bizonyos jellemzők megtörténnek (a pénz és az idő változó).
- Gyorsan be kell-e indítani (a pénz és a funkciók változóak).
- Ha költségvetését szem előtt tartva kell elindítani (az idő és a jellemzők változóak).
- Indítás a célvonal a kezdő vonal helyett szem előtt tartva. A webalkalmazásokat olyan projektnek kell tekinteni, amelyik megteszi kezdet és azután fejlődik. A ma fontos és kötelező megépítése a növekedés és az evolúció szem előtt tartásával mindig jobb, mint a kiindulási pont befejezésének szándéka.
- Túl sok eladó magában foglal. Beszámoltak arról, hogy az Obamacare webhelyén közel 55 eladó vett részt. Több szállító hozzáadása bármely projekthez csúszós lehet. Szinte garantálhatja, hogy problémák merülnek fel a fájlverzióval, az art fájlok eltéréseivel, a művészeti vélemények eltéréseivel, a projekt elhagyásával, és a lista folytatódik. Képzelje el, ha 55 szenátusunk lenne, akiknek feladata lenne a teljes probléma egy részének megoldása.
- Information Architecture nem veszik komolyan. Gyakran a nagy ügynökségek arra kérik az eladókat, hogy nyújtsanak be ajánlatot egy RFP-re, és teljesen átugorják az információs architektúra folyamatát, amely közvetlenül a fejlesztésbe ugrik, anélkül, hogy megértenék vagy megállapodnának a hatókörben. Ez hatalmas, csúnya, időpazarlás, pénzvesztés, hiba. Rendkívül értékes az alkalmazás annyi részének építész számára, amennyit csak tud előre, és felkészülhet arra, hogy mozgékony és rugalmas legyen azokban a dolgokban, amelyeket nem lehetett előre megjósolni, mielőtt elkezdené programozni (ez olyan, mintha házat tervrajz nélkül építenénk). Az árusok elfogynak a költségvetésből, és ha nem ezt teszik helyesen, elkezdik a sarkukat csökkenteni.
- Nincs elég idő Quality Assurance. Nyilvánvaló, hogy ez nagy bukás volt a HealthCare.Gov elindításában. Kemény indítási napon dolgoztak (ebben az esetben az idő a háromszög fix változója), és a jellemzőket és a költségvetést módosítani kellett volna, hogy a tervbe beépített megfelelő minőségbiztosítás érdekében időben megfeleljenek az indulás dátumának. Ez döntő hiba, és valószínűleg sok embernek kerül a munkájába.
