Управління ІТ-проєктами: повний посібник для менеджерів та підприємців

Коли розглянути питання управління ІТ-проєктами принципово, то, з одного боку, воно таке саме, як і будь-який інший тип проєктного управління. Тут також вимагається ретельне планування, командна робота, контроль діяльності кожного співробітника тощо. У сфері ІТ теж використовують типові методології та певні інструменти, щоб зменшити ризики та збільшити вірогідність успіху.

З іншого боку, ІТ-проєкти містять складні технічні елементи, такі як розробка програмного забезпечення, мережева інфраструктура, системна інтеграція і т. ін. Вони потребують не лише спеціальних знань, але й досвіду роботи в даній галузі. Те ж саме можна сказати про тестування розробок на різних стадіях та подальше забезпечення працездатності продукту. Ефективне управління проєктами — важливий фактор, що є складовою успіху фірми на ринку ІТ-технологій. Воно допомагає швидко адаптуватися до мінливих вимог навколишнього середовища та адекватно сприймати технологічні інновації.

Управління ІТ-проєктами

Типи людської діяльності

Всю людську діяльність можна розділити на два види: процесну та проєктну. До першої належать операції, що являють собою багаторазове повторення певного алгоритму. Приміром, виготовлення тортів за наданими рецептами. Або пошиття готового плаття за наявними моделями. До другої відносять створення якогось унікального продукту. Для вже згадуваних прикладів це може бути розробка оригінального рецепту або нової моделі.

Процесна діяльність монотонна, повторювана і стабільна. Вона потребує певної професійної кваліфікації, бо трапляються невизначені ситуації. Наприклад, карбюраторник в автопарку має спочатку зрозуміти причину некоректної роботи вузла, щоб знати, як його полагодити. Але він не створює нічого нового і працює за готовими схемами. В багатьох випадках процесну діяльність взагалі можна поставити «на конвеєр».

Проєктна робота різноманітна, унікальна та мінлива. Вона складніша за процесну, бо треба спочатку визначитися зі стратегічним напрямком, а під час реалізації ідеї доводиться щоразу вирішувати складні, а головне — нетипові завдання. Її неможливо побудувати так, щоб всі елементи виконувалися згідно розробленої інструкції, тому й цінується вона вище процесної. Щоб в цьому переконатися, досить порівняти платню швачки на трикотажній фабриці із доходами популярного модельєра.

Види ІТ проєктів

Стрімке сьогодення диктує нові правила гри кожному бізнесу. Згідно сучасних умов, кожній компанії потрібні ІТ технології, від email та додатків до застосунків для керування даними або ланцюжком поставок. Навіть коли фірма безпосередньо не орієнтована на електроніку, все одно вона має придбати ПЗ для управління замовленнями, мережу для виходу в інтернет тощо. Щоби бізнес мав високі шанси на досягнення загального успіху, кожне технологічне завдання для команди айтішників має бути виконане належним чином. Саме для цього й необхідне управління ІТ-проєктами.

До ІТ-проєктів належать процеси розробки, впровадження, доопрацювання та обслуговування будь-якої системи, від програмного чи апаратного забезпечення до мережевої інфраструктури. Ще один тип — інтеграція вже існуючих систем. Наприклад, коли необхідно об’єднати два програмні продукти, або масив даних з однієї системи перенести в іншу. Мета кожного проєкту в сфері ІТ полягає в тому, щоб з його допомогою покращити роботу підприємства — як загалом, так і окремих процесів. Наприклад, впорядкувати взаємодію з клієнтами, забезпечити ефективний складський облік, зменшити витрати, покращити якість послуг і т. ін. В залежності від потреб замовника ІТ-проєкти можуть мати різні форми виконання. Приміром, для створення ІТ-інфраструктури може знадобитися розробка ПЗ, щоб автоматизувати якийсь із процесів. Або в проєкті може бути впровадження нових технологій чи обладнання — серверів, мережних пристроїв, систем зберігання даних тощо.

Ризики, що загрожують ІТ-проєктам

Військові кажуть, що «будь-який план битви гарно працює до першого пострілу». В проєктній діяльності спостерігається приблизно те ж саме. Можна скласти найкращий план роботи, проте вона ніколи не йде призначеним шляхом. Керівництво проєктом, особливо тривалим — це постійне балансування між великою кількістю обмежень. Це сфера, в якій лімітується буквально все: бюджет, виконавці, терміни і т. ін. І якби ж тільки обмежувалося, а то ще й змінюється на протязі виконання, як наприклад, технічні вимоги. Ось кілька найбільш поширених ризиків, що можуть вплинути на успішне виконання ІТ-проєкту:

1. Технічні. Завдання від замовника може бути доволі складним для виконання. Члени ІТ-команди можуть виявитися не досить досвідченими та підготовленими. Існує небезпека некоректного вибору інструментів чи технологій для досягнення мети. Не слід виключати можливість несумісності різних систем та технічних неполадок.
2. Бюджетні. З проєкту пішли спонсори, партнери відмовилися від співпраці або просто вичерпано бюджет. Останнє може бути через незаплановані перевитрати, нераціональний розподіл коштів, неочікувані витрати, коливання курсів валют, інфляцію та з інших причин. Все це веде до фінансовій стабільності проєкту, коли загроза неможливості подальшої роботи постає на повний зріст.
3. По терміну завершення роботи. Зазвичай під час реалізації ІТ-проєкту команда має вкластися в доволі жорсткі строки. Нерідко це буває важко через можливі різноманітні затримки. Може мати місце залежність від результатів по іншим проєктам. Також впливають зовнішні фактори, незалежні від керівника.
4. Зміна вимог. Інколи замовник від самого початку висуває не дуже конкретні вимоги або в процесі розробки змінює деякі важливі пункти чи параметри. Така невизначеність змушує переглядати початкові плани, що закінчується збільшенням витрат та часу, потрібного на виконання нового варіанту.
5. Недостатньо ресурсів. Мається на увазі все. З проєкту пішли головні розробники, а в тих, що залишаються, недостатньо кваліфікації. Можливо, відсутнє необхідне обладнання чи програмне забезпечення.
6. Помилки. Вони трапляються часто, і коли їх не виявляти одразу, то в роботі системи можуть виникнути серйозні проблеми. На їх ліквідацію піде більше часу, якого й так не вистачає.
7. Залежність від постачальників та зовнішніх контрагентів. Тут все зрозуміло, кажуть одне, та інколи не виконують обіцяне. І справа не лише в тому, що час не чекає. Невідповідність номенклатури може негативно вплинути на якість виконання проєкту.

