Як боротися з розповзанням сфер?

У змаганні за досягнення високих KPI та збільшення споживання агентства та постачальники часто нехтують своїми початковими цілями та завданнями. Це стає проблематичним, коли ми ігноруємо нашу головну мету — задовольнити вимоги кінцевих користувачів.

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

Дослідження

Дослідження Lamri, проведене більше десяти років тому, виявило, що 71% проектів перевищили орієнтовний бюджет або потребували коригування початкового обсягу проекту. Навіть після численних змін у стратегії управління проектами розширення масштабів продовжувало створювати проблеми та перешкоди для бізнесу.

Дослідження PMI також показало, що у 2015 році близько 44% проектів мали справу зі зміною обсягу. Ця проблема також виникала з проектами з фіксованим бюджетом, де терміни та бюджети встановлювалися на початку проекту.

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

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

Scope Creep & Corporate Software

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

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

Чому відбувається повзучий розмах?

Збільшення робочого навантаження, викликане несхваленими змінами або додатковими розробками програм, відбувається в основному через такі причини:

• Нечіткі цілі проекту

Неадекватна інтеграція функціональних можливостей і цілей бізнес-програмного забезпечення клієнта, яке не задовольняє операційні потреби та вимоги кінцевих користувачів

• Погане управління часом

Недостатній час, виділений на дослідження та планування, створює непотрібний стрес і тиск на команду

• Швидкі зміни в бізнес-середовищі клієнта

Зміни в нормативних актах або діяльності клієнта можуть суттєво вплинути на вимоги до програмного забезпечення

• Відсутність повної документації, що підтверджує запити клієнтів

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

• Нерозуміння вимог клієнта

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

• Використання невідповідних модних слів чи складної термінології

Значення одного слова може сильно відрізнятися залежно від предмета. Використання таких слів може легко призвести до плутанини або непорозумінь у проекті

• Невизначені критерії для управління проектами

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

• Збільшення робочого навантаження без відповідного збільшення бюджету

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

• Мікро(не)управління клієнтами

Іноді питання вирішуються без обговорення з розробниками та без повідомлення команди.

Як можна запобігти розповзанню області?

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

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

Немає єдиного способу боротьби з Scope Creep, але наступні прості кроки можуть зменшити ризик:

1. Виберіть найбільш відповідний тип проекту. Щоб уникнути потенційних проблем із збільшенням робочого навантаження, не соромтеся запропонувати клієнтам пробну версію або фазу відкриття перед початком активного кодування. Дочекайтеся остаточного аналізу, щоб визначити бізнес-потреби клієнта, щоб належним чином узгодити архітектуру майбутнього програмного рішення.
2. Зосередьтеся на бізнес-потребах, а не на ефекті «вау». Коли вся команда розуміє справжні потреби клієнта , кількість непотрібних запитів на модифікацію зникне.
3. Стежте за змінами в бізнесі клієнта, щоб краще прогнозувати тенденції. Прикладом можуть бути нові державні правила щодо охорони здоров’я працівників це сигналізує про зміни в програмному забезпеченні лікарні. Моніторинг тенденцій виявляє потенційні зміни досить рано, щоб забезпечити своєчасне впровадження змін.
4. Ніколи не економте на етапі відкриття. Незалежно від часу ви отримаєте переваги в майбутньому.
5. Документуйте початкові вимоги. Незалежно від того, як подано ці документи, тобто офіційна специфікація SRS чи просто список пріоритетних завдань , ви та клієнт маєте погодитися, що документ є основою для оцінювання будь-яких майбутніх запитів.
6. Перевірте та виправте свої оцінки. Рекомендується, щоб члени команди виконали цей крок, щоб визначити обсяг роботи та надати остаточний приблизний бюджет проекту.
7. Максимально оптимізуйте завдання. Це дозволить вам керуйте обсягом роботи та аналізуйте вплив змін, щоб забезпечити задоволення потреб усіх зацікавлених сторін.
8. Розставте пріоритети для своїх завдань. Неможливо зробити все негайно через обмеження часу, ресурсів і бюджету.
9. Працюйте в межах тижневого спринту. Відповідно до розробки програмного забезпечення Agile, було б набагато краще працювати з елементами, які можна закодувати та запустити лише протягом одного тижня.
10. Об’єднайте своїх колег в одну команду. Коли люди працюють разом і відкрито спілкуються, вони можуть легко обговорювати, вирішувати питання та вирішувати питання будь-які питання або проблеми щодо прогресу проекту. Сьогодні, коли розробники, дизайнери, копірайтери та інші спеціалісти працюють віддалено, важливо, щоб компанії були технологічно здатні підтримувати таку співпрацю. Використання таких інструментів управління створює цифрове робоче місце, яке заохочує ефективне спілкування та керування завданнями.

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