• 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. Спробуйте пріоретизувати разом із командою та замовником найбільш критичні області та почати саме з них. При цьому критерії пріоритизації можуть бути різними в залежності від стадії розвитку продукту, релізного циклу та специфіки розробки.

Узнайте, что нового!
Никакого спама, никогда!