Про цю частину: іноді, коли ми беремо в роботу завдання, ми ще не в курсі, що за ним стоїть. Навіть не скажу, що ми бачимо тільки вершину айсберга, ми бачимо тільки його обриси вдалині. А нам потрібно підпливти до нього по солоній воді, не будучи віднесеними морськими течіями і не напоровшись на його частини, приховані під водою. У цій статті спробую сконструювати ехолот, який у цьому допомагає.
У попередній статті я розповідала, чому важливо вміти і хотіти ставити запитання тому, хто попросив вас щось зробити, сподіваюся, що мені вдалося показати на прикладах, що уточнення очікувань замовника - так я називатиму будь-кого, хто ставить задачу або звертається до вас із проханням - не необов'язкова нудьга, а необхідний інструмент, який зможе значно заощадити нам усім час і нерви. Того, хто бере завдання в роботу для вироблення комплексного рішення, що дає змогу принести цінність замовникові - тобто нам із вами - я називатиму експертом.
Я вважаю, що в ІТ дві визначальні сутності - це інформація і люди. Я дуже люблю і добре вмію працювати з інформацією і трохи менше люблю і трохи гірше вмію працювати з людьми. Інформація - плоть і кров нашої роботи, але тільки люди надають їй справжнього значення і перетворюють на застосовне знання. А значимість знання я навіть не готова обговорювати, настільки для мене це неминуща цінність.
Я часто чула від керівників у DataArt, що ми одразу маємо запропонувати замовнику рішення або набір рішень, щоб показати, що він прийшов до справжніх експертів, здатних вибудувати будь-яке технологічне рішення. Не можу сказати, що я з цим абсолютно згодна. Так, показати замовнику кілька способів вирішення його завдання - обов'язковий крок вибудовування роботи, але чи перший? Якщо ви одразу говорите і поводитеся так, наче точно знаєте, що робити, це, з одного боку, викликає повагу до вашого професіоналізму й уміння розв'язати практично будь-яке завдання, з іншого - не демонструє вашого бажання допомогти саме цій людині з саме її проблемою. Чуючи, що є готові рішення, людина відчуває, що її завдання стандартне, контрольовано розв'язуване, і в неї виникає бажання скинути ініціативу на вас - виконавця. І, з одного боку, це прекрасно, замовник не заважатиме нам робити нашу улюблену роботу, з іншого - величезний ризик: він не розуміє необхідність своєї залученості, і, найімовірніше, не прийме результат вашої спільної роботи як свій, не буде готовий виступати його адвокатом. Оскільки ми займаємося розробкою програмних рішень на замовлення, незалученість замовника в процес створення ПЗ стає однією з найбільших проблем.
4 питання для бізнес-аналітика перед початком робіт
Отже, повертаємося до нашого айсберга і спробуємо спорудити ехолот. Я пропоную сконструювати його з чотирьох блоків запитань, що стосуються:
· Поточного стану роботи.
· Задоволеності поточним станом.
· Узгодженістю використовуваного словника.
· З'ясуванням, хто ще залучений до процесу.
Припустімо, прийшов до вас приятель із проханням допомогти в переїзді, родич із проханням допомогти влаштуватися на роботу, керівник із дорученням підготувати інформацію для звіту, HR-фахівець із проханням проінтерв'ювати кандидата. Уявіть собі, що ви перебуваєте в першому діалозі з людиною, яка прийшла до вас по допомогу.
Першими запитаннями найчастіше буде "коли?" і "де?", хоча про це, найімовірніше, розкажуть і так, а важливе запитання, яке я б рекомендувала ставити, - "звідки ми рухаємося?".
Питання 1. Поточний стан
Той, хто звернувся до вас із проханням, має свій досвід і очікування від процесу та результату виконання завдання, про які ви часто не знаєте. Якщо вас попросили допомогти з переїздом, це може бути прохання надати вашу машину, а може, машина є, але потрібно носити речі на четвертий поверх. Інтерв'ю може бути у ваш проєкт, а може бути за вашою спеціальністю, але для людей, чиїх очікувань ви не знаєте.
Як це робиться зараз?
У новій для вас команді, найімовірніше, є правила виконання роботи, аналогічної тій, яку вам належить виконувати, у командах часто є стандартні підходи до проєктування інтерфейсу або API, звичні формати опису вимог, а замовник звикає отримувати звітність у конкретному форматі.
Коли ми приходимо на нове місце роботи, найчастіше чекаємо, що нам розкажуть, як тут усе влаштовано і за якими правилами отримувати перепустку в офіс або як погоджувати відпустку. Приходячи в гості і бажаючи помити руки, здається цілком логічним запитати де це можна зробити і яким рушником можна витерти руки. І в тому, і в іншому випадку вам навіть розкажуть про це до того, як у вас це питання виникне: у господаря ситуації є інтерес, щоб на його території зберігався вибудуваний ним порядок. Водночас, коли ви приходите в конкретну команду, її звички можуть виявитися несподіваними: десь заведено домовлятися про відпустку за кілька місяців, а десь достатньо закинути запит на відпустку в PM, десь заведено домовлятися про зустрічі за день-два, а десь достатньо закинути зідзвон на будь-який вільний у календарі слот протягом дня. І про це не те щоб не хочуть розповідати, просто в повсякденному житті команди це так природно, що ви дізнаєтеся про це, тільки коли вас не зможуть видзвонити на черговий дзвінок, тому що ви відійшли попити кави.
Так само і в роботі із замовником: ми приходимо щоб дописувати наявну систему, яка підтримує робочий процес. І цей процес зараз працює! Так, нехай він іноді має непоказний вигляд, але на те є свої причини: він зав'язаний на суміжні процеси і на конкретних людей, які в ньому беруть участь.
З одного боку, доручаючи роботу (беручи в проєкт) досвідченому фахівцеві, замовник чекає, що в роботі щось якісно зміниться - не завжди усвідомлюючи, що саме, - але водночас якесь робоче ядро має залишитися незмінним. І при тому воно здається йому очевидним і таким, що не потребує озвучування. Тому запитання "а як ви робите це зараз?" далеко не зайве, щоб своїми діями не завдати шкоди замовнику, замість того, щоб допомогти вирішувати його завдання.
Що вже зроблено і ким?
Працюючи у великій компанії, ми часто всього лише одна з ланок ланцюга створення цінності, причому, як я вже згадувала в попередній статті, ми часто погано розуміємо, як працюють попередній і наступний етап: на них працюють люди з принципово іншими компетенціями. Ще більше ситуацію ускладнює те, що при цьому наші компетенції та сфери відповідальності перетинаються. Перш ніж передати презентацію на оформлення дизайнеру, замовник уже взяв якийсь шаблон слайдів і створив структуру відповідно до своєї ідеї майбутньої розповіді. Керівник проєкту може спонтанно сформулювати шматок бізнес-вимог, а проєктувальник інтерфейсу без допомоги аналітика описати користувацькі сценарії. Тімлід може за відсутності досвідченого девопса сам спроектувати і налаштувати все необхідне середовище для розробки і тестування.
Причому, оскільки всі описані завдання багатофакторні, це не означає, що тепер дизайнеру, аналітику або девопсу, які переймають естафету, нема чого робити, або навіть, що його завдання стає набагато легшим. Це лише означає, що потрібно вже зважати на наявний бекграунд, щоб рухатися далі. Дизайнеру потрібно не тільки "пограти шрифтами", а й зрозуміти, чи відповідний шаблон слайдів використано, і наскільки може змінитися структура і кількість контенту, щоб дизайн не поповз при масштабуванні.
Керівник проєкту каже, що бізнес-вимоги такі і замовник з ним згоден? Аналітику тепер потрібно впевнитися, що формат, у якому ці вимоги написані, зрозумілий команді, і забезпечити трасування з того, що написано для замовника, на завдання команди.
Проектувальник інтерфейсів уже підготував набір користувацьких сценаріїв - аналітику потрібно перевірити їхню повноту, узгодженість із бізнес-вимогами й організувати їхнє узгодження з представниками замовника та командою.
Тім-лід видав девопсу завдання на побудову робочої інфраструктури за наявності вже працюючих стендів, але пізніше з'явилися додаткові вимоги до тестування, наприклад до навантажувального, і середовище потрібно модифікувати і підтримувати.
Кожен експерт на своєму місці відповідає за комплексне розв'язання свого завдання, і водночас розуміючи, що він не перша людина у світі, якій доручили це завдання, має насамперед дізнатися, що вже зроблено і ким. Це дасть змогу не тільки не дублювати вже зроблену роботу, а й уникнути конфліктів при перетині зон відповідальності.
Коли приходиш у нову команду, переймаючи роботу колеги, який пішов, потреба в цьому питанні є ще більш очевидною. З якої точки я починаю роботу? Хто робив це до мене? Чи доступна ця людина для передання експертизи за рішенням і вибудуваним процесом? Адже часто буває, що людина вже не тільки пішла з проєкту, а й звільнилася з компанії, це теж кратно збільшує час онбордингу і ризики проєкту.
Питання 2. Задоволеність поточним станом
Я дочка пострадянської інженерної сім'ї, а значить, моє ставлення до науки і техніки скоріше позитивістське: я вважаю, що вони покликані позбавити нас рутини, дати змогу займатися більш творчими завданнями і взагалі поліпшити нашу якість життя. Хоча зараз я розумію, що світ набагато складніший, і далеко не всім подобається займатися творчим абстрактним проєктуванням, у моїй голові намертво засіли цитати з мультфільмів і фільмів мого дитинства: "Щастя - справа техніки!" та "Гарують роботи - щаслива людина!" («Вкалывают роботы — счастлив человек!» ). Напишіть у коментарях, якщо розумієте, про що я говорю.
Тому, зустрічаючись із випадком, коли інтерфейс публічної системи настільки складний, що для внесення в неї даних найняли аж двох людей, це змушує волосся на моїй голові ворушитися. Наймати людей, щоб компенсувати недоліки системи? Неймовірно! Це приклад, як мій особистий досвід і переконання впливають на те, що я вважаю важливою проблемою, коли зустрічаюся з конкретною ситуацією. Але чи є те саме проблемою для замовника, чи йому потрібна моя допомога у вирішенні зовсім інших завдань?
Що саме ви хочете змінити?
Будь-який експерт, тим паче експерт у сфері IT, схильний до структурного мислення, вибудовування систем і оперування фактами, зрозумівши поточний стан завдання, готовий з місця в кар'єр видати пару-трійку критичних проблем у поточному стані справи та ще насипати дюжину дрібних рекомендацій, що можна поліпшити. І це найчастіше ясно написано на наших обличчях і викликає проблеми у вибудовуванні відносин із замовниками. В одному з проєктів через день збиралися зідзвони по 10+ осіб, включно з представниками замовника, щоб обговорити кілька не пов'язаних між собою питань. Неймовірна, божевільна трата часу! Про що я не забула сказати відразу після входу в проєкт. Але пізніше виявилося, що тільки так можна було дати зрозуміти власникам системи, що перебудовується, з боку замовника, що їхня команда контролює ситуацію, і забезпечити передачу ними знань з безпечної позиції. І питання стає, не як позбутися цих дзвінків, а як зробити їхню організацію якомога ефективнішою з огляду на зростаючу команду.
Я бачила проблему в тому, що виявилося несучою конструкцією проєкту. Чи могла я знати про це спочатку? Ні. Чи могла я розібратися в ситуації, перш ніж почати висловлювати судження? Так.
Ось інший приклад: ти дивишся на систему і бачиш, що тут мають вводитися дані дуже суворого формату, але жодних обмежень з точки зору внесення даних немає. А ще не передбачено зв'язку між даними в різних полях однієї форми, хоча за бізнес-логікою він явно присутній. Консистентність даних під загрозою! Але замовник пояснює, що цю форму заповнює рівно одна людина, яка ж і розробляла цю систему, тому за дані, які вводять, можна не хвилюватися, а ось дизайн форми треба переробити терміново відповідно до нових правил розроблення веб-інтерфейсу, прийнятих у компанії.
Щоб одразу не кидатися розв'язувати проблеми, які для замовника не є проблемою (читай, він не готовий витрачати сили і гроші на зміну ситуації в цих галузях), я навчилася, перш ніж висловлювати судження і рекомендації, ставити запитання, наскільки замовник задоволений поточним станом справ. Що хотілося б поліпшити? Чому замовник вважає, що тут потрібні зміни? І часто виявляється, що видима збоку неефективність процесу або милицю в рішенні виправдано об'єктивними факторами, і зробити з ними нічого не можна, а вирішувати треба зовсім іншу задачу, що впливає зовсім на інші процеси.
Ставлячи запитання, що не влаштовує в поточній ситуації, можна не просто зрозуміти, що для замовника значуща проблема, а що - просто факт, з яким він успішно співіснує, а й вибудувати пріоритети вирішення виявлених проблем.
Що зараз працює добре?
Однак поставити запитання тільки про те, що не влаштовує і потрібно поміняти, недостатньо, потрібно також з'ясувати, що зараз працює добре, і упевнитися, що наше нове рішення цього не зіпсує. Відповідь на запитання "а що зараз працює добре і не хотілося б міняти?" дає змогу дізнатися про процеси, що часто повторюються, звички користувачів і критичні функції, з якими, можливо, раніше були проблеми, але тепер усе добре, всі раді і - не дихайте!
Наприклад, зараз, коли всі працюють з одним excel-файлом, будь-який керівник може відкрити файл у реальному часі та переглянути звіт про актуальний стан справ, і є страх, що під час переходу на іншу, нехай навіть просунутішу, систему з гнучким керуванням правами доступу, таке формування звітів буде недоступне з коробки.
Таке запитання дасть змогу не тільки виконати принцип "працює - не чіпай", а й дасть змогу замовнику злегка похвалитися тим, чим він пишається у своїй роботі. Замовник дуже цінує, коли ви виявляєте щиру зацікавленість і бажання зрозуміти ситуацію, в якій він перебуває.
Питання 3. Що означають ті чи інші терміни?
Нещодавно один із колег проводив вебінар про те, як справлятися із синдромом самозванця. Одним із рецептів було "знати і використовувати професійну термінологію". Знати і використовувати професійну термінологію необхідно для ефективної роботи в команді та професійного розвитку, але під час спілкування із замовником спочатку добре було б упевнитися, що ваш vis-a-vis розуміє ці терміни і розуміє їх так само, як ви.
Простий приклад із нашої повсякденності: кожен, хто пропрацював в IT хоча б півроку, чув термін User Story, і 80 % із цих людей знають, що у User Story є канонічна форма "As a <Role>..." Водночас команди розробки, які користуються Jira для управління потоком завдань, знають, що в Jira є стандартний робочий елемент (Work Item) з назвою User Story, і те, що там пишеться і в якому вигляді, може трохи більше ніж повністю відрізнятися від загальноприйнятого розуміння терміна User Story, бо жодних обмежень на формат заповнення немає, і використовують цей елемент різні команди для дуже різних цілей.
Ще один приклад різного розуміння одного й того самого терміна: колега, з яким я була знайома до цього вже понад 5 років і вважала, що наші поняття щодо термінів бізнес-аналізу більш-менш синхронізовані, попросив мене описати блок бізнес-процесів, які забезпечуються системою, над якою він працював. Коли я принесла йому першу чернетку BPMN-діаграми, він виявився дуже здивований результатом, виявилося, він очікував чогось зовсім іншого. Після ще кількох ітерацій переговорів ми склали список функціональності системи, яка на той момент не відповідала потребам її власників, і цей результат задовольнив усіх. Який стосунок це мало до опису бізнес-процесів? Практично жодного.
На що я відразу звертаю увагу і намагаюся прояснити в інтерактивному режимі:
Коли замовник використовує один і той самий термін або словосполучення кілька разів, напевно, це щось важливе, і доскональне розуміння цього має ключове значення в подальшій спільній роботі.
Коли використовується зовсім вже затертий термін, типу того ж User Story, або SCRUM, або stakeholder.
Складати словник у перший же момент немає необхідності. Що саме багато людей розуміють по-різному, а отже, які терміни потребують тлумачення саме для вашої команди, стане зрозуміло пізніше, після місяця-двох спільної роботи.
Але щонайменше варто насторожитися, якщо такі терміни використовуються власне в постановці задачі, і переформулювати її конкретнішим чином.
Тепер, коли ви вже більш-менш говорите однією мовою і замовник уже достатньо розповів про ситуацію і своє ставлення до неї, можна розпитати і про інших потенційних учасників процесу.
Питання 4. Стейкхолдери
Дозвольте мені навести ще один приклад із реального життя. Мені спало на думку, що я можу написати книжку про те, як працює ІТ-галузь і що її відокремлює в плані повсякденних звичок від решти світу, моя подруга теж у цей час писала книжку й познайомила мене з маркетологом, яка допомагала їй із вибудовуванням стратегії написання та просування її книжки. Це виявилася досить приємна жінка, яка спочатку поцікавилася чим я займаюся, а потім приголомшила мене запитанням: "Хто твоя цільова аудиторія?" Це питання мене збентежило. Я підозрюю, що в маркетологів термін "цільова аудиторія" вважається таким самим самоописуваним, як "стейкхолдери" в ІТ-проєктах. Я сподівалася, що вона як маркетолог допоможе сформулювати поняття про цю саму цільову аудиторію, а не мені доведеться подавати на вхід інформацію, на роботі з якою вона спеціалізується. Чи відчула я силу її професіоналізму і серйозність підходу? Безумовно. Чи захотілося мені замовити в неї платну консультацію? Ні, я відчула, що всю роботу при співпраці з цим фахівцем мені все одно доведеться виконувати самій.
З іншого боку, не поставити мені це запитання вона теж не могла, адже їй же потрібно мати орієнтири, про кого взагалі йдеться. Як я згадала трохи вище, такі загальні терміни, як "стейкхолдер", вимагають розшифровки на самому початку спілкування із замовником. Ставити запитання про стейкхолдерів треба, і що раніше, то краще, але звичну форму "а хто в нас стейкхолдери" ("а хто в нас тут такий гарненький?") краще замінити на набір конкретніших запитань, на які набагато легше відповісти:
Хто ухвалюватиме рішення про бюджет і склад робіт?
Разом із ким я працюватиму над цим завданням?
З ким можна проконсультуватися щодо вимог безпеки?
Хто користуватиметься результатом роботи?
Хто оцінюватиме результат роботи?
І тільки цього варто блиснути запитанням "а які ще стейкхолдери можуть бути?".
Імовірність швидко отримати відповіді на такі сфокусовані запитання набагато вища, ніж на запитання з використанням максимально загального терміна, який радше викличе в людини хмару асоціацій, ніж змусить її видавати вам потрібну інформацію.
Звісно, замовник, чи то керівник проєкту, чи то менеджер з боку клієнта, чи то аналітик, чи то тімлід, рідко приходить на першу зустріч, щоб ви взяли в нього інтерв'ю, планомірно поставивши всі запитання. Якщо замовник захоче спочатку поговорити, що, на його думку, ви маєте зробити (а це буває частіше, ніж хотілося б), потрібно уважно його вислухати, але все-таки знайти хвилину і поставити необхідні запитання про контекст. Найкраще, звичайно, включити цю тему в план першої зустрічі. Але якщо не вийшло вперше, обов'язково поставте ці запитання пізніше - особисто або письмово.
Можливо, вам і не доведеться ставити всі ці запитання явно: коли ставиш одне запитання, це запускає в голові замовника ланцюжок реакцій, що змушує згадувати дедалі більше подробиць і деталей, і людина зазвичай починає розповідати їх уже самостійно.
Резюме
Перший діалог - ще не час включати експертизу на повну потужність, треба приготуватися перед стрибком і поспостерігати за рухом козулі: вивчити, як замовник орієнтується в поточній ситуації. Тут потрібно трохи пригальмувати себе і розуміти, що запитання мають бути гранично конкретними і не повертати людину у фрустрацію, тому вони мають бути відкритими, але не надто широкими та без застосування спеціалізованої термінології. Якщо ви втрутитеся в процес на етапі прояснення контексту, наводки вашого особистого досвіду і переконань завадять вам по-справжньому допомогти людині. Якщо не втрутитеся, вам відкриються несподівані коштовності в особистому і в професійному плані.
З одного боку, в процесі знайомства потрібно створити якусь магію, але ця магія має бути простою і відкритою, як повсякденні карткові фокуси або маги, що "левітують" на багатьох пішохідних вулицях столиць. Ми просто ставимо відкриті й конкретні запитання, які допомагають прояснити ситуацію і ставлення людини до неї, з іншого - вибудовувати довіру і робити основні ризики очевидними.
Тому варто підходити до першого діалогу не з чітким наміром знайти розв'язання одразу всіх проблем, а з бажанням зрозуміти якомога більше про ситуацію до того, як ви поринете в її зміну, і наміром побудувати середовище для спільного вирішення цього завдання.
Отже, відповіді на які запитання потрібно отримати бізнес-аналітику перед початком робіт в тому чи іншому вигляді:
Як замовник бачить поточну ситуацію,
Як це робиться зараз?
Що вже зроблено і ким?
Як він ставиться до цієї ситуації?
Що саме ви хочете змінити?
А що зараз працює добре і не хотілося б змінювати?
Які специфічні слова він для цього використовує?
Що саме ви маєте на увазі, коли говорите "наша система"?
Хто ще залучений до вирішення цього завдання?
Хто ухвалюватиме рішення про бюджет і склад робіт?
З ким можна проконсультуватися щодо вимог безпеки?
Хто користуватиметься результатом роботи?
Хто оцінюватиме результат роботи?
Зрозуміло, що це тільки приблизні формулювання запитань, і ви не тільки можете, а й маєте модифікувати їх під своє завдання, щоб зробити ще більш конкретними. Наприклад, на прохання підготувати звіт запитання звучатиме не "що вже зроблено і ким?", а "чи є вже дані для звіту і в кого їх можна взяти?". Іноді зручніше не поставити запитання, а перевірити самому: деколи в систему просять додати нову функціональність, а фактично можна знайти вже написаний і закоментований код, який робить приблизно те саме, але це потребуватиме часу. А в разі запиту замовника автоматизувати якийсь процес запитання "що не хотілося б міняти?" звучатиме радше як "яких сфер діяльності не повинна торкнутися нова автоматизація.
Іноді людина приходить за адресою, іноді взагалі незрозуміло, який стосунок її проблема має до вас. У будь-якому разі, не завадить поставити такий набір запитань. У кращому випадку, людина сама зрозуміє, що звернулася не до того, у більшості випадків ви зможете краще зрозуміти, як розв'язати задачу, у гіршому - обізве вас занудою, що буде для вас прапорцем: людина сама не знає, що їй потрібно. Як розбиратися, чи ви найкращий кандидат для виконання поставленого завдання, і говорити про це із замовником, буде наступна стаття.