Автор статті: Volodymyr Dovganyk
Напевне, в багатьох були ситуації, коли команда активно “ковбасить” скоуп, закриває кожен спринт, але беклог продукту не зменшується, реліз все відкладається і з’являються фідбеки на імплементовані фідбеки. Знайомо? Це можна назвати по-різному: нічний жах, страшний сон, але офіційно прийнята версія scope creep або, якщо спробувати перекласти – “розповзання скоупу”.
Scope creep – це неконтрольоване зростання скоупу проєкту в ході його реалізації. Відповідно до щорічних опитувань Project Management Institute, scope creep входить в топ 5 причин провалу проєктів уже протягом 5 років. І з року в рік приблизно третина з опитаних менеджерів називають його як основну причину провалу проєкту. Проте, не варто будь-яку неточність чи виправлення у вимогах моментально називати scope creep. Scope creep як явище має системний та затяжний характер, тобто ви щодня відкриваєте пропущенні вимоги і розмір вашого беклогу виріс/росте на 20%+.
Якщо спробувати розібрати причини виникнення такого явища, то їх безумовно декілька, але основні з них: відсутність контролю за зростанням скоупу та пропущені вимоги на початку ініціації проєкту чи його фази. Проте, цікавіше розглянути варіанти дій, коли ви вже потрапили у дану ситуацію.
Отже, якщо ви та ваша команда страждає від scope creep:
- Прийняти та визнати, що у вас scope creep
Якби це не було неприємно, але це треба визнати і пробувати будувати найближчі активності для виходу із даної ситуації. Ідеально спробувати узгодити план подолання кризи із ПМ та замовником і разом рухатися ним. - Прийняти або почати дотримуватися процедури управління змінами (change management)
Сподіваюсь, у вас є процедура управління змінами, якщо ні, то саме час її впровадити. А загалом всі зміни, які заходять в проект повинні проходити процедуру оцінки їх впливу на продукт, уже розроблену функціональність та на терміни виконання. На жаль, часто велика кількість побажань автоматично додається в беклог без найменшого аналізу їх впливу. - Перевірити чи всі зацікавлені сторони визначені та їх інтереси враховані
Неврахована група стейкхолдерів одне із найбільших джерел пропущених вимог. Тому, перевірка чи всі зацікавлені сторони ми врахували стає наріжним каменем в бізнес аналізі. Досить ймовірно, що причина вашої ситуації в тому числі у зв’язку із пропущеними групами зацікавлених осіб. - Переглянути вимоги та покрити процеси/сфери, які провисають
Якщо ви чітко бачите модуль чи частину продукту де найбільше відчувається “розмивання скоупу”, то їм варто приділити більше уваги. Якщо є така можливість, бажано призупинити розробку нового функціоналу в даній області доки не будуть повністю вирішені проблеми, якщо ні – то якомога акуратніше і детальніше продумувати кожну зміну, яка там планується. - Пріоритезувати скоуп та зосередитися на найбільш критичних відрізках
Розв’язати всі проблеми одночасно неможливо, тому first things first. Спробуйте пріоретизувати разом із командою та замовником найбільш критичні області та почати саме з них. При цьому критерії пріоритизації можуть бути різними в залежності від стадії розвитку продукту, релізного циклу та специфіки розробки.- Більш детально про управління змінами та організацію БА процесу ми говоримо на курсі Business Analysis Intensive Online
