Управління проєктами в IT: найкращі методології та практики
Коли компанія розробник розпочинає створення ПЗ, одним з перших завдань після визначення характеристик проєкту та основних інструментів розробки, є вибір ефективної методології управління проєктами. Методологія це стратегічний підхід до адміністрування та розподілу ресурсів, використання систем практик до організації роботи команд залучених до проєкту. На практиці застосовують одну або комбінацію декількох методологій, які давно довели свою ефективність. Ми розглянемо розповсюджені типи управління проєктами та визначимо доцільність їх застосування в певних умовах розробки.
Як правило за менеджмент проєктів відповідає project manager та technical lead (тім лід). Тому, одним з важливих етапів вибору методології розробки є первина оцінка потреб замовника, оцінки конкурентних рішень, план технологічних впроваджень, масштаб програмного продукту й тощо. Найчастіше цю оцінку проводять менеджер та технічний спеціаліст, узгодив усі деталі — вони визначають який підхід управління проєктом буде раціональним за отриманих умов.
Менеджер враховує кількість спеціалістів в команді, їх фахове направлення та етап на якому кожного спеціаліста буде залучено. Менеджер має враховувати форс-мажорні обставини, або різке масштабування проєкту яке тягне за собою залучення нових спеціалістів. Задача менеджера забезпечити кожного нового фахівця, який долучається до команди, забезпечити інформацією що до проєкту. Правильно обрані концепції управління проєктами спрощують процес інтеграції. Використання дощок задач, збереження ітерацій, класифікована технічна документація — пом’якшують процес ознайомлення з проєктом та загалом оптимізують процес.
Пропонуємо розглянути 14 моделей управління які використовуються розробниками для створення ефективних програмних рішень. Методи відрізняються за структурою та організацією. На перший погляд, деякі з них можуть бути дуже схожі, але мати відмінності які визначають критичні аспекти впливу не результативність обраної методології.
Водоспад або каскадна модель одна з найстаріших методологій розробки з чіткими етапами та правилами. Ця модель характеризується лінійністю процесів. Команда не може передати процес розробки на наступний етап до завершення поточного. Такий підхід вважають застарілим і часто критикують. Каскадна модель закладає тестування на останньому етапі, таким чином можуть виявитись проблеми які були допущені через помилки на етапах дизайну або навіть аналізу. Власне, зміни вносити вкрай складно. Проте вона все ще не полишає переліки та топи. Це пов’язано саме з його дисциплінованим процесом управління й веденням документації, і подекуди використовується для створення великих інженерних проєктів та систем. Під час розробки ПЗ чи мобільних застосунків, IT компанії обирають інші типи управління проєктами.
Ця методологія найпопулярніша серед розробників і має декілька підтипів. ЇЇ головні стовпи: гнучкість, комунікація та ефективність. Методологія заснована на постійних ітераціях до моменту релізу застосунку на ринок. Наприклад, команда аналізує та обговорює ідеї, створює дизайн та вносить інформацію до документації, проводить розробку та створює першу версію продукту (демо), потім проєкт віддають на тестування й аналізують отриманий результат (тобто ітерація завершилась). Щоб цей процес не ставав циклічним та нескінченим, Agile характерно розділяти проєкт на тижневі терміни. Наприклад, одна ітерація не може проводитись більше ніж 2 тижні.
Методологія Agile залучає до процесу замовника для отримання зворотного зв’язку. Команда можуть задовольнити потреби в змінах, наповнювати проєкт інноваційними ідеями та експериментувати, коли проєкт це дозволяє. На відміну від Каскадної моделі, гнучка модель дозволяє швидко та ефективно виправляти недоліки ПЗ. Проте, іноді це може посунути терміни реалізації. Задача менеджера слідкувати за тим, щоб терміни випуску продукт на ринок залишались сталими, або вчасно узгодити подібні зміни із замовником.
Система управління проєктами керується такими ж принципами що й Agile, але пропонує ще коротші ітерації, які називають спринтами. Методологія підходить для інноваційних та стартап проєктів незначного розміру, а від команди вимагає постійної комунікації, оскільки спринт може тримати всього тиждень. Підходи Kanban та Scrumban використовуються командами які надають перевагу Agile, і в першу чергу незначно відрізняються організаційними та візуальними аспектами.
Lean або ощадливий розробка зосереджена на усунені втрат та на оптимізації процесів. ЇЇ мета за високої ефективності зменшити споживання ресурсів та розподілити їх навантаження. Відповідно, з великими проєктами цей підхід управління працює погано.
Extrime programming – використовують для гнучких проєктів зі стислими термінами. Методологія враховує усі етапи програмування розподілені на кілька місяців до повної реалізації. Якість коду та тестування — передусім. Іноді за таких умов страждає дизайн. На жаль ця методологія не підходить для візуально складних проєктів, а стислі строки розробки вимагають команду висококваліфікованих експертів. Крім того, замовник також має підтримувати постійний зв’язок з командою. МетодологіяXP гнучка тому дає волю для пошуку та інтеграції свіжих рішень. CPM та CCPM є чудовою альтернативою цьому методу, бо чіткіші своїми вимогами.
Rapid application development – ітеративна методологія розробки ПЗ, яка так само спрямована на швидку розробку й прототипування. Порівняно до попереднього підходу, RAD надає більше уваги дизайну й орієнтується на потреби кінцевого користувача. Ця модель управління дозволяє здійснювати швидкі цикли розробки, що призводить до швидшого виведення додатків на ринок. Але, ефективність моделі значною мірою залежить від наявності інструментів та фреймворків швидкої розробки, а також досвідчених розробників.
Feature driven development це також різновид гнучкого підходу, яка зосереджена на наданні невеликих функцій або функціональних блоків. Попри свою природу цей підхід найменше залучає замовника до процесів. Але команда ретельно веде документацію за кожним функціональним етапом.
Методологія DSDM або Dynamic systems development – це ще одна проєктна методологія створена на принципах RAD, проте акцентується на управлінні ризиками. За такої методології команда визначає термін, якість та вартість як фіксовані параметри, та не змінює їх. Пріоритети встановлюються за системою 1) Must have; 2) Should have; 3) Could have; 4) Won’t have (currently). Таким чином команда розкладає потреби проєкту та вимоги замовника на категорії за необхідністю інтеграції. Методологія забезпечує своєчасну доставлення завдяки суворому дотриманню термінів. А проєкт може адаптуватись та продовжувати свою роботу навіть за наявності обмежень.
Як зрозуміло з назви, ця методологія сконцентрована на принципах створення прототипу, коли про проєкт мало відомо, а певні терміни та вимоги просто відсутні. Замовник може побачити майбутній вигляд продукту, а команда може швидко виявити проблеми та внести правки.
Сучасні методи управління проєктами дуже різноманітні та адаптовані під потреби команд, особливості проєктів та технологічні інструменти.
Підіб’ємо підсумки. Кожна описана вище методологія використовується на сучасному IT ринку, що вже доводить їх ефективність. Проте, ризик обрати методологію яке не відповідатиме пріоритетам проєкту та типу команді — все ще існує. Ми пропонуємо простий алгоритм для вибору найефективнішої методології проєктного менеджменту під ваші потреби.
| Модель | Тип проєктів | Проблематика | Вимоги до Команди |
|---|---|---|---|
| Waterfall | Сталі проєкти, чіткі вимоги та ясно визначені задачі. | Відсутня гнучкість до масштабування та змін | Для кожного етапу є кваліфікований спеціаліст, який повністю відданий своєму етапу |
| Agile | Гнучкі, інноваційні, та динамічні проєкти | Може не працювати на великих проєктах коли залучена дуже велика команда. Проте якщо комунікація налагоджена ця проблема незначна. | Команди з високим рівнем налагодженої комунікації. |
| Scrum | Гнучкі, інноваційні, та динамічні проєкти | Складні проєкти в високорегульованих галузях з жорсткими термінами реалізації. | Команди до 10 осіб, з можливістю підтримувати часту комунікацію. |
| Lean | Малі та середні проєкти націлені на ефективність та скорочення витрат | Великі проєкти з розлогою документацією | Невеликі команди та налагоджений зв’язок замовником |
| XP | Малі, іноді середні проєкти орієнтовані на користувача. Проєкти, в яких замовник не уявляє кінцевого продукту. | Проєкти в високорегульованих галузях з жорсткими термінами реалізації. | Малі та середні команди з високим рівнем креативності та широкими технічними навичками. |
| RAD | Малі та середні проєкти які мають вийти на ринок за короткий термін | Відсутність чітких вимог, постійна потреба в затвердженні від замовника. Не підходить під проєкти в високорегульованих галузях з жорсткими термінами реалізації. | Команда має вміти працювати в стислих умовах, та повністю віддана проєкту. |
| Prince2 | Корпоративні проєкти масштабного розміру, продуктові та маркетингові проєкти. | Не підходить під малі проєкти та критично малі команди. Маловідомий спеціально розроблений підхід. | Середні та великі команди. |
| Kanban | Гнучкі, інноваційні, та динамічні проєкти малих та середніх розмірів. | Проєкти в високорегульованих галузях з жорсткими термінами реалізації. | Віддалені команди різних розмірів |
| FDD | Великі та гнучкі проєкти. | Не підходить під малі проєкти та критично малі команди. Іноді, менш ефективний за великих проєктів при чітких вимогах. | Середні команди |
| DSDM | Середні та великі проєкти зі стислими термінами розробки, але з гнучкими вимогами. | Не підходить під малі проєкти та критично малі команди. Іноді, менш ефективний за великих проєктів при чітких вимогах | Команда має вміти працювати в стислих умовах та комунікувати з розробником. |
| Прототипна модель | Створення прототипів, відсутність чіткого бачення продукту | Високо регульовані проєкти та проєкти з чіткими вимогами | Досвід створення прототипів |
| CPM, CCPM | Підходить для детермінованих, добре спланованих проєктів й обмеженими ресурсами | Не підходить для проєктів з високою невизначеністю (стартап) | CPM- малі та середні команди; CCPM – середні та великі команди. Головна мета мінімізувати багатозадачність |
Компанія PNN Soft займається кастомною розробкою вже понад 20 років. За цей термін ми реалізували стартап проєкти, власні авторські продукти, великомасштабні ПЗ та системи для високорегульованих галузей, ERP системи для банкінгу/фінансів, а також безліч цікавих рішень для ритейлу та електронного навчання. Наші команди активно вивчають сучасні технологічні тренди та готові швидко адаптуватись до змін, проти для управління розробкою проєкту ми надаємо перевагу Agile, Scrum, RAD та FDD. Щоб замовити кастомну розробку вашого програмного рішення, чи це масштабний проєкт, або свіжий стартап — заповніть форму нижче. PNN Soft готовий втілити ваші ідеї у реальність.
