Воркшопи з виявлення вимог до IT-проектами: як і навіщо їх проводити?

image

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

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

Які тут можуть виникнути труднощі?

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

Що робити?

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


Що таке воркшоп?
Воркшоп — одна із стандартних практик збору вимог, якої в літературі приділяється незаслужено мало уваги, ймовірно, зважаючи на складність формалізації процесу. Із самої назви «Workshop» зрозуміло, що в його рамках відбувається активна діяльність. Відповідно, присутні за визначенням не можуть брати пасивну участь у цих заходах. Сенс полягає в тому, що зацікавлені особи збираються разом для того, щоб визначити вимоги для кінцевого продукту. На воркшопі обов'язково присутні представники виконавця та замовника. Як правило, воркшоп займає не менше половини робочого дня.

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

Практика розроблена компанією IBM в кінці 70-х. Тоді вони називалися JAD-сесії (Joint Application Development) і пізніше лягли в основу методології Joint Application Development. В тому чи іншому вигляді воркшопи застосовуються у багатьох процесах розробки, але можуть розглядатися і як окрема техніка, без прив'язки до якого-небудь процесу.

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

Воркшоп може бути корисним, якщо виконуються декілька умов:

  • Ви розробляєте складну систему з нетривіальними бізнес-процесами. Це, мабуть, головна умова. Наприклад, система призначена для певної галузі промисловості або не має готових аналогів.
  • У проекті багато суперечливих вимог, для вирішення яких необхідно колективне обговорення.
  • Критичні для бізнесу проекти. Замовнику складно побачити користь від подібних воркшопів, особливо враховуючи їх трудомісткість. Тому чим критичніше проект, тим більше замовник буде зацікавлений в його успішності, а значить, більш охоче буде приділяти йому час.
  • Проект досить великий. Згідно зі статистикою(C. Jones. Software assessments, benchmarks, and best practices. Addison — Wesley Longman Publishing Co., Inc. Boston, MA, USA, 2000) воркшопи найчастіше використовуються на проектах розміром більше 100 функціональних точок (Functional points).
  • У кінцевому продукті зацікавлене кілька груп користувачів. Наприклад, ERP-системою будуть користуватися фахівці різних профілів.
  • Необхідність швидко позначити вимоги. Наприклад, у ситуаціях, коли ринок вже завойовують конкуруючі рішення.
Узагальнивши вищесказане, воркшопи — це інструмент, що дозволяє одночасно дозволити конфліктуючі вимоги, проаналізувати потреби зацікавлених осіб і переконатися, що вимоги враховують ці потреби.

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

  • Зменшують кількість дефектів у кінцевому продукті 20-50%
  • Знижують ризик неконтрольованого збільшення обсягу робіт на 10-80%; при цьому максимальний результат досягається при застосуванні прототипування поряд з воркшопами
  • Економлять 5-15% часу і трудозатрат на збір вимог протягом всього проекту
З чого почати?
Доброю практикою вважається починати все з планування, у випадку з воркшопами це актуально як ніколи. Для цього в першу чергу необхідно визначитися з тим, чого ми хочемо від воркшопу, які цілі переслідуємо? Це може бути поліпшення бізнес-процесу, виявлення функціональних вимог (наприклад, у вигляді сценаріїв використання, користувальницьких історій), уточнення архітектурно значущих вимог і т. д. Крім того, метою воркшопу може бути створення чорнової, так і остаточної версії документа з вимогами.

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

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

Кількість учасників В середньому 4-12, не більше 25
Тривалість сесії Від 3 до 8 годин
Частота сесій 2-3 рази на тиждень
Кількість воркшопів на проект 1-8
Час на підготовку В 2 рази більше, ніж на саму сесію
Існує кілька різних технік проведення воркшопів із збирання вимог. Ми вирішили докладно зупинитися на техніці, описаної в рамках методології ACDM. ACDM (Architecture Centric Design Method) — це підхід до розробки програмного забезпечення, його особливість — упор на архітектуру. Це далеко не найпопулярніша методологія (недавно хтось навіть видалив сторінку з її описом на Вікіпедії), проте саме в ній наводиться найбільш детальний опис техніки проведення воркшопу, яке (доповнивши своїми зауваженнями і спостереженнями) ми тут і наведемо.

Отже, воркшоп складається з трьох основних частин: планування, проведення та заключна частина.

1. Планування
Результат воркшопу в чому визначається тим, наскільки ретельно до нього підготувалися. Не подумали про транспортування — половина учасників запізнилося; пізно відправили документи по проекту — половина воркшопу піде на їх прочитання; забули запросити потрібну людину — всю роботу потрібно буде переробити. Одним словом, потрібно розуміти, що ви займаєте час багатьох людей (як правило, керівників, а, значить, їх час найбільш цінне), і потрібно зробити все можливе, щоб отримати від дійства максимальну віддачу.
На етапі планування потрібно визначитися з такими основними моментами:
  • Місце
  • Учасники
  • Програма
  • Оглядова презентація проекту>
  • Матеріали
  • Харчування
  • Транспортування


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