Можуть бути й інші вагомі причини. На результат роботи впливають зміни політичних чи економічних обставин. Бізнес середовище, в якому обертається замовник, зазвичай нестабільне. Через це мета клієнта може змінитися до такої міри, що проєкт виявиться непотрібним. Якщо казати загалом, то, звичайно ж, не можна повністю виключити наявність в ІТ-проєктах ризиків та невизначеності. Але за допомогою правильного аналізу, планування та управління ними можна не тільки суттєво знизити їхній вплив на проєкт, але й забезпечити його успішне виконання.

Project management

Проджект менеджмент в ІТ, як і в інших галузях, являє собою процес планування проєктів, організації їх здійснення, координації зусиль різних ланок команди та контроля за діяльністю спеціалістів з метою досягнення поставленої мети. Все це робиться в сфері інформаційних технологій, а отже, з урахуванням особливостей, що з ними пов’язані.

Керування ІТ-проєктом дає можливість чітко визначити мету й завдання, розробити ефективний план дій для їх досягнення, забезпечити узгоджені дії не лише співробітників команди, але й інших зацікавлених сторін. А також своєчасно реагувати на несподівані зміни обставин та ризики, контролювати хід роботи та максимально ефективно використовувати ресурси. Під час планування встановлюється не якась загальна мета, а цілком конкретна величина, відчутна в часі й просторі, з певними фізичними параметрами й функціональними характеристиками, на кшталт: «До ось такого часу ми повинні створити ось такий продукт». І все це неодмінно з досить високим рівнем якості. Щоб виконати завдання, керівник:

1. Приймає участь у плануванні — визначенні мети, завдань та заходів, спрямованих на реалізацію проєкту.
2. Обирає найкращий метод управління. Підходів до вирішення питань існує чимало і далеко не завжди ті, що добре працювали в минулому, так само гарно підходять сьогодні.
3. Координує роботу на всіх етапах.
4. Оптимізує використання ресурсів. Чим більш масштабний проєкт, тим більших він вимагає вкладень, притому не лише фінансових, а ще й технічних та інтелектуальних. Планування й подальша оптимізація дають можливість зменшити витрати і, як наслідок, знизити вартість та скоротити терміни виконання.
5. Складає «План Б» щоб мінімізувати ризики. Випадки, коли щось іде «не так», трапляються не так вже й зрідка. В разі нештатної ситуації краще, коли є напоготові запасний варіант замість того, щоб довго й напружено думати, як «гасити пожежу».
6. Спілкується із зацікавленими сторонами, в першу чергу з представниками замовника чи ним самим. Це вкрай необхідно для результативної роботи.
7. Вимірює продуктивність колективу. Для цього керівник має розуміти, який обсяг роботи може виконати керована ним команда. Допомагає метрика Velocity, що показує обсяг успішно виконаної роботи в годинах. Ця характеристика дозволяє більш точно планувати завдання.
8. Швидко й ефективно вирішує проблеми, що виникають в процесі роботи. Для цього бажано їх вчасно виявляти, тобто треба не лише тримати «руку на пульсі», а ще й мати достатній рівень кваліфікації.
9. Контролює терміни виконання, бюджет і зміст роботи згідно моделі проєктного трикутника*. В ній ці елементи тісно пов’язані між собою. Коли змінюється один із них, то слід міняти й обидва інших, інакше трикутник не зійдеться.
10. Мотивує команду на продуктивну роботу, докладає зусиль до створення сприятливої атмосфери, стимулює співробітників на досягнення результату.

*Проєктний трикутник показує взаємозв’язок між часом, грошима та обсягом робіт, які впливають на якість проєкту. Зміна одного з параметрів впливає на інші.

Начебто такі ж дії виконує керівник будь-якого проєкту. Але в даному випадку на них накладається особливість роботи в сфері ІТ, а саме — більша кількість правок, ніж деінде, вища складність завдань, мінливість обставин, аж до кардинальної зміни завдання включно, необхідність виконувати певні етапи процесу не по одному разу тощо.

Хто входить до команди ІТ-проєкту

В широкому розумінні, коли вести мову про всіх, хто має відношення до проєкту від виникнення ідеї до її остаточної реалізації, можна виділити три групи:

1. Стейкхолдери

Це організації чи окремі особи, рішення яких суттєво й безпосередньо впливають на виконання проєкту. Коли останній є замовним, то в дану групу входять клієнт та його юристи, інвестори, директори (фінансовий, комерційний) і т. ін. Приміром, фіндиректор має право коригувати бюджет, а юрист компанії-замовника — накласти заборону на зберігання даних користувачів на іноземному сервері. Також до стейкхолдерів належать партнери, підрядники, постачальники, державні регулюючі організації тощо. Дехто вважає (і, напевно, небезпідставно), що в цю категорію входять ЗМІ.

1.1. Замовник чи ініціатор проєкту

Це теж стейкхолдери, бо доля проєкту в значній мірі залежить від їх рішень. Але оскільки, крім впливу на хід реалізації, вони взагалі започатковують роботу по даній темі, то інколи їх виділяють в окрему підгрупу.

2. Виконавці

Це команда спеціалістів, яка працює над проєктом.

2.1. Project manager

Це керівник, який працює над проєктом від обговорення вимог замовника й до завершення роботи. Він єдиний, хто бачить проєкт цілком, бо знаходиться немовби «над усіма». Він в курсі справ про всі процеси в команді. Він організовує роботу й оптимізує окремі ланки, контролює якість і терміни виконання. Фактично — він один із членів команди, але через специфіку роботи його теж інколи виокремлюють.

3. Користувачі

