ThinkStage18

1. Мастер-класс
Выявление ключевых требований при первом
контакте с заказчиком. Как не упустить важное
Алина Петренко, Infopulse, Украина

2. О мастере ☺
Алина Петренко
• Senior Business Analyst в
компании Infopulse
• CBAP, PSPO I
• 10 лет опыта в роли
функциональногои бизнес-
аналитика
• Web, десктопные, мобильные
приложения
• ERP-системы, BI-репортинг

3. Структура мастер-класса
• Вступление
1. Подготовка к знакомству с заказчиком
2. Выявление цели
3. Ключевые сущности и понятия
4. Тип проекта, концепция архитектуры
5. Рамки проекта, интеграция

4. Структура мастер-класса
6. Активы организационного процесса
7. Структура организации
8. Стейкхолдеры, пользователи
9. Анализ, управление требованиями,
коммуникации
10. Ключевые функциональные требования
11. Ключевые нефункциональные требования

5. Структура мастер-класса
12. Критерии приёмки проекта
13. Софт-скилы и компетенции аналитика
14. Результирующие документы

6. Вступление

7. 1. Подготовка к знакомству
• Сбор информации о заказчике (сайт компании)
• Изучение предметной области (википедия)
• Бенч-маркинг (google)
• Анализ документации (предоставленной
заказчиком плюс другие проекты)
• Опыт!

8. 2. Выявление цели
Цель – это достижимый, проверяемый (измеряемый)
результат проекта.
Цель — максимально сжатая, емкая и полная
формулировка конечного результата проекта, например:
1. Повышение доли присутствия на рынке на … %, на
основе…
2. Повышение оперативности (или качества) оказания
услуг, путем…
3. Повышение рентабельности (прибыльности,
капитализации) предприятия на …%, за счет…

9. 2. Выявление цели
SMART цель:
• Specific – описывает конкретный видимый результат;
• Measurable – результат можно отследить и измерить;
• Achievable – цель достижима в пределах имеющихся
ресурсов, знаний, опыта, рабочей нагрузки и т.д.;
• Relevant – соответствует ключевым принципам, миссии
и глобальным целям организации;
• Time-bounded – имеет чёткие временные границы.

10. 2. Выявление цели
• «5 почему»
• Зачем? Что? Как?
• Идентификация проблемы
• SMART подход
• Предыдущие попытки решения
• Коробочные решения

11. 3. Ключевые сущности и понятия
• Глоссарий
• Аббревиатуры
• Сущность-связь
• Пока не опускаемся до атрибутов
Клиент Заказ Товар
1 * * *

12. 4. Тип проекта, архитектура
Основные типы ИТ-
проектов
Разработкаи развитие
ПО
Внедрение
информационных систем
(ERP, CRM, …)
Инфраструктурные и
организационные
проекты (реплатформинг,
реинжиниринг, …)

13. 4. Тип проекта, архитектура
ПО
Прикладное
Web-
приложения
Desktop-
приложения
Мобильные
приложения
Системное
Утилиты
Драйверы

14. 4. Тип проекта, архитектура
• На каких устройствах должно работать?
• Доступность в рамках конкретного устройства,
локальной сети предприятия или глобальной
сети Интернет?
• Если web-приложение, то нужна ли мобильная
версия? И наоборот.
• Используем существующуюСУБД? Если да,
какую?

15. 5. Рамки проекта, интеграция
Интеграция
На уровне
брокеров
На уровне
данных
На уровне
сервисов
На уровне
пользователя

16. 5. Рамки проекта, интеграция
• Откуда система берет данные, куда отдаёт?
• С какими существующими (а также будущими, в
стадии проектирования) системами
взаимодействует?
• Какая система владеет первичными данными
по каждой из сущностей?
• Что остаётся вне рамок решения?
• Какие логические модули можно выделить?

17. 6. Активы организационного
процесса
Активы организационного процесса (Organizational
Process Assets):
• планы
• процессы
• политики
• процедуры
• базы знаний, принятые и используемые
в конкретной организации (включая
полученные уроки и историческую информацию).

18. 6. Активы организационного
процесса
• Какиеподходы/методологии ведения проектов и разработки ПО
используются в организации?
• Какиеинструменты и техники понятны и привычны для
заинтересованных лиц?
• Какиекорпоративные стандарты нужно учесть?
• Есть ли принятые шаблоны проектных документов, продуктов
поставки?
• Каковы процедурыинициациии сдачи проекта?
• Насколькожёстконеобходимо следовать упомянутым процедурам и
шаблонам?
• Какой опыт других проектов с данной организацией (если такие
были)?

19. 7. Структура организации
• Какие подразделения организации будут работать с
системой?
• Какие ключевые функции выполняют эти
подразделения?
• Какие из этих функций будут целиком либо
частично выполняться в проектируемой системе?
• Есть ли функции, подлежащие полной
автоматизации в рамках проектируемой системы?
• Приведёт ли автоматизация к сокращению
количества сотрудников данных подразделений?