Учасники. Для початку потрібно визначитися, хто є зацікавленими в проекті особами. Потенційні учасники воркшопу — це замовники, кінцеві користувачі, програмісти, аналітики, інтегратори, тестувальники, системні адміністратори… словом, всі, хто має відношення до проекту. Причому якщо проект об'єднує декілька компаній-замовників та/або декілька компаній-виконавців, то, зрозуміло, присутність представників усіх цих компаній на заході обов'язково. Крім зацікавлених осіб на воркшоп можуть бути запрошені експерти в предметній області.

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

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

Автор методології ACDM рекомендує обмежитися 25 учасниками, більшу кількість координувати дуже складно.

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

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


Також команді виконавця рекомендується провести попереднє зібрання, де учасників формально представлять один одному, введуть в курс справи, призначать ролі.

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

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

Місце:…
Дата:…
Час початку:…
Час закінчення:…
NB: Увага, вимкніть телефони на час воркшопу














Активність Хто Представлення учасників <Координатор> ~15 хв Оглядова презентація проекту <Представник замовника> ~1 година Перерву ~15 хв Виявлення функціональних вимог <Обговорення під контролем координатора> ~2 години Обід ~1 година Виявлення якісних характеристик (нефункціональні вимоги) <Обговорення під контролем координатора> ~2 години Перерву ~15 хв Виявлення бізнес-обмежень та технічних обмежень <Обговорення під контролем координатора> ~1 година Підбиття підсумків <Координатор> ~15 хв


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

В ідеалі, клієнт повинен підготувати графічну презентацію (а не усну). Нижче наведемо приблизний шаблон презентації:









Тема Опис Загальний бізнес-контекст Опишіть:
  • Коротку історію компанії та ринку
  • Відмітні особливості

  • Поточні потреби і як проект допоможе їх задовольнити

Зацікавлені особи Опишіть тих, хто є ключовими зацікавленими в проекті особами (юр/фіз), їх ролі і області відповідальності. Якщо зацікавлені особи будуть безпосередньо користуватися системою, поясніть як. Загальний функціонал Опишіть приблизний функціонал системи.
Сконцентруйтеся на головному, уникайте деталей
Технічні обмеження Опишіть:
  • Апаратне або програмне забезпечення, яке розробляється система повинна в силу певних причин використовувати
  • Інші системи, з якими потрібно буде інтегруватися

  • Обов'язкові техстандарти, Гости, протоколи
Бізнес-обмеження Опишіть:
  • Тимчасові рамки
  • Бюджетні обмеження

  • Юридичні аспекти
Якісні характеристики Розкажіть про якісні вимоги до системи, таких як продуктивність, доступність, безпека. Дослівно поясніть, навіщо і кому (зацікавлених осіб) вони потрібні.


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

По мірі наближення воркшопу потрібно буде розібратися і з логістикою:

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

Організувати простір можна наступним чином:

image

Харчування. Голодне черево до роботи глухо. Щоб заощадити час на обіді, краще провести його неподалік від місця проведення воркшопу, наприклад, в тому ж самому будинку. В цьому випадку можна уникнути ситуацій, коли обід затягується через те, що хтось надто довго шукав, де перекусити. Не забудьте заздалегідь забронювати місце, зробити замовлення. Також, щоб присутні не зголодніли і не занудьгували під час воркшопу, подумайте про невеликий перекус: чай-кава, снеки.

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

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

Далі замовник презентує проект (презентація, як ми пам'ятаємо, була підготовлена заздалегідь замовником). Проводить її менеджер проекту з боку замовника.

Далі починається процес збору вимог:
  • Функціональні вимоги. Тут важливо стежити за тим, щоб учасники не почали описувати готове технічне рішення, а сконцентрувалися на тому, які завдання система буде вирішувати.
  • Якісні характеристики системи. Спочатку визначається їх повний список, це повинно зайняти не більше десяти хвилин, потім пишуться детальні сценарії для кожної з якісних характеристик.
  • Бізнес-обмеження, такі як терміни, бюджет, законодавчі аспекти та інше.
  • Технічні обмеження включають необхідність використання певної технології (бібліотеки, фреймворку, платформи, ОС та інше).


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

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

image

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


По закінченні кожного етапу розставте пріоритети наступним чином: роздайте учасникам голосу (за кількістю вони повинні становити від третини до половини кількості вимог). Кожен учасник може віддати голоси вимогам так, як вважає за потрібне. Таким чином, при голосуванні учасники можуть визначити відносну ступінь важливості вимог, на відміну від пріоритизації в дусі high-medium-low. Голосувати можна як відкрито, так і закрито.

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

3. Заключна частина
image
Обробка отриманої інформації
Після початкового етапу збору від вимог зацікавлених осіб, команда виконавця збирається окремо для обробки отриманої інформації. Передбачуваний хід подій: секретар попередньої зустрічі показує свої записи на проекторі, команда доповнює і вносить правки, звіряючи зі своїми нотатками. Цей етап — саме час для того, щоб повернутися до відкладених раніше тем.
Фінальна версія документа надсилається усім учасникам воркшопу.

На схемі знизу представлений процес обробки вимог, зібраних в рамках одного або декількох воркшопів:
image

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

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

Матеріал був підготовлений програмою MSIT-SE Університету Иннополис. Докладно аспекти збору вимог розбираються в курсі «Методи проектування програмного забезпечення».

Детальніше про програму MSIT-SE можна дізнатися здесь.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.