Це люди чи організації, що будуть користуватися продуктом, який з’явиться внаслідок реалізації проєкту, і отримуватимуть з нього користь. Тобто, це покупці й споживачі. Ними можуть бути співробітники замовника, якщо проєкт призначений для потреб його компанії.

Коли ж говорити у вузькому значенні, тобто лише про команду виконавців разом із їхнім керівником, то в неї входять такі спеціалісти:

• Проєктний менеджер, тобто керівник. Його функції розглянуті вище.
• Бізнес-аналітик. Збирає та аналізує вимоги клієнта, формує технічне завдання, допомагає узгоджувати мету.
• Менеджер по ресурсам. Планує та розподіляє ресурси команди в рамках бюджету й терміну виконання, починаючи з визначення складу учасників та відповідності їх професійних навиків вимогам проєкту. Контролює і оптимізує використання ресурсів.
• Системний адміністратор. Забезпечує роботу мереж та серверів, налагоджує доступи й безпеку, підтримує інфраструктуру проєкту.
• Технічний архітектор. Розробляє архітектуру проєкту, визначає технології для її реалізації та необхідні інструменти, забезпечує стійкість системи та її масштабування.
• Розробники (фронтенд-, бекенд-, мобайл-, веб-). На них лежить головна відповідальність за розробку ідеї та її реалізацію. Вони слідкують за тим, щоб продукт відповідав меті й завданням клієнта, мав певні можливості та задовольняв конкретні потреби. Пишуть коди, пропонують найефективніші технології та інструменти. В групі розробників може бути тімлід, який нею керує.
• Тестувальник (QA-аналітик). Визначає перелік необхідних тестів та використовує їх для перевірки безпечності, продуктивності й функціональності продукту. Пише звіти, збирає дані тестування й перевіряє, чи розробники виправили помилки.

Крім вказаних можуть бути й інші спеціалісти: контент-менеджер, маркетолог тощо.

Принципи управління ІТ-проєктами

Щоби забезпечити структурований підхід до реалізації проєкту, бажано під час роботи дотримуватися певних принципів. Нижче наведені сім основних:

1. Чітке визначення мети. Всі члени команди повинні добре розуміти, що має бути на виході. Наприклад, вони розробляють новий веб-застосунок, за допомогою якого можна буде краще керувати базою даних. В цьому плані важливо сформувати єдине бачення проєктних дій згідно обраного фреймворку. Це стане основою для ефекту синергії дій різних спеціалістів, коли результат складання їх зусиль перевищує просту арифметичну суму, тобто 2 + 2 = 4,5 або навіть 5. Як наслідок — помітне підвищення загальної продуктивності команди.
2. Планування дій та контроль виконання. План має бути детальним, із розписаною послідовністю завдань, визначенням відповідальних та термінами здачі. Процес реалізації слід регулярно контролювати по кожній групі та по кожному етапу розробки, відслідковувати прогрес і, при необхідності, коригувати роботу. Наприклад, впровадження принципово нової системи обліку прибутків може складатися з етапів розробки, тестування ті запуску програми.
3. Оптимальний розподіл ресурсів. В ІТ-проєктах має особливе значення найкраще використання часу, фінансів та зусиль спеціалістів. Наприклад, під час створення мобільного застосунку може бути потрібна взаємодія не лише дизайнерів, розробників і тестувальників, але також менеджерів по ресурсам та по продукту (маркетолога).
4. Керування ризиками. Це поняття містить у собі не тільки ідентифікацію можливих проблем, але також їх аналіз та заходи, що попереджуватимуть їх виникнення чи хоча б суттєво зменшуватимуть негативний вплив. Наприклад, під час розробки нового ПЗ можуть виникнути певні технічні проблеми або клієнт побажає внести зміни у початкові вимоги (останнє, правда, передбачити зовсім не просто). Важливо заздалегідь визначити можливі ризики та виробити стратегію їх нівелювання.
5. Командна робота. Полягає у створенні постійних комунікативних зв’язків між окремими ланками колективу. Наприклад, постійний обмін інформацією між розробниками, менеджерами, тестувальниками тощо та регулярні наради допомагають не лише синхронізувати роботу всіх спеціалістів, але також швидко й ефективно вирішувати нагальні питання.
6. Гнучкість, адаптивність до змін. В ІТ-проєктах нерідко виникають ситуації, коли ринкова ситуація змінюється так, що результат доводиться пристосовувати но нових умов. Або замовник вирішує поміняти дизайн сайту чи функціональність застосунку. Команда повинна вміти швидко реагувати на подібні новації.
7. Участь зацікавлених сторін. В якості прикладу можна навести випадок із розробкою нового ПЗ. Взаємодія з майбутніми користувачами дає можливість отримати зворотний зв’язок та краще врахувати їх потреби.

Дотримання вказаних принципів дає можливість зосередити зусилля виконавців у єдиному напрямку, зменшити ризики, оптимізувати ресурси і т. ін., за рахунок чого суттєво підвищує вірогідність досягнення поставленої мети.

Стандарти управління ІТ-проєктами

Управління ІТ-проєктами бажано здійснювати відповідно до стандартів. Найбільш поширеними є:

1. РМВОК (Project Management Body Of Knowledge, Збірник знань з управління проєктами). Його видає та поновлює PMI (Project Management Institute, Інститут управління проєктами). РМВОК є базою для отримання сертифікату РМР (Project Management Professional) від РМІ, що високо цінується в усьому світі.
2. PRINCE2 (PRojects IN Controlled Environments, Проєкти в контрольованих середовищах) версія 2, 1996 р. вип. Наразі актуальна версія — PRINCE2 6th Edition (2017 рік). Це державна розробка (агенція ССТА, 1989 рік), що базувалася на PROMPT 1975 р. вип., доопрацьована представниками бізнесу. PRINCE2 являє собою головний стандарт project management Великобританії, він поширений в США та інших країнах.

Ці стандарти не обов’язкові до застосування, але будь-який з них сприяє успішній реалізації проєкту.

РМВОК