20. 8. Стейкхолдеры, пользователи
Стейкхолдер по BABOK:
• Группа или лицо,
имеющее интересы,
которые влияют на
инициативу (систему),
либо подвержены ее
влиянию.
• Включает всех участников
проектной команды,
спонсора, клиента, SME,
пользователей и др.
Стейкхолдер по Scrum
Glossary:
• Лицо вне скрам-команды,
имеющее интересы и
знания о создаваемом
продукте.
• Не включает скрам-
команду, спонсора
(владельца продукта) и
пользователей.

21. 8. Стейкхолдеры, пользователи
Выявить лиц, которые:
• Заинтересованы в достижениицели проекта
или
• Их интересы могут быть затронуты
(положительнолибо отрицательно) в ходе
проекта.
Определить власть и влияние
заинтересованных лиц на результаты
проекта.

22. 8. Стейкхолдеры, пользователи
• Кто заинтересован в проекте?
• Кто разделяет интересы?
• Каковы их роли и ответственность?
• Кто как влияет на результаты проекта?
• На кого как повлияет проект?
• Кто уполномочен принимать решения?
• Каковы потребности, ожиданияи желания
стейкхолдеров?

23. 8. Стейкхолдеры, пользователи
Отношение
к:
Целям, задачам проекта и решению в целом
Бизнес-анализу (готовность предоставлять и обсуждать требования)
Сотрудничеству
Спонсору
Членам команды
Влияние
на:
Проект
Организацию
Других заинтересованных лиц
Достаточно ли влияния для успеха проекта?

24. 8. Стейкхолдеры, пользователи
RACI матрица:
• Responsible – исполнитель (делает
работу)
• Accountable – ответственный
(принимает решения, всегда один)
• Consulted – консультант
(согласовывает, уточняет)
• Informed – наблюдатель (должен
быть проинформирован)

25. 8. Стейкхолдеры, пользователи
Матрица участников: Луковая диаграмма:

26. 8. Стейкхолдеры, пользователи
Пользователи:
• Кто будет пользоваться системой?
• Какие у них цели, проблемы, потребности и
ожидания?
• Сегментация – деление на группы
• Персонификация – составление
детализированныхтиповых профилей
• Customer Journey Mapping, Value Proposition
Canvas, Empathy Map Canvas и другие техники

27. 8. Стейкхолдеры, пользователи
Value
Proposition
Canvas

28. 8. Стейкхолдеры, пользователи
Empathy
Map
Canvas

29. 9. Анализ, управление
требованиями, коммуникации
Определение подхода к выполнению бизнес-анализа (waterfall,
agile, комбинации подходов). Зависит от:
• Подхода к выполнению проекта (обычно совпадает);
• Стандартов организации;
• Ограничений (бюджета, времени выхода на рынок и проч.);
• Сложности проекта, необходимого уровня формализации и
детализации требований;
• Уровня неопределённости.
Определение результатов проведения бизнес-анализа:
• БА документы и сроки их подготовки.

30. 9. Анализ, управление
требованиями, коммуникации
Управление требованиями:
• Инструменты управления
требованиями
• Виды и шаблоны
документов требований
• Процедура согласования
и утверждения
• Процедура управления
изменениями
Коммуникации:
• С кем аналитик будет
коммуницировать?
• Как часто?
• Регулярно/ситуативно?
• Местонахождение
стейкхолдеров?
• Предпочтительные
каналы коммуникаций?

31. 10. Ключевые функциональные
требования
Что система должна делать?
• Какие главные задачи решает система?
• Какие ключевые бизнес-процессы в ней
проходят?
• Какие основные результаты работы?

32. 11. Ключевые нефункциональные
требования
Какой система должна быть (каким критериям
соответствовать)?
• Производительность
• Надёжность
• Быстродействие, время отклика
• Безопасность
• Совместимость, миграция
• Устройства, операционные системы, браузеры

33. 12. Критерии приёмки проекта
• Как будет проходить процесс приёмки
проекта?
• Какие критерии успешности?
• Кто будет принимать решение?
• Какие действия или санкции будут
предприняты в случае неуспеха?

34. 13. Софт-скилы и компетенции
Аналитическое
мышление и
решение задач
Поведенческие
характеристики
Бизнес-знания
Навыки
общения
Навыки
взаимодействия
Знания
программных
продуктов

35. 14. Результирующие документы
• Видение/Концепция (содержит цель, границы проекта,
базовые сведения об архитектуре, интеграции,
ключевые требования)
• Глоссарий (словарь системы)
• ERD (диаграмма «сущность-связь»)
• Process Flow Diagram (диаграмма
бизнес-процессов)
• Data Flow Diagram (диаграмма
потоков данных, включает
внешние системы)

36. 14. Результирующие документы
• Site map (карта сайта)
• Структура системы (логические модули и их
взаимодействие)
• Список заинтересованных лиц, их роли,
полномочия и ответственность
• Типовые профили пользователей (обязательно
для продуктовой разработки)
• Proposal, Statementof Work