У розробці софта до 1990‑х років все було передбачувано і зрозуміло: чітка послідовність робочих процесів, покроковий план, документація, тестування, реалізація кінцевого продукту.
Управління проектом було занадто неповоротким, а відхилення від чіткого плану порушувало увесь робочий процес.
Waterfаll (каскадна м одель або модель «водоспаду») і є неповороткою моделлю розробки програмного забезпечення з чіткою послідовністю дій і неможливістю «стрибнути» в наступний етап, поки повністю не завершено попередній.
Розробка в Waterfаll виглядає як потік процесів від етапу до етапу з чіткими вимогами. Поки не завершено один етап — немає переходу до іншого.
У 1990‑х роках на зміну неповоротким методам прийшло сімейство гнучких
Звичайно, ми говоримо про Agile (agile software development, від англ. Agile — гнучкий) методи розробки програмного забезпечення. Новий підхід до методології управління проектами увірвався в IT і пізніше перейшов у виробництво, інженерію, розробку штучного інтелекту і т.д.
Першими гнучкими методами були: RAD (з орієнтиром на якість при мінімальному бюджеті і обмеженому терміні), XP (екстремальне програмування з колективним володінням кодом), SCRUM (де кожен учасник команди несе відповідальність за результат), Kanban (візуалізація етапів розробки на дошці) та інші.
Чотири Agile-ідеї, які важливо знати:
- Люди в команді і взаємодія між ними важливіше процесів
- Взаємодія з замовником важливіша узгодження умов договору
- Працюючий продукт на першому місці. Документація — другорядна
- Готовність швидко реагувати на зміни важливіше заздалегідь затвердженого плану
Перш, ніж ми перейдемо до опису основних конкурентів Waterfall, їх переваг/недоліків для розробки і управлінні проектами, пропонуємо порівняльну таблицю Agile та Waterfall:
| Agile | Waterfall |
|---|---|
| Гнучкість робочих процесів і внесення змін за першої необхідності | Каскадна модель розробки з жорсткою послідовністю процесів |
| Готовий продукт важливіше документації | Документація важливіше готового продукту |
| Особиста відповідальність кожного учасника команди за результат | Відповідальність за результат в цілому на команді |
| Взаємодія з замовником в процесі розробки | Замовник не залучається до робочого процесу |
| Максимальне залучення власника продукту в робочий процес | Власник продукту мінімально задіяний в робочому процесі |
| Робочий процес розбивається на короткі спринти. Зазвичай від 1 тижня до 1 місяця | Кожен робочий процес — окрема фаза, яка триває до тих пір, поки не проходить етап тестування і схвалення |
Популярні системи управління проектами в Agile
Розглянемо ті, які «прижилися» і найчастіше використовуються в розробці софта.Scrum
Гнучкий підхід до розробки софта, де одна задача — один спринт. Спринт при Скрам підході може тривати від 1 тижня до 1 місяця.
Для кого підходить Scrum?
Для невеликих компаній або відділів, де власник компанії або керівник відділу може фізично «ключитися» в робочий процес і бути його активним учасником. Також цей метод ідеальний для стартапів.
При використанні методу Scrum в проектному менеджменті складно знайти відповідального або винного за невиконання задачі. Відповідальний за результат кожен з учасників команди, а самоорганізація стає пріоритетною для формування робочих процесів.
Команда, яка обрала для управління проектами Scrum, повинна бути готова до максимальної гнучкості. Тобто, якщо один з учасників команди на деякий час «випав» з робочого процесу, його обов’язки по задачам або проектам повинен підхопити інший.
Скрам-майстер — проектний менеджер і ключова ланка в команді. На ньому: організація бізнес-процесів, зборів, мотивація команди, швидке реагування на зміни і вирішення поточних питань.
+ Плюси
Софт розробляється швидше, залучення кожного учасника команди максимальне, знижується вартість розробки за рахунок поділу робочого процесу на короткі спринти.
— Минуси
У Scrum немає жорстких рамок і вимог, але є місце експериментам, мінливим бюджетам і термінами. У роботі з клієнтами, для яких важливий чіткий план і наявність договору Scrum не підійде.
Наприклад: якщо потрібно створити продукт для державної організації, де укладення договору пріоритетне — Scrum не підійде. Тут звіти на передостанньому (і навіть останньому) місці. На першому: готовий продукт і тільки після — документація, звіти про роботу і тд.
Приклад управління проектами за методом Scrum
Є задача: створити програмне забезпечення в найкоротші терміни. Робочий процес ділиться на спринти. Кожен спринт закінчується демонстрацією готового результату. Крім того, в скрам-спринтах важливі збори і наради, на яких можна підвести проміжні підсумки та переходити до наступного спринту.
Контроль швидкості завершення спринтів — важливий елемент Scrum.
Щоб розуміти, скільки триватиме той або інший спринт, на старті спринту учасники команди можуть запускати таймер. Фіксація часу, витраченого на одну задачу, дасть розуміння необхідного часу для виконання однотипних задач. Достатньо заклали часу для задачі чи ні?
Kanban
Візуалізація робочого процесу і поетапне переміщення задачі від «Прийнято в роботу» (наприклад) до «Готово». Між цими двома станціями може бути ще кілька: «Розробка», «Тестування», «Оптимізація» і т.д. Канбан візуально представляє собою дошку, по якій ми перетягуємо однотипні задачі зі станції на станцію. І коли задача приходить на кінцеву станцію «Готово» — вона завершена.
Kanban — максимальна гнучкість і адаптація до змін в будь-який момент.
Scrum і Kanban — гнучкі підходи до управління проектами. Але Канбан, все-таки, більш гнучкий і ось чому:
- Допускає раптове надходження нових задач «переключення» між ними.
- Колективна відповідальність за результат підвищує ефективність роботи.
- Незаплановані задачі потрапляють в беклог. Це місце зберігання всіх задач, які ще не прийняті в роботу і не запущені по Канбан. Візуально беклог виглядає точно такою ж колонкою, як і інші етапи робочого процесу. Якщо якісь з етапів будуть завершені раніше запланованих термінів, задача з беклогу одразу потрапляє на першу станцію (етап) «Прийнято в роботу».
- Є місце для експериментів і невідомості в проектах або задачах. Якщо в процесі роботи над задачею з’являться нові дані, Канбан дозволяє швидко адаптуватися і продовжити роботу над задачею, не порушуючи в цілому робочий процес.
+ Плюсы
На відміну від Scrum, Канбан не вимагає регулярних нарад, переговорів і обговорень спринтів. Це заощаджує час і додає ефективності робочого процесу, де візуально на дошці видно всі етапи і немає потреби в додаткових обговореннях.
Гнучкість Канбан — краще, що можна придумати для ведення проектів з частими змінами вихідних даних або постійним потоком нових задач.
Ще про Kanban говорять як про підхід до управління проектами з позиції балансу: кожен має свою роль і якщо хтось перевантажений або навпаки, залишився без задач, все це видно на дошці.
— Минусы
Працювати з великими проектами по Канбан буде складно. Для таких проектів важливо дивитися проміжний результат, розбивати робочий процес на короткі спринти, затверджувати покроковий план дій заздалегідь і прописувати все в договорі. Тобто, Канбан — це більше про нетривалі проекти та короткі задачі.Приклад управління проектами по Канбан:
Є задача: зняти навчальне відео для клієнта. Для зйомки відео буде створено ряд однотипних задач: “Написання сценарію”, “Зйомка”, “Чорновий монтаж”, “Пост-обробка”. Кожна із задач на Канбан дошці буде окремою колонкою.
Як правило, при використанні Канбан методу, немає жорстких обмежень по часу для кожного окремого етапу. Але команда орієнтується на середній час роботи над кожним окремим етапом. Чим швидше — тим вище ефективність в цілому.
Канбан або Скрам? Яка система управління проектами потрібна
Вище ми описали плюси і мінуси цих двох гнучких методів, але є ще один цікавий нюанс:
Якщо Kanban — це максимальна гнучкість, то Scrum — більше про контроль і керованість. Коли процес налагоджений і все зрозуміло — приходить на допомогу Канбан. Він ідеальний для роботи з однотипними задачами.
Коли продукт новий і робочі процеси тільки-тільки налагоджуються — краще використовувати Scrum, щоб в разі різкої «турбулентності» швидко реагувати, утримувати контроль, вносити зміни і завершувати задачі далі з мінімальними втратами.
Scrum підхід до управління проектами передбачає більш тісну комунікацію. Це означає, що кожен учасник команди може ставити питання по задачам і тільки після повного занурення розпочинає роботу.
Як обрати інструмент управління проектами?
Правильний вибір таск-менеджера — половина успіху. Як тільки ви визначилися з методом управління проектами і обрали таск-менеджер, важливо перевести роботу над проектами та задачами в обрану систему. З чим стикаються керівники при переході до проектного менеджменту?
Команді непросто освоїти функціонал таск-менеджера і тому продовжуються листування в месенджерах, електронною поштою, ставляться усні задачі. На допомогу приходить навчання, що надається самою компанією таск-менеджера, внутрішні інструкції або навчальні тренінги, організовані відповідальним всередині команди.
Хтось сприймає роботу в таск-менеджері — як додатковий контроль і недовіру. Тут важливо пояснити всій команді, що таймер, наприклад, це необхідність, а не контроль або недовіра. Таймер — це як додатковий інструмент для поліпшення ефективності роботи, прозорості процесу та результату для клієнта.
До речі, таймер — це ще й можливість обґрунтувати необхідність в оплаті праці понад норму (якщо для виконання задачі знадобилося більше часу, ніж заклали спочатку).
6 ознак того, що таск-менеджер обраний правильно:
- Команда максимально безболісно перенесла всі робочі процеси в акаунт
- Функціонал інтуїтивно зрозумілий і використовується учасниками команди
- Команда легко використовує один з гнучких підходів в управлінні проектами: Scrum або Канбан
- З’явилася систематизація робочих процесів і збільшилася загальна ефективність
- Комунікація з командою стала більш злагодженою: проекти, задачі і коментарі до них не втрачаються
- Клієнт отримує зворотний зв’язок у вигляді прозорого звіту за задачами та проектами і може відстежувати робочі процеси, якщо у нього є такий запит
Щоб зрозуміти, як працюють гнучкі методи управління проектами, протестуйте таск-менеджер безкоштовно та оберіть те, що максимально підходить для вашої команди.