Роль і залученість бізнес-аналітика у проєктні активності розгортається на семи різних фазах, у яких може перебувати типовий проєкт.
У цій статті я розкажу вам про ключові зони відповідальності та участь бізнес-аналітика на кожному етапі розробки програмного забезпечення.
Ініціація проєкту
Початкова фаза включає в себе формування ідеї проєкту, оцінку можливості його реалізації, а також отримання фінансових узгодженостей.
На цьому етапі бізнес-аналітик опрацьовує та визначає проєктні можливості, а також розгорнуто документує бізнес-кейси. Без бізнес-аналітика критично важливі елементи ініціації проєкту можуть бути упущені, а сам проєкт може не отримати необхідної фінансової підтримки вже на старті.
На етапі ініціації наш фокус зосереджується на виявленні та формуванні задуму проєкту, аналізі здійсненності запропонованого обсягу і презентації чітко описаних бізнес-кейсів, які би покривалися готовим рішенням, вищому менеджменту.
Планування та виявлення вимог
Як тільки ми отримуємо «зелене світло» на заявлений проєкт, ми переходимо до детального планування. На цьому етапі бізнес-аналітик відіграє ключову роль, адже приступає до роботи над вимогами.
До теми: Для чого потрібен бізнес-аналіз і хто такі бізнес-аналітики?
Ми допомогаємо у налаштуванні базових процесів для управління змінами та ризиками, забезпечуючи таким чином оптимальний хід та розвиток проєкту.
Окрім цього, під час виявлення бізнес-потреб, бізнес-аналітики беруть активну участь у зборі та аналізі вимог. Результатом цієї роботи буде створення Документу бізнес-вимог (BRD).
Без бізнес-аналітика проєкт ризикує лишитися чіткої роадмапи та повних і структурованих вимог до розробки системи.
Дизайн
Бізнес-аналітик передає готовий BRD архітектору (солюшн архітектору, технічному архітектору), який, у свою чергу, документує високо- та низькорівневі деталі технічного дизайну запланованого рішення. Ця документація в подальшому служитиме свого роду навігатором для команди під час активної розробки.
Без бізнес-аналітика зростає ризик неузгодженості між технічним дизайном та бізнес-вимогами, що надалі може привести до потреби в доопрацюванні чи перероблянні логіки системи і, як результат, затримок у реалізації проєкту.
Розробники надалі використовуватимуть цю технічну дизайн-документацію для реалізації програмного забезпечення.
Відповідальність нас як бізнес-аналітиків на цьому етапі полягає в забезпеченні узгодження між запропонованим дизайном та виявленими вимогами.
Розробка
На етапі розробки ключову роль займають програмісти, адже саме вони трансформують специфікацію у функціонуючий продукт. За відсутності бізнес-аналітика в команді, у розробників можуть виникнути складнощі з розумінням та чіткою імплементацією заявлених вимог.
Тестування та прийомка
Етап тестування дуже багатогранний, бо полягає у виконанні тестів різного рівня та типу – юніт-тестування, тестування інтеграції, системне тестування, прийомка користувачами тощо.
Важливим, зокрема, є юніт-тестування: під час нього кожна окрема частина функціоналу підлягає ретельній перевірці. Після цього проводиться тестування інтеграції та системне тестування, упродовж яких перевіряється взаємодія цих різних частин функціоналу між собою. Така перервіка гарантує, що система працює цілісно. Якщо у цей процес не залучено бізнес-аналітика, підвищується ризик пропуску функціональних аспектів, що, як результат, може привести до некоректної роботи системи.
Завжди буде корисно: User Story та Acceptance Criteria: пишемо чіткі та зрозумілі вимоги
Після проведення ретельного тестування та забезпечення безперебійної роботи функціоналу, готова система переходить на етап користувацького тестування або тестування прийомки. Під час цієї активності спеціально виділена група кінцевих користувачів ретельно аналізує, наскільки розроблена система відповідає їхнім потребам та заявленим вимогам.
У ході детального тестування системи на стороні клієнта в рамках прийомки можуть бути виявлені деякі неточності в роботі функціоналу, які могли бути помічені раніше, якби на етапі тестування було залучено бізнес-аналітика з його чітким розумінням початкових вимог. Отже, наша роль на цьому етапі передбачає перегляд підготовлених тест-кейсів і активну участь у приймальному тестуванні користувачами.
Імплементація (розгортання на користувацькому середовищі)
Успішно пройшовши фазу тестування та отримавши затвердження від замовника системи, проєкт переходить на наступний етап, на якому з ним взаємодіятиме відділ інформаційно-технологічного обслуговування систем. Ці фахівці проводять розгортання заімплементованого функціоналу на кінцеве користувацьке середовище, гарантуючи при цьому безперебійний процес перенесення готової розробки.
Бізнес-аналітики на цьому етапі можуть бути залучені у процес комунікації вимог, що стосуються користувацьких доступів, а також можуть брати активну участь в управлінні процесом виведення системи на середовище кінцевого користувача.
Підтримка
Після того, як функціонал було випущено на середовище, доступне кінцевим користувачам, команда розробників (технічна підтримка) продовжує моніторити та підтримувати систему у робочому стані. Цей процес включає в себе випуск оновлень, виправлення критичних помилок тощо.
Зверніть увагу: Запис вебінару “Кращі практики взаємодії бізнес аналітика і UI-UX дизайнера”
Навички спілкування та управління, якими володіє бізнес-аналітик, лишаються ключовими на цій фазі. Ми робимо внесок у планування, виявлення додаткових вимог, беремо участь у активностях із тестування, а також ведемо багато комунікації з різними зацікавленими сторонами.
Від пошуку можливостей до виявлення вимог, а також забезпечення відповідності технічного виконання заявленим бізнес-потребам – роль бізнес-аналітика є невід’ємною складовою успіху проєкту із розробки програмного забезпечення.
Проєкти, що не мають бізнес-аналітиків, частіше стикаються з розростанням обсягу вимог, неузгодженістю, тестуванням невалідних сценаріїв, що зрештою ставить під загрозу загальний успіх ініціативи.
Керуючи складними ініціативами з розробки програмного забезпечення, організаціям украй важливо визнати незамінність ролі бізнес-аналітика для досягнення бажаних результатів та загального успіху проєкту.
Оригінальна стаття – Business Analyst Perspective in Software Development Lifecycle, переклад – Христина Новікова, ревью – Іван Вільчавський. Зображення з оригінальної статті.