Webudviklingstrekanten

Alle vores kontrakter med vores kunder er løbende månedlige engagementer. Meget sjældent forfølger vi et fast projekt, og næsten aldrig garanterer vi tidslinjen. Det lyder måske skræmmende for nogle, men problemet er, at målet ikke skal være datoen for frigivelsen, det skal være forretningsresultaterne. Vores job er at få vores kunders forretningsresultater og ikke genveje for at lave lanceringsdatoer. Som Healthcare.gov lærer, er det en vej, der vil føre til ubesvarede forventninger.

At prøve at beholde klienters projekter en gang, vi adskiller krav i skal have (opfylder forretningsresultaterne) og rart at have (valgfri forbedringer). Vi planlægger heller ikke nogensinde færdiggørelse på tidspunktet for frigivelsen, da vi ved, at der altid vil være nogle ændringer nødvendige.

Robert Patrick er administrerende direktør for Ph.d.-laboratorier, et bureau, der designer, bygger og lancerer hjemmesider for mange Fortune 500-virksomheder. Robert har holdt øje med de vanskeligheder, som Healthcare.gov er stødt på, og har angivet 5 hovedårsager til den mislykkede lancering.

  1. Overtræd aldrig, aldrig Tid, pris og funktion Indstil regel. Tænk på dette som en trekant, du skal vælge et punkt at være fast og de to andre variabler. I denne verden kan næsten alt oprettes, så længe der er tid og penge nok. Enhver, der bygger en webapplikation, skal dog vælge foran, hvilket er den højeste prioritet. Dette sætter tonen og fokus for, hvordan et projekt skal lanceres. For eksempel,
    • Bør det kun lanceres, når specifikke funktioner er udført (penge og tid er variabel).
    • Skulle det lanceres hurtigt (penge og funktioner er variable).
    • Bør det lanceres med et budget i tankerne (tid og funktioner er variable).
  2. Lancering med målstregen i tankerne i stedet for startlinjen. Webapplikationer skal ses som et projekt, der vil starte og så udvikle sig. At opbygge det, der er vigtigt og obligatorisk i dag med vækst og udvikling i tankerne, er altid bedre end at bygge med den hensigt at afslutte ved startpunktet.
  3. For mange leverandører involveret. Det er blevet rapporteret, at Obamacare-webstedet havde tæt på 55 involverede leverandører. Tilføjelse af flere leverandører til ethvert projekt kan være en glat skråning. Du kan næsten garantere, at der vil være problemer med filversionering, artfilafvigelser, afvigelser mellem kunstudtalelser, opgivelse af projekt, og listen fortsætter og fortsætter. Forestil dig, hvis vi havde 55 senater, der hver havde til opgave at løse en del af det overordnede problem.
  4. Information Architecture ikke taget alvorligt. Ofte vil store agenturer bede leverandører om at afgive et bud på en RFP og helt springe over informationsarkitekturprocessen, der hopper lige ind i udvikling uden at forstå eller blive enige om et omfang. Dette er en enorm, grim, spild af tid, tab af penge, fejl. Det er ekstremt værdifuldt for arkitekten så meget af applikationen, som du kan på forhånd, og være parat til at være adræt og fleksibel i forhold til de ting, der ikke kunne forudsiges i god tid, før du begynder at programmere det (dette er som at bygge et hus uden tegninger). Leverandører er bestemt til at løbe tør for budget og begynde at skære hjørner, hvis dette ikke gøres korrekt.
  5. Ikke nok tid til Kvalitetssikring. Det er tydeligt, at dette var et stort fald i lanceringen af ​​HealthCare.Gov. De arbejdede på en hård lanceringsdato (tid er den faste variabel i trekanten i dette tilfælde), og funktionerne og budgettet skulle have været ændret for at opfylde lanceringsdatoen med tid til korrekt kvalitetssikring indbygget i planen. Dette er en afgørende fejl og koster sandsynligvis mange mennesker deres job.

Hvad mener du?

Dette websted bruger Akismet til at reducere spam. Lær, hvordan dine kommentardata behandles.