Съдържание:
- Прогресивна разработка - Изградете успех на проекта стъпка по стъпка
- Прогресивна разработка
- Прецизността не е същата като детайлите
- Казус: Подобрения в уебсайта за увеличаване на процента на конверсия
- Нека постепенно да разработим обхвата на този проект:
- Повече подробности: Гмуркане в маркетинговите детайли
- Художниците винаги са използвали прогресивна разработка
- Постигането му от първия път е по-евтино
- Не е нужно да го правим наведнъж
- Прогресивна разработка за проекти, които решават проблеми
- Казус: Забавяне на изстрелването на космическата совалка „Атлантида“ от 2006 г.
- Прогресивната разработка не е само за обхват
- Прогресивна разработка на плана за комуникация на проекта
- Изработване на управление на риска в проект
- Прогресивна разработка и жизнен цикъл на проекти
- Прогресивна разработка в класическия водопад
- Прогресивна разработка с бързо проследяване
- Едновременно управление на проекти
- Разработка на софтуер с нулеви дефекти
- Спиралният модел
- JAD и RAD
- Прогресивна разработка в пъргавото развитие
- Какво мислите за прогресивната разработка?
- Прогресивната разработка поддържа проекта в движение
Прогресивна разработка - Изградете успех на проекта стъпка по стъпка
Много хора се страхуват от създаването на добър план на проекта - смятат, че това отнема твърде много време. Институтът за управление на проекти (PMI) има решение, наречено Прогресивна разработка. Това е фантастичен термин за правене на добър дизайн стъпка по стъпка, докато не постигнем страхотни резултати.
Прогресивна разработка
Оплакване, което често получавам от хора, които обучавам в управлението на проекти, е, че трябва да отнеме твърде много време, за да се определи проект достатъчно точно, за да се предотврати катастрофата на проекта. Те са загрижени, че ще планираме завинаги и никога няма да свършим каквато и да е работа. Това е истинско безпокойство и аз го наричам парализа чрез анализ . Но отличното планиране и дизайн не трябва да води до парализа чрез анализ.
Разбирането на три ключови точки ще отключи идеята - и стойността - на качествения дизайн чрез прогресивна разработка.
- Прецизността не е същото като детайла.
- Да го направите правилно от първия път е по-евтино.
- Не е нужно да проектираме всичко наведнъж, отпред.
Прочетете, за да научите повече.
Прецизността не е същата като детайлите
Ключът към прогресивната разработка е, че можем да започнем на много високо ниво, с обща картина на това, което искаме. Тогава можем да продължим напред с проекта и да преминем към все по-фини детайли, докато вървим. По този начин започваме да работим рано и продължаваме да работим, докато разработваме своя дизайн. Това предотвратява парализа чрез анализ.
За да направим това добре, трябва да сме много ясни: Изявление или дизайн на обхват на високо ниво може да не са подробни, но все пак трябва да са точни. Тя може да бъде кратка и проста, но трябва да е без никакви неясноти.
Казус: Подобрения в уебсайта за увеличаване на процента на конверсия
В този случай, типично за моята консултантска работа, разглеждаме компания, която има добра маркетингова и рекламна кампания - много хора идват на техните уеб сайтове. А проучванията на пазара показват, че хората, които идват, са на целевия си пазар. Освен това те имат добра, стабилна продуктова линия - няма нужда да променяте нещата там. Но след като хората дойдат на сайта, мнозина не купуват. Трябва да увеличим степента на конверсия, наричана още скорост на затваряне. Какво може да се направи?
Нека постепенно да разработим обхвата на този проект:
- Декларация за обхвата на изпълнителното ниво: Ще бъдат направени промени в уебсайта, за да се увеличи процентът на конверсия, т.е. процентът на хората, които действително купуват нещо от тези, които пристигат на сайта. След като увеличим тази ставка, искаме да запазим новата ставка. Изключване на обхвата: Няма да има промени в маркетинга или в нашата продуктова линия. Тези се проверяват добре.
- Измерване на ниво на изпълнително ниво: Това ще включва текущия процент на преобразуване, проучвания на стандартни за индустрията обменни курсове, определяне на цели за нов обменен курс до определена дата.
- Декларация за обхвата на ниво управление: Промените в уебсайта трябва да увеличат процента на конверсия, без да пречат на ъптайма, производителността или пазарската количка и финансовото управление. Промените и техните последици трябва да бъдат проследими, така че ние се научаваме какво да пазим, какво да изхвърляме и какво да подобряваме.
- Подход за управление: Ръководството избира определени продукти, върху които да експериментира. Успешните експерименти ще бъдат копирани на всички подходящи продукти.
- Технически проблеми: Изследваме подробности, изброени по-долу.
- Технически подход: Ние проектираме експерименти, тествайки различни опции, за да ги сравним и да видим какво работи.
Тези шест стъпки прогресивно разработват проекта. Всяко ниво на мислене предоставя повече подробности - повече доработка - докато напредваме в проектирането и внедряването на нови уеб страници.
Имайте предвид, че има поне три различни екипа от хора - вероятно четирима, ако имаме както технически експерти по маркетинг, така и технически програмисти. Всеки екип се включва, когато е необходимо, и добавя към детайлите, които са от съществено значение за успеха.
Повече подробности: Гмуркане в маркетинговите детайли
Ето частичен списък на техническите подробности за маркетинга (а не за уеб дизайна), по които ще работи проектът, за да увеличи процента на конверсия.
- По-малко кликвания за затваряне. Проучванията показват, че колкото повече кликвания има между пристигането на дадена страница и сключването на сделката, толкова повече хора изоставят сайта. Така страниците могат да бъдат рационализирани, за да се увеличи процентът на конверсия.
- Създаване на усещане за спешност. Ако даден продукт изглежда така, сякаш ще се появи по-късно, хората често забавят покупка - и след това никога не се връщат. Екипът за технически маркетинг може да се наложи да се върне при ръководителите, за да попита дали краткосрочните продажби с отстъпки са приемлив начин за увеличаване на скоростта на затваряне.
- Премахнете объркването. Подробни инструкции и много юридически език ще намалят скоростта на затваряне.
- Директни целеви страници. Рекламите трябва да отиват направо към целеви страници, които са страници за продажби на рекламирания артикул.
- Добре дошли клиенти обратно. Използвайки бисквитки, потребителско влизане или и двете, можем да насочим връщащите се клиенти там, където най-много искат да отидат. Също така можем да проверим отново с изпълнителния директор относно съхраняването на кредитни карти в архив, за да рационализираме бъдещите покупки.
Както можете да видите, нито една от тези идеи не трябва да се мисли в началото. Изпълнителното ниво определя целта, ръководството насочва посоката и след това техническите екипи постепенно разработват как промените ще постигнат целта.
Художниците винаги са използвали прогресивна разработка
Това е ранна скица, където художникът, освен че изобразява пълна фигура, добавя две алтернативни глави и цилиндър. В „Портрет на Едуар Мане, седнал на стол“ Дега разработва идеите си, без да се притеснява за създаването на последно парче.
Едгар Дега, Лувър, Париж (Public Domain) чрез Wikimedia Commons
Тук, в тази скица с черен тебешир, концепцията е разработена по-пълно като „Кабинет за портрет на Едуар Мане“. Разработката напредва.
Edgard Degas, Metropolitan Museum of New York (Public Domain) чрез Wikimedia Commons
Това цялостно „Офорт на„ Портрет на Едуар Мане, Етюд “, седнало, обърнато наляво, е богатият, силен резултат от прогресивната разработка на темата на Дега.
Едгар Дега, Публична библиотека в Бостън (Public Domain), чрез Wikimedia Commons
Постигането му от първия път е по-евтино
Във всеки проект има само три възможности за избор по отношение на качеството и резултатите:
- Най-евтиният избор е да настроите нещата правилно от първия път.
- Вторият вариант е да го погрешите, след което да го поправите по време на проекта.
- Третият вариант е да се обърка и да се получат лоши резултати.
Така че, като цяло е по-добре да бъдем ясни и точни в началото. Колко по-добре? Десетки проучвания през последните 40 години показват, че съществува съотношение между разходите за предотвратяване на грешка; разходите за отстраняване на грешка по време на проекта; и разходите за почистване на бъркотията след проекта. А минималното съотношение е 1: 10: 100. Така че грешка, която може да бъде предотвратена при допълнителен час планиране при $ 100 / час, ще отнеме десет часа време за проекта и $ 1000 за поправяне по време на проекта, и ще отнеме 100 часа и $ 10 000, ако трябва да направим изтегляне след приключване на проекта. И съотношения, много по-високи от 1: 10: 100, са открити, ако използваме най-добрите практики в управлението на качеството, за да направим дизайн без дефекти от самото начало.
Урокът: Прогресивното усъвършенстване - разработване на повече детайли, докато вървим напред - винаги има смисъл. Небрежната работа никога няма смисъл.
Не е нужно да го правим наведнъж
Ние правим добра, ясна работа на всяка крачка. В същото време не е нужно да определяме целия проект наведнъж или да дефинираме всички подробности в началото. Вместо това можем да работим на етапи. Ние сме ясни и точни на всеки етап, но ставаме по-подробни, докато вървим. Това се нарича прогресивна разработка. Правенето му добре включва:
- Като се започне с общата картина и се стигне до подробностите.
- Бъдете ясни на всяка среща, записвайте резултатите и ги потвърждавайте.
- Проследяване на това колко сме определили и колко още не е определено.
- Привеждане на правилните хора на всяка среща. По-вероятно е ранните срещи да бъдат с ръководители и мениджъри на по-високо ниво. А ние, ръководителите на проекти, вероятно ще бъдем на всички срещи. Докато се стремим да открием подробности за процеса, работния процес и интерфейса, ние работим повече с работниците. И тъй като срещите стават по-технически, имаме нужда от повече технически хора (като програмисти и инженери), ангажирани от страна на проекта.
- Продължаваме, докато не бъде дефиниран всеки детайл от всяка характеристика на продукта или услугата, която създаваме или подобряваме. Възможно е обаче да имаме написана голяма част от програмата или продуктът, докато продължаваме да детайлизираме други части.
Прогресивна разработка за проекти, които решават проблеми
Проектите, които решават проблеми, са специален случай, при който прогресивната разработка е особено полезна.
Проблем е нещо, което се е появило, което спира компанията или производствената линия да работи както преди. Така че целта вече е ясна: Накарайте това d ** mn * d нещо да работи! Участието на ръководителите е минимално и мениджърите нямат какво да направят, освен да предоставят подкрепа. Всъщност, тъй като мениджърите вече знаят какво е "нещото" и как трябва да работи, "Накарайте това d ** mn * d нещо да работи!" е пълна и точна декларация от високо ниво, изпълнителен обхват.
Казус: Забавяне на изстрелването на космическата совалка „Атлантида“ от 2006 г.
Добър пример за този тип проекти се случи през 2006 г., когато проблемите в 10-годишен манометър, който измерваше количеството водород в резервоарите за гориво на космическата совалка Атлантида, се повтаряха. Манометърът става ненадежден, понякога показва, че резервоарът е празен, когато е пълен и проблемът е периодичен.
Изявлението за обхвата на изпълнителното ниво би било ясно: Фиксирайте манометъра, за да можем да летим със совалката!
Въпреки това, докато изследваме проблема ниво на ниво, като използваме прогресивна разработка, откриваме четири технически проблема, които затрудняват все по-трудното разрешаване на проблема:
- Решение на ръководството: Ако знаем, че габаритът е дефектен, можем ли просто да го изключим, да разчитаме на други габарити и да летим така или иначе. Имаше много дебати по този въпрос. Но най-накрая беше решено, че основна характеристика за безопасност, Главният изключен двигател (MECO) няма да бъде надеждна без този габарит. Така че решението на ръководството беше, че габаритът трябва да бъде фиксиран.
- Технически проблем: Проблемът е периодичен. Следователно всеки издържан тест не е доказателство, че габаритът работи и че совалката може да лети безопасно. Трябваше да се намери конкретният проблем, за да се гарантира, че е отстранен.
- Подробен технически проблем: Манометърът не беше просто устройство. Той включваше много различни компоненти и електрическите съединители между тях. Някои от тях бяха заровени дълбоко в окабеляването на совалката. Само намирането на всички компоненти и почистването на съединителите им беше голяма работа. Неведнъж инженерите смятаха, че са отстранили проблема, но габаритът не тестваше чистота.
- Много подробен технически проблем: Плановете за проектиране на космическата совалка може да не са точно съвпадали с Атлантида, тъй като е построена. Частите бяха надстроени и заменени. Един инженер съобщи, че намирането на всички части на габарита е изследователска мисия, че те все още откриват как работи космическата совалка!
Това илюстрира как една много проста изпълнителна директива трябва да бъде разработена постепенно до по-фини и по-фини нива на детайлност, за да се гарантира успех. Тази разработка обаче не трябва да се извършва като част от планирането. Тъй като всеки компонент на манометъра беше достигнат, той можеше да бъде почистен, тестван и документиран. Това е, което се разбира под прогресивна разработка на проект, който решава проблем.
Прогресивната разработка не е само за обхват
Въпреки че тази статия се фокусира върху прогресивната разработка при разработването на обхвата и структурата на разбивка на работата (WBS), концепцията за прогресивна разработка е по-широка от тази. Всъщност той може да се приложи към всички девет области на управление на даден проект. Ето няколко примера:
Прогресивна разработка на плана за комуникация на проекта
Първата версия на плана за комуникация на проекта може да бъде просто списък с контакти на членовете на екипа и клиентите на проекта. Ние разработваме това чрез:
- Идентифициране на всички заинтересовани страни по проекта и добавянето им в списъка
- Взема решение как да общува с всеки участник
- Взема решение как да включи гласа на клиента в проекта
Изработване на управление на риска в проект
Официалните стъпки от управлението на риска от проекти постепенно доразвиват нашата дефиниция за проектния риск - какво може да се обърка - и отговора ни чрез:
- Идентифициране на риска, където правим първоначалния си списък с рискове.
- Анализ на риска, където оценяваме и приоритизираме рисковете
- Планиране на реакция на риска, където решаваме какво да направим, за да предотвратим рискови събития и какво да направим, ако се случат
- Мониторинг и контрол на риска, където ние следим за рисковете, търсим нови рискове и се справяме с тях, докато се случват.
От тези примери можете да видите, че постепенното разработване е стандартна практика за всички девет области на управление на проекти.
Прогресивна разработка и жизнен цикъл на проекти
Прогресивната разработка може да се прилага по различен начин за различни проекти. При избора как да се направи прогресивна разработка, ключовото е да се свърже разработването на детайли с жизнения цикъл на проекта, който използвате.
Прогресивна разработка в класическия водопад
В класическия водопад или жизнения цикъл на развитието на системата (SDLC) цялото планиране предхожда изпълнението. Следователно, постепенно разработване на обхвата се случва на етапите на планиране.
Прогресивна разработка с бързо проследяване
Ако класическият водопад е модифициран, за да позволи бързо проследяване, тогава целият продукт е разделен на модули. Тъй като планирането е завършено за всеки модул, разработката може да продължи за този модул, докато други все още се планират. В този жизнен цикъл някои модули се изработват по-бързо от други.
Едновременно управление на проекти
Едновременното управление на проекти е разработено от Hewlett-Packard и сега се използва широко в автомобилната индустрия. Чрез обединяването на всички различни специалисти в началото, жизненият цикъл на проекта (да речем за представяне на нова концептуална кола на пазара) може да бъде намален от пет години на 18 месеца! При едновременното управление на проекти постепенното разработване се извършва рано и бързо от междуфункционални екипи.
Разработка на софтуер с нулеви дефекти
Методът на нулеви дефекти при разработването на софтуер се фокусира върху прецизността, за да се предотврати навлизането на грешки в кода. Ранното разработване на дизайна, последвано от ранното разработване на самия код, с множество рецензии поставя множество очи върху проблема, създавайки софтуер с най-високо качество на най-ниска цена. Полагайки 80% от усилията за добър дизайн, тестването и отстраняването на грешки, които са скъпи, се намаляват драстично.
Спиралният модел
Спиралният модел беше предшественик на Agile Development. Той поставя функции по график и ако дадена функция закъснее, тя се изпуска в по-късен цикъл в спиралата. всяка характеристика е разработена, когато излезе за проектиране и след това отново, в следващия цикъл, когато излезе за разработка.
JAD и RAD
JAD, съвместно разработване на приложения и RAD, бързо разработване на приложения, не са действителни алтернативи на жизнения цикъл. По-скоро те са техники за извличане на изисквания, които засягат жизнения цикъл. Поставянето на дизайнери и програмисти в непосредствена близост до техните клиенти, потребителите на приложението, ускорява развитието. Честите срещи позволяват бързо прогресивно разработване. И този подход е ключов компонент на Agile Development.
Прогресивна разработка в пъргавото развитие
Agile Development, наричано още Agile Programming, е най-новият подход към жизнения цикъл на проекта и работи особено добре с днешните обектно-ориентирани кодове и платформи за уеб разработка. Програмистите работят в тясно сътрудничество с клиента, като често пребивават постоянно във всеки отдел за клиенти. Използвайки прототипи и бърза модификация на приложенията, дизайнът се обединява с разработката. Постепенното разработване е постоянен процес през целия проект.
Какво мислите за прогресивната разработка?
Прогресивната разработка поддържа проекта в движение
И така, последният урок е следният: Какъвто и да е тип проект, по който работим, и какъвто и жизнен цикъл и други методологии да изберем, не планираме и след това тръгваме. С прогресивна разработка ние планираме и вървим и продължаваме да планираме, докато вървим.