Правильное взаимодействие бизнес-аналитика с командой проекта и заказчиком — самая важная составляющая его успешности как специалиста. Во многом от бизнес-аналитика зависит, насколько комфортно будет команде работать над проектом, и будет ли доволен заказчик в итоге.

1. Взаимодействие бизнес-аналитика с
командой проекта и Заказчиком.
Как избежать ошибок?
Гулик Людмила

2.  в ИТ с 1999 года
 прошла путь от программиста до руководителя
отдела бизнес-аналитиков
 на позиции бизнес-аналитика с 2006 года
 большой опыт успешного внедрения как небольших
доработок по изменению существующих систем, так
и больших технически сложных проектов “с нуля”
 большой опыт анализа различных бизнес-
процессов в IT-компаниях и их успешной
оптимизации
 опыт организации с нуля отделов:
 сопровождения ПО
 тестирования ПО
 разработки требований к ПО
Мой опыт

4. В чем важность бизнес-аналитика?
Аналитик - это основной коммуникативный канал между группой
клиентов и командой разработчиков.
От таланта и умений бизнес-аналитика зависит успех проекта.
Один из клиентов, которых я консультировала, пришел к выводу,
что спецификации с требованиями, созданные опытными
аналитиками, удается изучать в несколько раз быстрее, чем
созданные новичками, поскольку в первых меньше недостатков.

5. Общая схема взаимодействий на проекте

6. 1. Выявление требований
 Сбор, документирование и учет
2. Анализ требований
 Систематизация и приоритезация
3. Участие в проектировании решений
 Прототипирование, моделирование, специфицирование
4. Управление изменениями
5. Сдача-приемка проектов
Задачи аналитика

7. 1. Коммуникативность
 Умение получать и предоставлять информацию
2. Аналитические навыки
 Умение структурировать, видеть взаимосвязи и
синтезировать идеи
3. Методики и инструменты
 Знание и умение использовать подходящие методики и
инструменты
Компетенции аналитика

8. BABOK 3.0 Техники бизнес-анализа

9. Включает в себя:
1. Определение ключевых лиц проекта и лиц, принимающих
решения
2. Определение источников требований
3. Собственно выявление требований
4. Структурирование требований
Сбор требований

10.  Заинтересованные лица
проекта:
 Клиент
 Пользователи клиента
(разделение по фокус-группам)
 Разработчики и…
 Внешние организации:
 Представители смежных систем
 Гос. органы
 Программное обеспечение
 Используемое в компании ПО
 Аналогичные и
конкурирующие решения
 Регламенты и инструкции
А еще…
 Стандарты индустрии
 Исследования рынка
 Результаты анализа рисков
 Выводы из предыдущих
проектов (например,
особенности интерфейса для
интернациональных
проектов)
 Личный опыт 
Источники требований

11.  Интервью (по четко подготовленному опроснику и с учетом
целей его проведения)
 Анкетирование (как открытые вопрос ДаНет, так и закрытые)
 Форум (отлично подойдет для B2C проектов)
 Изучение документов и бизнес-процессов
 Изучение существующего ПО
 Изучение аналогичных решений
 Мозговой штурм
 Слежение (наблюдение за процессом работы)
 Прототипы
 И др…
Основные методики выявления требований
и ошибки их использования)

12.  Источников требований может быть очень много, важно
учесть все (не полагаемся на память, - все записываем!)
 Обязательно определяем потребность, из которой проистекает
это требование (иногда озвучивается решение, а не
конкретная потребность)
 Выявляем требования в несколько итераций до тех пор, пока
не достигнем нужного уровня точности для текущего этапа
Итоги этапа выявления требований

13.  Объединение всех требований в общий список
 Исключение дубликатов (например, вход в систему для разных
групп пользователей; или формулировки отличаются – суть одна)
 Систематизация и группировка требований (по группам,
категориям и т.п.)
 Разрешение конфликтующих требований (например, один хочет
отображать список чего-либо в алфавитном порядке, а другой, - по
срокам поступления)
 Исключение ненужных требований (какова бизнес-польза и будет
ли кто-то этим реально пользоваться)
 Добавление недостающих требований (например, если есть
функция авторизованного входа в систему, то как будут добавляться
пользователи и определяться права на различные функции)
 Трансформация требований (с указанием статуса: черновик, на
согласовании, утверждено заказчиком)
 Определение приоритетов (лучше, если бизнес-аналитик
предварительно определит приоритеты, а заказчик проверит и,
либо утвердит, либо внесет мелкие правки)
Анализ требований

15. Способы работы с требованиями и их
изменениями

16.  Зафиксировать новое требование (и важно, от кого именно
оно поступило)
 Проанализировать новое требование и его влияние
 Проинформировать заинтересованных лиц
 Принять решение:
 Не делать вообще
 Сделать позже
 Сделать сейчас (в текущей итерации)
Реакция на изменение требований

17.  Не так важно, как ты сделаешь проект. Важно, как ты его
сдашь!
 Договариваемся об условиях заранее (как и о процессе
изменений требований в будущем)
Организация сдачи-приемки

18. Вопросы