Як стати справжнім аналітиком Частина 2

Виявлення вимог - найважчий, важливий, схильний до помилок і вимагає інтенсивного спілкування етап розробки ПЗ. Виявлення вимог – це творчий процес, і кожен використовує свої інструменти отримання результату, тобто. вимог. У багажі є такі методи, які називаю «Класика», тобто. це ті прийоми, які спрацьовують у 90% випадків. До традиційних методів виявлення вимог належать використання інтерв'ю та анкет, спостереження та вивчення ділових документів. Це прості та економічні методи. Сподіваюся, досвідчені хабраюзери доповнять список своїми.

Поділ користувачів на групи

Щоб не випустити з уваги потреби окремих користувачів необхідно:

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

ІМХО: Вибирайте не тих людей, хто базікає багато, а тих, хто говорить по суті.

Робота з користувачами для з'ясування вимог до продукту

1. Анкетування/Інтерв'ювання

2. Спостереження

Спостерігайте за роботою користувача. Не полінуйтеся витратити на це робочий день! За допомогою цього методу можна виявити неявні вимоги до системи, які не озвучив користувач. Іноді навіть з'ясовується, що для виконання завдань користувачам зовсім не потрібне нове ПЗ.

3. Проведення спільних семінарів

Вивчення звітів про проблеми працюючих систем чи аналогічної системи з метоюпошуку нових ідей

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

Повторне використання вимог у різних проектах

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

Як зрозуміти, що збирання вимог завершено?

Конкретних ознак, які свідчать, що виявлення вимог завершено, немає. Виявити вимоги повністю неможливо, проте такі ознаки підкажуть вам, що джерела відомостей вже майже вичерпалися:

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

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

Література:

Як стати справжнім аналітиком вимог? Частина 1. Великими аналітиками народжуються чи стають?

Вакансії компанії Нордавінд

Коментарі 29

Чекаю з нетерпінням на наступну статтю.

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

Досвідчений аналітик відразу чіпляється за слово "треба" і вже прикидає: "це атрибут якості або функціональна вимога?"

А чи не можна блок-схему прив'язати до циклу Демінгу з управління якістю:

- Удосконалення - Планування - Виконання - Аналіз -

На мою думку, схоже.

Ця схема також відповідає функціональній петлі Петра Кузьмича Анохіна.

Один із описів підходу наведено на сайті http://www.zooton.net/ind1026.html

Звідти ж схема реакції людського організму:

Тож у цієї класики ще й фізіологічні засади.

У тому й річ, що діяльність аналітика також може бути піддана аналізу. Мої пропозиції щодо аналізу людської діяльності - у http://integral-community.ru/forum/viewtopic.php?f=8&t=12#p68

Таким чином, представлену у Вашому пості схему після інваріантного графічного перетворення без втрати змісту можна поширити будь-яку діяльність. На мою думку, це легше, ніж запам'ятовувати окремі інтерпретації для кожного виду діяльності.

З повагою, Олексій.

Хотілося б почути досвід вирішення конфліктів інтересів. Мається на увазі конфлікт інтересів користувачів (керівництво клієнта також користувачі по суті). Прямі саботажі (кому воно треба впроваджувати щось нове, ще й «мутити» заважатимуть, краще все заплутуватиму) та інші людські фактори?

Хотілося б статтю з цієї теми.

Адже банальний підхід — слухай того, хто вище не пройде, — вище хоче більше контролю, часто недоречного тощо.

Працюючи з користувачами, ви ставитимете запитання, вислуховуватимете відповіді та спостерігатимете за їх діями (виявлення вимог).

Щоб не випустити з уваги потреби окремих користувачів необхідно:

З'ясуйте у користувачів, які завдання їм потрібно виконувати засобами програмного забезпечення.

Я правильно зрозумів, що ви пропонуєте розробляти систему тільки на основі вимог користувача? А як же бізнес-вимоги? Як робота з різними зацікавленими особами – замовник, спонсор, власник системи, покупець, продавець, впроваджений?

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

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

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

Мені теж подобається. Але чому б не порекомендувати м'якший вхід, наприклад, з 60-100 сторінок? bagcheck.com/bag/1377

Ви знайомі із статтею Химоніна?

Навіщо створювати такий високий поріг входу? Чи вам вигідна ця «елітарність» аналітиків? Чи не кожен, хто мріє стати аналітиком, долетить до середини Вігерса?

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