РМВОК допомагає систематизувати знання професійного менеджера. Це докладна база знань, в якій описані інструменти для роботи в project management. У 2021 році вийшло 7-ме видання втричі меншого об’єму зі зміненою структурою документу. Воно не скасовує 6-ту версіюю. Cьома версія книги відрізняється від попередніх тим, що в її основу лягли не процеси, а принципи. Це кардинально змінило структуру та підхід до проєктного менеджменту загалом. Cьома версія PMBOK Guide доступна багатьма мовами, а з початку 2022 року й українською мовою. Посилання на скачування в пдф.

РМВОК (Project Management Body Of Knowledge)

РМВОК містить три базових елементи: процеси, групи процесів та галузі знань, притому останні два фактично є класифікаціями першого. Процесів всього сорок дев’ять, на їх основі вибудовують управління проєктом. Груп процесів п’ять: ініціації, планування, виконання, моніторингу та контролю, закриття. Крім першої, вони зазвичай циклічні (PDCA або цикл Демінга). Галузей знань десять. Кожна містить опис «своїх» процесів, їхні входи, виходи та інструменти. Зв’язок між елементами візуалізований у вигляді таблиці.

РМВОК добре підходить для проєктів з високим ступенем визначеності вимог та великою вартістю помилки. З іншого боку, його краще не застосовувати там, де немає жорстких рамкових обмежень. Коли немає завдання з фіксованими вимогами та чіткими дедлайнами, краще вибрати більш гнучкі підходи. Те ж саме можна сказати відносно продýктових компаній, в яких немає терміну завершення робіт, бо створені ними продукти постійно доопрацьовуються та поновлюються. Переваги РМВОК полягають у його чіткій структурі та регулярних оновленнях. Це довідник найкращого практичного досвіду, а його основні ідеї використовуються деякими національними та міжнародними стандартами проєктного управління.

Мінуси — у великому обсязі документу (майже 1000 сторінок), тому початківцям його зазвичай важко опанувати й застосовувати. І, звичайно ж, він не може бути замінником реального досвіду. Як запевняють знавці, опанувати управління ІТ-проєктами «з нуля» за допомогою РМВОК так само неможливо, як вивчити іноземну мову за допомогою словника. Це не підручник, а довідник, тому бажаючим стати проджект-менеджерами краще починати з базових курсів або спеціальних навчальних посібників.

PRINCE2

PRINCE2 пропонує керувати проєктом на трьох рівнях. Замовник думає, яку він отримає вигоду. Виконавець — які його чекають виклики. Покупець — як цим скористатися. Завдяки Проєктному комітету ці три точки зору складаються в єдиний трикутник, якому підлеглий Проєктний менеджер. В даній методології виокремлюють три «сімки»: 7 компонентів, 7 процесів та 7 принципів.

В якості переваг PRINCE2 називають гнучкість, чіткий розподіл обов’язків між членами команди та посилений контроль над проєктом. Кожен знає, що йому робити. Розробників ніхто не «шарпає», керівник втручається лише тоді, коли порушені обмеження чи треба вносити зміни. Рішення приймаються збалансовано, бо Проєктний комітет представляє інтереси замовника, виконавців та споживачів. Методологія надійна, оновлення враховують досвід реалізації реальних ідей, має якісну технічну підтримку.

Серед недоліків — PRINCE2 не дуже підходить для дрібних проєктів, до того ж є ризик, що менеджери-початківці «заплутаються» в термінології. Досвідчені спеціалісти вважають, що PRINCE2 не дуже добре корелює з «м’яким менеджментом» — управлінням конфліктами та спілкуванням з керівництвом проєкту. А ще кажуть, що в ній перевагу віддають звітності на шкоду лідерству. Крім того, цей стандарт «чомусь» розповсюджений передусім в англомовних країнах, тому вважається, що він має обмежене використання.

Етапи управління ІТ-проєктами

Управління ІТ-проєктом — це доволі складна робота, незалежно від того, великий він чи не дуже. Від самого початку щось може піти «не так» через мінливі вимоги замовника й обставини, що не залежать від головного менеджера. Але можна розділити весь життєвий цикл на окремі етапи. В кожного з них має бути своя мета й конкретні результати — так легше спрямовувати зусилля колективу, керувати ресурсами, контролювати роботу виконавців та забезпечувати потрібну якість кінцевого продукту. Головні етапи реалізації проєкту:

1. Ініціація.
2. Планування.
3. Реалізація.
4. Завершення.

На кожному з них задіяні конкретні особи, поставлені певні завдання та існують визначені процеси.

1. Ініціація

Життєвий цикл проєкту починається з етапу ініціації. В замовника виникає ідея, він обговорює з проджект-менеджером всі аспекти питання починаючи з того, навіщо потрібен новий продукт і чи можна взагалі реалізувати задумане. На цьому етапі визначають стейкхолдерів, збирають вимоги від зацікавлених сторін, перелічують необхідні ресурси та окреслюють можливі ризики, а також оцінюють перспективи. Особливістю даного етапу є найдокладніше опрацювання деталей — чим краще це зроблено, тим легше потім буде реалізовувати проєкт та керувати роботою.

Оцінюючи перспективи, ініціатор і проджект-менеджер повинні знайти відповіді на такі запитання, як орієнтовна кількість ресурсів, можливі юридичні проблеми, складнощі технічного характеру і т. ін. Після чого — відповісти на головні питання: чи можна реалізувати ідею та навіщо це робити? Зокрема, який буде з неї прибуток? Коли відповіді знайдені, то менеджер формулює мету, до втілення якої будуть прагнути ініціатор, виконавці та стейкхолдери, і проєкт беруть в роботу. Якщо ж ні, то від реалізації ідеї краще відмовитися.

На етапі ініціації задіяні замовник, проджект-менеджер, стейкхолдери, пресейл-інженер. Останній проводить технічне консультування стейкхолдерів і менеджера проєкту. Він зустрічається із замовником для того, щоб зрозуміти його мету, потреби, побажання та пріоритети. На основі отриманої інформації він готує оптимальне рішення відносно побажань замовника, а також з урахуванням вимог інформаційної безпеки й достатнього рівня захищеності інфраструктури. Він працює з технічним завданням, виконує передпроєктне дослідження, складає техніко-комерційні пропозиції тощо. Від якості роботи даного спеціаліста в значній мірі залежить наскільки точно буде прописане завдання на проєкт і чи добре всі члени команди розумітимуть, що саме від них вимагається.

