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

Вірніше, вони були там з самого її початку, але перші десятиліття на них пробували відповісти в рамках регулярного менеджменту. І це були сильні спроби, які, в тому числі, розвинули проектний підхід і привели його в сучасний стан, PMBOK багато в чому заснований саме на практиках IT-проектів. Але в цілому ці спроби зазнали невдачі, гарантувати успіх проекту - не вийшло. 

І саме тому на початку нульових з'явився Agile як альтернатива регулярного менеджменту, і за минулі роки завоював IT-світ, ставши стандартом де-факто, а тепер йде в інші галузі. Розвитку Agile-менеджменту буде присвячена ця стаття.

У 2008 була опублікована книга Ентоні Лаудера «Культури програмних проектів». У дусі часу він вирішив не публікувати паперову книгу, а виклав текст в інтернеті. 

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

Кожна культура змінює не тільки спосіб реалізації проекту та управління ним, вона також розширює рамку проекту.

Розглянемо сучасну класфікацію, яка також складається з 4 культур.

1. Епоха НДДКР. Це період становлення IT-галузі, програми розроблялися в університетах та інститутах так само, як ведуться конструкторські роботи. Вони і самі були частиною більш масштабних проектів, забезпечуючи розрахунки для військової, космічної, атомної та інших галузей. Справа була нова, і основна проблема - домогтися, щоб програма працювала і видавала правильні результати.
2. Епоха RUP - класичне управління проектами. У міру розвитку галузі зростала потреба не просто розробляти програми, а робити це з передбачуваними термінами і витратами, відповідно до планів. Це пробували робити методами класичного менеджменту, і на цьому шляху були численні невдачі, а успіху так і не було досягнуто. І в принципі в 1980-х уже зрозуміли причину: ключовим фактором успіх IT-проектів не є процеси, а людський фактор. І в 1990-і роки був зроблений значний ривок в цьому напрямку - було створено Rational Unify Process (RUP), з якого пізніше значною мірою виросло сучасне проектне управління з його керівництвом PMBOK (Project Management Body of Knowledge). Але успіху досягнуто не було, передбачуваного результату отримати не вдалося.
3. І як альтернатива важким методам RUP на рубежі 21 століття з'явилися легкі Agile - підходи, настав час Agile і Scrum - першого з Agile-методів. який і приніс йому успіх. Формально зародження Agile - 2001, рік підписання Agile-маніфесту. Ідеї дуже прості: раз людський фактор - головне, то побудуємо процес на співпраці людей, а не на регламентах. А раз результат все одно гарантувати не можна - будемо спостерігати за просуванням до нього.

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

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

Все це визначило успіх Agile. На той час, крім Scrum був Kanban, гібридний Scrumban, і ще ряд методів і практик, що несуть більше IT специфіки і  тому менш відомих (XP, FDD, TDD, DDD і інші).

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

Принципово змінився характер завдань, які бізнес ставить перед IT: не "розробити конкретний набір фіч», а «доопрацювати продукт так, щоб частка займаного ним ринку в Латинській Америці зросла з 3 до 7%», не «впровадити нову систему управління складом», а «домогтися разом з логістами, щоб пропускна здатність складу в пікове навантаження збільшилася вдвічі». І це сприяло орієнтації продуктів для кінцевого користувача, а не для компаній, що викликало своє сімейство методів ведення проектів, заснованих на User Experience. Які, до речі, зараз стають актуальними і в інших галузях. 

Ця культура поки не має загальної назви, тому що вона не усвідомлюється як щось цілісне. Однак, складові її концепти широко відомі: UX, продуктовий підхід, DevOps. 

Висновки

Таким чином, кожна культура мала свої уявлення про те, що таке хороший проект і якісний продукт. Але найголовніша відмінність виникає, коли щось пішло не так, коли в ході розробки виявилося, що проект неможливо зробити в заплановані терміни і бюджети, або що система не вирішуватиме ту задачу, яку на неї покладали. Культури регулярного менеджменту пропонують замовнику змиритися: НДДКР - тому що всякі дослідження і конструкторські роботи можуть бути закінчитися невдачею, а RUP - тому що замовник сам погодив те завдання, яке було виконано і можливі ризики.

Типова ситуація в IT - коли після того як бюджет витрачений на 90% з'ясовується, що завдання зроблена наполовину, і треба ще стільки ж. І так - кілька разів.

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

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