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 az, hogy ügyfeleink üzleti eredményeket érjünk el, ne pedig parancsikonok segítségével állítsuk be az indulási dátumokat. Amint az 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üljön, 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 az é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 tervrajzok 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.
