Трикутник веб-розробки

Всі наші контракти з нашими клієнтами є постійними щомісячними зобов’язаннями. Дуже рідко ми переслідуємо фіксований проект і майже ніколи не гарантуємо терміни. Для когось це може здатися страшним, але проблема полягає в тому, що метою повинна бути не дата випуску, а бізнес-результати. Наша робота полягає в тому, щоб отримувати клієнтам бізнес-результати, а не вживати комбінації клавіш швидкого введення дати запуску. Поки Healthcare.gov навчається, це шлях, який призведе до втрачених очікувань.

Спробувати зберегти проекти клієнтів вчасно, ми розділяємо вимоги на must have (що відповідає діловим результатам) і nice to have (необов’язкові вдосконалення). Ми також ніколи не плануємо завершення на момент випуску, оскільки ми знаємо, що завжди будуть потрібні деякі зміни.

Роберт Патрік - генеральний директор компанії Кандидатські лабораторії, агентство, яке розробляє, розробляє та запускає веб-сайти для багатьох провідних компаній Fortune 500. Роберт відстежував труднощі, з якими зіткнувся Healthcare.gov, і надав 5 ключових причин невдалого запуску.

  1. Ніколи, ніколи не порушуйте Час, вартість та особливості Встановити правило. Подумайте про це як про трикутник, ви повинні вибрати одну точку, якою ви хочете бути фіксованою а дві інші змінні. У цьому світі можна створити майже все, що завгодно, поки є достатньо часу та грошей. Однак кожному, хто створює веб-додаток, слід вибирати, що є найвищим пріоритетом. Це задає тон і фокус щодо запуску проекту. Наприклад,
    • Якщо він буде запущений лише після того, як будуть виконані певні функції (гроші та час змінюються).
    • Якщо його швидко запустити (гроші та функції змінюються).
    • Якщо його запускати з урахуванням бюджету (час і особливості змінюються).
  2. Запуск з Фінішна лінія на увазі замість лінії старту. Веб-програми слід розглядати як проект, який буде старт , А потім еволюціонувати. Будувати те, що є важливим і обов’язковим на сьогодні з урахуванням зростання та еволюції, завжди краще, ніж будувати з наміром закінчити в початковій точці.
  3. Забагато продавців беруть участь. Повідомляється, що на веб-сайті Obamacare було задіяно близько 55 постачальників. Додавання кількох постачальників до будь-якого проекту може бути слизьким схилом. Ви майже можете гарантувати, що виникнуть проблеми з версією файлів, розбіжностями художніх файлів, розбіжностями в думках, відмовою від проекту, і список можна продовжувати і продовжувати. Уявіть, якби у нас було 55 сенатів, кожному доручено вирішити частину загальної проблеми.
  4. Інформаційна архітектура не сприймається всерйоз. Часто великі агентства просять постачальників подати заявку на тендерний конкурс та повністю пропускають процес інформаційної архітектури, переходячи безпосередньо до розробки, не розуміючи та не узгоджуючи сферу застосування. Це величезне, потворне, витрачання часу, втрата грошей, помилка. Надзвичайно цінно створити якомога більшу частину програми та бути готовим бути гнучким та гнучким у відношенні речей, які неможливо було передбачити задовго до того, як ви почнете програмувати (це як будівництво будинку без креслень). Постачальникам судилося закінчити бюджет і почати скорочувати кути, якщо це зроблено неправильно.
  5. Не вистачає часу на Гарантія якості. Очевидно, що це було великим падінням запуску HealthCare.Gov. Вони працювали над жорсткою датою запуску (у цьому випадку час є фіксованою змінною трикутника), а функції та бюджет мали бути зміненими, щоб відповідати даті запуску з часом для належного забезпечення якості, вбудованого в план. Це найважливіша помилка, яка, мабуть, коштує багатьом людям роботи.

Що ви думаєте?

Цей сайт використовує Akismet для зменшення спаму. Дізнайтеся, як обробляються ваші дані коментарів.