Die Webontwikkelingsdriehoek

Al ons kontrakte met ons kliënte is deurlopend maandeliks. Baie selde volg ons 'n vaste projek en waarborg ons die tydlyn amper nooit. Dit klink miskien vir sommige eng, maar die probleem is dat die doel nie die datum van vrylating moet wees nie, maar dat dit die besigheidsresultate moet wees. Ons taak is om ons kliënte se besigheidsresultate te behaal en nie kortpaaie te neem om bekendstellingsdatums te maak nie. Soos Healthcare.gov leer, is dit 'n pad wat tot gemiste verwagtinge sal lei.

Om klante se projekte te probeer behou betyds, ons skei die vereistes in moet hê (voldoen aan die besigheidsresultate) en lekker om te hê (opsionele verbeterings). Ons beplan ook nooit dat dit ten tyde van die vrystelling voltooi sal word nie, want ons weet dat daar altyd veranderings nodig sal wees.

Robert Patrick is uitvoerende hoof van PhD-laboratoriums, 'n agentskap wat webwerwe ontwerp, bou en bekendstel vir baie Fortune 500-maatskappye. Robert hou die probleme dop wat Healthcare.gov teëgekom het en het vyf belangrike redes vir die mislukte bekendstelling verskaf.

  1. Moet nooit die Tyd, koste en funksie Stel reël. Beskou dit as 'n driehoek; u moet een punt kies om te wees vasgestel en die ander twee veranderlikes. In hierdie wêreld kan omtrent enigiets geskep word solank daar genoeg tyd en geld is. Elkeen wat 'n webtoepassing bou, moet egter vooraf kies, wat die hoogste prioriteit het. Dit gee die toon en fokus vir hoe 'n projek van stapel gestuur moet word. Byvoorbeeld,
    • Moet dit eers van stapel gestuur word sodra spesifieke funksies gedoen is (geld en tyd is veranderlik).
    • Moet dit vinnig van stapel gestuur word (geld en funksies is veranderlik).
    • Moet dit met 'n begroting in ag geneem word (tyd en funksies wissel).
  2. Begin met die eindstreep in gedagte in plaas van die beginlyn. Webtoepassings moet gesien word as 'n projek wat sal Begin en dan ontwikkel. Om te bou wat belangrik en verpligtend is vir vandag met groei en evolusie in gedagte, is altyd beter as om te bou met die doel om by die beginpunt te eindig.
  3. Te veel verskaffers betrokke. Daar is berig dat byna 55 verkopers op die Obamacare-webwerf betrokke was. Die toevoeging van verskeie verskaffers aan enige projek kan 'n gladde helling wees. U kan amper waarborg dat daar probleme met die weergawe van die lêer, die afwykings tussen die kunslêers, die afwykings van die kunsmenings, die verlating van die projek is, en dat die lys voortduur. Stel jou voor dat ons 55 senate gehad het wat elk die taak gehad het om 'n gedeelte van die algehele probleem op te los.
  4. Information Architecture nie ernstig opgeneem nie. Dikwels sal groot agentskappe verskaffers vra om 'n bod op 'n RFP in te dien en die inligtingargitektuurproses heeltemal oor te slaan sonder om dit te begryp of in te stem. Dit is 'n groot, lelike, tydmors, geld verloor, fout. Dit is uiters waardevol om soveel moontlik van die toepassing te argitektuur en bereid te wees om rats en buigsaam te wees met die dinge wat nie goed voorspel kon word voordat u dit begin programmeer nie (dit is soos om 'n huis te bou sonder bloudrukke). Verskaffers is bestem om nie meer begroting te kry nie en begin om hul hoeke te sny as dit nie reg gedoen word nie.
  5. Nie genoeg tyd vir gehalteversekering. Dit is duidelik dat dit 'n groot ondergang was met die bekendstelling van HealthCare.Gov. Hulle was besig met 'n harde bekendstellingsdatum (die tyd is in hierdie geval die vaste veranderlike van die driehoek) en die funksies en die begroting moes gewysig word om aan die bekendstellingsdatum te voldoen, met die tyd vir behoorlike gehalteversekering wat in die plan ingebou is. Dit is 'n belangrike fout en kos heelwat mense waarskynlik hul werk.

Wat dink jy?

Hierdie webwerf gebruik Akismet om spam te verminder. Leer hoe jou opmerking verwerk is.