Webbutvecklingstriangeln

Alla våra kontrakt med våra kunder är löpande månatliga uppdrag. Mycket sällan driver vi ett fast projekt och garanterar nästan aldrig tidslinjen. Det kan låta skrämmande för vissa men problemet är att målet inte ska vara datumet för släpp, det ska vara affärsresultaten. Vårt jobb är att få våra kunders affärsresultat, inte genvägar för att göra lanseringsdatum. Som Healthcare.gov lär sig är det en väg som leder till missade förväntningar.

För att försöka behålla kundernas projekt i tid, vi delar upp kraven i måste ha (uppfyller affärsresultaten) och trevligt att ha (valfria förbättringar). Vi planerar inte heller att slutföra vid tidpunkten för utgåvan eftersom vi vet att det alltid kommer att behövas några ändringar.

Robert Patrick är VD för Doktorandlaboratorier, en byrå som designar, bygger och lanserar webbplatser för många Fortune 500-företag. Robert har kollat ​​på de svårigheter som Healthcare.gov har stött på och har anfört 5 viktiga orsaker till den misslyckade lanseringen.

  1. Bryt aldrig, aldrig Tid, kostnad och funktion Ställ in regel. Tänk på detta som en triangel, du måste välja en punkt att vara fixerad och de andra två variablerna. I den här världen kan nästan vad som helst skapas så länge det finns tillräckligt med tid och pengar. Den som bygger en webbapplikation bör dock välja framåt, vilket är högsta prioritet. Detta anger tonen och fokus för hur ett projekt ska startas. Till exempel,
    • Skulle den lanseras endast när specifika funktioner är klara (pengar och tid är varierande).
    • Bör den lanseras snabbt (pengar och funktioner är varierande).
    • Bör den lanseras med en budget i åtanke (tid och funktioner är varierande).
  2. Lanserar med mållinje i åtanke istället för startlinjen. Webbapplikationer bör ses som ett projekt som kommer starta och då utvecklas. Att bygga det som är viktigt och obligatoriskt för idag med tillväxt och utveckling i åtanke är alltid bättre än att bygga med avsikt att avsluta vid startpunkten.
  3. För många leverantörer inblandade. Det har rapporterats att Obamacare-webbplatsen hade närmare 55 leverantörer inblandade. Att lägga till flera leverantörer till något projekt kan vara en hal sluttning. Du kan nästan garantera att det kommer att finnas problem med filversionering, artfilavvikelser, art opinionavvikelser, projektavbrott, och listan fortsätter och fortsätter. Tänk om vi hade 55 senater som var och en hade till uppgift att lösa en del av det övergripande problemet.
  4. Information Architecture inte tas på allvar. Ofta kommer stora byråer att be leverantörer att lämna ett bud på en RFP och helt hoppa över informationsarkitekturprocessen och hoppa direkt in i utvecklingen utan att förstå eller komma överens om en omfattning. Det här är en enorm, ful, tidsödande, pengar att förlora, misstag. Det är oerhört värdefullt att arkitektera så mycket av applikationen som möjligt och vara beredd att vara smidig och flexibel när det gäller saker som inte kunde förutses innan du börjar programmera den (det här är som att bygga ett hus utan ritningar). Leverantörerna är avsedda att tappa budgeten och börja skära hörn om detta inte görs korrekt.
  5. Inte tillräckligt med tid för Kvalitetssäkring. Det är uppenbart att detta var en stor undergång till lanseringen av HealthCare.Gov. De arbetade med ett hårt lanseringsdatum (tiden är den fasta variabeln i triangeln i det här fallet) och funktionerna och budgeten borde ha ändrats för att möta lanseringsdatumet med tid för korrekt kvalitetssäkring inbyggd i planen. Detta är ett avgörande misstag och kostar förmodligen många människor sitt jobb.

Vad tror du?

Den här sidan använder Akismet för att minska spam. Läs om hur din kommentardata behandlas.