Прототипування - потужна техніка роботи з вимогами, яка неодноразово допомогала автору цієї статті з’ясувати, що хоче замовник та транслювати це командам розробників. Проте, як і будь яка техніка, прототипування має свої сильні та слабі сторони, про які, власне, і буде розмова.
Мушу також попередити прискіпливих колег-аналітиків, що ніяким чином не претендую на абсолютну істину. Все наведене – лише невелика ретроспектива власного досвіду та суб’єктивні висновки. Остаточне рішення щодо використання того чи іншого підходу, інструментарію або поради – особиста відповідальність читача.
Досвід перший, коли мудрості бракувало всім
Колись, на початку своєї кар’єри в середині буремних 90-х працював інженером з планування телекомунікаційних мереж в лавах компанії-оператора зв’язку.
Одного разу потрібно було вирішити питання обробки великого масиву показників роботи мережі. Як можна здогадатися, задача потребувала автоматизації, і мені доручили підготувати технічне завдання (ТЗ) для відділу ІТ-підтримки, де був невеликий штат програмістів чи програмістів-аналітиків, як тоді було прийнято їх називати.
Перша версія ТЗ, як то кажуть, «не зайшла», незважаючи на те, що вимоги були ретельно прописані за наданим шаблоном. Доля другої версії була не набагато кращою. Третя спроба була суттєвим, але все ще недостатнім прогресом. Це тривало близько двох місяців.
Отже, треба було міняти підхід: єдине, що мені прийшло в голову, було доповнення опису вимог прототипами екранних форм, що, власне, і було зроблено (на жаль, документ не зберігся). Але відчуваючи, що провал четвертої спроби буде важко пояснити своїм керівникам, вирішив перестрахуватися та пішов відразу до нового начальника відділу ІТ-підтримки, колишнього розробника, до речі.
Хлопець переглянув чималенький документ протягом хвилини-двох, підняв на мене очі та видав таке: «Питань немає, зробимо. Але, слухай, якщо ти вже витратив стільки часу на підготовку цього завдання, то може тобі варто додати ще трохи зусиль та дописати код?». Це було дотепно, але вони дійсно напрочуд швидко зробили аплікацію, яка без проблем обробляла великі обсяги даних, але без усіх отих екранних форм, які виявилися зайвими.
Чим користувався: MS PowerPoint.
Підхід: умовний Paper Prototyping.
Що спрацювало добре
“A picture is worth a thousand words”. Розробники з якихось причин відмовились відтворити прописані в технічному завданні екрані форми, але прототип допоміг проілюструвати саму ідею продукту. Це спрацювало краще ніж детальний опис варіантів використання (Use Cases).
Що варто було покращити, чого уникати
Прагніть вдосконалення, але не забувайте про здоровий глузд.
Якщо ви відчуваєте, що над вами знущаються, може, так воно і є. Це, звісно, жарт, але не слід нехтувати аналізом зацікавлених сторін (stakeholder analysis).
Досвід другий, здебільше позитивний
Уявіть собі, що вам потрібно описати вимоги для ось такого епіку «As a Customer, I want to a shop guidance to select items in a physical shop, so that I can pay either in the shop or by link later». Якщо ви вважаєте, що ця історія звучить трохи дивно, ви не дуже помиляєтесь, але в житті трапляється усіляке.
Зовсім коротко та схематично це мало виглядати як показано на мал. 1.
Мал.1.
Вам все ще не зрозуміло? Мені було теж, але на щастя здогадався перекласти свої сумніви на клікабельний прототип, створений на основі існуючих екранних форм та відправити його замовнику на валідацію, а потім на перегляд команді. Врешті решт зупинилися ось на такому варіанті (мал. 2)
Мал. 2.
Чим користувався: InVision.
Підхід: моделювання потоку робіт (Workflow Modelling).
Що спрацювало добре
Прототип чудово демонстрував реалізації різних варіантів процесу покупки.
Було створено єдиний робочий простір для взаємодії замовника, бізнес-аналітика, розробників та тестувальників.
Використання існуючих екранних форм суттєво скоротило час на створення прототипу, спростило валідацію та подальшу роботу розробників.
Що варто було покращити, чого уникати
Єдине зауваження з боку замовника: «Це ж так просто та очевидно! Навіщо вам потрібно два спринти (4 тижні, прим. автора), а не 2 дні на реалізацію?». Отже не забуваємо працювати з очікуваннями з боку замовника.
На жаль, InVision припинив підтримку інструментарію створення прототипів на основі існуючих екранних форм. Тому раджу поцікавитись останніми досягненнями в цьому напрямку, особливо з використанням штучного інтелекту.
Досвід третій: як можна, але не варто робити
Ви – бізнес-аналітик, працюєте над вимогами до створення звітності для керівників проектів. Незважаючи на те, що проектна інформація міститься в Jira, замовники вважають, що наявні інструменти побудови звітів недостатні.
Отже, ви розробили форми звітів (див. мал. 3), які вкрай сподобалися замовникам, але дехто з дуже впливових користувачів поставив під сумнів чи можливо таке взагалі.
Мал. 3.
Так, таке можливо, але для цього треба було побудувати функціональний прототип (мал. 4). Це була Windows аплікація, яка включала повноцінну базу даних, з пов’язаними екранними формами, процедурою імпорту даних Jira в вигляді CSV-файлу, та, власне, звітністю (мал. 3).
Мал. 4.
Чим користувався: MS Access, Visual Basic for Applications (VBA).
Підхід: функціональний прототип (еволюційний).
Що спрацювало добре
Доведено можливість побудови складної управлінської звітності шляхом створення робочого прототипу інформаційної системи.
Продемонстровано, що час на створення звітності можна скоротити в чотири рази.
Що варто було покращити, чого уникати
Створення вимог перетворилося на повноцінну розробку. Навіть якщо ви добре володієте тією чи іншою мовою програмування, не варто забувати про те, що ви аналітик (а я був саме аналітиком) і ваша первинна задача – робота з вимогами. Інакше кажучи, якщо ви побудуєте діючий прототип, але в процесі розробки проґавите критично важливу вимогу, таке навряд чи сподобається замовнику.
Варто зазначити, що замовники, навіть дуже впливові, теж люди та можуть помилятися. Тому перед тим як приймати вислів «Нас не влаштовує штатна звітність» за аксіому, раджу дослідити що саме не влаштовує та з яких причин. Особливо, якщо йдеться про Jira, або щось подібне.
Досвід четвертий, який враховує третій
Маленька компанія в Сполучених Штатах багато років працювала на ринку кухонних меблів на замовлення десь на Середньому Заході. Процес оформлення замовлення до умовного сьогодення (події відбувалися 2019 році) не змінювався з середні минулого сторіччя. Тобто замовник, звичайний господар, який захотів нові меблі на кухню, або вирішив оновити старі, приходив в офіс компанії, сідав за стіл з менеджером з продажів та листав величезні каталоги варіантів дизайну та комплектуючих. Менеджер все фіксував на папері, час від часу перевіряючи, чи все він правильно записав. Це могло займати від декількох годин до декількох днів, але всіх все влаштовувало. Раптом щось трапилось, і власники компанії вирішили автоматизувати процес створення замовлення, наскільки це було можливо.
Щоб уявити складність задачі, подивиться на кількість можливих варіантів реалізації дверцят (див. Мал. 5). Звісно, не для кожного стилю підходили всі породи деревини, або опції панелей, проте приблизно так, кінцева кількість варіантів величезна.
Мал. 5.
Як можна зрозуміти, візуалізація була ключовим інструментом спілкування. Ба більше, це було єдиним можливим варіантом, оскільки часу для підготовки опису вимог для такого проекту-перевірки концепції (Proof of Concept) майже не було: через два тижні замовник хотів відчайдушно бачити результат. Він його побачив у вигляді працюючої аплікації, дуже схожою на прототип, який він погоджував (мал. 6).
Мал. 6.
Чим користувався: MS PowerPoint, Sketch.
Підхід: моделювання потоку робіт (workflow modeling).
Що спрацювало добре
Використання вже готових шаблонів екранних форм однієї з е-комерційних платформ.
Передача щойно погоджених форм та моделей процесів розробникам.
Що варто було покращити, чого уникати
Коли діють жорсткі обмеження в ресурсах важливо чітко домовлятися з замовником, яку саме частину вимог буде демонструвати перевірка концепції.
Не забуваємо про час необхідний на опис самих вимог та не соромимося казати про це на етапі планування. В цьому конкретному випадку мені пощастило, бо працював з командою досвідчених розробників, але так було не завжди.
Досвід п’ятий, провальний
А як вам така задача? Компанія-дилер американського оператора мобільного зв’язку пропонує подорожуючим з Європи придбати заздалегідь SIM-картку оператора. Картки надсилаються звичайною міжнародною поштою на вказану домашню адресу майбутнього абонента, а активуються при прибутті до США. Причому абоненту потрібно заздалегідь подати заявку на активацію картки через окремий веб-портал, що, власне, і було темою розробки, де вказати номер замовлення, особисті дані, дату активації та 19-ти значний номер отриманої SIM-картки. Звісно, зараз таке важко уявити, але цієї історії не так багато років.
Перечитавши вимоги та згадав свій багатий досвід роботи в телекомі та е-комерції, вирішив запропонувати ось таке (мал. 7 та 8):
Мал. 7.
Мал. 8.
Для даної статті взяв лише дві форми з восьми, найбільш показові. Але кожна екрана форма була старанно відпрацьована з посиланням на конкретні вимоги та поясненнями. До речі, як вони вам? Мені досі подобаються. Те саме казав мій колега-аналітик, якому я відправив їх разом з вимогами на перегляд, як незалежному експерту.
Чим користувався: MS PowerPoint.
Підхід: такі собі візуалізації з текстом (Storyboarding).
Що спрацювало добре
Форми гармонічно поєднували функціонал онлайн магазину та порталу активації.
Послідовність форм в вигляди слайд-шоу наочно демонструвала процес повністю.
Кожна форма мала посилання на функціональні вимоги, які вона покривала.
Що варто було покращити, чого уникати
Якщо замовник каже, що його цікавить лише портал з активації, тож і дайте йому вимоги та прототипи саме порталу. Додатковий функціонал можна запропонувати потім, якщо, звичайно, замовник готовий це сприймати. В моєму випадку замовник не був до цього готовий, проте негативний результат теж має свою цінність. Тож, ділюсь.
Епілог
Отже, прототипування є надзвичайно ефективною технікою роботи з вимогами, а також
зазвичай добре сприймається замовником (але пам’ятаємо про аналіз зацікавлених сторін),
має доповнювати, але не підміняти собою вимоги,
має фокусуватися на ідеях/фунціоналі, нехтуючи деталями (what rather than how). І, нагадую, прагніть досконалості, але пам’ятайте про здорові обмеження та правильно формуйте очікування замовника.
Володіння спеціалізованими інструментами прототипування важливо, але не критично. Виключенням з цього можуть бути випадки, коли або вже напрацьована якась база прототипів в певному середовищі, або доступні якісні галузеві шаблони (приклад - Axure RP). Це дійсно працює, але здебільше чув від замовників щось на кшталт «Зробить як у тих хлопців, тільки краще», а для таких задач достатньо MS PowerPoint.
Ну, і нагадую прописну істину: замовника слухаємо уважно, неупереджено, але критично.
Власне, все. Удачі з прототипуванням!
Про автора
Володимир Туровець, практикуючий бізнес-аналітик, CBAP/PSPO II
e-mail: vturovets@gmail.com
Comentários