Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

Roadmap бізнес аналітика

478 Aufrufe

Veröffentlicht am

Чи замислювались ви колись, як почати проект так, щоб з самого початку закласти основи правильного бізнес аналізу, щоб не втрачати кроків, не закладати проблем сповільненої дії та мати впевненість в правильному векторі розвитку продукту або ідеї?

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

Також цей вебінар є вступним до курсу підготовки бізнес аналітика Business Analysis Big Bang 3.0 і ми розповімо трохи деталей і ви матимете шанс поставити питання по змісту курсу.

На вебінарі ви знайдете відповіді на важливі для бізнес аналітика питання:

З чого варто починати аналіз на проекті?
Як підготувати ґрунт для успішного проведення аналізу?
Які ключові етапи аналізу слід пройти залежно від методології, гнучкої (Agile), або планованої (Waterfall)?
Чим має забезпечити хороший бізнес аналітик команду задля успішного результату проекту?

Ви побачите повну картину активностей аналітика і аналізу необхідного на проекті і будете більш готовими до проектних викликів.

Veröffentlicht in: Bildung
  • Als Erste(r) kommentieren

Roadmap бізнес аналітика

  1. 1. Roadmap Бізнес Аналітика Ірина Крючкова та Роман Сахаров @E5
  2. 2. Про нас Ірина Крючкова Trainer @ E5 Business Analyst & Proxy Product Owner and BA Competency Manager @ Softserve CSPO, CBAP Роман Сахаров Co-founder & trainer @ E5 Business Analysis Manager & Delivery manager @ EPAM Systems, CSM & Trainer
  3. 3. чого ви починаєте проект?
  4. 4. Крок 1: Ваша (BA) роль
  5. 5. Типи методологій
  6. 6. Класичний проект 1. Project Coordinator/Manager 2. Configuration Manager, DevOps 3. Development Team Lead/Developer 4. Test/QA engineer 5. Technical Writer 6. Business Analyst
  7. 7. Agile => Scrum • Власник Продукту (Product Owner) • Scrum Master • Команда розробки (Development Team)
  8. 8. Крок 2: Аналіз зацікавлених осіб
  9. 9. Зацікавлені особи Особа або група, що має відношення до зміни, потреби або рішення Визначаються з точки зору: 1. зацікавленості в, 2. впливу на 3. чи залежності від зміни.
  10. 10. Зацікавлені особи 1. Кінцевий користувач 2. Експерт предметної області 3. Спонсор 4. Замовник (Замовника) 5. Постачальник 6. Регулятор 7. Експерт по реалізації 8. Бізнес аналітик 9. Менеджер проекту 10. Тестувальник 11. Підтримка
  11. 11. Техніки для аналізу зацікавлених осіб 1. Список зацікавлених осіб 2. Карта зацікавлених осіб • Матриця (вплив/зацікавленість) • Цибулева діаграма 3. RACI матриця 4. Персони
  12. 12. Крок 3: Solution definition
  13. 13. Визначити Рішення Аналіз поточного стану Визначення майбутнього стану Оцінка ризиків Визначення стратегії змін
  14. 14. Цінність як основна мета
  15. 15. Головне питання аналітика
  16. 16. Крок 4: Виявлення вимог
  17. 17. Етапи виявлення (все просто ) Prepare Conduct Follow- up
  18. 18. Домашня робота 1. Бізнес клієнта • Прочитайте про бізнес домен клієнта • Відкрийте сайт його компанії • Зрозумійте ключових конкурентів 2. Особистість клієнта • Вивчіть профайли в соц. мережах та лінкедині • Розпитайте людей які можуть його знати • Дізнайтесь хто приймає рішення
  19. 19. Техніки для виявлення вимог 1. Інтерв'ю 2. Мозковий штурм + 1. Benchmarking and Market Analysis, 2. Business Rules Analysis, 3. Collaborative Games, 4. Concept Modelling, 5. Data Mining, 6. Data Modelling, 7. Document Analysis, 8. Focus Groups, 9. Interface Analysis, 10. Mind Mapping, 11. Observation, 12. Process Analysis, 13. Process Modelling, 14. Prototyping, 15. Survey or Questionnaire, 16. Workshops
  20. 20. Після зустрічі, підтримка контакту • Напишіть meeting minutes • Домовтеся про подальші зустрічі і способи комунікації • Сформуйте план комунікацій
  21. 21. Крок 5: Організація вимог
  22. 22. Рівні абстракції/Requirement levels Бізнес вимоги Вимоги зацікавлених осіб Вимоги до рішення Реалізація Реалізація Бізнес вимоги Користувацькі вимоги Функціональні вимоги Рівеньдеталізації
  23. 23. Декомпозиція Декомпозиція – розбивка на менші задачі (нічого складного ) На чому засновуватись? -Функціональні модулі -Сценарії -Конструктивно
  24. 24. Крок 6: User Story mapping
  25. 25. Story Mapping: що? Цінна техніка для колективного створення функціональної декомпозиції продукту
  26. 26. Story mapping
  27. 27. Крок 7: Високорівневі вимоги
  28. 28. Які документи створює аналітик 1. Концепція 2. Бачення та скоуп 3. Документ бізнес вимог 4. Технічне завдання 5. Тендерна документація 6. Специфікації вимог до програмного забезпечення …
  29. 29. Для чого створюються документи? 1. Узгодження вимог 2. Управління скоупом 3. Передача знань 4. Зменшення невизначеності 5. Гарантування якості 6. … 7. Бо вимагає регулятор 8. Потрібно щось покласти в сейф 9. Виправдання вартості 10. Підстраховка 11. …
  30. 30. Крок 8: Пріоритезація
  31. 31. Prioritization - MVP
  32. 32. Чому важливо пріоритизувати?
  33. 33. Фактори, що впливають на пріоритет 1. Вигода 2. Зобов'язання 3. Вартість 4. Ризик 5. Залежності 6. Чутливість до часу 7. Стабільність 8. Відповідність політикам
  34. 34. Підходи
  35. 35. Крок 9: Створення Backlog
  36. 36. Product backlog … — це документ, який має список вимог до функціональності, які упорядковані згідно зі ступенем важливості. • Product backlog представляє список того, що повинно бути реалізовано. • Елементи цього списку називаються елементами backlog-у (product backlog items - PBI).
  37. 37. З чого складається Backlog?
  38. 38. Closest Iteration Final Iteration TASKS STORY STORY/EPIC EPIC THEME (Iteration in play) Detailed Appropriately: Just In Time
  39. 39. Detailed Appropriately: Product backlog
  40. 40. Крок 10: Створення Use Cases
  41. 41. Use Case - Визначення Опис послідовності дій (включаючи альтернативні та помилкові послідовності), які система може реалізовувати у взаємодії із зовнішніми акторами Поведінка, яку демонструє система з метою отримання значимого результату для одного чи більше акторів
  42. 42. ADM_UC.01 Створити обліковий запис Опис Створення облікового запису користувача Адміністратором Актор Адміністратор Передумови • Користувач залогінився в Систему • У Користувача достатньо прав Основний потік 1. Адміністратор викликає функцію 2. Система пропонує ввести інформацію про обліковий запис 3. Адміністратор зазначає необхідні дані 4. Система перевіряє коректність заповнення інформації 5. Система створює обліковий запис 6. Система повідомляє користувача (для якого створювався запис) про створення його облікового запису 7. Система повідомляє Адміністратора про успішність виконання операції Альтернативні потоки 3а Адміністратор відмовляється від виконання операції 3а.1 Система відображає попередження 3а.2 IF Адміністратор погоджується – Система припиняє виконання сценарію, ELSE – Система повертається до кроку 3 4а Введена інформація некоректна 4а.1 Система повідомляє Адміністратора про наявні помилки та повертається до кроку 3 Постумови Обліковий запис створено, користувач (для якого створювався запис) повідомлений
  43. 43. Крок 11: User Story
  44. 44. As a [user role] I want [activity] so I can [benefit] As a [user role] I can [activity] so that [benefit] User role – хто (новий користувач, гість, безробітний)? Activity – функціональність, дія системи, що? Benefit – цінність для кінцевого користувача, навіщо? Картка
  45. 45. Acceptance criteria - Критерії прийомки • набір тверджень (pass/fail) • визначають параметри користувацької історії • специфікують функціональні вимоги • закривають не функціональні • Вказують коли історія закінчена і працює, як очікувалося • додають визначеність, що команда будує
  46. 46. Крок 12: Прототипування
  47. 47. Прототипування Етап розробки програмного забезпечення на якому створюється прототип програми – макет, для того щоб 1. перевірити придатність запропонованих концепцій, 2. виявити прогалини у вимогах і 3. отримати зворотній зв’язок від користувачів.
  48. 48. Основні підходи 1. Throw-away • Паперові або на дошці • У певному програмному забезпечення • Інтерактивні або ні 2. Ті, що будуть розвиті у рішення (або функціональні) • Як етап розробки рішення
  49. 49. Крок 13: Моделювання
  50. 50. Мета моделювання Візуалізація структури або поведінки бізнес домену або інформаційної системи для подальшого аналізу, узгодження або удосконалення Модель – спрощене відображення реальності, часто розглянутої з обмеженої кількості різних кутів зору
  51. 51. Принципи моделювання • Вибір моделі справляє вирішальний вплив на рішення1 • Кожна модель може мати різні ступені абстракції2 • Найкращі моделі ті, що ближче до реальності3 • Не потрібно обмежуватися однією моделлю4
  52. 52. Що можна моделювати 1. Concept Modelling 2. Data Modelling 3. Decision Modelling 4. Mind Mapping 5. Organizational Modelling 6. Process Modelling 7. Scope Modelling 8. …
  53. 53. Типи діаграм Діаграми структури Моделі даних Діаграми компонент Контекстні діаграми Структурні … Діаграми поведінки Процесні Потоків даних Блок-схеми Діаграми станів …
  54. 54. Крок 14: Software Requirements Specification
  55. 55. Software Requirements Specification 1. Повний опис поведінки системи 2. Включає: • Функціональні вимоги • Нефункціональні вимоги • Інше
  56. 56. Характеристики SRS 1. Коректність 2. Повнота 3. Однозначність 4. Відслідковуваність 5. Тестованість 6. Відповідність 7. Визначені пріоритети 8. Можливість ідентифікації
  57. 57. Зміст SRS 1. Вступ • Мета документу • Умовні позначення • Цільова аудиторія • Скоуп продукту/проекту • Посилання 2. Загальний опис • Перспективи продукту • Загальний опис функціональності • Опис користувачів • Припущення, обмеження, залежності 3. Функціональні вимоги 4. Інші вимоги • Нефункціональні вимоги 5. Додатки
  58. 58. Функціональні вимоги 1. Варіанти використання 2. Прототипи користувацького інтерфейсу 3. Опис класів та об'єктів 4. Стани та переходи 5. Діаграми діяльності 6. Формули, правила та інші функціональні вимоги
  59. 59. Крок 15: Підтримка розробки
  60. 60. Комунікаційний хаб Communicates Communicates Facilitates Team Business Analyst Customer/Clients
  61. 61. Рівні планування
  62. 62. Активності для підтримки 1. Проводити тренінги по домену 2. Організовувати обмін знаннями на тему функціоналу, або процесу 3. Відповідати на питання команди, або переправляти їх до замовника 4. Пріоритезувати дефекти з замовником, або як проксі 5. Прийняття (acceptance) задач
  63. 63. Grooming – що? 1. Створення і деталізація PBI 2. Оцінка PBI 3. Пріорітизування PBI
  64. 64. Оцінка задач Estimation approach Category Examples of support of implementation of estimation approach Analogy-based estimation Formal estimation model ANGEL, Weighted Micro Function Points WBS-based (bottom up) estimation Expert estimation Project management software, company specific activity templates Parametric models Formal estimation model COCOMO, SLIM, SEER-SEM, TruePlanning for Software Size-based estimation models Formal estimation model Function Point Analysis,[14] Use Case Analysis, SSU (Software Size Unit), Story points-based estimation in Agile software development Group estimation Expert estimation Planning poker, Wideband Delphi Mechanical combination Combination-based estimation Average of an analogy-based and a Work breakdown structure-based effort estimate Judgmental combination Combination-based estimation Expert judgment based on estimates from a parametric model and group estimation
  65. 65. Робота в спринтах
  66. 66. Самостійне навчання 1. Вигерс Карл «Разработка требований к программному обеспечению» 2. Business Analysis Body of Knowledge (BABOK), v.3 3. Dean Leffingwell, Don Widrig «Managing Software Requirements: A Unified Approach» 4. Alistair Cockburn "Writing Effective Use Cases” 5. Dean Leffingwell “Agile Software Requirements"
  67. 67. Business Analysis Big Bang 3.0 1. Теорія онлайн 2. Практика офлайн (Київ) • Перевірені техніки бізнес аналізу, • Необхідна теорія • Практична робота на реальних прикладах • Можливість пройти всі етапи роботи аналітика • Домашні завдання та спільне обговорення результатів • Тестування знань щотижня
  68. 68. Принципи роботи Робота в міні-командах над власним продуктом від ідеї до детальних специфікацій. Починаючи 17 жовтня, протягом 2 місяців. Заняття 1: Блок теорії – основні аспекти задачі, перелік технік Домашнє завдання: детальне вивчення однієї з технік (відпрацювання на практиці, для тих, хто онлайн) Заняття 2: Відпрацювання техніки на практиці Домашнє завдання: завершити почате Контроль знань: Тестування з подальшим розбором результатів
  69. 69. Розклад Дата Місце Назва Деталі Вартість 05.10.2017 19:00 – 21:00 Онлайн Вебінар: Roadmap бізнес аналітика http://e- 5.com.ua/ru/calendar/event/351- vebinar-roadmap-biznes-analitika Безкоштовно З 17.10.2017 протягом 2 місяців Онлайн теорія Курс Business Analysis Big Bang 3.0 http://e- 5.com.ua/ru/?option=com_rseventspr o&layout=show&id=431:kurs- business-analysis-big-bang-3-0 15% (25% при повній оплаті) знижки по коду E5BABB Київ практика
  70. 70. Питання?
  71. 71. info@e-5.com.ua E5Trainings E5Trainings E5 www.e-5.com.ua

×