Історія одного аудиту: покращуємо процеси бізнес-аналізу

14 липня
Денис Гобов, Senior Business Analyst і співкерівник BA community, DataArt
Історія одного аудиту: покращуємо процеси бізнес-аналізу
Словосполучення “аудит проекту” для когось звучить загрозливо, для когось від цих слів віє формалізмом і бюрократією. Ніхто особливо не любить, коли перевіряють його роботу, особливо якщо перевіряючий — людина зі сторони. Найчастіше ми чули слово аудит у контексті перевірки фінансової чи бухгалтерської звітності, а в останні кілька років багато хто зіткнувся з аудитом IT-безпеки. Але я хотів розповісти про аудит процесів бізнес-аналізу для одного проекту нашої компанії. Можливо, цей сервіс стане у пригоді й вашому проекту.

Близько десяти років тому я вперше виступав у ролі аудитора проекту в частині бізнес-аналізу. Спочатку ми створили документ, який регламентує роботу бізнес-аналітика — процедуру розробки та управління вимогами. А аудит здебільшого полягав у перевірці її дотримання у конкретному проекті. Але в рамках аудиту я міг дати рекомендації, безпосередньо не передбачені формальними документами, а побудовані, швидше, на здоровому глузді та моєму практичному досвіді. Таким чином, я об'єднував аудит і консалтинг. За результатами складався план, виконання якого перевірялось під час наступного аудиту.

Відмінна особливість DataArt — культура компанії вітає різноманітність, немає необхідності суворо дотримуватись формальних правил і процедур, зокрема в бізнес-аналізі. Простіше кажучи, ми вітаємо гнучкість і намагаємось уникати формалізму. Замість цього професійні спільноти розробляють рекомендації та шаблони, які проекти можуть використовувати як є, адаптувати або придумати свої. Тому в нас аудит найчастіше передбачає консультаційну допомогу з боку експерта та ініціюється PM або DM. Оскільки заздалегідь спланованих аудитів (крім аудиту інформаційної безпеки) ми не маємо, експерта для аудиту залучають, коли у проекті спостерігаються стійкі проблеми. Їх перелік досить стандартний:

  • Затримки з підготовкою вимог до початку спринту.
  • Постійні зміни вимог та/або їхніх пріоритетів.
  • Команда та/або клієнт незадоволені якістю вимог.

Приводом для аудиту можуть бути не лише сумні моменти, а й позитивні зміни, наприклад, команда збільшилась, а старі підходи/процеси не масштабуються.

КЕЙС ІЗ БА-АУДИТОМ

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

Аудит почався з того, що мене запросили на щоденний стендап, де познайомили з усіма членами команди. З тієї зустрічі мені найбільше запам'яталася фраза менеджера проекту: “Знайомтесь, це Денис — наш експерт, бізнес-аналітик, але він з нами ненадовго”. Забігаючи вперед, скажу, що це пророцтво не збулось, після аудиту я успішно влився у команду та працюю в ній вже понад два роки. Після швидкого знайомства з командою я провів серію інтерв'ю з ключовими членами команди: PM, тімлідом, QA-лідом і бізнес-аналітиками. Паралельно почав вивчати проектні артефакти: вимоги, діаграми, плани релізів, описи поточного процесу. Після отримання загальної картини я перейшов до детального аналізу поточних процесів:

  • Як планується та відстежується робота бізнес-аналітиків.
  • Як проводиться виявлення вимог.
  • У якому форматі вимоги готуються для розробки та тестувальників.
  • Як ведеться база знань проекту.
  • Які інструменти та підходи використовуються.

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

ПРОЦЕС

В результаті я виявив і глобальні проблеми (відсутність бачення проекту, сформульованих проблем, на розв’язання яких спрямовано проект, дорожньої карти тощо), викликані тим, що проект переріс межі Proof of Concept і став стратегічною ініціативою, і ряд локальних. Наприклад, для моделювання бізнес-процесів, яке проводилось перед написанням детальних вимог, використовувалась нотація BPMN, але не зовсім коректно. Комусь це може здатися дрібницею, але уявіть, що ви взяли слова (аналоги графічних елементів нотації) та стали розташовувати їх у довільному порядку в реченні, ще й забуваючи про розділові знаки. У чому це виражалось у нашому випадку:

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

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

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

ПРОПОЗИЦІЇ

За результатами аудиту було сформовано звіт, який включав:

  • Опис поточного стану проекту з точки зору бізнес-аналізу пов'язаних з ним активностей команди.
  • Перелік виявлених ризиків і проблем, рекомендації щодо їх вирішення або пом'якшення.
  • Пропозиції щодо зміни процесів роботи з вимогами.
  • Точкові рекомендації щодо інструментів і шаблонів.

Стосовно пропозицій щодо поліпшення, якісь гарантували “quick wins”, деякі, наприклад, створення довгострокового плану розвитку платформи, вимагали значних зусиль і впроваджувались рік.

Вже у процесі аудиту стало зрозуміло, що деякі ризики та проблеми, в основі яких лежав людський фактор, ми розв’язати не зможемо. Але можемо їх урахувати та постаратися пом'якшити наслідки.

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

images images images

ПІДСУМКИ

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

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

За новими публікаціями Дениса Гобова можна стежити на сайті та сторінці DataArt у Facebook, а також на його особистих сторінках у Facebook і LinkedIn.