Втілення ваших ідей у життя
через управління проєктами

Угору

Натягнути сову на глобус: чому універсальні поради не працюють

9 лютого 2022

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

Розпочинаючи розробку новогу проєкту, багато менеджерів роздумують про те, який життєвий цикл слід підібрати для нього (Predictive, Agile, Hybrid) та який фреймворк використовувати (Waterfall, Scrum, Kanban, тощо).

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

Для цього вже більше 10 років існує і постійно вдосконалюється Посібник по Скраму (Scrum Guide) з чітко визначеними правилами, яких необхідно дотримуватися, щоб досягти успіху при гнучкій розробці проєкту по Скраму. Автори цього документа вказують, що “зміна базових основ Скраму, виключення окремих його елементів, або нехтування правилами Скраму – все це лише прикриває існуючі проблеми та обмежує користь від Скраму, навіть потенційно роблячи його використання марним.”

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

Тому що, визначаючи підхід до управління та фреймворк для майбутнього проєкту, менеджер повинен добре розуміти контекст проєкту. Усі проєкти унікальні саме через свій контекст, навіть якщо його результати (продукт) не є унікальними (PMBOK Guide 7-ї ред). Контекст проєкту формується його середовищем.

Зовнішнє середовище – це фактори, на які зазвичай ні команда проєкту, ні сама організація, що виконує проєкт, впливати не можуть (політичні, економічні, соціальні, законодавчі, ринкові, інфраструктурні та інші фактори).

Внутрішнє середовище – це власне організація, у якій виконується проєкт (правила бюджетування та управління проєктами, організаційна структура, культура, процеси та правила роботи, наявні ресурси,тощо).

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

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

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

Ефект “сови на глобусі” в управлінні проєктами можна спостерігати у наступних 2-х випадках:

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

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

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

Краще трішки помилитися спочатку, однак з рештою віднайти власний шлях до успіху, ніж сильно розчаруватися та виснажити команду, концентруючись лише на тому, щоб усе було зроблено ідеально “по книжці”.

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

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

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

Як же правильно проводити адаптацію фреймворка або методології при організації нового проєкту?

  1. Вивчіть контекст проєкту – зовнішнє та внутрішнє середовище, в тому числі наявну методологію та історичний досвід по релевантним проєктам. Порадьтеся з проєктним офісом щодо рекомендованої методології чи фреймворка.
  2. Визначте ключові обмеження та ризики – з ними пов’язані саме ті проблеми, виникненню яких ви хочете запобігти адаптацією певного фреймворка. Завжди робіть акцент, у першу чергу, на найбільш критичних ризиках та обмеженнях свого проєкту.
  3. Складіть список змін фреймворка, які допоможуть ефективно організувати роботу в умовах ключових обмежень – це можуть бути результати мозкового штурму команди або попередній успішний досвід в організації (можна використовувати також досвід інших організацій, однак з врахуванням ризиків, викладених вище). Поспілкуйтесь з досвідченими колегами, щоб отримати ”неявні знання”, які містять контекст.
  4. Перевірте, щоб з водою (адаптацією) не “вихлюпнути дитину” – нові правила повинні дозволяти вашій команді ефктивно створювати ті результати, яких від вас очікують ключові стейкголдери. Якщо ж ви стикнулися з нерозумінням з боку стейкголдерів, поверніться до другого пункту вище.
  5. Почніть використовувати адаптований підхід і регулярно оцінюйте його ефективність – за необхідності, ви зможете швидко внести невеликі зміни за результатами ретроспектив команди та зворотнього зв’язку від стейкголдерів.

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

 

СПИСОК ДЖЕРЕЛ:

Усі дописи