• Scope creep: хто винен і що робити?

    Scope creep: хто винен і що робити?

Scope creep: хто винен і що робити?

Автор статті: Volodymyr Dovganyk

Напевне, в багатьох були ситуації, коли команда активно “ковбасить” скоуп, закриває кожен спринт, але беклог продукту не зменшується, реліз все відкладається і з’являються фідбеки на імплементовані фідбеки. Знайомо? Це можна назвати по-різному: нічний жах, страшний сон, але офіційно прийнята версія scope creep або, якщо спробувати перекласти – “розповзання скоупу”.

Scope creep – це неконтрольоване зростання скоупу проєкту в ході його реалізації. Відповідно до щорічних опитувань Project Management Institute, scope creep входить в топ 5 причин провалу проєктів уже протягом 5 років. І з року в рік приблизно третина з опитаних менеджерів називають його як основну причину провалу проєкту. Проте, не варто будь-яку неточність чи виправлення у вимогах моментально називати scope creep. Scope creep як явище має системний та затяжний характер, тобто ви щодня відкриваєте пропущенні вимоги і розмір вашого беклогу виріс/росте на 20%+.

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

Отже, якщо ви та ваша команда страждає від scope creep:

  1. Прийняти та визнати, що у вас scope creep
    Якби це не було неприємно, але це треба визнати і пробувати будувати найближчі активності для виходу із даної ситуації. Ідеально спробувати узгодити план подолання кризи із ПМ та замовником і разом рухатися ним.
  2. Прийняти або почати дотримуватися процедури управління змінами (change management)
    Сподіваюсь, у вас є процедура управління змінами, якщо ні, то саме час її впровадити. А загалом всі зміни, які заходять в проект повинні проходити процедуру оцінки їх впливу на продукт, уже розроблену функціональність та на терміни виконання. На жаль, часто велика кількість побажань автоматично додається в беклог без найменшого аналізу їх впливу.
  3. Перевірити чи всі зацікавлені сторони визначені та їх інтереси враховані
    Неврахована група стейкхолдерів одне із найбільших джерел пропущених вимог. Тому, перевірка чи всі зацікавлені сторони ми врахували стає наріжним каменем в бізнес аналізі. Досить ймовірно, що причина вашої ситуації в тому числі у зв’язку із пропущеними групами зацікавлених осіб.
  4. Переглянути вимоги та покрити процеси/сфери, які провисають
    Якщо ви чітко бачите модуль чи частину продукту де найбільше відчувається “розмивання скоупу”, то їм варто приділити більше уваги. Якщо є така можливість, бажано призупинити розробку нового функціоналу в даній області доки не будуть повністю вирішені проблеми, якщо ні – то якомога акуратніше і детальніше продумувати кожну зміну, яка там планується.
  5. Пріоритезувати скоуп та зосередитися на найбільш критичних відрізках
    Розв’язати всі проблеми одночасно неможливо, тому first things first. Спробуйте пріоретизувати разом із командою та замовником найбільш критичні області та почати саме з них. При цьому критерії пріоритизації можуть бути різними в залежності від стадії розвитку продукту, релізного циклу та специфіки розробки.

    • Більш детально про управління змінами та організацію БА процесу ми говоримо на курсі Business Analysis Intensive Online
Sign up for our newsletter
Get the latest info with our monthly newsletter