Якщо проектний менеджмент — це методологія, то Waterfаll, Agile, Scrum, Kanban — це методи, завдяки яким досягаються цілі за проектами і задачами. Якщо говорити простіше: управління проектами є основою проектного менеджменту, а чим ефективніше управління — тим більше проектів завершуються успішно і з дотриманням дедлайнів.
Типова картина хаосу в управлінні проектами:
- Проекти ведуться в таблицях, хмарних документах і фіксуються в різних файлах, доступи до яких можуть губитися;
- Комунікація всередині команди — це листування електронною поштою, в месенджерах або усне обговорення деталей проекту, які ніде не фіксуються;
- Немає розуміння кінцевої мети проекту;
- Відсутня розбивка проекту на дрібні задачі з конкретизацією: що потрібно зробити, яка мета цих дій і хто за це відповідальний;
- Перестрибування з одного етапу реалізації проекту в інший, або навіть перестрибування з одного проекту в інший;
- Відсутність чіткого розподілу ролей в команді: хто Виконавець, хто Відповідальний, хто Керівник проекту.
Те, що ми описали вище — біль компаній, які ще далекі від проектного менеджменту або намагаються перейти до принципів проектного менеджменту в управлінні проектами, але перехід виходить болючим для всієї команди.
Важкий перехід до проектного менеджменту — це коли учасники команди не розуміють: Навіщо потрібен проектний менеджмент? Що дає систематизація робочих процесів? Як впливає новий формат роботи на кінцевий результат і ефективність?
Яким буває проектний менеджмент
Почнемо з головного: гнучкість — ось що рятує більшість компаній і дозволяє довести проект до кінцевої мети з мінімальними втратами. Втрати можуть бути як в бюджеті, так і у людському ресурсі, в репутації.
До того, як з’явилися гнучкі методи управління проектами, найпопулярнішим методом був Waterfаll (каскадна модель або модель «водоспаду»). Основний принцип схеми управління проектами при Waterfаll — це перехід від етапу до етапу поступово, без можливості що-небудь змінити. Тобто: є проект, вимоги до нього, бюджет і т.д.
Проект має окремі етапи роботи і поки один етап незавершений — немає переходу до іншого.
Каскадна модель управління проектами виправдовувала себе до тих пір, поки не з’явилися гнучкі методи і не довели, що гнучкість в управлінні проектами — це мінімізація ризиків, збереження грошей, людського ресурсу і репутації (яка страждає в першу чергу, якщо проект «провалився»).
Особливості Agile методу в управлінні проектами
Щоб не було плутанини між Agile, Waterfаll, Scrum і Kanban, відразу скажемо, що гнучкий Agile — це як заміна неповороткому Waterfаll, а Scrum і Kanban — це вже інструменти Agile.
П’ять ключових особливостей Agile:
- Робочий процес — це короткі спринти від 1 тижня до 1 місяця.
- Зміни можна вносити в процесі роботи над проектом.
- На першому місці — готовий продукт і тільки після — документація.
- Під час роботи над проектом йде тісна взаємодія з клієнтом. Клієнт включений в робочі процеси і може контролювати їх на всіх етапах.
- Кожен учасник команди несе відповідальність за кінцевий результат реалізації проекту.
Scrum і Kanban — як інструменти реалізації проекту, спочатку прижилися в IT сфері, але як показує досвід інших сфер — вони багатофункціональні.
Наприклад Скрам і Канбан відмінно підходять для інженерії або виробництва.
Що потрібно для реалізації проекту на практиці
Так, як ми визначили основні переваги гнучкого Agile підходу і його інструментів для реалізації проектів, для практичного розгляду візьмемо Scrum і Kanban.
Більшість систем управління проектами (або таск-менеджерів) побудовані на основі гнучких інструментів реалізації проектів.
Наприклад Канбан, Діаграма Ганта, таймер, фіксація планових і фактичних витрат — всі ці інструменти всередині системи управління проектами забезпечують гнучке управління проектами та їх реалізацію з максимальною ефективністю на кожному окремому етапі.
Як застосувати Scrum в системі управління проектами
Коли всі проекти будуть додані в систему і розбиті на окремі задачі, саме час застосувати Scrum на ділі:
Одна задача = один спринт. Як ми вже писали вище, Scrum передбачає тривалість одного спринту від тижня до місяця. Якщо взяти за приклад розробку ПО, то сам процес розробки буде розбитий на окремі задачі, де за кожною задачею закріплений свій Виконавець і Відповідальний.
Незважаючи на наявність Виконавця і Відповідального за задачі (спринти), Scrum передбачає колективну відповідальність за фінальний результат по всьому проекту. Якщо дедлайн однієї задачі в рамках проекту, наприклад, зірваний, не шукають «крайнього» або винного. Відповідальність на команді. Такий підхід ідеальний для стартапів.
Власник компанії і скрам-майстер активно задіяні у всіх робочих процесах. Контроль і внесення змін (вчасно) лягає на плечі скрам-майстра. Якщо такої людини в команді ще немає, найчастіше її обов’язки повністю переходять в руки власникові компанії.
Ще скрам-майстра можна пізнати за іншою, більш поширеною назвою: project manager. Можна сміливо сказати, що всі бізнес-процеси за проектом — це зона відповідальності проджект менеджера.
Якщо хтось із робочого процесу «випав» — його роботу підхоплює інший. Це важливий принцип Scrum, так як спринти не повинні ставати на паузу.
Якщо проект масштабний і новий, на перших етапах його реалізації немає розуміння, скільки триватимуть спринти. Саме тому, учасники команди запускають таймер для окремих задач проекту, щоб фіксувати витрачений час.
Надалі, наявність зафіксованого часу роботи над задачами дасть можливість скорегувати спринти за схожими проектами.
Якщо передбачуваний час, закладений для задачі (спринту) виявився меншим фактичного (затреканного за допомогою таймера), можна внести зміни в процесі роботи. В цьому і переваги гнучкого підходу в проектному менеджменті — адаптивність на всіх етапах реалізації проекту.
Висновки Scrum підхід — це реалізація проекту швидко, з мінімальними ризиками і втратами.
Також це максимальна залученість в робочий процес учасників команди і розбивка проекту на окремі спринти (задачі) для деталізації, розуміння того, що і як відбувається на кожному окремому етапі і якщо в процесі реалізації щось пішло не так — визначити швидко причину і скорегувати процес.
Як застосувати Kanban в системі управління проектами
Якщо порівнювати Kanban і Srcum, то перший — більш гнучкий. Чому?
Канбан являє собою віртуальну дошку, по якій переміщуються задачі від етапу до етапу.
Тобто: головна цінність Канбан в тому, що ця дошка дозволяє відстежити, на якому етапі перебуває задача і що з нею відбувається.
Якщо задача затримується за термінами, також можна побачити, в чому причина. До появи систем управління проектами таких, наприклад, як Worksection, Канбан представляв собою звичайну фізичну дошку з кольоровими стікерами.
Зараз менеджмент управління проектами — це гнучкість і мінімум ризиків, на що Канбан впливає в першу чергу.
Чому Канбан важливий в управлінні проектами
Є можливість переходити від задачі до задачі, якщо у процесі роботи над однією задачею терміново потрібно зробити нову. Часто буває, що в процесі роботи над однією задачею, несподівано «прилітає» інша. Що робити: кидати першу і переходити до другої або другу ставити на очікування? Це питання легко вирішується, якщо простежити етапи реалізації проекту по Канбан і зрозуміти завантаженість команди.
Нові задачі потрапляють в беклог. Візуально це виглядає як колонка. Назвемо беклог, умовно, колонкою очікування. Всі нові задачі, які ще не прийняті в роботу, потрапляють в беклог.
Коли задачу взяли в роботу, вона потрапляє на перший етап реалізації і далі «подорожує» по іншим етапам (візуально це також виглядає як окремі колонки), поки не приходить до фінішу — задачу завершено.
Якщо інформація за задачею змінюється, ці зміни вносяться прямо в процесі роботи, не зачіпаючи при цьому інші задачі і процеси по ним.
Канбан, як інструмент реалізації проектів, гарний з усіх боків. Ще один плюс цієї дошки: немає потреби в частих нарадах і обговореннях етапів реалізації проекту (що вітається при Scrum підході).
На Канбан можна відстежити всі зміни і поточну ситуацію кожного окремого етапу, тому потреба в нарадах відпадає сама собою (а це, звичайно, економія часу).
Як виглядає Канбан
За кожну окрему колонку Канбан відповідає статус. Тобто: статус = етап реалізації задачі. Щоб задача могла переміщатися від етапу до етапу, вона повинна на старті мати статус і в процесі реалізації цей статус, як і етап, будуть змінюватися.
Висновки Kanban — це максимальна гнучкість робочих процесів, ідеальний інструмент для однотипних задач, можливість відстежити задачі на кожному етапі реалізації.
Якщо порівнювати Канбан і Скрам, то можна зробити висновок, що Скрам — більше про контроль, Канбан — про гнучкість. Для нових проектів з великою кількістю невідомих і для стартапів краще на перших порах дотримуватися Scrum підходу.
Коли з’являться однотипні задачі і процес роботи буде налагоджений, можна переходити до Канбан, як ключового інструменту гнучкого управління проектами.
Як протестувати інструменти гнучкого управління проектами
Ви можете зробити це прямо зараз, зареєструвавши акаунт на нашому сайті. Worksection — це система управління проектами, де гнучкість і керованість однаково важливі і доступні для ваших проектів.
Нам важливо, щоб ваша команда могла перейти до проектного менеджменту максимально м’яко.
Спробуйте перейти від хаосу до проектного менеджменту просто зараз.