2. Планування

В тому разі, коли прийнято рішення про можливість та вигідність реалізації ідеї, внаслідок чого проєкт беруть в роботу, головний менеджер разом із стейкхолдерами остаточно визначають його мету, встановлюють масштаб та вимоги для реалізації. Вони проводять бізнес- та системний аналіз і формують карту ризиків, після чого прописують скоп, тобто перелік завдань, які необхідно вирішити для успішного завершення. Після цього ТОП-менеджер разом із командою (головні учасники: пресейл-інженер, архітектор, група аналітиків, тімліди розробки й тестування) складають план по реалізації, формують бюджет та розподіляють ресурси. Якщо виконавців під проєкт ще не набрали, то менеджер залучає для планування сторонніх спеціалістів.

На етапі планування ТОП-менеджер разом із членами своєї команди виконує декомпозицію процесу. Великі завдання розбивають на менші, після чого з’являється можливість оцінити кожне по витратам часу та зрозуміти, в який термін можливо завершити проєкт. В плані прописують контрольні пункти з проміжними результатами, яких обов’язково треба досягти, щоб виконати загальне завдання.

Після виконання декомпозиції мети та визначення, скільки часу піде на виконання кожної частини, менеджер будує діаграму Ганта, на якій зображений взаємозв’язок між окремими частинами. Вона може бути простою, без подробиць — тільки основні етапи й терміни виконання. Або складною, з проміжними кроками та завданнями, з часовими рамками. Діаграма Ганта корисна тим, що наочна ілюстрація зручна у випадку, коли якесь завдання залежить від виконання інших завдань, над якими працюють різні спеціалісти. Чим краще вона складена, тим менше ризиків та невизначеності.

Проста діаграма Ганта. Gantt Chart. Source: Canva

Складна діаграма Ганта. Gantt Chart. Source: Canva

Зазвичай базовий план не співпадає з фактичним терміном виконання окремих завдань. Але це не означає, що не треба намагатися його дотримуватися. Він допомагає концентрувати увагу на планових строках завершення і показує, наскільки сильно команда відхилилася від проєктних дат. А коли виникають об’єктивні перепони, то план можна скоригувати. Після того, як діаграма Ганта зроблена та узгоджена, проджект-менеджер проводить kick-off meeting (настановчу зустріч). На неї запрошуються стейкхолдери та члени команди. Менеджер розповідає їм все по даному проєкту, після чого офіційно починається робота по його реалізації.

3. Виконання

На цьому етапі команда займається виконанням затвердженого плану роботи. Під час проєктування дизайнери намагаються знайти оптимальне рішення для досягнення мети. Вони створюють кілька варіантів з прототипами. Коли обрано той, що підходить найкраще, створюють специфікації, які передають розробникам.

Реалізація — це одна з найдовших фаз в життєвому циклі проєкту. Спеціалісти розробляють запланований продукт. Вони працюють короткими спринтами, тобто відрізками по одному-два тижні. В кожному спринті приймають участь одночасно дизайнери та розробники. Спринти бажано розраховувати таким чином, щоб після завершення кожного отримувати чергову, хай невеличку, але вже працюючу функцію.

Важливою частиною етапу виконання є управління змінами, коли під час роботи постають нові вимоги, або доводиться коригувати вже зроблене. Проведення час від часу загальних нарад зі звітністю дає можливість відслідковувати процес та синхронізувати роботу різних ланок.

Паралельно з реалізацією виконується моніторинг діяльності та контроль результатів. Проджект-менеджер і стейкхолдери відслідковують виконання завдань, порівнюють планові показники з фактичними та керують ризиками. Якщо план виконується з незначним відхиленням, то менеджеру залишається лише слідкувати, щоб ніхто його не порушував. Інакше — треба розібратися, що трапилося і, в разі необхідності, надати допомогу. Головна мета моніторингу — переконатися в тому, що робота йде як заплановано, та виявляти проблеми на початкових стадіях.

4. Завершення

Після того, як готовий проєкт з документацією передано замовнику, починається наступна фаза, коли формують службу підтримки, роблять необхідні доопрацювання, навчають кінцевих користувачів. Наостанок складають детальний звіт, в якому описані всі аспекти роботи над продуктом. Більшість команд проводить ретроспективу — фінальні збори, на яких розбирають, що було зроблено добре, а що вимагає покращення, які виникали проблеми та як їх уникнути в майбутньому. Такий аналіз сприяє професійному зростанню команди.

Методи управління ІТ-проєктами

Waterfall (Водоспад)

Каскадний метод Waterfall — це традиційна схема роботи з лінійною структурою, дуже поширена в проджект-менеджменті. Вона була відома ще тоді, коли про гнучкі технології ніхто навіть не замислювався. Вперше ця назва з’явилася в 1970 році в статті Вінстона Уолкера Ройса, який на той час займав посаду директора Lockheed Software Technology Center. Структура запозичена у діаграми Ганта. Для ІТ-проєктів Водоспад застосовується не часто. Чому — стане зрозуміло згодом.

В основу способу покладена послідовність виконання. Це немовби каскад з кількох водоспадів, де робота з одного етапу перетікає до наступного, і так до самого завершення. Ось як це виглядає для ІТ-проєкту:

Етапи роботи:

1. Вимоги до проєкту та їх аналітика. Замовник передає своє бачення того, яким повинен бути продукт, висуває певні вимоги. Команда їх аналізує, пише технічне завдання, оцінює можливі ризики, складає план-графік виконання робіт. До наступного етапу переходять тільки після того, як прописані всі вимоги, підготовлено ТЗ, створено не тільки план, але й інструкції відносно того, що й коли слід робити.
2. Проєктування (дизайн). Команда готує прототип та дизайн-макети. Після цього починають працювати розробники.
3. Розробка. Спеціалісти згідно вимогам, плану та макетам пишуть коди проєкту. Все так, як написано та узгоджено, чітко по ТЗ. Жодних імпровізацій.
4. Тестування. Виконується після того, коли все зроблено. Цей етап вважається головним недоліком каскадної моделі, бо коли виникають суттєві проблеми, то інколи на їх усунення витрачається надто багато часу.
5. Впровадження. Виконаний проєкт здається замовнику та запускається в роботу.
6. Підтримка. На протязі певного часу надається технічна допомога.

