“Одного разу ми зарелізили не ту фічу через те, що бізнес-аналітик її неправильно описав”
Коли я обирала тему для статті, то думала про те, що могло б допомогти мені бути ефективнішою як бізнес-аналітику, якби я дізналася про це років так на 5 раніше. І найближчою виявилася тема взаємодії з командою. Ні, не тому що стосунки з командами не складалися - всі мої команди були настільки доброзичливими і готовими допомогти, наскільки це взагалі можливо. На той момент, у моєму розумінні, професіоналізм полягав у тому, щоб закривати максимум питань самостійно, не залучаючи команду. Давайте розберемо, чому це не працює?
Бізнес аналітик - не розробник.
Маючи ступінь магістра в галузі розробки програмного забезпечення, я визнаю, що будь-який Junior developer володіє тими технічними скілами, про які я і думати забула. І ось саме вони зі свого боку дадуть відповідь на технічні питання точніше і швидше, саме вони з кількох варіантів запропонують саме той, який буде оптимальнішим і правильнішим з точки зору реалізації, і саме вони стоятимуть на сторожі всіх наших non-functional requirements.
Завдяки взаємодії з розробниками, бізнес-аналітик вчиться звертати увагу на технічні аспекти і деталі реалізації та з кожним разом бачитиме все більше і більше технічних нюансів. Давайте не забувати комунікувати з тими, хто розвиває наші technical skills день у день.
Бізнес-аналітик - не QA.
Дуже не хочеться тут применшити чийсь внесок у роботу бізнес-аналітика на проєкті, але я абсолютно щиро вважаю саме тестувальників кращими друзями бізнес-аналітиків. Саме в них у голові під час прочитання вимог виникає багато проміжних і негативних кейсів, які варто було б прописати у вимогах. Тестувальники - найуважніші та найприскіпливіші читачі ваших acceptance criteria, бо саме вони планують їх використовувати у своїх майбутніх тест-кейсах. Тож лайфхак особисто від мене: коли, як вам здається, всі вимоги написані, всі кейси враховані, видихніть, заплющте очі та уявіть перед собою команду тестувальників, з якими ви працюєте. Кілька додаткових кейсів спадають на думку гарантовано.
Бізнес-аналітик - не PM.
Як би я не вивчала ризик-менеджмент, скільки б я не складала собі списків можливих ризиків, на які варто звернути увагу, проєктні менеджери завжди знайдуть, що додати зі свого боку. Ба більше, у той час, коли розробники й тестувальники вдаються в деталі, РМи завжди тримають у себе в голові цілісну картину проєкту, і саме вони не дадуть відійти від initial vision і взяти щось out of scope.
Бути на одній хвилі з ПМами - це завжди показувати чудовий командний дух (team spirit) замовнику, на важливих коллах ваш найголовніший союзник і навіть іноді рятівник - це проєктний менеджер (і працює це в обидва боки).
Спільна робота бізнес-аналітика і проєктного менеджера дає змогу ефективно розподіляти завдання, ресурси і час, а також швидко реагувати на зміни в проєкті.
Бізнес-аналітик - не дизайнер.
Як людина, яка не менше тисячі разів уже приходила до дизайнера із запитом "Давай зробимо красиво?", я можу сказати, що дизайнери - це ще одне джерело натхнення. Крім того, що всі чорнові вайрфрейми від руки в блокнотах стануть ідеальною картинкою, на яку приємно дивитися, дизайнери завжди із задоволенням підкинуть вам кілька ідей з юзабіліті і навіть озвучать кейс, який, після всіх обговорень, уже просто неможливо було знайти. А він знайшов. В ідеальному світі дизайнери беруть участь від самого початку проєкту, тобто у вас теоретично навіть може бути можливість обговорити з ними вимоги і не один раз почути запитання "А як ти собі це уявляєш?".
Тепер я хотіла б розглянути детально основні етапи роботи з вимогами, на яких залучення команди принесе максимальну користь. Одразу кажу про те, що я пропускаю етап збору вимог, оскільки на цьому етапі переважно вся робота лежить на плечах бізнес-аналітика.
Аналіз вимог
Розглянемо ситуацію, коли у нас вже є вимоги у вигляді user stories, і на цьому етапі нам знадобиться допомога команди у виділенні основних фічей і епіків. Зі свого боку розробники можуть вже мати уявлення про архітектуру системи і не дадуть помилитися в розподілі та декомпозиції вимог, наприклад, відокремити логіку платежів від логіки реєстрації користувачів. Від себе мені б хотілося додати, що на цьому етапі бізнес-аналітик зазвичай видихає після нескінченних інтерв'ю зі стейкхолдерами і нарешті розуміє, що він тут не один, а з цілою командою людей, які готові брати, і беруть на себе відповідальність за вироблений продукт.
Специфікація вимог
На цьому етапі бізнес-аналітик знову ненадовго повертається у свій світ для написання вимог уже в більш детальному форматі (наприклад, user stories + acceptance criteria). Одразу після цього - одна з найважливіших, як на мене, частин - обговорення вимог із командою. На цьому етапі в нас уже будуть відкинуті ті вимоги, які ми не можемо реалізувати через технічні обмеження, тому ми працюємо вже з готовим і детально описаним списком вимог. Щоб показати яку реально користь може принести команда, я б хотіла надати список речей, які були б втрачені, якби я не набиралася сміливості для того, щоб прийти до команди зі своїми напрацюваннями:
всілякі валідації;
коректне опрацювання винятків у роботі системи;
аналітика для відстеження метрик;
нефункціональні вимоги;
крос-платформеність.
І це далеко не весь список. Такі сесії для опрацювання вимог особливо актуальні на початкових стадіях проєкту, а потім вони часто переносяться в грумінг беклога.
Як окрему частину цього етапу, я хотіла б виділити обговорення дизайну, якщо він має місце бути на проєкті. Після того, як бізнес аналітик отримав дизайни, які відповідають баченню його, і баченню проєкту, ми показуємо це команді. Ви самі здивуєтеся тому, скільки всього могло бути втрачено хоча б через те, що ви кілька днів поспіль у поті чола просиділи з дизайнерами над прототипами, втративши будь-яку здатність адекватно їх оцінювати.
Проектування
На етапі проєктування ми продовжуємо деталізувати вимоги, але що цікавіше - це опис складних потоків виконання. Разом із командою бізнес-аналітик займається створенням (або рев'ю заздалегідь створених) діаграм - наприклад, діаграми послідовностей і діаграми активностей. Навіщо над команда, якщо ми пройшли вже стільки курсів, прослухали стільки вебінарів з Use case діаграм? Обговорення допоможе нам доповнити діаграму, якщо ми щось проґавили, і так само допоможе нам спростити її, адже ще не раз цю діаграму ми використовуватимемо під час онбордингу нових членів команди або для презентацій технічним фахівцям з боку замовника.
Разом з діаграмами, на цьому етапі створюється технічна документація, яка зі свого боку може бути перевірена бізнес-аналітиком на предмет повноти опису і рівня доступності.
Розробка
Я не буду детально описувати, що відбувається на цьому етапі, але хочу сказати, що робота бізнес-аналітика на ньому не закінчується. Для мене цей етап відрізняється вже повноцінним і регулярним "виходом у світ". Ви вже не сидите день і ніч, опрацьовуючи вимоги, а відвідуєте стендапи, мітинги з окремими членами команди і замовниками, і тепер можна починати аналізувати свою роботу, як бізнес-аналітика. Чи багато виникло додаткових запитань? Чи багато було внесено змін до вимог? Скільки було витрачено часу на довияснення? Ці та багато інших запитань і метрик допоможуть вам побачити якщо не прогалини у вашій роботі, то як мінімум речі, яким наступного разу варто приділити більше уваги.
Давайте підіб'ємо підсумок і окремо виділимо профіт для бізнес аналітика і для команди:
Вигода | Для команди | Для бізнес-аналітика |
Відчуття впевненості | Допомагає поліпшити розуміння основних вимог і скоротити час на розробку продукту, підвищує довіру і впевненість у команді | Дає змогу оцінити, наскільки точно були зрозумілі вимоги і наскільки продукт відповідає очікуванням |
Можливість впливати на продукт на ранніх етапах | Дає змогу зробити правильні висновки і поліпшити продукт на ранніх етапах розробки | Дає змогу підвищити значущість своєї ролі в команді, продемонструвати та закріпити свої професійні навички |
Валідація прийнятих рішень | Допомагає переконатися, що прийняті рішення відповідають вимогам і не суперечать бізнес-цілям | Дозволяє перевірити, наскільки успішно було реалізовано завдання, і зробити висновки на майбутнє |
Отримання загальної картинки продукту до початку етапу розробки | Дає змогу точно визначити цілі та завдання проєкту, а також переконатися, що всі учасники команди перебувають на одній хвилі | Дає змогу глибше зрозуміти бізнес-завдання та їхнє вирішення, а також отримати чіткіше бачення проєкту |
Обговорення проблеми з експертом | Допомагає знайти найкраще розв'язання проблеми, враховуючи думку та досвід експерта | Дозволяє отримати додаткову інформацію та поглибити розуміння проблеми |
Опрацювання користувацьких сценаріїв для подальшого використання при створенні тест-кейсів | Допомагає точніше визначити вимоги користувача і розробити ефективні тест-кейси | Дає змогу на основі користувацьких сценаріїв визначити функціональність продукту і зробити висновки про його працездатність |
Налагодження стосунків усередині команди, створення довірливої атмосфери | Дає змогу поліпшити комунікацію між учасниками команди та підвищити якість взаємодії | Дає змогу створити довірчі стосунки і поліпшити процес обговорення вимог. |
Commentaires