Триаголник за развој на веб

Сите наши договори со нашите клиенти се тековни месечни ангажмани. Многу ретко спроведуваме фиксен проект и скоро никогаш не гарантираме временска рамка. Можеби за некого звучи застрашувачки, но проблемот е во тоа што целта не треба да биде датумот на објавување, тоа треба да бидат деловните резултати. Нашата работа е да ги добиеме деловните резултати на нашите клиенти, а не да преземаме кратенки за да ги направиме датумите за започнување. Како што учи Healthcare.gov, тоа е пат што ќе доведе до промашени очекувања.

Да пробам и да одржувам проекти на клиенти на време, ние ги одделуваме барањата во мора да ги имаме (исполнување на деловните резултати) и убаво да ги имаме (опционални подобрувања). Ние, исто така, никогаш не закажуваме да завршиме во моментот на објавување, бидејќи знаеме дека секогаш ќе има некои потребни промени.

Роберт Патрик е извршен директор на Докторски лаборатории, агенција која дизајнира, гради и лансира веб-страници за многу врвни компании на Fortune 500. Роберт водеше сметка за тешкотиите со кои се соочуваше здравството.gov и даде 5 клучни причини за неуспешно лансирање.

  1. Никогаш, никогаш не кршете го Време, цена и одлика Поставете правило. Сфатете го ова како триаголник, мора да изберете една точка фиксна и другите две променлива. Во овој свет, скоро се може да се создаде сè додека има доволно време и пари. Сепак, секој што гради веб-апликација треба да избере однапред, што е највисок приоритет. Ова го поставува тонот и фокусот за тоа како треба да се започне проект. На пример,
    • Треба да се активира само откако ќе се направат специфични карактеристики (парите и времето се променливи).
    • Треба да се започне брзо (парите и карактеристиките се варијабилни).
    • Треба да се започне со буџет на ум (времето и карактеристиките се променливи).
  2. Лансирање со финиш во умот наместо почетната линија. На веб-апликациите треба да се гледа како на проект што ќе го стори тоа Почеток и потоа се развива. Градењето на она што е важно и задолжително за денес имајќи го предвид растот и еволуцијата е секогаш подобро отколку да се гради со намера да се заврши во почетната точка.
  3. Премногу продавачи вклучени. Известено е дека на веб-страницата Обамакер имало околу 55 вклучени продавачи. Додавањето повеќе продавачи на кој било проект може да биде лизгав наклон. Скоро можете да гарантирате дека ќе има проблеми со верзијата на датотеките, разликите во уметничките датотеки, разликите во уметничкото мислење, напуштањето на проектот и списокот продолжува и продолжува. Замислете кога би имале 55 сенати со задача да решат дел од целокупниот проблем.
  4. Информации за архитектура не се сфаќа сериозно. Честопати, големите агенции ќе побараат од продавачите да достават понуда за распишување на понуди и целосно да го прескокнат процесот на архитектура на информации, скокајќи во развој, без разбирање или договарање за опсегот. Ова е огромна, грда, губење време, губење пари, грешка. Тоа е исклучително вредно за архитектот колку што е можно повеќе од апликацијата, и да бидете подготвени да бидете агилни и флексибилни за работите што не може да се предвидат добро пред да започнете со нејзино програмирање (ова е како да се гради куќа без нацрти). Продавачите се предодредени да останат без буџет и да почнат да ги намалуваат аглите ако ова не е направено правилно.
  5. Нема доволно време за Обезбедување на квалитет. Очигледно е дека ова беше голем пад на лансирањето на HealthCare.Gov. Тие работеа на тежок датум на лансирање (времето е фиксна променлива на триаголникот во овој случај) и карактеристиките и буџетот требаше да бидат изменети за да се исполнат датумот на лансирање со време за правилно осигурување на квалитетот вграден во планот. Ова е клучна грешка и веројатно многу луѓе ги чинеа своите работни места.

Што мислите?

Оваа страница користи Akismet за намалување на спам. Научете како се обработува вашиот коментар.