Консалтингові ІТ-проекти в стилі Agile?

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

image

Консультанти Hewlett Packard Enterprise виконують подібні проекти в області управління ІТ: ITSM, управління проектами та портфелями, моніторинг на будь-якому рівні і т. д.

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

Ясна річ, що за багато років підхід до реалізації консалтингових проектів у галузі управління ІТ був відпрацьований у HPE на «п'ять з плюсом». Тисячі реалізованих проектів по всьому світу, величезну кількість вивчених уроків і сувора методологія, яка говорить, як правильно. І це все, зрозуміло, у форматі waterfall. Тобто «Пуск проекту», «Проектування», «Створення», «Розгортання і досвідчена експлуатація». «Прийшов, побачив, переміг».

Навіщо
Тут все просто – замовнику потрібен результат якомога швидше. Посудіть самі. Візьмемо майже будь-яку російську компанію середнього або великого масштабу:

1. Планування бюджету починається десь у серпні:

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

3. В березні, якщо пощастить, починаємо роботи.

4. Результати треба так чи інакше видати в кінці року, адже у всіх KPI (як на стороні замовника, і на стороні підрядника).

Разом: життєвий цикл проекту від ініціативи до результатів проекту – близько одного року-півтора років. Це дуже довго.

Що не так
Причин такої ситуації декілька, але як мінімум:

  1. Бюджетні та тендерні процедури «перемогти» (скоротити їх терміни) важко. Після 4-6 місяців від появи ініціативи до підсумків тендеру вимоги замовника можуть помінятися, нехай і в рамках тієї ж теми. Потрібен інструмент для гнучкої переприоритизации завдань.

  2. В рамках проекту працювати з waterfall замовник, звичайно, теж звик. І це написано у всіх його внутрішніх регламентах, стандартах з управління проектами і т. д. Але чекати результатів 6, 9 або 12 місяців – дуже нудно. Знову ж таки, за цей час вже в ході реалізації проекту багато чого може змінитися. Та якщо й не змінилося, результат хочеться отримувати по частинах і відразу ж використовувати його в роботі.
Що робити
Замовник повинен зрозуміти, що виділяти гроші під рішення конкретних завдань – минуле століття. Постановка завдань, як ми вже з'ясували, встигає часто змінюватися в ході реалізації цих завдань. Тому гроші треба виділяти на розвиток якогось магістрального напрямку (у разі консалтингових проектів, які робить наша компанія – на ITSM, управління портфелями і проектами, моніторинг інфраструктури або послуг тощо), задаючи певний вектор розвитку, але не конкретні вимоги і результати. Безумовно, це потребує зміни способу мислення, перебудови внутрішніх процедур, але без цього – нікуди.

Крім того, потрібно забезпечити гладке проходження організаційних змін, змін у способах роботи людей. У багатьох організаціях ми стикаємося з тим, що люди звикли до швидким і численних змін – зазвичай це результат «ручного управління» на тому чи іншому рівні в організації. Потрібно використовувати кращі практики управління організаційними змінами – MoC, Management of (Organizational) Changes – в тому числі, щоб показати людям, що ці зміни не носять хаотичний характер, а забезпечують той самий вектор розвитку, який був заданий раніше.

Нарешті, якщо ми говоримо саме про консалтингових проектах, то ми в HPE використовуємо так звану «модель бутерброда» (sandwich model):

  1. На початку проекту формується вихідний backlog завдань, які потрібно реалізувати. Можна вважати це «микропроектированием», схожим на те, як ми проектуємо процеси та функціональні вимоги до системи в рамках підходу waterfall.

  2. Даний backlog приоритизируется, як велить нам, наприклад, ScrumXP. Далі працюємо в режимі Agile, вимоги можуть коригуватися і змінюватися. Зрозуміло, необхідна жорстка дисципліна, наявність відповідних ролей (product owner, scrum master тощо). Паралельно з розробкою коду пишемо необхідні документи, готуємо організаційні зміни (до речі, в рамках DevOps є мантра «everything is code», яка дуже добре трансформує свідомість процесних консультантів).

  3. Від поняття проекту ми все одно не позбудемося, коли працюємо у зв'язці «замовник-підрядник». А проект за визначенням – це обмежена в часі діяльність. Тому Agile-історію в якийсь момент потрібно підсумувати, і здати замовникові результат проекту (можливо, забезпечивши його необхідної додаткової бюрократією). До речі, це зовсім не означає, що робота завершена – замовник, звикнувши до того, що в рамках середини «бутерброда» (п. 2) він регулярно отримує нові релізи і нову цінність, з більшою охотою і заздалегідь буде готовий подбати про продовження робіт і про виділення нових коштів.
Як можна бачити, ми обгортаємо Agile з двох сторін waterfall-му, що дозволяє, з одного боку, робити релізи та видавати цінність замовнику частіше, з іншого боку, за рахунок початку і закінчення проекту, близького до підходу waterfall, зовні проект виглядає як щось, що має початок і кінець. Це необхідно, в т. ч., тому що замовники дуже часто хочуть реалізовувати навіть Agile-проекти за схемою fixed price, а не за схемою time & material.

Дана тема здається нам досить перспективною, та вже зараз йдуть досить багато проектів в такому форматі. Наприклад, є великий проект в компанії, що працює по всьому світу, де між релізами product owner збирає до 200 ключових користувачів системи з усього світу, їм демонструються результати роботи, а з них збирається зворотний зв'язок і при їх допомозі додаються нові пункти в backlog. Це лише невеликий штрих, що показує можливий масштаб таких проектів, адже традиційно Agile добре живе в невеликих командах. Втім, коли ми говоримо про рівні підприємства, на допомогу приходить SAFe, про який ми вже розповідали.

Підводячи підсумок, хочеться сказати наступне: консалтингові проекти у форматі Agile або «майже Agile» можливі. Ми навіть їх робимо. Будемо раді почути запитання та коментарі по даній темі, в тому числі з урахуванням специфіки вітчизняних компаній і організацій.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.