Починаючи роботу над проєктом, члени команди обговорюють усі особливості реалізації поставленого завдання та занотовують найголовніше, після чого проджект-менеджер складає та затверджує план наступних дій, відхилятися від якого неприпустимо.

Каскадний метод Waterfall

Принципи Waterfall вимагають, щоб команда переходила до наступного кроку лише після того, як завершено попередній. Пропускати будь-який етап не можна. Повертатися до вже зробленого, хай навіть для доопрацювання, теж не можна. Помилки виявляються та виправляються лише під час тестування. Ітерації не передбачені, схема вимагає, щоб був єдиний процес реалізації замовлення. Коли раптом змінюються вимоги до кінцевого продукту — слід переписати наново ТЗ. Клієнт, до речі, після того, як створене ТЗ, в процесі розробки продукту не бере ніякої участі, не бачить проміжних результатів і не може ні на що вплинути. Багато уваги надається документації та інструкціям — все має бути належним чином зафіксовано.

Переваги Водоспаду полягають в тому, що це найпростіша схема для використання. Проджект-менеджер складає план-графік, після чого йому насамперед лишається контролювати, щоб всі спеціалісти дотримувалися строків здачі своїх частин роботи. Відстежувати результати не важко, особливо маючи на руках діаграму Ганта. План-графік зазвичай добре продуманий та узгоджений з виконавцями, послідовність робіт доволі чітка. Разом із суворим менеджментом це добре дисциплінує спеціалістів.

До плану додається чимало інструкцій, він спирається на записи, що зроблені в процесі обговорення, та іншу документацію. Тому, коли раптом виникає необхідність залучити до проєкту нових виконавців, то проблем майже ніколи не виникає. Приміром, коли з команди пішов один із розробників, то прийнята на його місце людина завдяки технічним матеріалам та наданій регламентації продовжує роботу, витративши на ознайомлення зі справою мінімум часу.

Серед інших переваг Waterfall називають реальну оцінку терміну впровадження та вартості продукту, які в процесі виконання не змінюються. Завдання стабільні, в команди відсутня невизначеність, бо є затверджений план-графік, чимало інструкцій та правил для всіх нюансів роботи.

В якості головного недоліку відзначають недостатню гнучкість для перегляду етапів, внесення змін та доопрацювання. Тому в управлінні ІТ-проєктами, де нові вимоги — зовсім не рідкість, та ще й бажано часто випускати оновлення, Waterfall обирають помітно менше, ніж гнучкі Agile. Тут мало простору для творчого підходу, а щоб фантазія злетіла у височину, то це вкрай важко, бо крила обрізані планом-графіком та інструкціями. Тож важко сподіватися на те, що вдасться розробити якийсь унікальний продукт.

Крім того, треба вести багато документації, і чим пізніше виявлена проблема, тим більше для її виправлення витрачається ресурсів. З приводу командної роботи — з одного боку, співробітники суміжних груп пов’язані між собою за результатом. Бо коли в одної «горять» строки, то це негативно відображається на роботі тих, що по плану рухаються за ними, та й кінцевий продукт може не встигнути до дедлайну. З іншого боку — кожен спеціаліст працює на окремій ділянці і зайнятий вирішенням певної частини загального завдання. Спілкування з колегами мінімальне. Щоправда, декому це подобається.

Для кого підходить Waterfall? Для завдань з конкретно визначеними вимогами, малою кількістю змін та високою вартістю останніх. Для масштабних проєктів з великою кількістю стейкхолдерів. Там буде корисною модель управління, що передбачає складання максимально деталізованого плану та чималу кількість розгорнутої документації. Наприклад, в будівництві, в тому числі за типовими проєктами, або розробці обладнання. Тобто, в таких випадках, коли є конкретне завдання, і на виході слід отримати чітко визначений та вимірюваний результат. Також вона непогано себе зарекомендувала в проєктах, що висувають дуже суворі вимоги по дотриманню термінів здачі ТЗ та виконанню бюджетів. В ІТ Waterfall застосовують для невеликих за масштабами та короткострокових проєктів з обмеженим фінансуванням.

Чим відрізняються між собою методологія, метод та методика

Терміни «методологія», «метод» і «методика» багато хто вважає синонімами, не замислюючись про їх точне значення. Але, хоча вони й відносяться до однієї категорії понять, різниця все-таки є. В галузі програмування вважається наступне.

Методологія, модель або парадигма — це філософський підхід чи перелік головних принципів, від яких залежить її ефективність. Принципи можна коротко сформулювати та легко пояснити. Зазвичай вона характеризується методами, що її реалізують. Має концепцію, яка краще їх пояснює. Теоретична методологія намагається обґрунтувати принципи. Практична являє собою набір правил та способів, за допомогою яких можна досягти мети, залишаючись в рамках обраного філософського підходу.

Виходячи зі сказаного, Waterfall, про який розповідалося вище у статті, не буде помилкою назвати методологією, бо ця система сповідує певні принципи. Якби для неї написали маніфест, як це було зроблено для Agile, то він виглядав би приблизно так:

• Працювати за правилами. Ніяких змін. Постійна документація роботи.
• ТЗ обов’язкове. Чим докладніше, тим кращий продукт.
• Послідовність роботи. Наступний етап — тільки після завершення попереднього. Не можна повертатися до вже зробленого.
• Ніяких ітерацій, має бути єдиний «прямолінійний» процес розробки.

Метод або техніка виконання — це спосіб досягнення заданої мети, набір прийомів, що застосовуються під час певної діяльності. Може містити в собі кілька методик, які мають більш вузьку спрямованість. Можливо, кожна з них охоплює якусь частину загального напрямку, або працює дещо по-іншому, але обов’язково в рамках методу.

Методика або фреймворк — це покроковий алгоритм, процедура виконання певних дій для реалізації чітко визначених завдань. На відміну від методу, вона надає більш конкретні інструкції для спеціаліста на кожному етапі роботи. (Іноді вважають навпаки, що методика — це ширше поняття, яке може складатися з кількох різних технік виконання. Точного визначення не завжди дотримуються).

