Коли мова йде про програмні проекти, чи бачили ви, як різні компанії з розробки програмного забезпечення та компанії з дизайну програмних послуг описують проект? Чи можете ви швидко зрозуміти конкретні вимоги та передумови проекту після їх опису?

Зазвичай опис програмних проектів включає такі чотири пункти:

Опис галузі клієнта

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

Проблеми в бізнес-процесі (де знаходяться потреби)

Це основний мотив клієнта. Які проблеми виникають у клієнта в робочому середовищі? Чи потрібно оцифрувати існуючі робочі процеси, чи потрібно реорганізувати інформаційну систему, чи потрібно впровадити цифрові заходи у відповідь на нові тенденції в галузі? Необхідно об'єктивно зрозуміти ситуацію, з якою стикається клієнт.

Запропоноване рішення

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

Результати

Порівняно зі старими рішеннями, які зміни та відмінності принесло нове рішення для клієнта? Наприклад, підвищення ефективності виробничих процесів, скорочення часу на обробку інформації, надання нових каналів для залучення клієнтів тощо.

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

Створити «основну цінність», яка визначає межі проекту

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

Приклад:

Клієнт хоче, щоб інформаційна система мала функцію «натисніть кнопку запуску, і завдання автоматично виконується». Інтуїтивно це може здатися простим, але насправді розробка може вимагати врахування різних бізнес-логік, таких як права доступу, статус попереднього виконання, стабільність з'єднання системи тощо. У цей момент клієнт може раптово сказати: «Я хочу, щоб при натисканні кнопки запуску було відчуття, що все оживає».

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

Що робити, коли у обмежений час розробки виникає конфлікт між функціональністю та очікуваннями клієнта щодо інтерфейсу?

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

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

Визначте найвідповіднішу «основну цінність» разом з клієнтом для кожного проекту

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