De driehoek voor webontwikkeling

Al onze contracten met onze klanten zijn doorlopende maandelijkse verbintenissen. Zeer zelden streven we een vast project na en bijna nooit garanderen we de tijdlijn. Dat klinkt misschien eng voor sommigen, maar het probleem is dat het doel niet de releasedatum moet zijn, maar de bedrijfsresultaten. Het is onze taak om de bedrijfsresultaten van onze klanten te behalen, niet om snelkoppelingen te maken om lanceerdata te maken. Zoals Healthcare.gov leert, is dat een pad dat zal leiden tot gemiste verwachtingen.

Om projecten van klanten te behouden op tijd, scheiden we vereisten in must-have (voldoen aan de bedrijfsresultaten) en nice to have (optionele verbeteringen). We plannen ook nooit de voltooiing op het moment van uitgave, omdat we weten dat er altijd enkele wijzigingen nodig zullen zijn.

Robert Patrick is CEO van PhD Labs, een bureau dat websites ontwerpt, bouwt en lanceert voor veel Fortune 500-bedrijven. Robert houdt de problemen bij die Healthcare.gov is tegengekomen en heeft 5 belangrijke redenen gegeven voor de mislukte lancering.

  1. Nooit, nooit de Tijd, kosten en functie Regel instellen. Beschouw dit als een driehoek, je moet één punt uitkiezen vast en de andere twee variabelen. In deze wereld kan zo ongeveer alles worden gecreëerd, zolang er maar genoeg tijd en geld is. Iedereen die een webapplicatie bouwt, moet echter vooraf kiezen wat de hoogste prioriteit heeft. Dit zet de toon en focus voor hoe een project moet worden gelanceerd. Bijvoorbeeld,
    • Moet het pas worden gestart nadat specifieke functies zijn voltooid (geld en tijd zijn variabel).
    • Moet het snel worden gelanceerd (geld en functies zijn variabel).
    • Moet het worden gelanceerd met een budget in gedachten (tijd en functies zijn variabel).
  2. Lancering met de eindstreep in gedachten in plaats van de startlijn. Webapplicaties moeten worden gezien als een project dat dat wel zal doen begin en ontwikkelen. Bouwen aan wat vandaag belangrijk en verplicht is met groei en evolutie in gedachten, is altijd beter dan bouwen met de bedoeling om bij het beginpunt af te werken.
  3. Te veel leveranciers betrokken. Er is gemeld dat de Obamacare-website bijna 55 betrokken leveranciers had. Het toevoegen van meerdere leveranciers aan een project kan een gladde helling zijn. U kunt bijna garanderen dat er problemen zullen zijn met bestandsversiebeheer, discrepanties in art-bestanden, discrepanties in art opinion, stopzetting van projecten en de lijst gaat maar door. Stel je voor dat we 55 senaten hadden die elk een deel van het totale probleem moesten oplossen.
  4. Informatie Architectuur niet serieus genomen. Vaak zullen grote bureaus leveranciers vragen om een ​​bod op een offerteaanvraag in te dienen en het informatiearchitectuurproces volledig over te slaan en direct in ontwikkeling te springen zonder een reikwijdte te begrijpen of overeen te komen. Dit is een enorme, lelijke, tijdverspilling, geldverlies, fout. Het is buitengewoon waardevol om van tevoren zoveel mogelijk van de applicatie te ontwerpen en bereid te zijn om wendbaar en flexibel te zijn met de dingen die niet goed konden worden voorspeld voordat u begint met programmeren (dit is als het bouwen van een huis zonder blauwdrukken). Verkopers zijn voorbestemd om zonder budget te komen en te bezuinigen als dit niet correct wordt gedaan.
  5. Niet genoeg tijd voor Kwaliteitsborging. Het is duidelijk dat dit een grote ondergang was voor de lancering van HealthCare.Gov. Ze werkten aan een harde lanceringsdatum (tijd is in dit geval de vaste variabele van de driehoek) en de functies en het budget hadden moeten worden aangepast om de lanceringsdatum te halen, met tijd voor een goede kwaliteitsborging die in het plan was ingebouwd. Dit is een cruciale fout en kost waarschijnlijk veel mensen hun baan.

Wat denk je?

Deze site gebruikt Akismet om spam te verminderen. Ontdek hoe uw reactiegegevens worden verwerkt.