Методологія Agile

“Agile” перекладається як «гнучкий», «спритний». Саме на цих якостях базується дана система. Вона була презентована офіційно в 2001 році у штаті Юта (США). Саме тоді 17 відомих світових розробників створили альтернативу Waterfall, жорсткі рамки якої були надто незручними для мінливих умов Project management у сфері ІТ. Спеціалісти зрозуміли, що далі працювати за старими суворими та надто забюрократизованими технологіями не можна. І представили нову у вигляді “Agile Manifesto”, про який мова піде трохи згодом. Agile швидко стала популярною. За відгуками лідерів проєктного ринку, що працюють в різноманітних галузях, від будівництва до маркетингу, більш як 70% з них віддають перевагу якомусь із її методів. В сфері ІТ виникнення Agile взагалі стало переломним моментом, бо команди отримали можливість швидко адаптуватися не тільки до мінливих вимог замовників, але й до стрімкого розвитку технологій.

Термін “Agile” вживають у двох значеннях. По-перше, це методологія, тобто підхід, який сповідує певний набір принципів: гнучкість, ітерації, командна робота, взаємодія між співробітниками та з клієнтом, мотивація тощо. Тут мова йде не про конкретні практики чи застосовані інструменти, а саме про систему цінностей, в рамках якої можна з великою вірогідністю досягти успіху. По-друге, це збірна назва для різноманітних методів, для яких характерна «гнучка» філософія Agile.

Маніфест Agile не містить ніяких конкретних алгоритмів чи інструментів. В ньому відображені саме принципи даного підходу. Вони створювалися для команд розробників ПЗ, але наразі їх залюбки використовують проєктувальники в багатьох інших сферах бізнесу. Всього їх дванадцять:

1. Головне завдання, яке стоїть перед командою — задовольнити клієнта. Для цього останній має своєчасно та у повному обсязі отримувати якісне ПЗ, а також його оновлення.
2. Зміни під час розробки продукту — це на краще. Завдяки гнучким процесам клієнт з більшою вірогідністю матиме продукт із суттєвими конкурентними перевагами.
3. Готове до вживання ПЗ має надходити до замовника чим частіше — тим краще, орієнтовно в діапазоні 2-16 тижнів.
4. На протязі всього процесу керівники й спеціалісти працюють разом.
5. Для успіху проєкту важливо забезпечити персоналу необхідні умови та вагому мотивацію. Люди повинні відчувати, що керівництво підтримує їх та довіряє їм.
6. Кращій спосіб обміну інформацією всередині команди — особисте спілкування.
7. Команда працює на результат, це основне мірило роботи. Головний критерій — працююче ПЗ, а не людино-години чи інші показники.
8. В основі роботи лежать гнучкі процеси. Працюючи в такому форматі, можна витримувати потрібний темп не лише на короткій «дистанції», але й при розробці масштабних проєктів.
9. Готовий продукт має бути технічно досконалим, з якісним дизайном.
10. Слід зводити до мінімальної «зайву» роботу. Надмірне ускладнення проєкту та процесів не вітається.
11. Так само шкідлива заорганізованість, намагання жорсткого керівництва на всіх рівнях. Ідеал Agile — самоорганізована команда, тобто така, де немає яскраво вираженого лідера. Але кожен із учасників за необхідності може в будь-який момент виказати лідерські здібності та організувати роботу в інтересах команди. Тільки в таких умовах народжуються найкращі продукти.
12. Команда має час від часу оцінювати свою роботу й коригувати поведінку.

На основі перелічених вище принципів сформовані чотири цінності Agile:

1. Люди й те, як вони взаємодіють між собою важливіше, ніж процеси та інструменти.
2. Працююче ПЗ на виході важливіше, ніж детальна документація.
3. Співробітництво із замовником важливіше, ніж технічне завдання.
4. Готовність до змін важливіше, ніж затверджений план роботи.

Методології Agile притаманна робота короткими ітераціями (спринтами) по 2-3 тижні. Всередині кожної зазвичай існує стандартний кластер завдань: аналіз, проєктування, власне робота й тестування. На виході кожного спринта має бути працюючий продукт, хай навіть без деяких функцій. Строки беруть з запасом, аналітикою та плануванням не захоплюються, бо потім все одно це доведеться робити знову. Після кожної ітерації команда аналізує результати й коригує пріоритети.

Переваги Agile полягають у гнучкості, є можливість швидко відреагувати на будь-які зміни. Ризики невдачі невеликі, так само як і невиконання строків. Знайдений баг ліквідовують в наступному спринті, рутинна робота (звіти й документація) мінімальна, самоорганізація команди позитивно впливає на результат.

Недоліки Agile — це відсутність чіткого плану та необхідність замовнику постійно спілкуватися з командою (не всім це подобається). Якщо з процесу йде хтось із провідних виконавців, замінити його можна, але це не просто. Іноді розробники так фокусуються на виправленнях та оновленнях, що випускають з уваги головну мету. І, нарешті, якщо команда працювала по іншій методології, то перейти на Agile — це зазвичай довго і без досвідченого в цій справі спеціаліста може бути досить складно.

Scrum

Серед вітчизняних ІТ-спеціалістів Scrum є найбільш поширеним методом управління проєктами. Він доволі простий та високопродуктивний, розрахований на відносно невеликі колективи із 7-9 учасників. Має на увазі командну роботу, в якій поруч із розробниками приймають активну участь і замовники.

Робота починається з того, що власник продукту формує перелік вимог (беклог), що являє собою загальний список робіт. Масштабне завдання поділяється на невеликі задачі, для виконання яких даються короткі (1-4 тижні) часові фази — спринти. Роботи беруть із беклогу. Спринти бажано планувати так, щоб на виході кожного показати якийсь вимірний результат, тобто частину кінцевого продукту. Після виконання спринта проводять огляд та ретроспективу. Коли є необхідність, переглядають завдання та формують міні-беклог для наступного спринта.

Scrum-дошка часто виглядає як Kanban, але має чітку структуру спринтів

