Die Webontwikkelingsdriehoek

Al ons kontrakte met ons kliënte is deurlopende maandelikse verbintenisse. Baie selde volg ons 'n vaste projek, en selde waarborg ons die tydlyn. Dit klink dalk vir sommige eng, maar die probleem is dat die doel nie die datum van vrystelling moet wees nie, dit moet die besigheidsresultate wees. Ons werk is om ons kliënte besigheidsresultate te kry, nie kortpaaie te neem om bekendstellingsdatums te maak nie. Soos Healthcare.gov leer, sal daardie pad lei tot gemiste verwagtinge.

Om te probeer om kliënte se projekte betyds te hou, skei ons vereistes in moet-hê (voldoen aan die besigheidsresultate) en nice-to-haves (opsionele verbeterings). Ons skeduleer ook nooit voltooiing ten tyde van vrystelling nie, aangesien ons weet daar sal altyd 'n paar veranderinge nodig wees.

Robert Patrick is uitvoerende hoof van PhD-laboratoriums, 'n agentskap wat webwerwe vir baie top Fortune 500-maatskappye ontwerp, bou en bekendstel. Robert het die probleme wat Healthcare.gov ondervind het dopgehou en het vyf hoofredes vir die mislukte bekendstelling verskaf.

1. Moet nooit die Tyd, koste en funksie Stel reël. Dink hieraan as 'n driehoek; jy moet een punt kies om vas te stel en die ander twee veranderlikes. In hierdie wêreld kan omtrent enigiets geskep word as daar genoeg tyd en geld is. Enigiemand wat egter 'n webtoepassing bou, moet vooraf kies, wat die hoogste prioriteit is. 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 ontwikkel. Om te bou wat noodsaaklik en verpligtend is vir vandag met groei en evolusie in gedagte, is altyd beter.
3. Te veel verskaffers betrokke is. Daar is berig dat die Obamacare-webwerf byna 55 verskaffers betrokke was. Om veelvuldige verkopers by enige projek by te voeg, kan 'n gladde helling wees. Jy kan amper waarborg dat daar probleme sal wees met lêerweergawe, kunslêer-afwykings, kuns-opinie-teenstrydighede, projekverlating, ens. Stel jou voor dat ons 55 senate gehad het wat elkeen die taak het om 'n gedeelte van die probleem op te los.
4. Information Architecture word nie ernstig opgeneem nie. Dikwels sal groot agentskappe verkopers vra om 'n bod op 'n RFP in te dien en die inligtingsargitektuurproses heeltemal oor te slaan om reg in ontwikkeling te spring sonder om 'n omvang te verstaan ​​of ooreen te stem. Dit is 'n groot, lelike, tydmorsende, geldverloorende fout. Dit is uiters waardevol om soveel as moontlik van die toepassing vooraf te bou en bereid te wees om rats en buigsaam te wees oor die dinge wat nie goed voorspel kon word voordat jy dit begin programmeer nie (dit is soos om 'n huis sonder bloudrukke te bou). Verkopers is bestem om hul begroting op te raak en te begin draai as dit nie korrek gedoen word nie.
5. Nie genoeg tyd vir gehalteversekering. Dit was 'n groot ondergang vir die bekendstelling van HealthCare.Gov. Hulle het gewerk aan 'n harde bekendstellingsdatum (tyd is die vaste veranderlike van die driehoek in hierdie geval), en die kenmerke en begroting moes gewysig gewees het om die bekendstellingsdatum te bereik met tyd vir behoorlike kwaliteitsversekering wat in die plan ingebou is. Dit is 'n deurslaggewende fout en kos waarskynlik baie mense hul werk.