І ось у менеджера розробка вимог – це

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

Навіщо витрачати час на аналіз та пошук корисного у великому тексті, якщо можна прочитати короткий?

Я не проти довгих підручників загалом. Я проти того, щоб перший підручник на тему був — довгим підручником.

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

Засвоюваність це не показує.

Є різні завдання, режими та формати: Ознайомлення - оглядовий матеріал Глибоке занурення - дослідження Вивчення конкретної методики - методичка Перегляд свого досвіду - модель процесу, підходу, карти понять та явищ Довідка - Довідник

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

Ви читали Вігерса?

Я проти того, щоб перший підручник на тему бувдовгим підручником.

Я не можу сперечатися з питанням огидності перекладу, якщо його не читав.

Питання засвоюваності це не так питання розміру, як концентрації нових знань.

Якщо досвідчений інженер цілком задовольниться таким записом.

Колесо — пристрій зменшення сили тертя під час переміщення предметів. Колесо - кругле. Інша форма зазвичай неефективна, але бувають варіанти. Технічно колеса це відносно невеликі пристрої, закріплені на основному транспортному засобі так, щоб вони могли вільно прокручуватися. Ефект зменшення сили тертя ґрунтується на тому, що сила тертя кочення менша. Недоліки — складність конструкції, потребує більш якісних матеріалів та обробки Переваги — значне скорочення сили тертя і як наслідок економія енергоресурсів.

Щоб скоротити кількість рабів необхідні транспортування вантажу необхідно скоротити зусилля, необхідне переміщення вантажу. Давайте уявімо, що нам потрібно перемістити сто тисяч величезних каменів. Очевидно, що кількість рабів необхідна для переміщення кожного каменю залежить від ваги каменю. Проте ми не можемо зменшити камінь — тоді нам знадобиться більше каміння, тож виграш буде сумнівним. Давайте подумаємо - що заважає каменю рухатися? Виявляється, що це так звана сила тертя. Так, не дивуйтеся - камінь просто трется об дорогу, і це заважає йому рухатися швидше. Сила тертя залежить від багатьох факторів - від ваги каменю, від його розміру, від площі контакту з дорогою, від якості дороги, від гладкості каменю, і ще багатьох факторів. Ще наші пращури помітили, що більш гладкий камінь легше тягнути, якщополивати дорогу перед каменем водою, то тягнути буде легше, що можна підкласти під камінь м'які шкури, та багато інших хитрощів. Однак революційним було відкриття, що сила тертя кочення набагато менша — насправді, якщо штовхати колоду так щоб вона котилася, то це буде набагато легше, ніж штовхати її перпендикулярно. Хоча здавалося б — площа зіткнення з дорогою однакова, вага однакова і т.п. Про причини такого дивовижного феномену ми дізнаємося в наступному розділі. А зараз ми навчимося цим користуватися. Давайте підкладемо п'ять-шість колод під наш камінь. Так штовхати камінь стає значно простіше. Однак камінь переміщається по колодах, і їх доводиться постійно переставляти із заду на перед. Як це ще можна поліпшити? Уявіть собі, що ми підкладаємо під камінь не цілі колоди, а лише короткі шматки по краях каменю. Катити таку конструкцію нітрохи не важче ніж попередню, але вона страшенно нестабільна, чурки весь час норовлять викотиться ... Давайте з'єднаємо протилежні чурки довгим ціпком. А ці палиці з'єднаємо між собою іншими палицями, але таким чином, щоб ціпки, що з'єднують, чурки могли вільно крутитися в місцях з'єднання. Наша конструкція стала трохи меншою, за рахунок сили тертя в місцях з'єднання, зате набагато стабільнішою. І як бонус — ми можемо закріпити на поперечних палицях настил, який не крутиться, а значить поклавши на нього наш камінь, нам не доведеться щось перекладати і т.п. Так ось, дорогі читачі - ті чурки, на яких котиться наша конструкція називаються колесами.

Це ви показуєте різні стилі викладу. Другий стиль, більш розлогий і наочний - це не те, чим відрізняється Вігерс.

Мій досвід показує, що в середньому, приоднаковому стилі викладу, ймовірність прочитання книги обернено пропорційна квадрату від її обсягу.