“Інтерфейс не дуже інтуїтивний”
“Ця функція не працює”
“Программа має обробляти данні швидше”
Такі репліки стейкхолдерів доводиться часто чути і … ігнорувати. Бо під ними немає жодного конкретної вимоги – як саме має бути. Це або невідомо самому автору, або він очікує, що виконавець буде читати його думки, або у нього просто поганий настрій.
Намагатися задовольнити ці “вимоги” – все одно що мандрувати лабіринтом, в кінці якого клієнт обовʼязково звинуватить вас в марнотратстві його бюджету.
Клієнти часто висувають вимоги, що базуються на їхньому обмеженому розумінні технічних аспектів або реальних бізнес-потреб.
Це може призвести до:
1. Недостатньо конкретних вимог, що не описують чітко функціональність.
2. Суперечливих вимог, що суперечать одна одній або існуючим бізнес-процесам.
3. Вимог, що не враховують реальні потреби кінцевих користувачів.
4. Розробки зайвого функціоналу.
У таких випадках важливо використовувати методи аналізу першопричин, такі як Root Cause Analysis, метод 5 Why та діаграма Ішикави.
Використання Root Cause Analysis
та методу 5 Why
Root Cause Analysis (Аналіз першопричин) — це процес виявлення основних причин проблеми. Його мета полягає в тому, щоб знайти та усунути причину, а не лише її симптоми. Один із популярних методів аналізу першопричин — метод 5 Why.
Метод 5 Why передбачає задавання питання “Чому?” п’ять разів або більше, поки не буде знайдено корінь проблеми. Наприклад:
1. Чому вимоги не відповідають бізнес-очікуванням?
Тому що клієнти не мають повного розуміння бізнес-процесів.
2. Чому клієнти не мають повного розуміння бізнес-процесів?
Тому що у них немає достатнього досвіду в цій сфері.
3. Чому у них немає достатнього досвіду?
Тому що вони не проводили глибокий аналіз бізнес-процесів.
4. Чому вони не проводили глибокий аналіз?
Тому що їм бракує методологічних інструментів.
5. Чому їм бракує методологічних інструментів?
Тому що вони не проходили відповідне навчання.
Таким чином, використання методу 5 Why допомагає виявити корінь проблеми та зосередитися на його вирішенні.
Діаграма Ішикави
Діаграма Ішикави (або діаграма “риб’ячої кістки”) допомагає візуалізувати всі можливі причини проблеми. Вона складається з “хребта” риби (проблеми) та “кісток” (категорій причин). Цей метод дозволяє структурувати та класифікувати можливі причини, щоб далі провести детальний аналіз.
Процес використання діаграми Ішикави включає наступні кроки:
1. Визначення проблеми та написання її в “голові” риби.
2. Визначення основних категорій причин (наприклад, люди, процеси, технології, середовище).
3. Додавання детальних причин до кожної категорії.
4. Аналіз отриманої діаграми та ідентифікація корінних причин.
Рекомендації для перевірки якості вимог
1. Чіткість та конкретність: Усі вимоги повинні бути чіткими, однозначними та зрозумілими.
2. Вимірюваність: Вимоги повинні бути вимірюваними та такими, що можна перевірити.
3. Сумісність: Вимоги не повинні суперечити одна одній та існуючим бізнес-процесам.
4. Повнота: Всі необхідні аспекти функціональності повинні бути охоплені.
5. Пріоритетність: Вимоги повинні бути пріоритезовані за важливістю та впливом на бізнес.
6. Валідація з кінцевими користувачами: Вимоги повинні бути перевірені та погоджені з кінцевими користувачами для забезпечення їх відповідності реальним потребам.
Висновок
Правильне формулювання вимог до програмного продукту є критично важливим для успішної розробки. Використання методів аналізу першопричин, таких як Root Cause Analysis, метод 5 Why та діаграма Ішикави, допомагає виявити та усунути корінні проблеми, що заважають правильному формулюванню вимог. Дотримання рекомендацій щодо перевірки якості вимог дозволить уникнути багатьох помилок та забезпечить розробку продукту, який відповідає потребам бізнесу та користувачів.
