Разлики между класическото и пъргавото управление на проекти (част 1) - проекти, улеснени
Класически или пъргав - две методологии в управлението на проекти, които не могат да бъдат по-различни: Разбира се, всеки ръководител на проекта иска да доведе проекта си до успех, но основните идеи и процедурата на двата подхода изглеждат напълно противоположни. Това се изразява не на последно място в разгорещени дебати за това кой метод е „по-добрият“. Но има ли това одеяло „по-добро“? Едва ли вероятно! Добре известно е, че инструментите работят само ако са избрани подходящо за целта. В статията „Agile, classic & Co: Кога е подходяща коя методология за управление на проекти?“ Можете да научите повече за правилния избор на методология.
И така, как избирате единия или другия подход? На първо място, трябва да знаете в какво влизате с всеки метод. По-конкретно, това означава: Какво означава ангажиментът за вашия проект и как се различават двата подхода. За да ви улесни, следващата статия е първата от поредица от 4 статии, в които обясняваме разликите между класически и пъргав стигнете до дъното.
В началото на поредицата започваме с три много основни разлики:
Опасност: Зад условията класически и пъргав Много различни модели на процеси, рамки и внедрения са скрити. На практика има някои смесени подходи с най-различни характеристики. Класически организиран проект може да съдържа гъвкави подпроекти. Дори ако проектът официално следва едно или друго преподаване на 100% и рамката е фиксирана, проницателният мениджър на проекти често ще намери прагматично решение за справяне с възникналите проблеми. В тази поредица няма да навлизаме в подобни смесени форми и заобикалящи решения, но умишлено разглеждаме крайните форми на „класически“ и „пъргави“ за по-добро разбиране.
Късна обратна връзка срещу ранна обратна връзка
От гледна точка на клиента разликите между класическите и пъргавите процедури стават особено ясни кога Време и честота на обратна връзка да се има предвид: Кога може или трябва (или може) клиентът (клиент, краен потребител, ...) да даде обратна връзка за резултата от проекта/продукта?
Класическо управление на проекти:
Често резултатът се представя на клиента само в края на проекта. Това може напр. да бъде продукт, разработен в проекта. За да се гарантира, че това не се обърка и че този продукт действително отговаря на очакванията на клиента, трябва да се обърне голямо внимание при определянето на изискванията в началото на проекта. Обикновено се създава спецификация на изискванията, която в края на проекта формира основата за приемане от клиента. Така че обратната връзка идва само в самия край.
Примери:
- Изработена по поръчка помпа за пречиствателна станция с ясни технически изисквания и спецификации
- Изпълнение на маркетингово събитие за представянето на нов смартфон
- Обучение на служителите на орган по темата "нови правила за защита на данните"
Опасност: При класическото управление на проекти, разбира се, има възможност да се даде възможност на клиента да предостави обратна връзка, докато проектът се изпълнява. Примери моля?
- В проекта за разработка, показан по-горе, консултация с клиента може да се проведе след края на фазата на проектиране.
- В примера за обучение на служители, разработената концепция за обучение може да бъде представена на ръководството на органа за одобрение.
При класическото управление на проекти такива точки за обратна връзка се използват предимно, за да се провери дали проектът все още е на път, за да се предотвратят по-лоши неща. Ако в такъв момент е необходима корекция на курса, това обикновено изисква значителни усилия за разсрочване - проектът често е скъп и забавен.
Agile управление на проекти:
Клиентът получава частични функции или стъпки на продукта за оценка на редовни цикли - изрично се иска обратна връзка и критика. Това работи само ако резултатът от проекта може да бъде разбит добре на стъпки, които могат да бъдат генерирани един след друг и след това да бъдат изследвани/оценени. Основният пример е разработването на софтуер - областта, в която се заражда пъргавата идея.
Фигурата показва процедурата, използвайки примера на рамката Scrum в гъвкаво управление на проекти:
В опасни среди с променящи се изисквания предимството е очевидно: Вместо да разработваме цялостен продукт за дълги периоди от време, всички участващи получават редовна представа за напредъка на проекта. Изискванията могат да се коригират и да се дефинират следващите стъпки. По този начин обширните последващи настройки автоматично се елиминират. За разлика от класическото управление на проекти, няма риск промените в изискванията да останат неоткрити или в най-лошия случай даден продукт да бъде заобиколен на пазара.
Примери:
- Разработване на уебсайт с онлайн магазин и множество други подробни функционалности
- Разработване на софтуер за управление за нов дизайн на двигателя
- Планиране на еднофамилна къща от архитектурен офис
Дефинирани процеси vs. иновация
Изграждането на тринадесетата сглобяема къща "извън колчето" се различава изключително много от разработването на иновативно приложение въпреки всички опции за конфигуриране - и следователно процедурата също ще се различава значително:
Класическо управление на проекти:
Класически планираните и изпълнявани проекти са особено подходящи за проекти, които следват дефинирани процеси, в които се използват добре разбрани подробни решения/компоненти и от които трябва да се получи предсказуем резултат. Доказаните и дефинирани стъпки водят до предварително определен резултат.
Примери:
- Изграждане на еднофамилна къща "извън колчето"
- Надстройка на сървърния пейзаж във фирма
Agile управление на проекти:
Agile управлението на проекти често се използва в динамична среда: при разработване на продукти, изследвания и разработване на софтуер. Често не е възможно да се предскаже ясно как ще изглежда резултатът в детайли и кои подходи ще донесат най-доброто решение - в началото просто никой не знае. Даден план или процес няма много смисъл, в крайна сметка трябва да се създаде нещо ново. Ако трябва да се създадат новаторски иновации, няма стандартна рецепта, която да може да се приложи директно.
Примери:
- Оптимизиране на дисплея на лаптоп с нова технология, която все още не е напълно разбрана
- Разработване на иновативно приложение за отслабване
Последователно развитие vs. итеративно развитие
В предварително определени последователни стъпки към целта - или на кратки цикли? Тук методологиите за управление на проекти се различават значително. Тази точка е тясно свързана с честотата на обратната връзка (виж по-горе):
Класическо управление на проекти:
При традиционно изпълняваните проекти дефинираните фази се обработват една след друга в началото. Когато фаза или блок от задачи са завършени, започва следващата. По принцип фазите също могат да се припокриват, но поне в рамките на един подпроект те никога не се обработват приблизително паралелно, а по същество една след друга.
Този подход се основава на предположението, че цялата информация е налична в началото на проекта. Те са опаковани в изисквания и проекти, след което изпълнението започва.
Пример: Едва когато дизайнът на уебсайта е напълно завършен, програмирането ще започне.
Agile управление на проекти:
При пъргавото управление на проекти не всичко е дефинирано подробно в началото. Основната идея: хората не могат да видят всички подробности предварително и дори клиентите не знаят точно какво искат и какви опции са на разположение в началото. Поради тази причина се прилагат малки единици, те се проверяват и при необходимост се подобряват.
Итеративен:
Итеративният подход се основава на предпоставката, че много неща често са неправилно или не идеално решени в първата стъпка, преди грешките да бъдат коригирани в следващата стъпка. Казано направо: Първото хвърляне е за кошчето, но ние можем да се поучим от него и да надграждаме върху него. Или друго: Първото хвърляне е предложение към клиента. Следователно многократни опити не се разглеждат като грешки, а по-скоро се планират като част от процедурата от самото начало.
пример: Вместо директно представяне на подробен проект на нов уебсайт във всички негови подробности, се създават груби скици, създават се предишни версии и те постепенно се усъвършенстват в консултация с клиента.
Постепенно:
С инкрементния подход големите парчета се разбиват на подзадачи и те се изпълняват едно след друго. Фон: Ако е изградена малка част, знанията могат да бъдат получени и приложени към други функции.
Пример: Вместо да проектирате всички подстраници на присъствие на нова компания, първоначално се създава само началната страница.
Заключение
Изборът на подходящия инструмент за всяко приложение често е трикът! В тази статия се запознахте с първите три разлики между класическото и пъргавото управление на проекти. Любопитни ли сте да научите повече? Продължава в част 2!