Щодня команда проводить невеликі скрам-мітинги або стендапи чи сінки, під час яких кожен учасник розказує, що зроблено, що заплановано та які виникають проблеми. Не відхилятися від поставленої мети допомагають, крім стендапів, також робота із беклогом, перегляд пріоритетів і планування. За всім слідкує scrum-майстер, який ще й допомагає розробникам взаємодіяти між собою. Особливістю Scrum є наявність квартального планування та звітність. Цей метод добре працює в умовах невизначеності, він дає можливість з самого початку пообіцяти бізнесу певні результати роботи в чітко визначені строки.

Kanban

Це також досить поширений метод, ще гнучкіший, ніж попередній. В його основі лежить візуалізація процесів на дошці за допомогою карток. Кожна задача має певний статус (наприклад: to do — зробити, doing — в роботі, done — зроблено). Деякі завдання можуть мати позначку «Високий пріоритет». Команди, що працюють онлайн, застосовують інструменти Trello, Jira та ін. Кількість завдань, що взяті до роботи, обмежена, завдяки цьому уникають неефективної багатозадачності. Керівник має постійно відслідковувати рух карток по стовпчикам дошки та коригувати роботу.

Приклад стандартної Kanban-дошки

Спринтів немає. Якщо Scrum — ітеративний, то Kanban — безперервний. Він краще пасує для команд, що мають багато незапланованої роботи, такої як постійні виправлення, проблеми з підтримкою, термінові запити функцій тощо. Замість того, щоб чекати на закінчення чергового етапу роботи, команда починає працювати над новими питаннями у міру їх появи і в процесі роботи змінює пріоритети. З іншого боку, в Kanban важко складати квартальні плани, призначати конкретні терміни виконання, надавати чіткі результати і писати звіти.

Scrumban

Ще один досить цікавий метод управління ІТ-проєктами із кластеру Agile-методологій. Він поєднує структуру та прогнозованість Scrum із гнучкістю Kanban, за рахунок чого команди працюють швидше та продуктивніше. Тут є цикли зі спринтами та канбан-дошки. Як наслідок, можна точніше встановити тривалість ітерацій, правильніше розставити пріоритети на спринтах та обмежити кількість завдань на етапах. Кожен спринт планують, грунтуючись на попередніх результатах, а також враховуючи вже виконані завдання. Завдяки щоденним стендапам покращується контроль командної роботи.

Lean

В основу методології Lean покладено концепцію максимальної цінності для споживача при мінімальних витратах ресурсів. Це не перелік якихось інструментів, а саме певний підхід — зроби пробну версію продукту, досліди на ній вимоги ринку і зрозумій, в якому вигляді він потрібен, а потім покращуй зроблене. Наприклад, таксопарк бажає мати застосунок для виклику машини. Компанія розробляє програму, в якої буде мінімальна функціональність і простий дизайн, та випускає її на ринок. Потім збирає зворотний зв’язок, враховує зауваження клієнтів та удосконалює додаток. Lean добре підходить стартапам, а також будь-якому бізнесу, де є можливість запустити мінімально життєздатний продукт.

Крім вказаних вище, є й інші методології та методи: eXtreme Programming для динамічних проєктів, що мають бути реалізовані у стислі строки, Six Sigma для контролю якості, Critical Path Method, що визначає критичні завдання та інші.

Поради щодо вибору методу управління ІТ-проєктом

Як стверджують співробітники Half Double Institute, у 2019 році більш як 53% ІТ-проєктів можна було б завершити у визначені терміни лише за рахунок правильного обрання методу. Ось кілька порад, якими бажано користуватися при його визначенні:

1. Напрямок діяльності. Слід зауважити, що в багатьох галузях є методи, що вже давно й широко використовуються. Вони довели свою ефективність, тому цей аспект варто не просто дослідити, а ще й постаратися зрозуміти, чому обирають саме їх. Бо в бізнесовій ніші серед команд-лідерів знайдеться як позитивний досвід, так і негативний. Наприклад, для ІТ-проєктів 71% американських фірм (дані zippia.com, 2022 рік) обирають один із фреймворків Agile, бо це найліпше в ситуації мінливого ринку. А в промисловості з її давно сформованими стандартами краще Waterfall з його ретельним контролем та численною документацією.
2. Пріоритети проєкту. Звичайно, на виході кожної розробки має бути продукт з вимірними характеристиками. Але бажано з’ясувати, що більш важливе: дотримання бюджету та здача роботи в строк, чи відшліфований функціонал? Точне врахування завдання клієнта та стандартів чи експерименти та інновації? Розподіл обов’язків членів команди та чітко розмежована зона відповідальності чи однакове залучення у процес роботи всіх причетних? Кожна методологія має певні цінності й пріоритети, вони повинні відповідати вимогам проєкту.
3. Складність та масштабованість. Не всі методи однаково добре підходять для виконання складних або простих завдань. Крім того, коли існує вірогідність зміни ТЗ в плані його розширення, то бажано визначити, чи може обрана методологія бути застосована для більших проєктів.
4. Які є обмеження по дедлайнам та ресурсам. Бюджет — він буде фіксований чи на виконання кожного наступного етапу виділяються окремі кошти.
5. Комунікація зі стейкхолдерами. Слід розуміти, наскільки тісними будуть зв’язки з клієнтом, підрядниками, постачальниками. Як швидко вони реагуватимуть на пропозиції, відповідатимуть на запитання, чи часто з ними можна буде спілкуватися.
6. Команда виконавців.  Обираючи метод, треба враховувати досвід та уподобання команди проєктувальників, бо деякі фреймворки вимагають спеціальних навичок чи навіть навчання. Слід розібратися, чи має команда можливості для ефективного впровадження конкретного методу та дотримання його принципів. Ще один аспект — розмір команди. Одні методології краще працюють на значних довготривалих проєктах з великою кількістю виконавців, тоді як інші — у невеликих колективах.

Керувати ІТ-проєктами складно. Але, якщо велику задачу розбити на дрібні частини, значні фрагменти декомпозувати на вкладені завдання, то процес стає цілком керованим. В цьому полягає сутність будь-якої методології.