Триъгълник за уеб разработка

Всички наши договори с нашите клиенти са текущи месечни ангажименти. Много рядко следваме фиксиран проект и почти никога не гарантираме времевата линия. Това може да звучи страшно за някои, но проблемът е, че целта не трябва да бъде датата на пускане, а бизнес резултатите. Нашата работа е да получаваме нашите клиенти бизнес резултати, а не да използваме преки пътища, за да определяме датите на стартиране. Докато Healthcare.gov се учи, това е път, който ще доведе до пропуснати очаквания.

Да се ​​опитаме да запазим клиентски проекти на време, ние разделяме изискванията на must have (отговарящи на бизнес резултатите) и приятно да имаме (незадължителни подобрения). Също така никога не планираме завършване по време на пускането, тъй като знаем, че винаги ще са необходими някои промени.

Робърт Патрик е главен изпълнителен директор на Докторски лаборатории, агенция, която проектира, изгражда и пуска уебсайтове за много водещи компании от Fortune 500. Робърт следи за трудностите, с които се сблъска Healthcare.gov, и посочи 5 ключови причини за неуспешния старт.

  1. Никога, никога не нарушавайте Време, разходи и характеристики Задайте правило. Мислете за това като за триъгълник, трябва да изберете една точка да бъде фиксиран а другите две променливи. В този свят може да се създаде почти всичко, стига да има достатъчно време и пари. Всеки, който създава уеб приложение, обаче трябва да избере отпред, което е най-високият приоритет. Това задава тон и фокус върху начина, по който даден проект трябва да бъде стартиран. Например,
    • Трябва ли да бъде стартиран само след като са направени специфични функции (парите и времето са променливи).
    • Трябва ли да бъде стартиран бързо (парите и функциите са променливи).
    • Трябва ли да бъде стартиран с предвид бюджета (времето и характеристиките са променливи).
  2. Стартиране с ��������� ����� в ума вместо стартовата линия. Уеб приложенията трябва да се разглеждат като проект, който ще Начало и след това се развива. Изграждането на това, което е важно и задължително за днешния ден с оглед на растежа и еволюцията, винаги е по-добро от изграждането с намерение да завършим в началната точка.
  3. Твърде много доставчици участващи. Съобщава се, че в уебсайта на Obamacare са участвали близо 55 доставчици. Добавянето на множество доставчици към всеки проект може да бъде хлъзгав наклон. Почти можете да гарантирате, че ще има проблеми с версирането на файлове, несъответствия в художествените файлове, несъответствия в художественото мнение, изоставяне на проекта и списъкът може да продължава и продължава. Представете си, ако имахме по 55 сената, на които беше възложено да разрешат част от цялостния проблем.
  4. Информационна архитектура не се приема сериозно. Често големите агенции ще поискат от доставчиците да подадат оферта за RFP и напълно да прескочат процеса на информационна архитектура, като се впуснат направо в разработката, без да разбират или да се споразумеят за обхвата. Това е огромно, грозно, губене на време, загуба на пари, грешка. Изключително ценно е да създадете колкото се може повече от приложението предварително и да сте подготвени да бъдете пъргави и гъвкави по отношение на нещата, които не могат да бъдат прогнозирани добре, преди да започнете да го програмирате (това е като да построите къща без чертежи). Доставчиците са предназначени да останат без бюджет и да започнат да режат ъгли, ако това не е направено правилно.
  5. Няма достатъчно време за осигуряване на качеството. Очевидно е, че това е голям крах за стартирането на HealthCare.Gov. Те работеха върху твърда дата на стартиране (в този случай времето е фиксираната променлива на триъгълника) и характеристиките и бюджетът трябваше да бъдат променени, за да отговарят на датата на стартиране с времето за правилно осигуряване на качеството, вградено в плана. Това е решаваща грешка и вероятно струва на много хора работата си.

Какво мислите?

Този сайт използва Akismet за намаляване на спама. Научете как се обработват данните за коментарите ви.