Доброго часу доби. Хотілося б поміркувати про один з відомих аспектів проектів - ресурсний. Передумова така - якщо відкрити, наприклад, підручник Мазура, Шапіро, Ольдерогге «Управління проектами», то там відразу проект розглядається як «процес переходу з вихідного стану в кінцевий - результат за участю ряду обмежень і механізмів».
Тобто спочатку була ідея (сайту, софту, наданої послуги), потім її конкретна речова реалізація.
Реалізація, очевидно, є ланцюжком перетворення одних ресурсів в інші, як і будь-яке виробництво. Цей пост буде присвячений розгляду ІТ-проектів якщо не як виробництва, то як ряду перетворень вже точно.
Тут і далі під ресурсом будемо розуміти будь-який об'єкт, наявність якого необхідно для досягнення результату проекту. У тому числі і проміжні артефакти проекту будуть для нього ресурсами.
Поширені ресурси ІТ-проектів
Що можна віднести до ресурсів? Крім очевидних «гроші» і «час», також можна віднести їх похідні:
- Інструментарій (починаючи від банального робочого місця і закінчуючи стендами і засобами розробки) - вимагає грошей
- Персонал і його специфічні знання - вимагає грошей (він такий, так:)), і, в разі знань, можливий час
- Клієнтські бази і лояльність клієнтів - вимагає і часу і грошей
- Будь-який артефакт- «напівфабрикат», вироблений в проекті, вимагає і грошей і часу
Останні в свою чергу бувають, для прикладу:
- Програмний код
- Документація (ТЗ, користувацька і будь-яка інша)
- Розгорнуті рішення
- Інформація в базах даних, інформація про клієнтів
- Якщо мова про виробництво пристроїв, то зібрані прототипи і безпосередньо матеріали для виробництва (готові комплектуючі)
Сильно вдаватися в поняття ні на прикладах, ні в теорії немає сенсу. Зрозуміло, що будь-який матеріальний або нематеріальний об'єкт (або навіть одушевлений), який необхідний для досягнення мети, можна позначити поняттям ресурс. Як і в будь-якій системі, важливі по суті не стільки самі ресурси, скільки їх взаємозв'язок.
Наведу приклад з ігрострою: для готового результату завжди потрібні і арт, і код. Код без арту написати можна, протестувати не можна. Арт без коду намалювати можна, але подивитися «живцем» на загальний результат арту (вижн та інтерекшн) без коду практично не можна. Що робити? Найчастіше пишуть код із заглушками з арту, який повторює основні властивості готового, а загальний вижн по арту роблять нашвидкуруч рендерерами засобів розробки арту (без жодного інтерекшну). В кінці все зливається в екстазі воєдино. Тут які справи: якість кінцевого результату залежить від наявності художньої уяви у програмістів з одного боку, і розуміння пристрою програмних систем у художників. На щастя такі ресурси можна замінити їх тісним спілкуванням.
Взаємозв'язок методики ведення проекту з ланцюжком ресурсних перетворень
Ітераційний (з таймбоксами, буду називати далі узагальнено Agile) і каскадний підходи розрізняються з точки зору перетворення ресурсів в основному тим, як вони обходяться з часом. В одному випадку воно «нарізане» на рівні шматки, в каскадному немає. Ітерації можуть бути і там і там, все питання в тому, які проміжні результати створює проект: у разі гнучких підходів ми маємо кінцевий неповнофункціональний продукт на кожній ітерації, у разі каскаду - ми маємо окремі функції/модулі. При цьому кількість результатів, очевидно, різна, особливо чим коротша таймбокс.
Все сказане досить очевидно, проте вже зараз можна відзначити наступне: витрачання ресурсів різне. У вже згаданій вище книзі ресурси ділять на два типи:
- Невироблені, складовані, накопичувані - «енергія» (фінанси для ІТ-проектів),
- Відтворювані, нескладані, ненакопливі ресурси - «потужності» (люди для ІТ-проектів).
У той час як каскадний підхід використовує і «потужності» і «енергію» у міру необхідності, гнучкі підходи задіють «потужність» по повній, дозуючи відповідним чином «енергію». Щоб другий випадок гарантував нам не більшу сумарну витрату, необхідно щоб вироблені ітераціями проміжні результати (ресурси вони ж) не вимагали постійних переробок в ході проекту. Таким чином, сам факт використання гнучкого підходу не виправдовує відмови від розробки архітектури та послідовності реалізації функціоналу - і останньої зовсім не на основі пріоритетів користувача, якщо хочеться оптимізувати проект.
Приклади ланцюжків перетворень
Розглянемо пару варіантів - B2B і B2C. Для B2B розглянемо проект розробки що-небудь за типом простецького документооборотного ERP, для B2C - сайт-біржу, де відвідувачі замовляють і купують один у одного послуги.
Стрілки на діаграмах відображають послідовність.
B2B «ERP» Agile
B2C «Біржа» Cascade
Якщо діаграми читаються погано через те що, на перший погляд, «все пов'язано з усім», то їх можна розбивати на кілька. Але все одно пов'язано з усім, це неминуче. Проекти такі, що результати попередні використовуються в наступних, як при зведенні багатоповерхівки будують знизу вгору (у разі будівництва - через проблеми з гравітацією, у випадку з проектами - через неминучі причинно-наслідкові зв'язки). Такий ресурс як «час» взагалі не приведений, щоб не захаращувати все стрілками.
І так. Якщо (раптом) здасться, що гнучкий підхід «стрункіше», то за примітивністю його діаграми ховається відсутність деяких ресурсів, які є в другій.
Замість висновку - управління ризиками в проекті через призму ресурсного ланцюжка
«План без ризиків - набір побажань, ризик без плану - казино». (с) моє).
Ризик - це подія, яка відхилить показники проекту від потрібних. Ризик впливає на кінцевий результат проекту (або він не вчасно, або неякісний, або за бюджет вилізли). Тепер уважно стежимо за руками:)
Твердження. Послідовність створення та застосування ресурсів, а також наявність або відсутність самих ресурсів у ресурсному ланцюжку, визначає рівень ризикованості проекту.
Доказ. Розглянемо довільний показник, його ризиком буде можливість відхилення значення від планового. Значення показника в деякий момент часу є функція задіяних до цього моменту ресурсів, в кінці проекту - всіх ресурсів. З цього випливає, що зміна складу ресурсів та їх послідовності призводить до зміни (графіка) значень показника. Звідси ж випливає і те, що проектів без ризику не буває (оскільки ресурси за фактом ніколи не відповідають плановим). Сам «зміст» ресурсу генератором ризику назвати не можна, оскільки змінюючи його «зміст» ми змінюємо ресурс (наприклад база не MS SQL Server, а Firebird - це два різних ресурси). [Кінець доказу]
Якщо все вищесказане здається якоюсь теорією, задумайтеся про те, що ця теорія проявляється і у великому і в малому. Навіть коли ви вирішуєте, яку задачу з беклога взяти першою, з двох варіантів краще той, який вимагатиме створення меншої кількості проміжних ресурсів «на викид» (заглушок та іншого). Навіть якщо ви намагаєтеся вирішити, що краще - організувати впровадження в сотні робочих місць в різних офісах на основі географічного поділу, або функціонального - подивіться, який варіант ресурсного ланцюжка відхилить ваші показники від бажаних менше (вибір залежить від обраної пари з трійки показників проектного трикутника).
Спасибі за те, що прочитали. Всім вдалих проектів!