5 alina petrenko - key requirements elicitation during the first contact with your customer. avoiding gaps
- 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 и другие техники
- 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