Сергей Корбан БИЗНЕС-АНАЛИЗ В СХЕМАХ ПОШАГОВОЕ РУКОВОДСТВО К ДЕЙСТВИЮ 2021 Сергей Корбан Бизнес-анализ в схемах: пошаговое руководство к действию Перевели с английского С. Щербаченко, А. Меркулова Руководитель дивизиона Ю. Сергиенко Руководитель проекта И. Сальникова Ведущий редактор А. Юринова Литературный редактор А. Руденко Корректоры М. Одинокова, Г. Шкатова Обложка Р. Яцко Верстка Е. Неволайнен ББК УДК 65.290-21 658.1 Корбан Сергей К66 Бизнес-анализ в схемах: пошаговое руководство к действию. — СПб.: Питер, 2021. — 352 с.: ил. ISBN 978-5-4461-1498-6 Идеей цифровой трансформации охвачен весь мир. Именно данный тренд обусловливает высокую потребность в специалистах по бизнес-анализу. С одной стороны, такой специалист должен разбираться в бизнес-процессах, а с другой – быть «своим человеком» у разработчиков информационных систем, чтобы они смогли создать адекватный программный код. Вы можете иметь опыт в инженерии, разработке ПО, в области управления проектами. Вы можете быть IT-специалистом или бизнес-консультантом. Сергей Корбан, практикующий специалист и наставник в области бизнес-анализа, делится своими знаниями и умениями, которые помогут вам стать главным специалистом на любом проекте по информационным системам. А учитывая, что в настоящее время все проекты связаны с информационными технологиями, поле деятельности для специалистов, владеющих навыками бизнес-анализа, со временем будет только расширяться. Из книги вы узнаете о структуре IT-проектов, способах взаимодействия между структурными подразделениями, а также о том, как наладить отношения с партнерами и заказчиками в рамках цифровой трансформации современного бизнеса. Издание адресовано менеджерам в области IT и управления проектами, а также студентам и специалистам, желающим начать карьеру бизнес-аналитика. 16+ (В соответствии с Федеральным законом от 29 декабря 2010 г. № 436-ФЗ.) ISBN 978-5-4461-1498-6 © Издание на английском языке, Aotea Studios Ltd, Сергей Корбан, 2016 © ООО «Парадокс», перевод с английского языка, Щербаченко Светлана, Меркулова Алена, 2020 © Издание на русском языке, оформление ООО «Прогресс книга», 2021 Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав. Изготовлено в России. Изготовитель: ООО «Прогресс книга». Место нахождения и фактический адрес: 194044, Россия, г. Санкт-Петербург, Б. Сампсониевский пр., д. 29А, пом. 52. Тел.: +78127037373. Дата изготовления: 07.2021. Наименование: книжная продукция. Срок годности: не ограничен. Налоговая льгота — общероссийский классификатор продукции ОК 034-2014, 58.11.12 — Книги печатные профессиональные, технические и научные. Импортер в Беларусь: ООО «ПИТЕР М», 220020, РБ, г. Минск, ул. Тимирязева, д. 121/3, к. 214, тел./факс: 208 80 01. Подписано в печать 06.07.21. Формат 70х100/16. Бумага офсетная. Усл. п. л. 28,380. Тираж 1140. Заказ Содержание Подходит ли вам эта книга?...................................................................................................... 9 Об авторе.................................................................................................................................................. 10 ЧАСТЬ I. БИЗНЕС-АНАЛИЗ Введение....................................................................................................................................................12 Модуль 1. Обзор бизнес-анализа............................................................................................................................15 Модуль 2. Основные навыки бизнес‑аналитика.......................................................................................33 Модуль 3. Жизненный цикл бизнес‑анализа..............................................................................................54 Модуль 4. Технология бизнес‑анализа.............................................................................................................64 Модуль 5. Методы бизнес‑анализа: важное............................................................................................... 120 Модуль 6. Артефакты бизнес‑анализа............................................................................................................. 158 ЧАСТЬ II. ЗА ПРЕДЕЛАМИ БИЗНЕС-АНАЛИЗА Модуль 7. Архитектура предприятия............................................................................................................... 186 Модуль 8. Управление проектом.......................................................................................................................... 198 Модуль 9. Управление IT-услугами......................................................................................................................215 6 Содержание Модуль 10. Управление безопасностью...........................................................................................................227 Модуль 11. Регулирование..........................................................................................................................................240 Модуль 12. SDLC......................................................................................................................................................................255 ЧАСТЬ III. ВВЕРХ ПО КАРЬЕРНОЙ ЛЕСТНИЦЕ Модуль 13. Повысить свою значимость...........................................................................................................284 Заключение.......................................................................................................................................... 351 Дорогой читатель! Я много лет работаю в области автоматизации различных видов человеческой деятельности. Начинал с локальных систем регулирования в 80-х годах прошлого столетия, а в настоящее время пул моих задач охватывает всю пирамиду управления предприятием, завязанную на множество информационных систем. Моя специализация затрагивает следующие области знаний: автоматизация технологических процессов, автоматизация производственной деятельности и управление проектами в указанных областях. Сегодня одним из важнейших факторов успеха в любой области становится взаимодействие — людей, технологий, процессов. Требования развития кроссфункциональных навыков у специалистов по автоматизации, разработке программного обеспечения, развитию IТ-сервисов даже не обсуждаются. Они стали фактом, и им надо соответствовать, если вы желаете быть востребованным профессионалом на рынке высокотехнологических профессий. Результаты бизнес-анализа служат основой информационной архитектуры взаимодействия при создании информационных систем управления. Специалисты, владеющие этими навыками, востребованы и ценятся на рынке. Знания бизнес-анализа и умение применять их важны не только для аналитиков, но и для руководителей IТ-проектов. Разница лишь в широте охвата данной темы. Представленная книга прекрасна тем, что дает возможность взглянуть на свод знаний по бизнес-анализу сверху, понять взаимосвязи и ценность применения в своей деятельности и при этом разобраться, «куда копать» дальше. Это издание принесет пользу студентам, менеджерам и целым командам. Оно научит структурировать IT-проекты, улучшать взаимодействие и взаимопонимание между структурными подразделениями исполнителя, строить стабильные отношения с заказчиками и партнерами в рамках цифровой трансформации современного бизнеса. Книга Сергея Корбана в деталях расскажет, что дает бизнес-анализ всей компании в целом и отдельно каждому сотруднику, чтобы проекты работали без остановок и в верном направлении. Желаю интересного чтения и применения полученных знаний на практике. Юрий Волщуков 8 В настоящее время ситуация в мире бизнеса такова, что молодых профессиональных аналитиков категорически не хватает — как на международном, так и на отечественном рынке труда. Все отрасли нуждаются в свежих подходах к построению информационных систем, которые могли бы гарантировать реальную ценность для бизнеса. В связи с этим очень радует, что аналитика наконец приобрела заслуженный статус важной и необходимой профессии. Она призвана обеспечить качественно новый уровень работы с данными, а также возможность применения современных технологий для их обработки. Бизнесу нужны высококлассные и высокопрофессиональные специалисты со знанием бизнес-анализа, которые знают, как устроен бизнес и как он работает. В классическом понимании бизнес-аналитик — это экономист, который хорошо разбирается не только в финансах и деловых процессах, но и помогает руководству в организационном развитии и решении стратегических задач. Отдел бизнес-анализа в компании занимается долгосрочным планированием, внедряет цифровые технологии с целью оптимизации различных процедур: • повышения ценностей для клиентов; • разработки инновационных решений. Дальнейшее становление и развитие отечественного бизнеса во многом зависит от разрешения вопроса нехватки квалифицированных кадров, и потому каждый научный труд в сфере аналитики имеет огромную ценность. Книга позволит вам овладеть полезными навыками востребованной на рынке труда профессии «бизнес-аналитик». Желаю вам успехов! Генеральный директор ЗАО «КонсОМ СКС» Борис Владимирович Драгунов Подходит ли вам эта книга? Верите ли вы, что бизнес-анализ — залог успеха любого проекта? Если да, то понимание бизнес-анализа, а также смежных дисциплин, их задач, базовых компетенций жизненно важно для вашего успеха. Неважно, насколько велики ваши достижения в проектном менедж­ менте и как вы себя позиционируете. Может быть, вы только учитесь или вы разработчик ПО, а может быть, уже руководите проектом. Начать структурированно понимать бизнес-анализ и его методы в этой области поможет эта книга! Вы уже бизнес-аналитик, но хотите повысить квалификацию и стать преуспевающим специалистом? Мы представим вам принципы бизнес-анализа, проверенные на реальных проектах. Покажем, что работает, какие сведения имеют ключевое значение и о чем необходимо помнить. Здесь найдется информация для каждого, кто хочет начать карьеру бизнес-аналитика, получить практические советы и изучить приемы, чтобы эффективно справляться с бизнес-задачами. Бизнес-анализ не просто отдельная дисциплина. Он находится на стыке других дисциплин. И если вы уделите внимание их изучению и найдете способы улучшить свои навыки, то станете профессионалом, вооруженным практическими знаниями и готовым использовать самые различные инструменты. ВЫ можете стать бизнес-аналитиком и лучше разбираться в этой сфере. Эта книга вам поможет. Об авторе Сергей Корбан — практикующий специалист и наставник в области бизнес-анализа (БА) уже более 33 лет. Сотрудничал с государственными и частными компаниями в таких отраслях, как сбыт компьютерного оборудования, розничная торговля ПО, автопромышленность (сеть автосалонов), ERP-системы (бизнес-консалтинг и разработка софта), телекоммуникации. Принимал участие во множестве проектов, связанных с комплаенсом, совершенствованием бизнес-процессов, бизнес-трансформацией, заменой и обновлением технологий, внедрением ПО и т. д. Живет в Веллингтоне — красивой и ветреной столице Новой Зеландии. Работает в энергетическом секторе над соблюдением современных стандартов бизнес-анализа, PM, ITIL и Agile в бизнес- и технологических проектах. Обладатель сертификатов PRINCE2, ITIL и Agile. Участвует в развитии сообщества БА через свои блоги и большое количество статей о различных аспектах бизнес-анализа и управления проектами. Делится своими идеями на сайте aoteastudios.com. Часть I Бизнес-анализ Модуль 1. Обзор бизнес-анализа..................................................................................15 Модуль 2. Основные навыки бизнес‑аналитика...........................................33 Модуль 3. Жизненный цикл бизнес‑анализа..................................................54 Модуль 4. Технология бизнес‑анализа.................................................................64 Модуль 5. Методы бизнес‑анализа: важное................................................... 120 Модуль 6. Артефакты бизнес‑анализа................................................................. 158 i Введение BA Путеводитель О путеводителе по бизнес-анализу Я понимаю, что бизнес-анализ считается отдельной дисциплиной. И все же он существует не сам по себе. Он взаимодействует со многими хорошо известными дисциплинами, такими как управление проектами, управление рисками, управление изменениями и т. д. Эти взаимодействия делают бизнес-анализ важным звеном производственно-сбытовой цепи любой организации. Если вы новичок в сфере бизнес-анализа, вам необходимо приобрести: • знания во многих бизнес-областях; • гибкие навыки (так называемые soft skills); • практический опыт; • желание помогать предпринимателям добиваться успеха; • психологическую резистентность/устойчивость в отношениях со стейкхолдерами; • настойчивость в повышении качества бизнеса. Любой человек, мечтающий стать бизнес-аналитиком, должен обладать: • сильным желанием учиться и ежедневно практиковаться; • стрессоустойчивостью к дедлайнам; • способностью как повторно использовать элементы, так и вводить новшества; • умением видеть общую картину. Вы можете иметь опыт разработки ПО или управления проектами. Можете быть IT-специалистом, бизнес-консультантом, аналитиком данных, аналитиком качества или просто хотеть стать частью мира бизнес-­анализа. Моя цель — дать каждому из вас прочную основу и уверенность в собственных знаниях и превратить ваш опыт в практические навыки бизнес-аналитика. Эта книга содержит ценный обзор бизнес-анализа и практических инструментов, которые помогут вам в работе. 13 Введение Я также считаю, что успешному бизнес-аналитику необходимы: • широкий взгляд на свою работу; • понимание окружения бизнеса; • умение использовать передовые методы дисциплин, связанных с бизнес-анализом. Эта книга станет хорошим введением в дисциплины, в окружении которых находится бизнес-анализ. ЧАСТЬ I БИЗНЕС-АНАЛИЗ ЧАСТЬ II ЗА ПРЕДЕЛАМИ БИЗНЕС‑АНАЛИЗА ЧАСТЬ III ВВЕРХ ПО КАРЬЕРНОЙ ЛЕСТНИЦЕ Модуль 1. Обзор бизнес-анализа Модуль 7. Архитектура предприятия Модуль 13. Повысить свою значимость Модуль 2. Основные навыки бизнес-аналитика Модуль 8. Управление проектом Модуль 3. Жизненный цикл бизнес-анализа Модуль 4. Технология бизнес-анализа Модуль 9. Управление IT-услугами Модуль 10. Управление безопасностью Модуль 11. РегулироваМодуль 5. Методы ние бизнес-анализа: важное Модуль 6. Артефакты бизнес-анализа Модуль 12. SDLC Путешествовать по «терра инкогнита» лучше с экскурсией, чем самостоятельно... Aotea Studios 14 Часть I. Бизнес-анализ Цели обучения • Представить бизнес-анализ как дисциплину. • Показать компоненты бизнес-анализа. • Познакомить с основными и специальными навыками бизнес-­ аналитика. • Представить эффективные методы бизнес-анализа. • Показать бизнес-анализ во взаимодействии с другими дисциплинами. • Обучить практическим приемам эффективного выполнения работы. Подход • Модульная структура тем. • Иллюстрации для быстрого освоения нового материала. • Перечни ключевых моментов изученного материала для запоминания. • Практические инструменты для реальной работы. • Задания для развития практического опыта. Обозначения Книга содержит несколько иконок для удобства. СОВ ЕТ Эта иконка обозначает практический совет. Эта иконка обозначает рекомендацию по инструментарию, который поможет выполнить работу. Эта иконка указывает на дополнительные источники. Модуль 1 ОБЗОР БИЗНЕС-АНАЛИЗА Что такое бизнес-анализ?...................................................... 16 1 Бизнес-анализ кратко............................................................... 17 Планирование и управление бизнес-анализом........................................................................... 19 Анализ текущего состояния................................................. 21 Сбор и документирование требований.................. 23 Анализ требований и расстановка приоритетов...................................................................................... 25 Взаимодействие со стейкхолдерами и коммуникация по требованиям................................ 27 Представление будущего состояния и оценка решения.......................................................................28 Окружение бизнес-анализа...............................................30 Самопроверка................................................................................. 32 Задание.................................................................................................. 32 16 Часть I. Бизнес-анализ Что такое бизнес-анализ? Все проще, чем вы думаете, и в то же время сложнее, чем можете себе представить. Иоганн Вольфганг фон Гете Бизнес-анализ является важной частью производственно-сбытовой цепи наряду с известными нам процессами, такими как продажи, закупки, маркетинг, финансы и т. д. Продажи Продажи Закупки Sales БизнесБизнес анализ Маркетинг Маркетинг Финансы Финансы Основные цели бизнес-анализа тоже складываются в цепь. Она состоит из трех звеньев: 1 2 3 исследовать текущую бизнес-модель организации и ее функционирование, чтобы найти причины низкой производительности, ограниченных возможностей, потери конкурентного преимущества или др.; указать на материальные и нематериальные последствия выявленных проблем, чтобы обосновать возможные изменения; найти решения, чтобы устранить выявленные проблемы и их причины. Люди, которые изучают текущее состояние организации, ищут бизнес-проблемы, их причины, а также их возможные решения (будущее состояние бизнеса), и есть бизнес-аналитики. 17 Модуль 1. Обзор бизнес-анализа Бизнес-анализ кратко БА — это центральный момент между организацией (бизнес-областью* — business domain), технологиями (внутренней и внешней IT-инфраструктурой), вендорами (поставщиками технологий и других услуг) и регулирующими органами (если нужно). Бизнес-аналитик «переводит сообщения на разные языки», чтобы удовлетворить бизнес-потребности (business needs) и решить бизнес-задачи путем согласования и соблюдения многочисленных требований (requirements) и условий. Знания из разных областей и владение терминологией помогут вам стать успешным бизнес-аналитиком и ценным сотрудником. Бизнес-домен Технологии Бизнес-анализ Вендоры Рынок/рег. органы Структура БА (business analysis f ramework) определяет окружение бизнес-анализа, его границы и фазы, а также задачи, выполняемые на каждой фазе, и способы их взаимодействия. Бизнес-анализ имеет дело одновременно с двумя средами организации: внешней и внутренней. Ведь ни один бизнес не функционирует в вакууме. Так или иначе, каждый бизнес взаимодействует со своим окружением и находится под его влиянием. * Бизнес-область, или бизнес-домен, — определенная отрасль экономики, например телеком, страхование, розничное кредитование и т. д. — Примеч. ред. 18 Часть I. Бизнес-анализ Внешнее окружение Вендоры Сбор требований и документирование Планирование анализа Анализ требований и расстановка приоритетов Анализ текущего состояния Управление анализом Внутреннее окружение Рынок/рег. органы Привлечение к участию стейкхолдеров и коммуникация по требованиям Бизнес Технологии Будущее состояние и оценка решения Модуль 1. Обзор бизнес-анализа 19 Планирование и управление бизнес-анализом Планирование бизнес-анализа • границы бизнес-анализа; • подход, который будет применен; • результаты бизнес-анализа и рабочие документы; • вовлекаемых стейкхолдеров (stakeholders); • способ мониторинга процесса; • форматы и частоту формирования отчетов; • продолжительность работы; • ключевые этапы. Управление бизнес-анализом СОВ ЕТ Бизнес-анализ необходимо детально планировать, чтобы достичь ожидаемого результата. Нужно определить: Бизнес-анализом также необходимо хорошо управлять, чтобы достичь запланированных целей. Управление бизнес-анализом фокусируется на: • атрибутах метаданных требований; • принципах расстановки приоритетов; • прослеживаемости требований; • обсуждении требований; • управлении выполнением задач; • управлении изменениями; • утверждении результатов бизнес-анализа. Изменения в проекте требуют соответствующих изменений в плане бизнес-анализа. В бизнес-анализе очень полезны шаблоны. Они проясняют структурный и методологический подходы к бизнес-анализу и упрощают коммуникацию между стейкхолдерами, руководителем проекта и его командой. Структура, показанная в шаблонах ниже, представляет собой отличную основу для бизнес-анализа. 20 Часть I. Бизнес-анализ План бизнес-анализа Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. КОНТЕКСТ ПРОЕКТА................................... 5 2.1. ИСТОРИЯ ПРОЕКТА................................ 5 2.2. ЦЕЛИ ПРОЕКТА..................................... 5 2.3. ЦЕЛИ БИЗНЕС-АНАЛИЗА.......................... 5 2.4. РАМКИ РАБОТЫ БИЗНЕС-АНАЛИТИКА.......... 5 2.5. ТО, ЧТО НЕ ВХОДИТ В РАМКИ................... 5 3. ПОДХОД.................................................. 6 4. ДАННЫЕ.................................................. 6 5. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 7 5.1. ДОПУСКИ............................................ 7 5.2. ОГРАНИЧЕНИЯ...................................... 7 6. ОЦЕНКА.................................................. 8 7. КЛЮЧЕВЫЕ СТЕЙКХОЛДЕРЫ......................... 9 8. МАТРИЦА КОММУНИКАЦИЙ.......................... 9 План управления требованиями Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ПРЕДИСЛОВИЕ.......................................... 4 1.1. ПРЕДПОЛАГАЕМАЯ АУДИТОРИЯ................. 4 1.2. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.3. АРТЕФАКТЫ БИЗНЕС-АНАЛИЗА.................. 4 2. ВВЕДЕНИЕ............................................... 6 2.1. ГРАНИЦЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ...... 6 2.2. НЕ ВХОДИТ В ГРАНИЦЫ........................... 7 3. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ....................... 7 3.3. ПРОСЛЕЖИВАЕМОСТЬ ТРЕБОВАНИЙ........... 7 3.4. РАСПРЕДЕЛЕНИЕ ИДЕНТИФИКАЦИОННЫХ ДАННЫХ..................................................... 8 4. ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ............. 10 5. УПРАВЛЕНИЕ ДОКУМЕНТАЦИЕЙ.................. 11 6. ПОВТОРНОЕ ПРИМЕНЕНИЕ ТРЕБОВАНИЙ....... 14 СОВ ЕТ СОВ ЕТ Планирование и управление анализом помогают регулировать другие фазы бизнес-анализа в рамках проектах. Независимо от выбранной методологии (Waterfall/Agile/Scrum), используйте эти шаблоны как руководство по бизнес-анализу на протяжении всего проекта. 21 Модуль 1. Обзор бизнес-анализа Анализ текущего состояния Когда вы не знаете, где находитесь, на самом деле вы не знаете, куда идти. Aotea Studios Анализ Анализ текущего текущего состояния состояния Чтобы определить будущее состояние (найти решение бизнес-проблем) организации, оцените ее текущее состояние. Анализ текущего состояния направлен на поиск причин обозначенных бизнес-потребностей и определение актуальных бизнес-потребностей в текущем контексте. Конкретизированные бизнес-потребности дают прочную основу для корректировок, обычно выполняемых при реализации проекта. Результатом анализа текущего состояния являются документированные описания: СОВ ЕТ • затронутых частей бизнеса со ссылкой на бизнес-модель организации; • затронутых бизнес-процессов; • стейкхолдеров, вовлеченных в затронутые бизнес-процессы; • затронутых технологий (IT-услуг и приложений); • интерфейсов между внутренней и внешней средами; • не соблюденных нормативных требований (если есть); • неэффективности в работе с вендорами. В бизнес-анализе широко используется итеративный подход. Это означает, что все фазы бизнес-анализа взаимосвязаны и вы можете выполнять их более одного раза в течение проекта. Результат анализа текущего состояния влияет на следующие фазы: • сбор и документирование требований; • анализ требований и расстановка приоритетов; • взаимодействие со стейкхолдерами и коммуникация по требованиям; • представление будущего состояния и оценка решения. 22 Часть I. Бизнес-анализ Шаблон анализа текущего состояния, представленный ниже, поможет зафиксировать результаты бизнес-анализа и представить их в логической последовательности. Помните, что анализ текущего состояния дает информацию, необходимую для движения по остальным фазам и подтверждения финансово-экономического обоснования (business case). Анализ текущего состояния Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ВВЕДЕНИЕ............................................... 3 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ.............3 1.2. УСЛОВИЯ............................................ 3 2. ТЕКУЩИЙ БИЗНЕС-КОНТЕКСТ.......................3 2.1. ФУНКЦИИ И ПРОЦЕССЫ...........................3 2.2. БИЗНЕС-УСЛУГИ.................................... 3 2.3. АНАЛИЗ СТЕЙКХОЛДЕРОВ........................3 3. БОЛЕВЫЕ ТОЧКИ....................................... 3 3.1. БИЗНЕС-ПРОЦЕССЫ................................3 3.2. БИЗНЕС-УСЛУГИ.................................... 3 4. РЕКОМЕНДАЦИИ....................................... 3 4.1. БИЗНЕС-ПРОЦЕССЫ................................3 4.2. ВЗАИМОДЕЙСТВИЕ СО СТЕЙКХОЛДЕРАМИ....3 4.3. БИЗНЕС-УСЛУГИ.................................... 3 СОВ ЕТ Анализ текущего состояния — это всегда стартовая точка в бизнес-анализе. Модуль 1. Обзор бизнес-анализа 23 Сбор и документирование требований Сбор Сбор требований требованийи и документирование документирование Собирать и документировать требования — это не только делать пометки на полях в процессе встреч со стейкхолдерами, быстро составлять отчеты и списки идей. Это не все! Цель этой фазы — определить, а затем и применить подходы, которые позволят исследовать причины обозначенных бизнес-проблем, получить сведения о проблемах и требованиях стейкхолдеров, а затем задокументировать собранную информацию с помощью шаблонов организации. На этой фазе документируются: • специфическая бизнес-терминология, используемая стейкхолдерами; • терминология, описывающая будущее состояние; • шаги в рамках затронутых бизнес-процессов; • взаимодействие между бизнес-процессами и стейкхолдерами; • высокоуровневые требования стейкхолдеров в отношении бизнес-процессов и бизнес-приложений; • первый (верхний) уровень прослеживаемости* требований (требования высокого уровня); • нормативные требования, которые необходимо соблюдать. Эта фаза дополняет фазу анализа текущего состояния в определении бизнес-проблем. Прохождение обеих фаз помогает сформулировать бизнес-потребность. СОВ ЕТ Обратите внимание на высокоуровневые требования (в отношении возможностей или функций), определяемые на данной стадии. Они позволяют предположить первоначальный объем и возможные варианты удовлетворения бизнес-потребности. Руководители проектов используют эту информацию, чтобы обозначить объем решения, обрисовать возможные результаты и создать предполагаемый план всего проекта с ожидаемыми этапами. * Под прослеживаемостью (traceability) подразумеваются связи между разными типами потребностей с возможностью увидеть зависимость одних потребностей от других с целью понимания, на что может повлиять решение от отклонении той или иной потребности. 24 Часть I. Бизнес-анализ Собранная информация может быть упорядочена на основе шаблона, представленного ниже. Шаблон позволит обозначить бизнес-проблему, указать ожидаемое будущее состояние, перечислить варианты решения и прописать контекст «как будет». Видение решения Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. КОНТЕКСТ РЕШЕНИЯ.................................. 5 2.1. ПОСТАНОВКА ПРОБЛЕМЫ........................ 5 2.2. ОТЧЕТ О РЕЗУЛЬТАТАХ РЕШЕНИЯ.............. 5 2.3. АНАЛИЗ СТЕЙКХОЛДЕРОВ (RACIS).............. 5 3. ВОЗМОЖНОСТИ РЕШЕНИЯ............................ 6 3.1. ТО, ЧТО ВХОДИТ В ГРАНИЦЫ................... 6 3.2. ТО, ЧТО НЕ ВХОДИТ В ГРАНИЦЫ............... 6 4. КОНТЕКСТ РЕШЕНИЯ.................................. 7 4.1. ТЕКУЩЕЕ СОСТОЯНИЕ............................ 7 4.2. КАРТА ИЗМЕНЕНИЙ................................ 7 5. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 8 5.1. ДОПУСКИ............................................ 8 5.2. ОГРАНИЧЕНИЯ...................................... 8 Модуль 1. Обзор бизнес-анализа 25 Анализ требований и расстановка приоритетов Анализ Анализ требований требованийии расстановка расстановка приоритетов приоритетов Это фаза разделения собранных требований на три категории: должно, следует и желательно. • Категория должно содержит требования, определяющие основу будущего решения. • Категория следует содержит требования, определяющие дополнительные функции для решения обозначенных бизнес-проблем и удовлетворения бизнес-потребностей. • Категория желательно содержит либо персональные предпочтения пользователей, либо те требования, которые было бы здорово удовлетворить когда-нибудь, если позволят ресурсы и деньги. Цель данной фазы — обосновать, утвердить и упорядочить собранные и задокументированные требования методом моделирования текущего состояния с элементами возможного будущего состояния. Результат данной фазы — одобренные требования, расставленные по приоритетам. На этой фазе также определяются допущения, риски, бизнес- и технологические ограничения. Результаты данной фазы необходимо согласовывать с результатами анализа текущего состояния. Результаты также попадают в фазу проектирования, а затем и в фазу разработки решения. СОВ ЕТ Используйте визуальные коммуникации со стейкхолдерами, чтобы ускорить утверждение требований. Добавляйте только необходимые обозначения, чтобы сохранить картину ясной для понимания и проверки моделируемого состояния. Матрица, представленная ниже, поможет быстро разделить требования на категории и утвердить их на воркшопе (рабочей встрече). Наглядность поспособствует вовлечению стейкходеров в процесс приоритезации. 26 Часть I. Бизнес-анализ Матрица приоритезации требований Основные функциональные возможности (должно) Сопутствующие функциональные возможности (следует) Желаемые функциональные возможности (желательно) Приоритет исполнения Приоритет исполнения Функциональная область :_________________________ Решение идентифицированной проблемы Добавленная стоимость Стоимость, $ СОВ ЕТ Стоимость, $ Стоимость, $ Каждый участник воркшопа должен понимать, что требования из категории должно формируют основу решения, в то время как требования из категорий следует и желательно могут быть источником добавленной стоимости, но не так уж необходимы. Запускайте воркшопы, когда вооружены сметой расходов и представляете приоритеты выполнения. Модуль 1. Обзор бизнес-анализа 27 Взаимодействие со стейкхолдерами и коммуникация по требованиям Процесс привлечения к участию стейкхолдеров фокусируется на построении хороших и доверительных рабочих взаимоотношений с ними на протяжении, а затем и после, проекта, привлечении их к прояснению бизнес-проблем, подтверждению и дальнейшей проверке выявленных требований. Взаимодействие со стейкхолдерами и коммуникация по требованиям Обсуждение требований должно быть направлено на распространение информации о них на разных этапах проекта в соответствии с механизмом управления бизнес-анализом. Оно включает: • воркшопы для сбора требований; • воркшопы для утверждения требований; • экспертную оценку и одобрение артефактов бизнес-анализа. Эта фаза имеет следующие результаты: СОВ ЕТ • закрепление доверительных рабочих отношений со стейкхолдерами, проектной командой, партнерами и вендорами; • решение конфликтных вопросов; • просмотр и утверждение требований; • документирование прослеживаемости утвержденных требований; • представление требований на шаблонах организации. Повторяйте эту фазу несколько раз в течение проекта. 28 Часть I. Бизнес-анализ Представление будущего состояния и оценка решения Данная фаза направлена на определение желаемого результата проекта и требуемых возможностей решения. Основное внимание здесь уделяется приемлемым для бизнеса критериям и выгодам, которые должны быть реализованы в решении. Шаблоны, представленные ниже, позволяют обрисовать будущее состояние, определить ожидаемое поведение решения и пользовательский опыт в контексте «как будет». Будущее состояние и оценка решения Бизнес-требования Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. БИЗНЕС-ТРЕБОВАНИЯ................................. 5 2.1. ТЕКУЩИЙ БИЗНЕС-КОНТЕКСТ................... 5 2.2. БУДУЩИЙ БИЗНЕС-КОНТЕКСТ................... 5 2.3. БИЗНЕС-ПРАВИЛА.................................. 5 2.4. БИЗНЕС-ТРЕБОВАНИЯ (В ГРАНИЦАХ)........... 5 2.5. БИЗНЕС-ТРЕБОВАНИЯ (ВНЕ ГРАНИЦ)........... 6 3. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 7 3.1. ДОПУСКИ ........................................... 7 3.2. ОГРАНИЧЕНИЯ...................................... 7 Спецификация сценариев использования Наименование проекта: <xxx> Код проекта: <xxx> Автор: <наименование> Статус: <xxx> Версия: <xxx> Дата: Содержание 1. ВВЕДЕНИЕ..................................................4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ................4 1.2. УСЛОВИЯ...............................................4 2. РЕЗЮМЕ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ...............5 3. ПОТОКИ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ..............6 3.1. ОСНОВНОЙ ПОТОК....................................6 3.2. АЛЬТЕРНАТИВНЫЙ ПОТОК <наименование>....6 3.3. АЛЬТЕРНАТИВНЫЙ ПОТОК <наименование>....6 3.4. ПОТОК ИСКЛЮЧЕНИЙ <наименование>..........6 3.5. ПОТОК ИСКЛЮЧЕНИЙ <наименование>..........7 4. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ.....................8 4.1. БИЗНЕС-ПРАВИЛА.....................................8 4.2. ТРЕБОВАНИЯ...........................................8 4.3. СООБЩЕНИЯ...........................................8 4.4. ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ — ЭКРАНЫ.......8 5. ЭКРАНЫ.....................................................9 5.1. ЭКРАН <наименование>.............................9 5.1.1. КОНФИГУРАЦИЯ ЭКРАНА...........................9 5.1.2. ЭЛЕМЕНТЫ ДАННЫХ................................9 5.1.3. НАВИГАЦИОННЫЕ ЭЛЕМЕНТЫ УПРАВЛЕНИЯ....9 29 Модуль 1. Обзор бизнес-анализа Будущее состояние и оценка решения На этой фазе нужно протестировать предоставленные возможности, подтвердить удовлетворение требований, измерить производительность решения и устранить дефекты, обнаруженные в решении. Результаты данной фазы: • критерии приемки решения; • критерии удовлетворенности требований; • обучение конечных пользователей; • обсуждение организационных изменений. План тестирования Отчет по результатам тестирования Журнал дефектов Отчет оценки решения Резюме правления Введение Обзор решения Возможности решения Подход к оценке Выводы Заключение Ссылки Приложения 30 Часть I. Бизнес-анализ Окружение бизнес-анализа Бизнес-анализ не существует сам по себе. Схема справа иллюстрирует сосуществование бизнес-анализа и других областей знаний в любой современной организации. Знакомство с этими областями поможет достичь успеха в бизнес-анализе. СОВ ЕТ Блоки, связанные с ITIL (information technology infrastructure library — библиотекой инфраструктуры IT-технологий), иллюстрируют жизненный цикл услуги независимо от отрасли. Бизнес испытывает потребность в изменениях, которые бизнес-анализ принимает в качестве входных данных для поиска приемлемого решения. Архитектура предприятия определяет среду для текущих бизнес-процессов и решений, поддерживающих эти процессы. Структура ITIL основана на жизненном цикле услуги, который включает такие стадии, как стратегия, проектирование, преобразование, эксплуатация и постоянное совершенствование. Внедрение новой или улучшенной услуги зависит от управления проектами, которое при необходимости включает процессы управления изменениями. Этот короткий рассказ иллюстрирует, как тесно бизнес-анализ связан с другими дисциплинами. Поддержка Существующие возможности и бизнес-процессы Бизнес Бизнесзапросы Управление проектом Бизнес-анализ Связь изменений Бизнес-правила и ограничения Бизнес-экспертиза Изменения к состоянию « как есть» Привлечение к участию Анализ запросов Результаты Привлечение Низкая Анализ производительности производительность Существующие решения Управление вендорами Портфолио сервисов Управление и шаблоны Методологии Стандарты организации Преобразование услуг Новые сервисы IT-управление (коммуникации) Экспертиза вендора Изменения в технологическом ландшафте Требования преобразования Доступные опции Проектирование сервисов Требуемые возможности Стратегия сервиса Планируемые сервисы Дорожная карта предприятия Стандарты Планируемые возможности Запрос на услугу Технические ограничения Запрос Эксплуатация услуг Бизнес- цели Архитектура предприятия Новое решение 32 Часть I. Бизнес-анализ Самопроверка Пришло время проверить, как вы поняли терминологию и другие материалы. Отметьте вопросы, ответы на которые не вызовут у вас затруднения. Вопросы с пустыми чекбоксами требуют повторения материала модуля. Что такое бизнес-анализ? Каковы основные цели бизнес-анализа? С каким окружением бизнес-анализ имеет дело? Каковы фазы бизнес-анализа? Какие две фазы управляют бизнес-анализом на протяжении всего проекта? Какая фаза может повторяться несколько раз в течение всего проекта? Какой инструмент помогает расставить требования по прио­ ритетам? Вы отметили все чекбоксы? Прекрасно, поздравляю! Применяйте полученные знания в изучении следующих модулей. Задание Ничто так не помогает лучше «записать» новые знания в долгосрочную память, как выполнение задания. Цель задания — обратить ваше внимание на применение материала модуля. Ваше первое задание практическое. Вернитесь к схеме на с. 16 и используйте ее как карту областей, которые вам нужно освоить лучше. Просмотрите информацию по каждой фазе и создайте свой план действий. ASSIGNMENT СОВ ЕТ Будьте честны в оценке своих навыков, потому что только хорошая карта превращает длинную дорогу в приятное путешествие. Модуль 2. ОСНОВНЫЕ НАВЫКИ БИЗНЕС‑АНАЛИТИКА Основные навыки бизнес-аналитика........................34 Слушать.................................................................................................. 35 2 Наблюдать...........................................................................................38 Изучать (читать).............................................................................. 39 Говорить............................................................................................... 40 Писать..................................................................................................... 47 Иллюстрировать............................................................................49 Связывать.............................................................................................50 Проводить итерации.................................................................. 51 Самопроверка................................................................................. 52 Задание.................................................................................................. 52 34 Часть I. Бизнес-анализ Основные навыки бизнес-аналитика В основе бизнес-анализа лежит общение. Бизнес-аналитики несут ответственность за правильное понимание появляющихся бизнес-потребностей, преобразование их в требования, общение со множеством стейкхолдеров внутри и вне организации. Слушать Изображать Писать Говорить Смотреть Исследовать Стыковать Работать итерационно Бизнес-аналитики тесно сотрудничают с руководителями проектов, чтобы сделать проекты выгодными для бизнеса. Роль важного связующего звена между стейкхолдерами и IT-миром обязывает бизнес-аналитика развивать навыки общения. Люди общаются, используя разные способы передачи сообщений. Мы считаем, что бизнес-аналитик должен владеть следующими основными навыками: • слушать, наблюдать, изучать (читать) — для сбора, подтверждения и проверки требований; • иллюстрировать, связывать и проводить итерации — для интерпретации и проверки требований; • говорить, писать и иллюстрировать — для налаживания взаимодействия и распространения информации. Модуль 2. Основные навыки бизнес‑аналитика 35 Слушать Слушая людей, вы можете узнать, что они делают, когда и зачем. Слушайте стейкхолдера внимательно — и узнаете об инструментах, которые он использует в своей работе, определите, какие стейкхолдеры взаимодействуют с ним. Обращайте внимание на правила, упоминаемые стейкхолдером при описании своего рабочего дня: когда он их соблюдает и зачем. Определите границы между людьми, группами, подразделениями и организациями, вовлеченными в описываемую деятельность. Учитывайте контекст, в котором представлена информация. Не принимайте чье-нибудь мнение как единственно верное объяснение существующего порядка вещей. Ищите факты и примеры, подтверждающее это мнение. Когда вы слушаете, кратко отмечайте прозвучавшие сокращения и термины. Не стесняйтесь спрашивать, что они означают. Некоторые из терминов и сокращений являются общеотраслевыми, в то время как большинство других стейкхолдеры используют только в своем коллективе. Изучайте бизнес-терминологию — это очень упростит ваше общение со стейкхолдерами. СОВ ЕТ Создайте свой глоссарий терминов для всех бизнес-областей и сфер, с которыми сталкиваетесь. СОВ ЕТ Используйте ресурс по адресу http://www.acronymfinder.com/ для расшифровки сокращений (содержит не все бизнес-термины). Схема, приведенная ниже, иллюстрирует, сколько всего вы можете узнать, просто внимательно слушая людей, например положение стейкхолдера в организационной иерархии и роли, выполняемые им. Довольно часто стейкхолдеры играют несколько ролей. Слушая стейк­ холдера, вы расширите свой словарный запас и изучите внутренний язык организации. Вы увидите, какие IT-услуги (приложения) использует стейкхолдер ежедневно, для каких целей, и запомните, какие IT-услуги находятся в аутсорсинге. Вы узнаете правила, определяющие распорядок дня, и увидите, какие из них навязаны извне, например государством или отраслью. 36 Часть I. Бизнес-анализ Стейкхолдеры Акронимы Словарь Фокус Люди Роли Терминология Внутренние Орг. структура Функции Процессы Виды деятельности Бизнес-данные Внутреннее окружение IT-сервисы Внешние Интерфейсы Внешнее окружение Внутреннее управление Потребности в изменениях Рынок Политика Процессы Партнеры Правила Возможности Гос. органы Бизнес-данные Выслушав стейкхолдера, вы получите преставление о внешнем окружении организации: ее партнерах и конкурентах. Вам станут известны способы ее взаимодействия с партнерами, а также процессы и технологические интерфейсы, соединяющие ее с партнерами и вендорами. Рассказ стейкхолдера раскроет перед вами и внутреннюю среду организации: ее сферу деятельности; текущую структуру; ключевые бизнес-функции; бизнес-процессы, реализующие эти функции; деятельность в рамках бизнес-процессов; инструменты (программные пакеты), поддерживающие эту деятельность; роли сотрудников и т. д. Как видите, этот тривиальный, но мощный навык помогает получить огромное количество информации для дальнейшего применения и анализа. Приучите себя быть внимательным к тому, что люди вам говорят, и фиксируйте все важные детали. Модуль 2. Основные навыки бизнес‑аналитика 37 Слушать с максимальной пользой Вы замечали, что слушать внимательно не так просто? В определенный момент ваши мысли начинают блуждать, и вы это понимаете только после того, как уже обдумали что-то постороннее, например меню на обед или чью-то странную стрижку. Люди склонны отвлекаться от собственных мыслей. Решение? Начать слушать — снова и снова. Просто обращать внимание, когда вы отвлекаетесь, и стараться сосредоточиться на говорящем. И важно слушать c сочувствием. Поставить себя на место собеседника и попытаться понять его точку зрения. Обращайте внимание на любые признаки разочарования. Как бы банально это ни звучало, это настоящие болевые точки стейкхолдера. Но помните, что эмпатия не подразумевает принятия! Ваша задача — найти реальные требования и предложить лучшие решения. Применяя эти два простых приема, вы получите и сохраните ценную информацию. 38 Часть I. Бизнес-анализ Наблюдать Наблюдение — это эффективный способ познакомиться с ролями ключевых пользователей, их обязанностями и повседневными действиями. Используйте этот навык, чтобы посмотреть, кто что делает и как. Как это делается — особенно важно, чтобы понять общий процесс, поднявшись над деталями. Одни действия составляют кратчайший путь к достижению цели, в то время как другие — продуманы как обходной путь для упрощения процесса. Благодаря внимательному наблюдению вы можете получить много дополнительной информации о неписаных правилах и процессах, о которых стейкхолдер вам не рассказывал. Запишите, какие IT-услуги поддерживают увиденное вами действие и какие из них вызывают проблемы. Триггеры Коммуникации Фокус Количество Шаблоны Обработка данных Трансформация Бизнес-данные Данные Ввод/вывод Последовательность шагов Бизнес-правила Документы Используемые инструменты Действия Отчеты Как правило, стейкхолдер, за которым вы наблюдаете, взаимодействует с другими стейкхолдерами в группе или подразделении. Помните, что никто не работает один внутри организации. Люди связаны между собой разными способами, которые не всегда заметны. Наблюдайте, какие действия стейкхолдеров требуют взаимодействия. Отметьте, какой информацией обмениваются стейкхолдеры, когда возникает повод (триггер) для контакта, и кто участвует во взаимодействии. Обратите внимание на способы обработки входных данных: по каким правилам входные данные преобразуются в выходные данные и для каких документов эти данные используются. Документы являются ценным источником информации, поскольку они поддерживают коммуникацию внутри организации и за ее пределами. Они являются письменными подтверждениями бизнес-данных, используемых в бизнес-процессах. 39 Модуль 2. Основные навыки бизнес‑аналитика Изучать (читать) Изучение бизнес-области — хороший способ понять, из чего она состоит и что ее окружает. Читайте, чтобы получить дополнительные знания и почувствовать себя более комфортно в общении со стейкхолдерами. Демонстрация своих знаний добавит бонусные баллы к оценке вашего профессионального уровня. Прочтите всю доступную документацию. Этот вид исследования поможет понять, каково текущее состояние, почему нужны изменения, что можно улучшить, какие ограничения могут встретиться и т. д. По режиму Правила Регулирование Фокус Ограничения Внормальное рабочее время Паттерны действий Сверхурочно IT-услуги Рынок/п артнеры Бизнес-область Обмен данными Процессы Архитектура Решения Безопасность данных Действия Готовые элементы Компоненты Безопасность данных Инфраструктура Триггеры событий Посмотрите, какие компоненты текущего IT-ландшафта можно повторно использовать в будущих решениях. Часто новое решение не такое уж и новое. Помните, что бизнес-процессы тоже могут претендовать на повторное применение. Узнайте о принципах ежедневной организации работы, а также о модели нагрузки и о пакетной обработке. Изучите, что происходит при обработке данных, какие атрибуты данных существенны и какие — дополняют друг друга. Познакомьтесь с передовыми методами, используя которые организация получает конкурентное преимущество. Обсудите другие возможные методы со стейкхолдерами и определите, какие из них подходят вашей организации. Цель исследования — определить потребности бизнеса и способы их удовлетворения, а также оценить пользу для бизнеса, связанную с ними. СОВ ЕТ Интернет — огромная «библиотека», которая добавляет бизнес-­ анализу новые возможности. 40 Часть I. Бизнес-анализ Говорить Бизнес-аналитики всегда задают много вопросов! Вопросы позволяют подробнее рассмотреть потребности, болевые точки и существующие проблемы. Практикуйте общение со стейкхолдерами, используя язык их бизнес-области, специальные термины и сокращения. Привыкая к условиям общения, вы повысите его эффективность. Стейкхолдеры увидят в вас инсайдера, который работает на их стороне. Это укрепит доверие в ваших рабочих отношениях. Ваша речь должна быть направлена на поиск нового бизнес-контекста, сопоставимого с уже существующим. Вы будете преобразовывать выявленные потребности в предполагаемые изменения бизнес-процессов, открывая новые технологические возможности. Поэтому вам потребуется формулировать предлагаемые преимущества как способ устранения существующих проблем и несоответствий в бизнес-процессах. Вводите новую терминологию в общение со стейкхолдерами. Смешение текущего делового языка с новыми обозначениями поможет стейкхолдерам постепенно принять новый язык, использовать новые термины и называть ими новые потребности. Ликвидация сопротивления изменениям начинается здесь! Планируйте свое общение, учитывая особенности слушателей. Это самое важное правило разговора об изменениях, которые повлияют на людей. Даже незначительное изменение может вызвать конфликт. Трудно перечислить все правильные вопросы для общения со стейкхолдерами, но можно подумать, что вообще подразумевает правильный вопрос. Далее вы найдете описание подхода. СОВ ЕТ Подчеркните преимущества передовых методов, чтобы настроить стейкхолдеров не только на ожидаемые выгоды, но и на долгосрочные перспективы. Задавать правильные вопросы не так уж сложно, если следовать нескольким ключевым шагам: Цель Стейкхолдер Болевая точка Формулировка вопроса ГОВОРИТЕ! Модуль 2. Основные навыки бизнес‑аналитика 41 Давайте посмотрим, к чему ведут эти шаги. Цель Определите, что вы хотите выяснить: СОВ ЕТ • События. Что является триггером бизнес-процесса или его этапа? • Бизнес-процесс. Что приводит к низкой производительности? • Правила. Какие условия должны быть выполнены? • Данные. Какие бизнес-данные используются в бизнес-процессе? Как они в нем преобразуются? • Люди. Кто участвует в бизнес-процессе? Как люди взаимодействуют? • Люди. Что является болевыми точками стейкхолдера? • Инструменты. Какая технология используется для поддержки бизнес-процесса? Избегайте вопроса «Каковы ваши требования?» и ему подобных. Маловероятно, что вы получите вразумительный ответ. Стейкхолдер Определите, кому вы собираетесь задавать вопросы. Постарайтесь найти подходящего человека для разговора — вы сэкономите много времени, если ваш собеседник будет обладать необходимыми знаниями. Прежде чем начать общение, учтите следующие факторы: • Компетентен ли он в интересующих вас функциональных областях бизнеса? • Каков его ее уровень квалификации — знания на высоком уровне или глубокое понимание? • Знает ли он/она контекст запланированной с вами встречи? • Какой точки зрения он/она придерживается по проблемному вопросу? • Является ли он/она лицом, принимающим решения в интересующей вас области? • Существуют ли какие-либо препятствия, например культурные различия или неготовность решать вопросы и тратить время на поиск ответов? 42 Часть I. Бизнес-анализ Внимание к этим факторам поможет вам формулировать вопросы в соответствии с индивидуальными особенностями стейкхолдера и сделает ваше общение эффективным. Болевая точка Болевая точка — это проблема, отрицательно влияющая на работу стейк­холдера. Все проблемы, перечисленные в кратком описании проекта, должны быть подтверждены. Начинайте налаживать сотрудничество со стейкхолдерами с выявления болевых точек. Эффективно определять проблемы вам поможет исследование следующих аспектов вокруг них: • Каков источник проблемы? • Есть ли у проблемы взаимозависимости? • Каковы возможные пути решения проблемы? • Удовлетворит ли решение проблемы потребности бизнеса? Лучший способ определить проблему — сформулировать ее по-своему, а затем попросить компетентного стейкхолдера подтвердить вашу информацию. В моей практике ответы на перечисленные выше вопросы часто раскрывали дополнительную информацию и помогали выстроить диалог о поиске основных причин проблемы. СОВ ЕТ Сосредоточьтесь на выявлении одной проблемы. Если в ответе стейкхолдера упоминаются новые проблемы, зафиксируйте их и разберите позднее по очереди, чтобы получить по каждой проблеме четкие ответы. Формулировка вопроса Можно сформулировать множество вопросов, чтобы получить нужную информацию. Иногда вы ждете короткий ответ «да» или «нет», а иногда стремитесь начать обсуждение. Хороший способ изучить проблему — использовать в беседе знакомую вам справочную информацию о проблеме, чтобы стейкхолдер вас понимал. Часто ключевые пользователи (business users) предпринимают некие действия по устранению проблем еще до начала проекта. Чтобы прове- 43 Модуль 2. Основные навыки бизнес‑аналитика рить, актуальны ли ваши представления о текущем состоянии, задайте стейкхолдеру вопрос в первой части разговора: «Какую часть проблемы вы сейчас решаете?» А завершая проверку отсутствия недоработок и переходя к следующей проблеме, спросите: «Какие еще проблемы, на ваш взгляд, связаны с предыдущей?» Используйте слова «почему», «что», «где», «когда», «кто», «как», чтобы получить описание проблемы. Если вы хотите узнать, существуют ли бизнес-правила (business rules), определяющие текущее состояние, используйте слова «обязан», «следует», «должно быть». Пример: «Я понимаю, что текущий <...> имеет несколько недостатков, таких как <...>. Верно? Что можно сделать для их устранения? А какие из этих шагов должны быть реализованы?» СОВ ЕТ Максимально применяйте терминологию стейкхолдера, чтобы поддерживать связь. СОВ ЕТ Еще один способ сформулировать вопрос — использовать простую конструкцию «или... или ...», чтобы определить правильный порядок действий или выбрать из нескольких вариантов корректный. Наводящий вопрос Почему? Гд е? а? гд Ко ? Что Кто? Обычно вы задаете вопрос и ждете ответ, не сообщая никакой дополнительной информации. Однако когда стейкхолдер затрудняется ответить, вы можете переформулировать вопрос. Похожим образом персональные коучи стимулируют самоопределение человека через наводящие вопросы. Такой подход помогает увидеть те аспекты, которые не может осветить ваш собеседник. 44 Часть I. Бизнес-анализ Формулируйте вопросы следующим образом: • Как вы думаете... ? • Учли ли вы... вообще? • Пытались ли вы улучшить... ? • Должно ли следующее решение включать... ? • Есть ли особые трудности, которые... ? Пять ключевых аспектов бизнеса помогут вам сформулировать вопрос: СОВ ЕТ • Люди. Кто участвует в бизнес-процессах? • Процессы. Как работает бизнес и как взаимодействуют процессы — каковы входные и выходные данные? • События. Что и когда запускает бизнес-процессы? • Информация. Какие потоки данных есть в бизнесе и кто какие данные использует? • Контекст. В какой среде работает бизнес, где он находится? Внимательно слушайте, чтобы найти якоря для построения вопроса. Вопрос прозвучит яснее, если в нем вы повторите слова, которые использовал стейкхолдер при описании проблемы. Использование пауз Недостаток пауз разрушает переговоры. Aotea Studios Вот довольно распространенная ситуация из моей практики: на встрече руководитель должен узнать мнения нескольких человек, но его речь занимает примерно 90 % времени, из-за чего другие участники не успевают нормально ответить на вопросы. Легко попасть в ловушку, если говорить слишком много, чтобы произвести впечатление. Остерегайтесь этого! Как лучше всего предоставить стейкхолдерам время для ответа? Предлагаю использовать подход QPAP (question, pause, answer, pause) — «вопрос — пауза — ответ — пауза». Не бойтесь пауз. Они дают собеседнику время подумать над ответом и принять верное решение. Получив ответ, проанализируйте его (используя вторую паузу), а затем определитесь, как продолжить разговор. 45 Модуль 2. Основные навыки бизнес‑аналитика На самом деле QPAP — это естественный способ общения, но мы склонны его усложнять. Сколько должна длиться пауза? Наш мозг считает, что разговор прерывается, если пауза превышает 7 секунд. Измерьте паузу в 3–4 секунды, чтобы почувствовать ее, или придумайте фразу такой длительности, чтобы проговаривать ее про себя, давая собеседнику время подготовить ответ. СОВ ЕТ Пауза перед следующим вопросом может принести вам больше информации, если собеседник примет ее за ваше предложение подробнее остановиться на предыдущем вопросе. Четкие и эффективные запросы Помните свои электронные письма с просьбами, на которые не получили ответ? Или непонятные ответы руководителя проекта? Или документы, которые стейкхолдеры проверили с опозданием? Такие явления можно предотвратить, если вы убедитесь, что запрос сформулирован четко и эффективно. Рассмотрим компоненты эффективного запроса: Кто Признание Что Когда Зачем Кто Когда вы озвучиваете запрос на встрече, обратитесь к человеку по имени. Если ваше электронное письмо адресовано нескольким людям, убедитесь, что вы четко обозначили, кого и о чем просите. Признание Выразите признание человеку, которого о чем-то просите, например: «Уважаемый Сергей Петрович, вы много знаете о данном аспекте бизнеса. Не могли бы вы рассказать мне о тех болевых точках, которые вам известны?» Удивительно, как охотно люди отвечают на просьбу, преподнесенную таким образом! Вы получите целое экспертное заключение! Что Четко определите, что вам нужно. Избегайте фраз «было бы хорошо, если», «возможно, вы могли бы» и пассивного залога (например, «эко- 46 Часть I. Бизнес-анализ номическое обоснование должно быть пересмотрено»), поскольку из-за таких фраз запрос становится расплывчатым и неэффективным. Когда Это очень важная часть. Если вам нужен ответ к определенному времени и дате, обязательно сообщите об этом! Можно предположить, что люди ответят в разумные сроки, но их представление о разумных сроках может отличаться от вашего. Зачем Это необязательный компонент. Но в некоторых случаях полезно объяснить, зачем вам нужна помощь. Так вы дадите человеку некоторый контекст или поясните, что вы хотите получить в итоге. Что делать с нечеткими запросами окружающих К вам могут обратиться с нечетким запросом, и вы не сможете понять, что именно от вас хотели. В таких случаях сами задавайте вопросы, чтобы выяснить, кто, что и когда: «Какая задача следующая?», «Когда это нужно сделать?», «Кого вы хотите назначить исполнителем?» Часто не хватает времени, чтобы продумать все темы встречи, и вам, возможно, придется импровизировать на месте. На простой схеме я покажу, что встречи полезны. Это своеобразная карта, которая помогает мне на встрече уделить внимание всем аспектам бизнес-проблемы. Новый Процессы Потребности Фокус Повторно используемый Контекст Возможности Текущий Варианты решения Изменения Терминология Выгода Роли Новая Явная Архитектура Интерфейсы Процессы Текущая Скрытая Компоненты Безопасность данных Действия Готовые элементы Наконец, при работе над проектом записывайте хорошие вопросы. Вы обнаружите, что одни вопросы вызывают нужные ответы лучше, чем другие. 47 Модуль 2. Основные навыки бизнес‑аналитика Писать Документирование результатов бизнес-анализа — необходимый навык. Ссылки на предысторию бизнес-потребностей, существующие процессы, современные технологии, внутренние и внешние правила имеют решающее значение для эффективного представления ваших выводов. Приведенная ниже схема поможет вам донести информацию, сосредоточиться на важных для стейкхолдеров темах и сориентироваться в структуре вашей документации. Текущее состояние Изменения Фокус Рынок Будущее состояние Контекст Новые возможности Варианты решения Изменения Правила Выгода Роли Изменения Регулирование Явная Архитектура Интерфейсы Процессы Бизнес Скрытая Компоненты Безопасность данных Действия СОВ ЕТ Инфраструктура GUI Не забудьте проверить, поддерживает ли существующая инфраструктура (серверы, операционные системы и т. д.) предлагаемое решение. Представьте текущее состояние, объясните причину возникновения потребности и укажите, что можно улучшить, чтобы изменить текущее состояние. Опишите будущее состояние, ожидаемые новые возможности и готовые элементы (reusable parts) бизнеса (процессы и технологические решения), которые можно использовать в будущем состоянии. Не забудьте представить будущее состояние с высоты птичьего полета: опишите внешнюю и внутреннюю среды и области, требующие изменений. 48 Часть I. Бизнес-анализ Выражайте мысли на бумаге четко и лаконично. Указывайте ссылки на все источники, которыми пользовались при подготовке документа. Убедитесь, что эти источники доступны другим стейкхолдерам и членам проектной группы. При создании писем соблюдайте простые правила: • используйте доступный язык, избегайте редких слов; • объясняйте технические термины к месту; • избегайте жаргонизмов; • сокращайте длинные предложения (не более 20 слов); • сохраняйте логическую последовательность изложения своих идей; • используйте списки при необходимости. Помните, кто ваш читатель и какова цель документа. Используйте заголовки, чтобы документ было легче читать. СОВ ЕТ Создайте общий глоссарий терминов, чтобы облегчить общение между стейкхолдерами и членами проектной группы. 49 Модуль 2. Основные навыки бизнес‑аналитика Иллюстрировать Рисование — чрезвычайно эффективный способ общения, поскольку многие люди воспринимают визуальную информацию намного легче, чем текст. Более того, рисование схем поможет вам лучше сконцентрироваться на проблеме и увидеть, какие детали нужно подробнее обсудить со стейкхолдерами. Применяя этот навык, вы сможете лучше ориентироваться в информационных потоках, данных в этих потоках и разберетесь, кто что и когда выполняет. Вы сэкономите много времени при обсуждении процессов и информационных потоков, поскольку, глядя на схему, ваш собеседник быстро различит проблему, сможет внести исправления или добавить объяснения. Состояние Взаимодействие Рынок Фокус Контекст Переход Будущее состояние Решение Карты Данные Роли Объекты Архитектура Интерфейсы Процессы Метаданные Компоненты Безопасность данных Многоразовые элементы GUI Деятельность Узнайте, что важно для стейкхолдеров в бизнес-процессах, которыми они владеют или в которых участвуют. Добавьте бизнес-данные, используемые в конкретном бизнес-процессе, чтобы сделать изображение более информативным. Различайте уровни детализации ваших схем в зависимости от того, кому вы их представляете (руководителям, специалистам в предметной области (SME) или конечным пользователям). Руководителей в основном интересует картина высокого уровня. Специалисты в предметной области и конечные пользователи обеспокоены деталями своей деятельности на низком уровне. СОВ ЕТ Используйте простые символы. Не пытайтесь впечатлить стейкхолдеров формальными подходами к моделированию. 50 Часть I. Бизнес-анализ Связывать «Переварив» информацию, полученную от стейкхолдеров, свяжите ее с проектами, находящимися на стадии разработки, известными ожидаемыми нормативными требованиями и изменениями внутренних бизнес-процессов или технологических решений. Эти связи позволят вам внедрить новаторский подход в определение необходимого решения. Почему? Потому, что вы увидите, как информация из связанных областей может изменить предлагаемое решение и повысить его ценность для бизнеса. Вы получите возможность удовлетворить будущие потребности, предоставляя текущее решение. Представьте такой пример из моей практики: ожидаемое нормативное требование по изменению способа уравновешивания продаваемых объемов газа может приостановить проект, критически важный для бизнеса. Если не обращать внимание на это требование, организация потеряет свои вложения. Будущие проекты Требования Рынок Фокус Ф Решения Архитектура Интерфейсы Компоненты Многоразовые элементы Контекст Текущие проекты 51 Модуль 2. Основные навыки бизнес‑аналитика Проводить итерации Итеративный подход позволит вам начинать анализ со схемы общей картины и постепенно переходить к сути бизнес-потребности. С каждой итерацией вы будете уточнять информацию о стейкхолдерах, правилах, бизнес-методах, бизнес-процессах, инструментах и т. д. Тот же подход применяется, когда вам нужно ознакомить стейкхолдеров с возможными вариантами решения. Изложите общую идею, назовите требования высокого уровня и предложите варианты решения, затем пошагово разберите каждый вариант решения. Подумайте о фрагментах информации, которые можно представить вместе, но не пытайтесь сделать все сразу. Соблюдайте короткий цикл итераций (одна рабочая неделя), чтобы убедиться, что отношения со стейкхолдерами «теплые» и каждую неделю они видят результаты вашей работы. Мой опыт показывает, что если в течение недели нет итераций, стейкхолдеры начинают беспокоиться. Слушать Говорить Смотреть Исследовать Работать итеративно Писать Рисовать Связывать 52 Часть I. Бизнес-анализ Самопроверка Теперь пришло время проверить, как вы поняли данные определения и подтверждающую информацию. Уделите несколько минут и отметьте вопросы ниже, в которых вы уверены. Вопросы с пустыми чекбоксами будут служить картой отображения изложенного материала. Каковы основные навыки бизнес-аналитика? Какие навыки необходимы для сбора информации? Какие навыки необходимы для распространения информации? Какие навыки нужны для поддержания «теплых» рабочих отношений? Поставили галочки во всех чекбоксах? Отлично, поздравляем! Давайте закрепим полученные знания выполнением задания. Задание Бизнес-анализ требует немного юмора по мере выполнения работы. Без удовольствия эта работа будет очень быстро надоедать. Поэтому давайте повеселимся и создадим игрушку, которая поможет вам сосредоточиться на бизнес-анализе. ASSIGNMENT Используйте изображение на следующей странице, чтобы вырезать куб и собрать его с помощью клея. Возьмите прочную бумагу, чтобы изделие прослужило дольше. Терминология Люди Контекст Потребности Технология Правила ПИСАТЬ Проблемы IT-услуги Паттерны (шаблоны) Бизнес-домен Регулирование Рыночные силы ИССЛЕДОВАТЬ СВЯЗЫВАТЬ ИТЕРАТИВНО РАБОТАТЬ СЛУШАТЬ Контекст Рынок Карты изменений Процессы Границы решения Данные РИСОВАТЬ Контекст Потребности Изменения Процессы Технологии Выгода ГОВОРИТЬ Модуль 2. Основные навыки бизнес‑аналитика 53 Модуль 3. ЖИЗНЕННЫЙ ЦИКЛ БИЗНЕС‑АНАЛИЗА Жизненный цикл бизнес-анализа................................ 55 Планирование................................................................................. 56 3 Определение.................................................................................... 57 Анализ.....................................................................................................58 Разработка.......................................................................................... 59 Построение........................................................................................60 Тестирование.................................................................................... 61 Развертывание................................................................................ 62 55 Модуль 3. Жизненный цикл бизнес‑анализа Жизненный цикл бизнес-анализа Все, что вам нужно, — это план, дорожная карта и смелость, чтобы идти к месту назначения. Эрл Найтингейл Современные проекты все больше ориентированы на предоставление решений, включающих бизнес-процессы и программные приложения для их поддержки. Работая над бизнес-анализом таких проектов, вы пройдете этапы его жизненного цикла, показанные ниже. На каждом этапе вы будете получать определенные результаты (документы), которые помогут руководителю и проектной группе принимать решения. Итерационные циклы каждого этапа имеют разную интенсивность. К проектам можно применять различные подходы: каскадную модель (waterfall), спиральную модель жизненного цикла (spiral lifecycle), инкрементальный (incremental) и гибридный (hybrid) подходы и, наконец, гибкую методологию разработки (agile). Выбор подхода будет основан на характере проекта и имеющихся ограничениях (по срокам, стоимости или качеству). Далее я проведу вас по жизненному циклу бизнес-анализа, чтобы показать, что происходит на каждом этапе. План Определение Определение Анализ Анализ Разрабокта Разработка Построение Построение Тестирование Тестирование Развертывание 56 Часть I. Бизнес-анализ Планирование Краткое описание проекта, представленное руководителем проекта, станет основой для планирования бизнес-анализа. В плане вы обозначите объем бизнес-анализа и выбранный подход, составите график (выявление, анализ, моделирование и документирование), выделите ключевые контрольные точки мониторинга прогресса бизнес-аналитических мероприятий и перечислите артефакты бизнес-­ анализа, которые нужно предоставить в указанные сроки. Бизнеспотребности Краткое изложение Изложение Проекта проекта Бизнесдокументы Политики/ Процедуры Документация решений CMDB, Служба технической поддержки Входные данные СОВ ЕТ БA Компетентность и навыки ПЛАН БА Границы работы БА Подход БА Предполагаемые результаты Планируемый график Ключевые точки контроля Согласованная отчетность Заметка: CMDB — База данных менеджмента конфигурации Используйте все доступные бизнес-документы, чтобы узнать о бизнес-функциях, процессах и приложениях, поддерживающих эти процессы. 57 Модуль 3. Жизненный цикл бизнес‑анализа Определение На этом этапе вы установите потребности и соберете информацию об организации, ее бизнес-функциях, основных бизнес-процессах и структуре. Вы сопоставите функции сначала с процессами, а затем, на более детальном уровне, — со стейкхолдерами. Такие сопоставления потребуются для управления изменениями. Информация, собранная на этом этапе, станет входными данными для следующего этапа. Бизнес-контекст Организационная структура Люди Функция Процесс Процесс Процесс Орг. диаграмма Операционный контекст Карта функций Карта IT-услуг Карта процессов Бизнес-данные Рабочие потоки Стейкхолдеры Карта стейкхолдеров Анализ стейкхолдеров Матрица коммуникаций Функционирование услуг Входные данные Бизнес-потребности «Как есть» против «Быть» Выходные данные 58 Часть I. Бизнес-анализ Анализ На этапе анализа вы соберете и проанализируете нормативные требования, политики и бизнес-правила, чтобы оценить, насколько деятельность организации и бизнес-процессы им соответствуют. Нормативные требования регулируют соответствие правилам. Нормативные политики и бизнес-правила определяют, как эти правила применяются к бизнес-процессам. Вы зафиксируете терминологию, используемую стейкхолдерами, в глоссарии. Потребности, определенные и утвержденные в завершении этого этапа, станут входными данными для этапа разработки. План Управления управления Требованиями требованиями Бизнес-контекст Организационная структура Люди Операционный контекст Карта функций Карта IT-услуг Требования высокого уровня Бизнес-правила Нефункциональные требования Карта процессов Бизнес-данные Рабочие потоки Стейкхолдеры Анализ разрывов (Текущее состояние против будущего) Бизнестребования Сценарии использования, сценарии Карта стейкхолдеров Анализ стейкхолдеров Матрица коммуникаций Опции решения Границы проекта Бизнес-данные Потоки данных Матрица соответствия требований Бизнес-потребности «Как Есть» против «Быть» Истории пользователей, Сценарии использования Функциональные требования Глоссарий решения Входные данные Анализ высокого уровня Выходные данные 59 Модуль 3. Жизненный цикл бизнес‑анализа Разработка На этом этапе вы упростите поиск вариантов решения и выбор наиболее осуществимого варианта. Вы подготовите архитектуру решения (solution architecture), подробный дизайн решения (solution detailed design document), спецификацию интеграции (integration specification) и артефакты моделей данных (data models artifacts) для следующего этапа. Бизнес-аналитик должен разъяснять архитекторам решений в разработке (solution architects in designing) требования, которые нужно удовлетворить. Лучшие Лучшие Архитектурные архитектурные практики Практики Стандарты Стандарты Предприятия предприятия Опции решения Подробный дизайн решения Бизнестребования Бизнес-правила Бизнес-потоки данных Нефункциональные требования Функциональные требования Сценарии использования, сценарии Входные данные Архитектура решения Спецификация интеграции (интерфейсы) Модели данных Разработка решения 60 Часть I. Бизнес-анализ Построение На этом этапе разрабатывается проектно-техническая документация (technical design document). Дополнительно формируется техническая спецификация программного обеспечения (software technical specification document), в которой подробно описывается внедрение решения. Когда на пути технического внедрения встают технологические ограничения, может потребоваться запрос на изменение требований и выбор другого прецедента использования (use case). Документ подробного дизайна решения (business process design document) также необходимо создать на данном этапе, чтобы проект­нотехническая документация соответствовала изменениям в затронутых бизнес-процессах. Бизнес- требования Функциональные требования Нефункциональные требования Сценарии использования Проектное задание (Technical Design) Подробный дизайн решения Техническая спецификация программного обеспечения Архитектура решения Разработка бизнес процесса Спецификация интеграции (интерфейсы) Модели данных Модели данных Входные данные СОВ ЕТ Запрос на изменение требований Входные данные Не забывайте выполнять формальные процедуры управления изменениями. Если изменения были одобрены, обновите подробный дизайн решения. 61 Модуль 3. Жизненный цикл бизнес‑анализа Тестирование На этом этапе тестировщики и корпоративные пользователи будут проверять разработанное решение и убеждаться, что ожидаемые функциональные возможности, поведение, производительность и другие критерии приемлемости выполнены, а дефекты и проблемы будут отражены в отчете о дефектах (defects report) и рассмотрены в соответствии с их серьезностью. Вы сгенерируете несколько новых артефактов, показанных на схеме ниже. Техническая спецификация программного обеспечения Построение План приемочного пользовательского тестирования Бизнес-требования Сценарии тестирования Функциональные требования Тестовые скрипты Нефункциональные требования Отчет о дефектах Сценарии использования Отчет об одобрении решения Подробный анализ Приемочное пользовательское тестирование 62 Часть I. Бизнес-анализ Развертывание На этом этапе участие бизнес-аналитика в проекте завершается. Решение будет развернуто в производственной среде после подтверждения отчета об одобрении решения (solution validation report). Бизнес-пользователи должны получать копии всех утвержденных прецедентов использования и технической спецификации программного обеспечения. Перечень «извлеченных уроков» (lessons learned document) будет дополнять комплект документов по управлению проектами. Глоссарий решения будет доступен бизнес-пользователям. Новые и повторно применяемые компоненты решения должны быть занесены в базу данных управления конфигурацией (CMDB, configuration management database), чтобы гарантировать, что эксплуатация услуг строится на самой последней и актуальной информации о развернутом решении. Рассмотрим общую картину жизненного цикла бизнес-анализа. Извлеченные уроки Бизнес-требования Глоссарий решения Функциональные требования Подробный дизайн решения Нефункциональные требования Интеграция спецификации (интерфейсы) Сценарии использования Отчет об одобрении решения Руководство пользователя решения Сценарии использования Новые элементы CMDB Карта стейкхолдеров РВ План БА Анализ стейкхолдеров План Матрица коммуникаций Артефакты БА Документация менеджера проекта План анализа РВ 1 10 UAT UATрешения Набор 5 Определение Владельцы бизнес-процесса Функции Ключевые моменты Фазы Планирование закрытия проекта Управление проектом План проекта -- -- -- -- -План этапов Актеры 6 Анализировать Принятые/неудачные релизы Релизы и запросы на изменение Подробный анализ Бизнестребования Функциональные требования 9 Отклонения Запросы на изменение CMDB Руководство пользователя Производство BAU Test Exit Report (Отчет пробного выхода) Утвержденный отчет тестового выхода Тестирование «Извлеченные уроки» Развертывание Утвержденная техническая спецификация (проектная документация) Полный глоссарий Утвержденные сценарии использования Сценарии тестирования Скрипты тестирования Передача (Handover) Отчет о подтверждении решения План UAT Отчет о дефектах Утвержденное решение UAT решение Элементы конфигурации 10 Разработка Необходимое решение Завершенные релизы решений Дефекты Построение Разработка решения Необходимая функциональность и поведение Модели данных Итерации Техническая спецификация ПО Технический дизайн Копия решения (Blueprint) Построение 8 Необходимое Архитектурный дизайн решение Решения Уточнение требований 7 Бизнеспотоки данных Правила: Рынок Бизнес Матрица отслеживания Глоссарий Нефункциональные требования Уточнение требований высокого уровня Границы решения Контекст решения Анализ высокого уровня Требования высокого уровня Результаты/рабочие пакеты Архитектура решения и рабочие пакеты Видение и границы Бизнеспотребности Действия актера Процессов «Как есть» против цели Рыночные правила Модель сценариев использования Видение решения Глоссарий Анализ разрывов План управления требованиями Каталог услуг и CMDB Карта применяемых систем Карта процессов Применяемые данные Согласование со стейкхолдерами проекта База данных управления конфигурацией Жизненный цикл БА Инициация проекта План Легенда Потребность/возможность 1 3 4 Карта применяемых услуг Карта функций Операционный контекст Владельцы функций Осознание Должности против ролей Предполагаемые Коммуникационные входные данные требования Риски Источник Бизнеспотребности и проблемы Организационная единица(ы) Участвующие команды 2 Контекст Структура Люди Модуль 4. ТЕХНОЛОГИЯ БИЗНЕС‑АНАЛИЗА Подход к бизнес-анализу...................................................... 67 Критерии приемлемости и оценки.............................68 4 Управление бэклогом..............................................................69 Сбалансированная система учета результатов..........................................................................70 Бенчмаркинг и анализ рынка............................................ 71 Брейнсторминг.............................................................................. 72 Анализ бизнес-возможностей......................................... 73 Финансово-экономическое обоснование............ 74 Канва бизнес-модели............................................................... 75 Анализ бизнес-правил............................................................ 76 Совместные игры.......................................................................... 77 Концептуальное моделирование..................................78 Словарь данных..............................................................................78 Диаграмма потока данных................................................... 79 Сбор данных (data mining)...................................................80 Моделирование данных......................................................... 81 Анализ решения............................................................................82 Моделирование решений...................................................83 Анализ документации..............................................................84 Оценка....................................................................................................85 Финансовый анализ...................................................................87 Фокус-группы...................................................................................88 Модуль 4. Технология бизнес‑анализа 65 Функциональная декомпозиция...................................89 Глоссарий.............................................................................................. 91 Анализ интерфейса..................................................................... 91 Интервью.............................................................................................. 92 Отслеживание элементов..................................................... 93 Извлеченные уроки................................................................... 93 Метрики и KPI..................................................................................94 Интеллект-карта............................................................................. 95 Анализ нефункциональных требований................96 Наблюдение......................................................................................98 Организационное моделирование............................99 Расстановка приоритетов...................................................100 Анализ процесса.......................................................................... 101 Моделирование процессов............................................. 102 Создание прототипа................................................................ 103 Анализ коммуникативных требований..................104 Планирование управления требованиями....... 105 Обзоры.................................................................................................106 Анализ и управление рисками...................................... 107 Матрица ролей и разрешений......................................108 Анализ основных причин...................................................109 Моделирование рамок.......................................................... 110 Диаграмма последовательности....................................111 Список стейкхолдеров, карта, личности..................112 Моделирование состояний................................................112 Опрос или анкета.........................................................................113 SWOT-анализ................................................................................... 114 Примеры использования и прецеденты...............115 Пользовательские истории................................................ 116 Оценка работы поставщика................................................117 Воркшопы........................................................................................... 118 66 Часть I. Бизнес-анализ Введение В этом разделе приведена справочная информация о методах бизнес-­ анализа, рекомендованных Международным институтом бизнес-анализа (IIBA®). IIBA® — независимая некоммерческая профессиональная ассоциация, обслуживающая развитие сферы бизнес-анализа. Я структурировал и сжал информацию о методах и добавил краткие описания и подсказки. Если моего описания метода будет недостаточно, обратитесь за подробной информацией к последней редакции книги A Guide to the Business Analysis Body of Knowledge (BABOK Guide®) («Общее руководство по бизнес-анализу»), в которой обобщены знания по бизнес-анализу и рекомендованы общепринятые методы. 67 Модуль 4. Технология бизнес‑анализа Подход кбизнесанализу Оценка рамок Приведите предлагаемое решение всоответствие стеми областями, где потребуется бизнес-анализ. Для каждой фазы проекта(если они известны) назначьте области. Определите, что выходит за рамки бизнес-анализа, исогласуйте это срамками проекта. Детализация Определите, какой уровень детализации необходим для представления результатов бизнес-анализа. Глубина Определите иерархию требований, которые должны быть представлены врезультате бизнес-анализа. Зафиксируйте это документально исогласуйте сключевыми стейкхолдерами. Работа сизменениями Определите, как будет проходить обработка изменений требований. Предпочтительно следовать формальной процедуре изменений. Неофициальные уведомления об изменениях неприемлемы. Управление требованиями Определите используемые шаблоны(если есть), сами требования, содержание иформат технического задания, рабочие процессы рассмотрения иутверждения. Коммуникация Определите способы ичастоту передачи результатов бизнесанализа различным группам стейкхолдеров. 68 Часть I. Бизнес-анализ Цель Определить требования, результаты и условия, которым должно соответствовать решение, чтобы стать приемлемым для ключевых стейкхолдеров. Используйте критерии оценки для анализа набора требований, чтобы выбрать между несколькими вариантами решения. Критерий приемлемости Определите меры для оценки и сравнения решений и альтернативных вариантов разработки. Критерии, поддающиеся измерению и тестированию, позволяют объективно и последовательно оценивать решения и проекты. Опишите минимальный набор требований, которые нужно выполнить, чтобы выбрать предпочтительное решение. Критерии приемлемости и оценки Критерий оценки СОВ ЕТ Определите набор измерений для ранжирования решений и альтернативных разработок в соответствии с их ценностью для стейкхолдеров. Измеряйте стоимость, производительность и удобство использования по критериям оценки — и узнаете, насколько точно решение отражает потребности стейкхолдеров. Модуль 4. Технология бизнес‑анализа Управление бэклогом 69 Цель Записать, отследить иопределить приоритеты незавершенных рабочих элементов. Бэклог Задержка(и переход задач вбэклог (backlog)) возникает, когда нет возможности выполнить весь объем рабочих элементов. Подход Ранжирование Составьте план, чтобы определить: какие рабочие элементы должны быть официально включены вбэклог; как описать рабочие элементы; как отслеживать рабочие элементы; как провести обзор рабочих элементов ирасставить приоритеты по остальным пунктам вбэклоге; как выбрать элементы для выполнения; как удалить рабочие элементы из бэклога. Элементы, расположенные выше, имеют наибольшую ценность для бизнеса инаивысший приоритет. Обычно именно их выбирают для работы. 70 Часть I. Бизнес-анализ Цель Составить стратегический план иоценить эффективности работы организации, проводимой за пределами традиционных финансовых мероприятий. Сосредоточьтесь на результатах бизнеса иобеспечьте сбалансированное представление опроизводительности организации. Сбалансированная система учета результатов Сбалансированная система учета результатов включает всебя четыре измерения: Подход обучение ирост; бизнес-процесс; клиент; финансы. В сбалансированную систему учета результатов входят: материальные цели; конкретные меры; целевые показатели, вытекающие из концепции истратегии организации. Модуль 4. Технология бизнес‑анализа Цель Бенчмаркинг Бенчмаркинг и анализ рынка 71 Улучшить работу организации через удовлетворение потребностей клиентов и стейкхолдеров. Сосредоточьтесь на сравнении своих организационных показателей с лучшими показателями в своем классе. Передовой опыт можно увидеть у организацийконкурентов, в правительстве или отраслевых ассоциациях. Бенчмаркинг (benchmarking), или контрольное тестирование, можно провести по стандартам, чтобы соблюсти все требования. Сосредоточьтесь на поддержке различных процессов принятия решений в таких областях организации, как Анализ рынка деловое партнерство; слияние; разделение и диверсификация. Изучите доступных клиентов для определения необходимости продуктов и услуг. Определите факторы, которые влияют на их решения о покупке, и конкурентов организации на рынке. 72 Часть I. Бизнес-анализ Цель Сгенерировать потенциальные варианты удовлетворения определенных потребностей бизнеса. Ранжировать эти варианты, чтобы найти среди них наиболее ценные для бизнеса. Найдите ответы на следующие вопросы: Какие варианты доступны для Брейнсторминг Исследование решения проблемы? Какие факторы препятствуют тому, чтобы команда двигалась вперед? Что может вызвать задержку вмероприятии «А»? Какие действия может предпринять команда для решения проблемы «B»? Этапы Подготовка. Брейнсторминг(brainstorming), то есть мозговой штурм. Итог. 73 Модуль 4. Технология бизнес‑анализа Предоставить основу для определения объема работ ипланирования спомощью: Цель формирования общего понима ния текущих возможностей организации; определения соответствия стратегии; предоставление масштабов ипринципов приоритизации. Анализ бизнесвозможностей Возможности(операционные Исследование Выходные файлы итехнологические). Риски(технологии/бизнес/ рынок). Ожидаемые результаты. Карты возможностей. Поддержка стратегического планирования. Карты ипрофили рисков. . 74 Часть I. Бизнес-анализ Финансовоэкономическое обоснование Цель Обеспечить обоснование проекта, основанное на преимуществах, которые можно реализовать спомощью предлагаемого решения сучетом затрат, усилий идругих издержек для реализации данного решения. Показатели издержек ивыгод Определите, как будут измеряться ираспределяться затраты ивыгоды по всему проекту, чтобы обосновать ожидаемые результаты. Оценка рисков Инвестиционный прогноз SWOT-анализ СОВ ЕТ СОВ ЕТ Стремитесь оценить первоначальные риски вариантов решения. Сосредоточьтесь на допустимости рисков иожидаемых мерах по предотвращению рисков, определенных бизнесом. Используйте оценочный подход для прогнозирования инвестиций, необходимых для реализации иэксплуатации предлагаемого решения. Продемонстрируйте, как решение повлияет на сильные ислабые стороны организации иее конкурентоспособность. Согласуйте ваши результаты с управлением рисками проекта. Составьте перечень затрат на обслуживание, поскольку их легко забыть. Модуль 4. Технология бизнес‑анализа Цель Конструктивные блоки Канва бизнесмодели 75 Описать, как организация создает продукт, приносит клиентам пользу иизвлекает выгоду. Ориентир полезности. Ключевые действия. Ключевые ресурсы. Каналы. Сегменты клиентов. Ключевые партнерские связи. Отношения склиентами. Источники доходов. Структура расходов. Подход Расположите строительные блоки на бизнес-канве(business canvas), чтобы показать взаимосвязь между деятельностью, финансами, клиентами ипредложениями(продуктами иуслугами) организации. Удобство использования Бизнес-модель, которая упрощает составление изображений программ, проектов идругих бизнес-инициатив со стратегией организации. Модель также можно использовать, чтобы изобразить, какие усилия различных подразделений ирабочих групп согласуются собщей стратегией организации. 76 Часть I. Бизнес-анализ Цель Определить, выразить, проверить, уточнить исистематизировать правила, регулирующие повседневную бизнес-деятельность ивлияющие на принятие бизнес-решений. Бизнес-политики Создайте каталог бизнес-правил формальных политик, определяющий требования крешению исвязывающий бизнес-процессы споддерживающими их системами. Действующие нормы Создайте каталог действующих норм, определяющий метаданные, которые будут использоваться при осуществлении деятельности врамках бизнес-процесса. Структурные правила Определите бизнес-правила, которые могут меняться со временем и таким образом влиять на деятельность врамках бизнес-процесса. Анализ бизнесправил 77 Модуль 4. Технология бизнес‑анализа Цель Побудить участников активно сотрудничать впоиске общего понимания проблемы или решения Установка Каждая игра вкоманде (collaborative game) направлена на развитие лучшего понимания проблемы истимулирует появление творческих решений, характерных для данного типа игры. Совместные игры Шаг открытия(участники Подход включаются, знакомятся справилами игры, генерируют идеи). Шаг исследования (участники взаимодействуют друг сдругом иищут связи между своими идеями, проверяют эти идеи иэкспериментируют сновыми идеями). Шаг завершения(идеи оцениваются, иучастники решают, какие из них наиболее полезны ипродуктивны). 78 Концептуальное моделирование Часть I. Бизнес-анализ Цель Сосредоточиться на основных понятиях бизнес-области. Особое внимание уделить высококачественным, независимым от разработки определениям, которые не содержат данных или предвзятости вреализации. Задокументировать: стандартные определения элементов данных; Цель Словарь данных Главное значения элементов данных; допустимые значения данных. Словарь данных содержит определения каждого элемента данных иуказывает, как эти элементы образуют составные элементы данных. Разработайте словарь, содержащий набор данных, которые должны быть захвачены исохранены врешении, входные данные для систем ивыходные данные, генерируемые решением. Модуль 4. Технология бизнес‑анализа 79 Цель Показать, откуда поступают данные, какие действия обрабатывают данные исохраняются ли результаты вывода или используются ли они вдругом действии или внешним объектом. Главное Используйте диаграммы потоков данных(data flow diagrams), чтобы проиллюстрировать перемещение ипреобразование данных между внешними объектами ипроцессами. На этих диаграммах можно также показать временные или постоянные репозитории(называемые хранилищами данных или терминаторами), хранящие данные системы или организации. Диаграмма потока данных 80 Часть I. Бизнес-анализ Цель Главное Сбор данных (data mining) Улучшить процесс принятия решений через нахождение полезных паттернов иидей вдоступных организационных ирыночных данных. Проанализируйте большие объемы данных сразных точек зрения ипредставьте данные таким образом, чтобы они показывали полезные паттерны ивзаимосвязи. Результаты дата-майнинга(data mining) представляют собой математические модели или уравнения, описывающие исходные паттерны ивзаимосвязи. Эти модели можно развернуть спомощью дашборда или отчета, чтобы визуализировать информацию, важную для принятия решения. Описательный: кластеризация Методы исследования данных упрощает просмотр паттернов внаборе данных. Диагностический: деревья принятия решений или сегментация, показывающие, почему паттерн существует. Прогнозный: регрессия или нейронные сети, показывающие, насколько что-либо возможно вбудущем. Модуль 4. Технология бизнес‑анализа Моделирование данных СОВ ЕТ 81 Цель Описать сущности, классы или объекты данных, относящиеся кбизнес-области, иатрибуты, используемые для их описания. Описать взаимосвязи между идентифицированными сущностями, классами или объектами данных, чтобы составить общий набор семантических технологий для анализа иреализации. Концептуальная модель Ваш взгляд на решение со стороны бизнеса. Опустите некритичные детали иподчеркните бизнес-правила, бизнес-объекты иограничения. Логическая модель Продемонстрируйте обобщенную формальную структуру объектов иих атрибутов врешении. Эта модель будет основой для создания физической модели. Физическая модель Покажите, как логическая модель решения будет реализована на практике. Эта методика полезна при проработке и подтверждении требований. 82 Часть I. Бизнес-анализ Цель Оценить проблему и возможные решения, чтобы определить пользу альтернативных результатов в неопределенных условиях. Пути принятия решения Выяснить, какие возможные решения и факторы необходимо принимать во внимание, чтобы сделать выводы по каждому пути (стоимость, время, ресурсы и т. д.). Оценка успеха Оцените вероятность достижения бизнес-цели и удовлетворения заявленных бизнес-потребностей. Оценка альтернативных решений Определите ожидаемые ценности каждого возможного варианта и сравните их с критериями приемлемости бизнеса. Анализ решения Модуль 4. Технология бизнес‑анализа 83 Цель Продемонстрировать, как принимаются повторяющиеся бизнесрешения. Подход 1 Таблица решений. В бизнес-решениях используется определенный набор входных значений для получения конкретного результата. Для выбора одного результата из множества доступных применяется набор бизнес-правил. Таблица решений — это компактное табличное представление набора этих правил. Моделирование решений Подход 2 Подход 3 Дерево решений. Деревья решений используются для представления набора бизнес-правил. Каждый путь на листовом узле дерева решений обозначает одно правило. Каждый уровень в дереве представляет определенный элемент данных. Нисходящие ветви представляют различные условия, которые должны выполняться для продолжения движения по этой ветви. Диаграммы требований к решениям. Визуальное представление информации, знаний и решений, связанных с более сложными бизнес-решениями. Диаграмма содержит: решения; входные данные; модели бизнес-знаний; источники знаний. 84 Часть I. Бизнес-анализ Цель Получить информацию, втом числе об окружении итребованиях, путем изучения доступных материалов, описывающих бизнес-среду, и/или существующих активов организации. Обзор документации Подумайте, является ли содержание документа актуальным, подлинным идостоверным, понятно ли оно иможет ли быть легко передано стейкхолдерам по мере необходимости. Определите данные, которые предстоит получить(на основе нужных классов данных), икластеры данных, которые предоставляют элементы, сгруппированные по логическим отношениям. Анализ документации Проведите подробный обзор каждого документа исделайте заметки по каждой теме. Проверьте, чтобы ваши примечания не противоречили друг другу ине повторялись. Найдите пробелы вполученных знаниях или ограниченную информацию по теме. Анализ документации Документирование результатов Задокументируйте источники проанализированных материалов (общедоступные или собственные), оцените их достоверность исделайте основные выводы. 85 Модуль 4. Технология бизнес‑анализа Цель Прогнозировать затраты иусилия, связанные среализацией курса действий. «Сверху вниз» Рассмотрите компоненты на высоком уровне виерархии. «Снизу вверх» Используйте элементы нижнего уровня иерархии, чтобы подробно рассмотреть работу иоценить индивидуальные затраты или усилия. Суммируйте все элементы, чтобы получить общую оценку. Параметрическая Используйте откалиброванную параметрическую модель оцениваемых атрибутов элемента. Параметры, доступные из данных прошлых периодов, умножаются на количество запланированных на проект часов. Коэффициент рентабельности проданной продукции (ROM, rough order of magnitude) Дайте оценку высокого уровня на основе ограниченной имеющейся информации. Обратите внимание, что она может иметь большой доверительный интервал. Поэтапная Уточняйте оценки после каждой итерации, чтобы получать аналогичную оценку на всем диапазоне работы по бизнес-анализу. Оценка 86 Часть I. Бизнес-анализ Метод Дельфи Оценка (окончание) Метод оценки ианализа проектов, PERT Соедините экспертные оценки иданные прошлого периода. Получите индивидуальные оценки иобсудите их сэкспертами внесколько этапов до достижения согласия. Используйте среднее значение трех оценок. Каждому компоненту оценки даны три значения: (1) оптимистическое значение (лучший случай); (2) пессимистичное значение (худший случай); (3) наиболее вероятное значение. Значение PERT для каждого оцениваемого компонента вычисляется как средневзвешенное: ((1)+(2)+4×(3))/6. 87 Модуль 4. Технология бизнес‑анализа Цель Финансовый анализ Понять финансовые аспекты инвестиций ирешения или подходы крешению. Затраты на изменения Стоимость изменения включает всебя: предполагаемые расходы на построение или приобретение компонентов решения; предполагаемые расходы на переход организации от текущего состояния кбудущему. Совокупная стоимость владения Совокупная стоимость владения (TCO, total cost of ownership)— это затраты на приобретение решения иего использование истоимость поддержки решения вближайшем будущем. Объедините эти элементы стоимости, чтобы лучше понимать потенциальную ценность решения. Реализация стоимости Обычно стоимость реализуется со временем. Предполагаемые расходы могут взиматься ежегодно или ввиде совокупной стоимости за определенный период. Анализ затрат ивыгод Прогнозируйте выгоды за вычетом общей суммы предполагаемых расходов, чтобы получить предполагаемую чистую прибыль(плановую стоимость бизнеса). 88 Часть I. Бизнес-анализ Цель Выявить идеи имнения оконкретном продукте, услуге или возможностях винтерактивной групповой среде. Главное Установите четкую цель для основного направления деятельности фокус-группы. Сформулируйте вопросы так, чтобы быстрее достичь поставленной цели. План Фокусгруппы Благодаря плану фокус-группы все стейкхолдеры находятся вкурсе целей фокус-группы, согласны сожидаемыми результатами, асессия соответствует целям. Руководство для дискуссий Подготовьте сценарий сконкретными вопросами итемами для обсуждения, которые соответствуют целям сессии. Модератор/ протоколист Модератор/протоколист должен уметь поддерживать сессию ибыть осведомленным оее инициативе. Протоколирование результатов Результаты фокус-группы необходимо расшифровать после сессии как можно скорее. Проанализируйте изафиксируйте документально согласие инесогласие участников, определите тенденции вответах исоздайте отчет, вкотором суммируются результаты. Модуль 4. Технология бизнес‑анализа 89 Цель Анализировать сложные системы иконцепции, рассматривая их как набор взаимодействующих или связанных функций, различных факторов икомпонентов. Главное Руководите процессом декомпозиции иопределите, что икак нужно разделить ина каком уровне детализации. Бизнес-результаты: доход, Функциональная декомпозиция Вопросы обсуждения прибыль, расходы, объем услуг или объем производства. Иерархическая структура работ(WBS, work breakdown structure): разделите работу по фазам, этапам, действиям, задачам, рабочим элементам иконечным результатам. Бизнес-процесс: обработка деталей для измерения, управления, оптимизации или повторного использования процесса или его компонентов. Функция: оптимизация или реализация. Бизнес-единица: инженерный анализ иразработка. Компонент решения: разработка, реализация или изменение. Деятельность: шаги реализации, изменения, оптимизация, измерение иоценка. Продукты иуслуги: разработка, реализация иусовершенствование. 90 Часть I. Бизнес-анализ Уровни Взависимости от соответствующего уровня функциональной декомпозиции определите, где, почему икогда остановиться, чтобы выполнить задачи анализа. Древовидные диаграммы: Представление Функциональная декомпозиция (окончание) иерархическая декомпозиция работы, действий или резуль татов. Вложенные диаграммы: иерархические соотношение между результатами декомпозиции. Диаграммы прецедентов использования: декомпозиция прецедента использования более высокого уровня. Диаграммы потоков: результаты декомпозиции процесса или функции. Диаграммы перехода состоя ний: поведение объекта внутри его составного состояния. Диаграммы причинно-след ственных связей: события, условия, действия иразличные факторы, участвующие всоздании сложного результата или феномена. Деревья принятия решений: структура сложного решения иего возможные результаты. Интеллект-карты: декомпозиция информации по категориям. Диаграмма компонентов: совместное подключение компонентов для формирования более крупных компонентов и/или систем программного обеспечения. Модель принятия решений иобозначение: анализ бизнеслогики для гарантии ее логической иделовой целостности. 91 Модуль 4. Технология бизнес‑анализа Цель Определить ключевые термины, относящиеся кбизнес-области ипредлагаемому решению. Элементы Список терминов сопределениями исинонимами вконкретной бизнес-области. Глоссарий Цель Определить, где, какой, почему, когда, как идля кого происходит обмен информацией между компонентами решения или через границы решений. Анализ интерфейса Включает всебя: Спецификация интерфейса имя интерфейса; охват или диапазон интерфейса; метод обмена данными; направление(я) потока данных; формат сообщений; частота обмена. 92 Часть I. Бизнес-анализ Цель Применить системный подход для получения информации обизнесанализе от человека(группы людей) путем диалога(полилога), задавая соответствующие вопросы идокументируя ответы. Проведение цикла интервью, основанного на потребности бизнеса; Направления проведение нескольких индиви- дуальных интервью, темы которых соответствуют компетенциям интервьюируемых. Открытые вопросы, запускающие развитие диалога или серию Интервью Вопросы дальнейших шагов; закрытые вопросы для получе- ния однозначного ответа(например, «да», «нет», конкретное число). Логистика Место проведения интервью; записывать интервью или нет; отправлять вопросы заранее или нет; конфиденциальная или общедоступная информация. Открытие(определены цель, формат, время интервью); Течение интервью; закрытие(отсутствуют недостаю- щие области, соблюден формат, подведены итоги). Последующие меры Систематизируйте информацию исогласуйте результаты сопрашиваемыми вскоре после интервью. 93 Модуль 4. Технология бизнес‑анализа Цель Назначить ответственного за рассмотрение проблем стейкхолдеров, влияющих на решение. Отслеживание элементов Записи элементов сих метаданными; Элементы управление элементами для поиска решения; метрики процесса поиска решения. Цель Собрать изадокументировать ошибки, успехи, возможности по улучшению ирекомендации по повышению эффективности будущих проектов иих фаз. Бизнес-анализ: действия или результаты; окончательное решение, Извлеченные уроки услуга или продукт; автоматика или технология, которая была введена или отменена; влияние на организационные Темы процессы; производительность: ожидания ирезультаты; отклонения сположительным или отрицательным влиянием; основные факторы, влияющие на производительность; рекомендации по поведенче- ским подходам; рекомендации по технологиче- ским решениям. 94 Часть I. Бизнес-анализ Цель Измерить эффективность решения, его компонентов идругих вопросов, представляющих интерес для стейкхолдеров. Индикаторы Покажите ввиде таблицы или графической формы результат анализа одной или нескольких мер по удовлетворению потребности, определению стоимости или необходимых действий, выводом или вводом данных. Метрики Это количественные уровни индикаторов. Измеряйте их вопределенный момент, чтобы достичь цели втечение периода. Структура Процедура сбора данных, процедура анализа данных, процедура отчетности исбор исходных данных. Для сбора данных определите единицы анализа, способ выборки, инструменты сбора, частоту сбора иответственность за сбор. Отчетность Сравните базовые, текущие ицелевые показатели, рассчитайте различия ипредставьте их как вабсолютных, так ивотносительных величинах. Метрики иKPI Модуль 4. Технология бизнес‑анализа Цель Четко сформулировать изафиксировать мысли, идеи иинформацию. Основная тема Формулируемая мысль или концепция, расположенная вцентре изображений таким образом, чтобы можно было выделить несколько тем иассоциаций. Темы Интеллекткарта 95 Мысли или концепции, которые раскрывают или дополняют формулировку основной темы. Подтемы Мысли или концепции, которые расширяют или дополняют основную тему инепосредственно кней относятся. Отрасли Связи между основной темой, темами иподтемами, каждая из которых содержит ключевое слово, которое четко формулирует характер связи. Цвет Используйте цвета для обозначения классов, приоритетов, тем, подтем иих связей. Изображения Сокращайте большие объемы информации, которые невозможно передать через рубрикацию. 96 Часть I. Бизнес-анализ Цель Изучить требования к решению, определяющие его эффективность. Доступность: насколько Анализ нефункциональных требований Категории решение применимо и доступно по необходимости. Совместимость: насколько эффективно решение работает с другими компонентами в своей среде. Функциональность: насколько функции решения соответствуют потребностям пользователей. Обслуживаемость: насколько легко можно изменить решение или его компоненты для исправления ошибок, повышения производительности и других свойств или адаптации к измененной среде. Производительность: насколько хорошо решение или его компоненты функционирует с минимальным потреблением ресурсов. Восстановление: возможно ли восстановление решения с минимальной потерей данных. Паттерны использования: применяются в зависимости от периодов повышенной, среднепиковой или непиковой нагрузки. Мобильность: насколько легко можно перенести решение или его компонент из одной среды в другую. Модуль 4. Технология бизнес‑анализа 97 Надежность: способность Анализ нефункциональных требований (окончание) Категории решения или его компонента функционировать при установленных условиях втечение определенного периода. Масштабируемость: насколько решение может расти или развиваться, чтобы выполнять большее количество работы. Безопасность: аспекты решения, защищающие его содержимое или компоненты от случайного либо злонаме ренного доступа, использования, изменения, уничтожения или открытия. Удобство использования: насколько легко пользователь учится применять решение иработает сним. Сертификация: ограничения на решение, необходимые для соблюдения нормативных стандартов или отраслевых конвенций. Комплаенс представляет собой соответствие каким либо внутренним или внешним требованиям или нормам. Локализация: требования, касающиеся языков, законов, валюты, культуры, вариантов написания идругих характеристик местного рынка. Соглашения об уровне обслуживания: ограничения, которые формально согласовали поставщик решения иего пользователь. Расширяемость: возможность решения включать новые функции. 98 Часть I. Бизнес-анализ Цель Получить необходимую информацию, просматривая иосознавая действия иих контекст. Активный/заметный: при Наблюдение Подход наблюдении за деятельностью наблюдатель задает любые вопросы по мере их возникновения. Несмотря на прерывание рабочего потока, наблюдатель может быстрее понять причины искрытые процессы, от которых зависят такие действия, как принятие решений. Пассивный/незаметный: во время действий наблюдатель не прерывает работу. Все замечания возникают после завершения наблюдения. Модуль 4. Технология бизнес‑анализа Цель Организационные модели 99 Описать роли, обязанности иструктуры отчетности, существующей ворганизации, исогласовать этих структуры сцелями организации. Функционально-ориентирован ные; ориентированные на рынок; матрица. Роли Вкаждую роль входит набор навыков изнаний, конкретные обязанности, выполнение определенных видов работ иотношения сдругими ролями ворганизации. Интерфейсы Интерфейсы между подразделениями. Интерфейсы(взаимодействия) могут быть вформе коммуникации слюдьми вдругих ролях или ввиде рабочих пакетов, которые подразделение получает или передает другим подразделениям. Схема организации Подразделения; роли иотдельные личности; порядок подчинения. Инфлюенсер Человек, ккоторому каждый обращается за информацией, направлением исоветом(часто представляет группу на собраниях). Организационное моделирование 100 Часть I. Бизнес-анализ Цель Предоставить фреймворк для бизнес-аналитиков, чтобы облегчить процесс принятия решений стейкхолдерами ипонять относительную важность информации бизнес-анализа. Группировка— классификация Расстановка приоритетов Подход информации по определенным категориям. Ранжирование— упорядочение информации от более важной до наименее важной. Таймбоксинг (выделение фиксированного периода для работы над конкретной задачей или группой задач)(time boxing) / составление бюджета (budgeting)— определение приоритетов информации взависимости от фиксированного ресурса. Переговоры— установление консенсуса между стейкхолдерами вотношении того, какие требования будут вприоритете. Модуль 4. Технология бизнес‑анализа Анализ процесса 101 Цель Оценить эффективность ирезультативность процесса ивыявить возможности для изменений. Основная причина Найти основную причину пробелов иобласть для улучшения, чтобы гарантировать, что решение направлено на соответствующие пробелы иобласть. SIPOC Модель потока создания стоимости Анализируйте процесс, следуя порядку SIPOC(supplier, input, process, output, clientinplus), чтобы изучить поставщиков, входные данные, процессы, выходные данные иклиентов. Подход включает всебя построение диаграмм, атакже мониторинг входных данных иточек их обработки, которая начинается на внешнем интерфейсе цепочки поставок. На каждом этапе карта потока создания стоимости выверяет время ожидания входных данных ифактическое время их обработки вуказанных точках(время преобразования). Вконце цепочки поставок карта потока создания стоимости отображает клиенту логистику или процесс распределения. 102 Часть I. Бизнес-анализ Цель Представить стандартизованную графическую модель, показывающую, как выполняется работа. Модель станет предпосылкой для анализа процесса. Структурные схемы икарта потока создания стоимости (VSM, flowcharts and value stream mapping). Диаграммы потоков данных Типы моделей Моделирование процессов иунифицированный язык моделирования(UML®, unified modelling language). Система условных обозначений (нотация) для моделирования бизнес-процессов(BPMN, business process model and notation). Интегрированное обозначение (IDEF, integrated definition notation), диаграммы входных данных, руководства, выходных данных, активации(IGOE, input, guide, output, enabler diagrams). SIPOC: применяется для моделирования процессов. Действие: отдельный шаг или Ключевые элементы этап работы, составляющий часть бизнес-процесса. Событие: событие снулевым временем, которое инициирует, прерывает или завершает действие внутри процесса или весь процесс. Направленный поток: путь, указывающий логическую последовательность рабочего процесса. Точка принятия решения: точка процесса, вкоторый поток работы делится на два или более потоков (путей), которые могут исключать друг друга как альтернативы или выполняться параллельно. Связь: соединение сдругими картами процессов. Роль: тип лица или группы, вовлеченных впроцесс. Модуль 4. Технология бизнес‑анализа Цель 103 Выявить иподтвердить потребности стейкхолдеров спомощью итеративного процесса создания модели или разработки требований. Одноразовый прототип создается спомощью простых Создание прототипа Подход инструментов(таких как бумага икарандаш, доска или ПО) ипомогает выявить иуточнить требования. Такой прототип можно обновить или изменить входе обсуждения иразработки, но он не станет работоспособным кодом ине будет поддерживаться как продукт после внедрения окончательной системы или процесса. Эволюционный или функциональный прототип создается для расширения первоначальных требований функционирующего решения. Требования определяются после эксплуатации таких прототипов стейкхолдерами. Данный подход создает рабочее решение итребует использования специальных инструментов или языков. 104 Часть I. Бизнес-анализ Цель Определить проблемы скоммуникацией, средствами связи, потоками ичастотами. Определите, что вы будете Сложность коммуникаций Анализ коммуникативных требований Средства коммуникаций сообщать, куда информация должна быть направлена (место), используемые каналы, типы аудитории ичастоту связи. Определите изадокументируйте события, когда коммуникация необходима(изменение статуса, проблемы, риски, элементы действий ит.д.). Определите, окаких типах требований необходимо сообщать(высокого уровня, бизнес-, функциональные, нефункциональные, все водном пакете) икому. Определите ограничения по времени иресурсам. Выберите способы доставки, формат, уровень детализации, стиль(формальный/неформальный) для каждого типа аудитории. Определите, есть ли воргани Потоки информации зации стандарты коммуникации для бизнес-анализа. Определите аудиторию для распространения утвержденных документов. Получите рекомендации по связи от внешних участников проекта. Модуль 4. Технология бизнес‑анализа 105 Укажите, как будут осущест Цель вляться сбор, документирование, уточнение, подтверждение, анализ, проверка иутверждение требований. Укажите, как будут идентифицированы ипронумерованы требования. Укажите, как будет поддерживаться контроль версий. Укажите владельца требований. Укажите иерархию требований Прослеживаемость Планирование управления требованиями ивзаимосвязи между уровнями иерархии. Укажите связь требований сдокументами. Метаданные Укажите, какие атрибуты метаданных требований будут фиксироваться иподдерживаться входе бизнес-анализа. Ранжирование Укажите, как будет проводиться ранжирование требований или распределение приоритетов. Общим подходом является high− moderate−low(высокий− средний−низкий). Обработка изменений Укажите, как будут происходить регистрация изменений, сообщение оних, оценка их воздействия на проект, утверждение иотражение вдокументе бизнес-требований. Опишите порядок сообщения об изменении заинтересованным сторонам. 106 Часть I. Бизнес-анализ Цель Оценить содержание рабочего продукта(документы, пакет требований). Инспекция: формальный метод, Подход Обзоры включающий обзор рабочего продукта, его индивидуальную проверку, регистрацию игруппирование дефектов,меры конт роля над внесением изменений. Формальный сквозной контроль: формальный метод, основанный на индивидуальной проверке продукта игруппировании действий, которые часто встречались при этой проверке. Обзор отдельной проблемы: формальный метод, ориентированный на одну задачу либо на стандарт, по которому рецензенты проводят тщательный анализ рабочего продукта до проведения совместной сессии анализа, чтобы решить основной вопрос. Неформальный сквозной контроль: неформальный метод, при котором бизнес-аналитик просматривает черновик продукта исобирает отзывы онем. Анализ историй «за столом» (Desk Check): неофициальный метод, при котором рецензент, который не участвовал всоздании рабочего продукта, предоставляет устные или письменные отзывы онем. «Передай другому» (Pass Around): неофициальный метод, вкотором несколько рецензентов предоставляют устные или письменные отзывы опродукте. 107 Модуль 4. Технология бизнес‑анализа Цель Выделить неопределенные области, которые могут отрицательно повлиять на ожидаемую выгоду, проанализировать иоценить их иразработать меры по снижению рисков. Подход Идентификация. Анализ. Оценка. Обработка. Избегать: ликвидации источника Анализ иуправление рисками Обработка риска, корректировки планов, чтобы риск не возникал. Передавать: ответственность за риск третьей стороне. Снижать: вероятность возникновения риска или возможные негативные последствия. Предпринимать: ничего вотношении риска. Если риск возникнет, будет разработано обходное решение. Увеличивать: риск, за который вы ответственны. Делить: ответственность за риски между организацией итретьими сторонами. 108 Часть I. Бизнес-анализ Цель Охватить все действия, обозначив роли, их ответственность, недостающие роли иожидаемые результаты запланированных изменений. Матрица ролей иразрешений Определите роли исоотнесите их сдействиями по решению. Назначьте ответственных по Подход каждому действию. Назовите группу лиц, которые выполняют общие функции по ролям. Свяжите действие содной или несколькими ролями, назначьте ответственный орган. 109 Модуль 4. Технология бизнес‑анализа Цель Определить иоценить основные причины указанной проблемы. Реактивный анализ: определить Направления Анализ основных причин основную причину/проблемы, чтобы корректно на них отреагировать. Упреждающий анализ: выявить потенциальные проблемы, чтобы их предупредить. Постановка проблемы: опишите задачу, подлежащую решению. Сбор данных: соберите инфор мацию охарактере, величине, месте ивремени принятия мер Подход по решению проблемы. Идентификация причин: иссле- дуйте паттерны последствий, чтобы найти действия, которые привели кпоявлению проблемы. Идентификация действий: определите корректирующие действия, которые предотвратят проблему или снизят вероятность ее повторного возникновения. 110 Часть I. Бизнес-анализ Цель Определить характер одного или нескольких ограничений, атакже рамки проекта или решения. Моделирование рамок Определите иопишите: что необходимо сделать; когда это необходимо завершить; почему это необходимо сделать; кто будет выполнять работу; как работа будет выполняться. Родительский элемент—дочерний эле- Моделирование рамок Взаимосвязи мент или множество—подмножество: свяжите элементы одного типа спомо щью иерархической декомпозиции. Функция—ответственность: свяжите функцию сагентом(стейкхолдером, подразделением или компонентом решения), который отвечает за ее выполнение. Поставщик—потребитель: спомощью передачи информации или материа лов свяжите процессы, системы, компоненты решений или подразделения(внутренние ивнешние субъекты организации). Причина—следствие: свяжите элементы по принципу логической вероятности их связи, чтобы определить цепочки элементов, подверженных влиянию изменения или участвующих вего проведении. Непредвиденные связи: вбольшинстве сложных систем несколько элементов взаимодействуют для получения результата, который невозможно предсказать. 111 Модуль 4. Технология бизнес‑анализа Цель Смоделировать логику прецедентов использования, представляя информацию, переданную между объектами всистеме во время выполнения прецедента. Определите иопишите: линия жизни: продолжитель Диаграмма последовательности Подход ность жизни объекта во время прецедента, смоделированного на диаграмме последова тельности; блок активации: период, втечение которого выполняет ся операция; сообщение: взаимодействие двух объектов; синхронный вызов: передает управление объекту-получателю. Отправитель не может действовать до получения ответного сообщения; асинхронный вызов(или сигнал): позволяет объекту продолжать собственную обработку данных после отправки сигнала. 112 Часть I. Бизнес-анализ Упростить анализ стейкхолдеров иих характеристик. Цель Определите иопишите: список стейкхолдеров, чтобы анализиро- вать их деятельность ипланировать работы по получению информации, сотрудничеству икоммуникации; карту стейкхолдеров, чтобы проиллюстри ровать их взаимодействие; матрица стейкхолдеров показывает уровень влияния изаинтересованности стейкхолдеров; концентрическая схема указывает, насколько стейкхолдеры вовлечены врешение: — напрямую взаимодействуют срешением или участвуют вбизнес-процессе; — являются частью более крупного объекта; — находятся вне организации. Список стейкхолдеров, карта, личности Подход Цель Описать и проанализировать возможные состояния объекта в системе, его переходы из одного состояния в другое, а также поведение объекта в каждом из его состояний. Определите и опишите: название состояния. Какие Моделирование состояний Подход действия оно включает в себя. Как происходит изменение объекта или его переход от одного состояния в другое; диаграмму состояний: жизненный цикл объекта, начинающийся с ее первого появления; все состояния, которые могут быть у объекта до прекращения его применения; таблицу состояний: двухмерную матрицу, отображающую состояния и переходы. Модуль 4. Технология бизнес‑анализа Цель 113 Структурировать сбор информации оклиентах, продуктах, методах ипозициях группы людей вкороткие сроки. Разработка опроса. Тестирование опроса. Распространение опроса. Документирование результатов Опрос или анкета опроса. Используйте два типа вопросов: Подход закрытый: респондента просят выбрать один или несколько вариантов из списка готовых ответов(«да» или «нет»), определить ранг или порядок, подтвердить факт вопределенной форме; открытый: респонденту задают вопрос всвободной форме без выбора ответа из готового списка. 114 Часть I. Бизнес-анализ Цель Оценить сильные ислабые стороны организации, атакже угрозы внутренним ивнешним условиям. Сильные стороны(S, strengths): SWOT-анализ все, что оцениваемая группа выполняет верно. Слабые стороны(W, weaknesses): Подход действия или функции, которые оцениваемая группа выполняет плохо или не выполняет совсем. Возможности(O, opportunities): внешние факторы, которыми оцениваемая группа может пользоваться. Угрозы(T, threats): внешние факторы, которые могут негативно повлиять на работу оцениваемой группы. 115 Модуль 4. Технология бизнес‑анализа Цель Описать, как человек или система взаимодействует срешением, направленным на достижение цели. Подход Используйте диаграмму, наглядно отображающую объем решения, субъектов, которые взаимодействуют срешением, варианты использования решения ивзаимосвязи между разными прецедентами использования. Цель. Участники. Предпосылки. Триггер. Поток событий. Постусловия. Взаимосвязи между прецеден- Примеры использования ипрецеденты тами использования: Ключевые элементы —один прецедент расширяет другой дополнительным поведением. Прецедент использования должен быть полностью функциональным, иего успех не должен зависеть от расширяющего прецедента; — один прецедент добавляет необходимую функциональность вдругой. Добавлен ный прецедент не обязательно должен быть завершенным, если он напрямую не инициирован участником. 116 Пользовательские истории Часть I. Бизнес-анализ Цель Представить небольшой сжатый отчет офункциональности или возможностях, необходимых для удовлетворения потребностей конкретного стейкхолдера. Формат «Такой, как <кто>, Яхочу, чтобы <что>, так вот <почему>». «Дано... Когда... Затем». Стоимостные данные: Ключевые элементы кто; — что; — почему. — Критерий приемлемости 117 Модуль 4. Технология бизнес‑анализа Цель Главное Оценить способность поставщика выполнять обязательства вотношении поставки ипоследовательного оказания услуги или предоставления продукта. Получить опыт изнания. Сравнить модели лицензирова ния иценообразования. Оценить рыночную позицию поставщика. Понять условия. Оцените опыт, репутацию иуровень финансовой стабильности. Оценка работы поставщика Запрос информации(RFI, request for information). Подход Запрос цены(RFQ, request for quotation). Запрос предложения(RFP, request for proposal). Необходимая функциональность. Поведение системы. Архитектура икомпоненты. Необходимая техническая среда. Используемые стандарты(ПО/ Критерий оценки аппаратное ПО). Соблюдение нормативно-право вых требований. Масштабируемость. Возможности интеграции. Общая стоимость владения. Режим развертывания(на локальном или виртуальном сервере). Техническая поддержка(стоимость, доступное окно). Запреты иограничения. Возможности поставщика (финансовая/техническая). 118 Часть I. Бизнес-анализ Цель Роли участников Воркшопы Сплотить стейкхолдеров для достижения намеченной цели. Спонсор. Посредник. Скрайбер(scribe) (скрайбинг — это процесс визуализации сложного смысла простыми образами, при котором отрисовка образов происходит впроцессе донесения информации). Табельщик(timekeeper). Участники. Подготовка. Проведение. Резервный пакет вопросов (список идей, тем или вопросов, Формат не требующих немедленного решения, но достаточно важных для будущего обсуждения или развития). Завершение. Task BAMP Критерии приемлемости и оценки Управление Backlog Сбалансированная система показателей Бенчмаркинг и анализ рынка Брейнсторминг Анализ возможностей бизнеса Бизнес-случай Холст бизнес-модели Анализ бизнес-правил Совместные игры Концептуальное моделирование Словарь данных Схема потоков данных Сбор данных Моделирование данных Анализ принятия решений Моделирование принятия решений Анализ документации Оценка Финансовый анализ Фокус-группы Функциональная декомпозиция Глоссарий Анализ интерфейса Интервью EC RLCM SA RADD SE 43 44 45 46 47 48 49 50 33 34 35 36 37 38 39 40 41 42 31 32 29 30 26 27 28 Task BAMP Отслеживание элементов «Извлеченные уроки» Метрические показатели и показатели KPI Схема выражения идей Анализ нефункциональных требований Наблюдение Организационное моделирование Расстановка прироритетов Анализ процессов Моделирование процессов Макетирование Отзывы Анализ рисков и управление Роли и матрица разрешений Анализ основных причин Моделирование границ Диаграмма последовательности Список стейкхолдеров, карта Моделирование состояний Анкетирование Анализ SWOT Сценарии использования Истории пользователей Оценка поставщиков Воркшопы EC RLCM SA RADD SE ВАРМ — Мониторинг и планирование БА; ЕС — Сбор информации и сотрудничество; RLCM — Управление требованиями жизненного цикла проекта; SA — Стратегический анализ; RADD — Анализ требований и определние проектирования; SE — Оценка решения. 18 19 20 21 22 23 24 25 12 13 14 15 16 17 4 5 6 7 8 9 10 11 2 3 1 ЗАДАЧИ В ОБЛАСТИ ЗНАНИЙ Модуль 5. МЕТОДЫ БИЗНЕС‑АНАЛИЗА: ВАЖНОЕ 5 Введение..............................................................................................121 Карманный путеводитель....................................................122 Стратегия изменений..............................................................123 Управление требованиями ............................................. 124 Нефункциональные требования..................................127 Эффективный воркшоп......................................................... 128 Самопроверка...............................................................................140 Пользовательская история................................................ 142 Прецедент использования................................................ 145 Анализ процесса.........................................................................149 Отзывы (артефакты бизнес-анализа)..........................151 Типы личностей.............................................................................153 Соответствующий язык.......................................................... 154 Оценка решения......................................................................... 156 Модуль 5. Методы бизнес‑анализа: важное 121 Введение Возможно, вы наблюдали за работой автомеханика, сантехника или продавца. Качество и сроки выполнения их работы зависят от навыков и инструментов. Подчеркну здесь «и», поскольку недостаточно обладать только навыками или только инструментами. Это относится и к бизнес-аналитикам. Вы можете эффективно выполнять свою работу до получения желаемого результата, когда у вас есть нужные инструменты (методы) и умения (навыки). Хотел бы поделиться с вами сведениями о методах бизнес-анализа, эффективность которых доказана за годы моей карьеры. Эти идеи сэкономили мне много времени и позволили своевременно выполнить проекты. 122 Часть I. Бизнес-анализ Карманный путеводитель Я создал для себя небольшую карту, которой хочу поделиться с вами. Она показывает, какой метод следует применять для выявления определенной информации или требований. Вы можете распечатать карту, сложить ее и убрать в карман в качестве шпаргалки. Бизнес-объекты/метаданные Болевые точки Анализ документов Видимый/невидимый Наблюдение Возможности/ ограничения/решения Личное мнение Фокус-группа Интервью Спецификация пользовательского интерфейса Опросы Брейнсторминг Прототипирование UI/компоненты Сбор данных Воркшоп по требованиям Бизнес-потребности Обратный инжиниринг* События, данные, потоки, управление * Применимо канализу программного кода. Белый/черный ящик 123 Модуль 5. Методы бизнес‑анализа: важное Стратегия изменений Каждый проект направлен на достижение бизнес-целей. Думайте об этих целях как о пунктах назначения анализа. Изучите способы достижения каждой цели организации, глядя на ее текущее состояние с разных точек зрения. Определите ограничения на каждом уровне, а затем свяжите цели с выявленными проблемами организации. Расположите уровни так, чтобы они отражали суть и цели проекта. Такой подход позволит представить общую картину зависимостей и правильно оценить финансовые возможности организации и ее готовность рисковать в работе над проектом. Цели организации Перспектива Управлять рисками Повышать эффективность Обеспечивать комплаенс Управление, стандарты Политики, бизнес-правила, внутреннее регулирование ирыночные правила Клиенты, поставщики, партнеры Имидж бренда, обязательства, стоимость предложения, сегменты, конкуренция, взаимосвязи, услуги, цепочка поставок Внутренние процессы Ручные/автоматизированные процессы, предоставление IT-услуг, межведомственные границы, потоки информации иих эффективность Стейкхолдеры внутри организации Роли, матрица компетенций, взаимодействие, болевые точки, обязательства Предоставление IT-услуг Хостинг/по запросу/внутренние бизнес-приложения иуслуги, IT-инфраструктура Проблемы/возможности/уровни Увеличивать прибыль 124 Часть I. Бизнес-анализ Управление требованиями Бизнес-анализ строится вокруг определения требований. Термин «требования» понимается по-разному. Некоторые люди не различают нормативные и внутренние (бизнес-) требования, не разделяют этих понятий. Другие более детально подходят к определению требований. При управлении требованиями в любой среде важно иметь четкое представление об источниках требований и об их взаимосвязях. Вот схема, которая поможет быстро сориентироваться. Пакет требований для коммуникации Прямые требования Определенные компоненты решения Поведение Бизнесправила Интерпретация Бизнестребования высокого уровня Входные данные Бизнестребования Имеющиеся + новые правила Вклад в успех проекта Определенные компоненты решения Качества Входные данные Функциональные требования Разработка бизнес-процесса 55% Нефункциональные требования 45% «Спецификация» решения Регулирование Реализация решения После определения требований высокого уровня позаботьтесь о прослеживаемости требований. Это поможет вам гарантировать, что взаимосвязи между требованиями не утеряны и решение соответствует указанным требованиям. Я собрал подробную матрицу прослеживаемости, работая над множеством проектов. Она позволяет отслеживать любые требования — от источника до тестового скрипта. Вы можете настроить ее так, как вам необходимо. 125 Модуль 5. Методы бизнес‑анализа: важное РЕШЕНИЕ Бизнес-требования Бизнес-потребности Требования высокого уровня Функциональные/нефункциональные требования СОВ ЕТ Используйте матрицу прослеживаемости для коммуникации с проектной группой и стейкхолдерами. Сложно управлять требованиями без атрибутов метаданных . Сообщая о своем прогрессе в работе над требованиями, считайте атрибуты метаданных критически важным элементом своих отчетов. Рассмотрим, какие атрибуты включены в метаданные требований и какие значения могут быть присвоены этим атрибутам. 126 Часть I. Бизнес-анализ Уникальный идентификатор (поддержка соответствия) Функциональная область Компонент решения Тип (MRL, BRL, HLR, BR, FR, NFR) Требование Статус (Утверждено... Подтверждено) Приоритет (высокий/средний/низкий) Сложность (высокая/средняя/низкая) Соответствие (см. выше — правила рынка, см. ниже — в зависимости от уровня) Описание Дата последнего изменения Владелец Последнее изменение — стейкхолдер Рабочий пакет (где требование будет реализовано) Id проекта Контрольный журнал (история изменений) Пакет требований (Id сценария использования) Наконец, понимание жизненного цикла требований поможет вам эффективно общаться с проектной группой и стейкхолдерами. Ход работы бизнес-аналитика будет отражен в статусе, который даст всем четкое представление о стадии развития проекта. : - - : : : : - : формальная оценка до принятия : ] [ Модуль 5. Методы бизнес‑анализа: важное 127 Нефункциональные требования Часто нефункциональным требованиям уделяется мало внимания. Это ведет к нежелательным последствиям, которые проявляются при реализации решения. Универсального списка нефункциональных требований нет, но я хотел бы поделиться перечнем, который применял в нескольких проектах. Надеюсь, он будет вам полезен (привожу его не полностью). СОВ ЕТ • Пользовательский доступ (удаленный, безопасный, аутентификация пользователя, администрирование аккаунтов пользователя, полномочия пользовательских ролей (user role-permission)). • Доступность и надежность (например, 24 × 7 × 365 @ 99,99 %). • Аварийное восстановление (время на восстановление, приемлемая потеря данных, время возврата к полноценному функционированию). • Производительность (количество одновременных пользователей, допустимая задержка) и ее мониторинг. • Совместимость и интеграция (с текущим и будущим IT-ландшафтом и инфраструктурой). • Портативность (функционирование приложения на нескольких платформах). • Аудиторский след (соответствие требованиям рынка и внутренний аудит). • Обслуживание и поддержка (служба поддержки, установка патчей, обновление аппаратного и программного обеспечения). • Документация решения (исходное состояние (обязательно!) и руководство пользователя). • Локализация (если требуется). Расширяйте или изменяйте предлагаемый список в соответствии с вашими потребностями. 128 Часть I. Бизнес-анализ Эффективный воркшоп Иногда воркшопы кажутся трудными, и это вполне понятно. Заставить группу людей работать вместе, следить за тем, чтобы обсуждение продолжалось по теме, согласовывать противоречивые ответы и извлекать полезную информацию за короткий промежуток времени — непростая задача. Тем не менее воркшопы становятся основной компетенцией бизнес-аналитика, поскольку позволяют достичь большего результата за меньшее время (если проводятся эффективно!). Независимо от того, являетесь ли вы новичком на воркшопах или обладаете многолетним опытом, это руководство поможет вам улучшить свои навыки и успешно взаимодействовать с группами. Ответственность за проведение воркшопов подразумевает ряд обязанностей, которые можно резюмировать следующим образом: • направлять группу к достижению намеченных целей или результатов; • инициировать и поддерживать взаимодействие во время воркшопа; • привлекать всех участников и отмечать их вклад во время воркшопа. Ваша задача — создать пространство для беспрепятственного общения, без отвлекающих факторов, задержек, барьеров. Бˆольшая часть работы по улучшению эффективности воркшопа выполняется до и после его проведения. Четыре этапа Я разделяю каждый воркшоп на четыре этапа: ОБУЧЕНИЕ, ПЛАНИРОВАНИЕ, ВЗАИМОДЕЙСТВИЕ и ЗАВЕРШЕНИЕ. Каждый этап включает в себя ряд мероприятий, которые вы должны выполнить, чтобы быть хорошо подготовленным к конкретному воркшопу. ОБУЧЕНИЕ ПЛАНИРОВАНИЕ ВЗАИМОДЕЙСТВИЕ ЗАВЕРШЕНИЕ 129 Модуль 5. Методы бизнес‑анализа: важное Рассмотрим, что входит в каждый этап. Прежде чем приступить к планированию воркшопа, подумайте о способах обучения. Не бывает двух одинаковых людей, и к каждому нужен индивидуальный подход. Обучение Стили обучения Существуют три основных стиля обучения. Первый стиль обучения — действие. Люди воспринимают новую информацию и учатся, выполняя действия, пробуют применить новую информацию или инструмент. Людям, предпочитающим такой стиль обучения, можно предложить испытать новый прототип или готовый к использованию пакет ПО, а также разыграть бизнес-процессы. Второй стиль обучения — иллюстрирование. В рамках этого стиля обучения люди полагаются на иллюстрации, например фотографии, чтобы быстро понять идею, а затем работать над деталями. Этот стиль позволяет представить схему концептуальной модели решения и общую картину того, как решение впишется в текущую бизнес-среду. Последний стиль обучения — это чтение. Некоторые люди могут понять новую информацию только после прочтения пояснительного документа или книги. Используйте этот стиль для раздаточных материалов, чтобы подкрепить понимание информации, которую вы сообщаете, и позволить участникам добавлять заметки рядом с соответствующими материалами. ЗНАНИЕ Принципы обучения Подход: Стили обучения: (A) Действие (I) Иллюстрация (R) Чтение (F) Полный (U) Полезный (S) Четко определенный (E) Побуждающий квзаимодействию Развитие проектной группы Опасения, которые необходимо развеять 130 СОВ ЕТ Часть I. Бизнес-анализ Чтобы запомнить стили обучения, вы можете использовать аббревиатуру AIR (action, illustration, reading). Готовьте материалы так, чтобы они соответствовали каждому из этих стилей — аудитория будет вовлечена, и вы добьетесь лучших результатов! Конечно, часто люди воспринимают сразу несколько стилей обучения. Скорее всего, на каждом воркшопе вы встретите людей, не отдающих предпочтения только одному стилю обучения. Поэтому представляйте материалы разными способами, чтобы оптимизировать взаимодействие людей. Например, вы можете занять людей раздаточными материалами, пока обсуждаете схемы с визуалами. Проиграйте пару бизнес-процессов в ролевых играх с учениками, которые воспринимают информацию через действия. Благодаря такому подходу каждый сможет обучаться предпочтительным способом хотя бы иногда. Развитие проектной группы Люди, с которыми бизнес-аналитик работает над проектом, могут стать членами проектной группы временно. Эта группа не связана с подразделениями, к которым принадлежат ее члены. У проектной группы есть свой жизненный цикл. Команда обычно проходит через несколько этапов, работая над проектом. Эти этапы — формирование, штурм, нормализация, выполнение и закрытие. О них сказано ниже. Вам необходимо понять эти этапы, чтобы быстро пройти первые три из них на первом воркшопе с группой. Второй и последующие воркшопы будут легче, если вы продолжите работать с той же группой. Формирование Члены группы встречаются впервые. Важно, чтобы они начали взаимодействовать. Руководитель группы (как правило, руководитель проекта) дает четкие и надежные рекомендации, чтобы члены группы чувствовали себя комфортно и хорошо понимали поставленные цели. Штурм Члены группы проявляют свою индивидуальность, объединяются с теми, кто разделяет их убеждения и ценности, и конкурируют за более высокое положение в группе. Руководитель команды призывает коллег изложить свои мысли для достижения консенсуса внутри группы. Модуль 5. Методы бизнес‑анализа: важное 131 Нормализация Члены группы находят общие цели. Руководитель группы определяет структуру группы, роли и обязанности каждого члена. Также он определяет процессы, которые необходимо выполнить для достижения запланированных целей. Чтобы быстрее перейти к выполнению, возьмите на себя роль руководителя и назначьте ответственного за каждое действие. Выполнение Члены группы совместно работают над достижением целей. Руководитель группы отступает на задний план, чтобы члены группы вели себя активнее. Обмен знаниями и честность становятся нормами внутри группы. Закрытие Группа достигла целей. Здесь важно признать вклад каждого члена в успех группы и убедиться, что все сотрудники вернутся в свои подразделения с позитивным настроением. СОВ ЕТ Любимый этап организатора — это выполнение, когда нужно просто осторожно направлять стейкхолдеров к цели. В дополнение к жизненному циклу группы вам необходимо знать следующие факторы, влияющие на воркшоп: • уровень участия (Кто ведущий? Какова очередь выступлений?); • взаимодействие (Кто с кем разговаривает? Присутствуют ли отдельные места для бесед (conversation islands)? Кто молчит?); • влияние (Кто пытается подавить других? Почему?); • атмосфера (Дружелюбная и открытая? Напряженная?); • сотрудничество (Кто поддерживает дискуссию? Достаточно ли сотрудничества?). Планирование Подход Давайте обсудим подход, который вы могли бы использовать. За годы практики я пришел к простому подходу, который назвал FUSE. 132 Часть I. Бизнес-анализ С самого начала я предоставляю участникам полный (full) обзор тем, которые будут затронуты на воркшопе. Так я формирую ожидания стейкхолдеров и структуру дальнейшей работы. Далее я планирую воркшоп так, чтобы обмен знаниями и идеями был полезен (useful) участникам. Для участников тема должна соответствовать их деловым интересам и быть четко определенной (specific). Удобный способ получения и распространения знаний должен побуждать (engaging) людей к открытому сотрудничеству и участию в воркшопе. СОВ ЕТ Чтобы запомнить ключевые шаги при планировании воркшопа, используйте аббревиатуру FUSE. Человек подобен айсбергу. Мы видим верхушку айсберга и не представляем, что скрыто под водой. Но скрытая область управляет поведением видимой части. Эмоции Мысли Убеждения Ценности Естественные потребности Страхи При общении с человеком необходимо учесть следующие факторы: • эмоции; • мысли; • убеждения; • ценности; • естественные потребности; • страхи. 133 Модуль 5. Методы бизнес‑анализа: важное Все они влияют на восприятие людей, их общение и понимание правильности своих решений. Обратите внимание на поведение и реакцию людей при личной встрече. Приложите все усилия, чтобы найти способы обойти возникающие барьеры. Выделите различные перспективы, обозначьте и рассмотрите проблемы людей, попытайтесь проникнуться их ценностями. Даже такая незначительная вещь, как холодная комната, может существенно повлиять на то, как люди с вами работают. Если им неудобно, они могут в течение всего воркшопа концентрироваться на своем дискомфорте, вместо того чтобы вносить свой вклад в работу. Поэтому так важно учитывать естественные потребности людей при планировании и проведении воркшопа. Помещение Этап планирования является основой хорошего воркшопа. Вам необходимо такое место для проведения воркшопа, которое легко сможет найти каждый участник. Забронируйте конференц-зал с возможностью размещения всех стейкхолдеров, которых вы хотите видеть на мероприятии. Схема помещения Схема помещения важна, потому что она может способствовать либо мешать взаимодействию. Продумайте расстановку столов и стульев, чтобы создать комфортную среду. ПЛАНИРОВАНИЕ Помещение Схема помещения Приветствие Основные правила Тема Сроки проведения Провокационные или вступительные вопросы Интересная история Цели(Goals) Подход(Approach) Обсуждение (Discussion) Взаимодействие(enGagement) Оценка(Evaluation) Завершение(Termination) «Перезарядка батарей» Резервный пакет идей Приветствие Составьте приветствие, которое создаст непринужденную обстановку с самого начала. Используйте приветствие, чтобы настроить людей на предстоящую дискуссию и побудить их оставить свой багаж (проблемы) 134 Часть I. Бизнес-анализ за пределами помещения. Попросите каждого представиться и рассказать о своих сферах деятельности и бизнес-знаниях. Основные правила Определите основные правила, которые помогут вам поддерживать порядок и следовать плану проведения воркшопа. Эти правила будут полезны, если придется прервать разговор между участниками. Тема или повестка дня Определите повестку(и) дня и представьте ее (их) аудитории. Изложите свои мысли кратко и доступно, чтобы обрисовать ментальную карту воркшопа участникам. Сроки проведения Определите сроки проведения воркшопа по возможности с помощником. Делайте заметки там, где может понадобиться дополнительное время на дискуссии. Создайте график работы воркшопа со всеми заметками, чтобы было удобнее придерживаться плана. Открытие воркшопа Чтобы помочь участникам настроиться на волну воркшопа, подумайте над вступительными вопросами, которые могут иметь провокационный характер. Они привлекут внимание в силу естественного человеческого любопытства. Касательно новых проектов может быть полезно подготовить рассказ, который передаст основную идею предстоящей темы или метафорически представит причину проведения воркшопа. План Б Запланируйте, как вы поступите, если обсуждение отклонится от повестки дня. Постарайтесь извлечь из такого момента дополнительную информацию, связанную с темой воркшопа. Например, вы хотите собрать требования, чтобы улучшить инструмент, но обсуждение ведет к улучшению процесса. Свяжите процесс и его шаги с инструментом, поддерживающий этот процесс. Все может оказаться лучше, чем вы представляли. СОВ ЕТ Рассмотрение и планирование возможных способов работы с изменениями первоначальной повестки дня всегда окупаются. Чтобы упростить подготовку и структурировать планирование воркшопа, предлагаю использовать аббревиатуру GADGET. Модуль 5. Методы бизнес‑анализа: важное 135 • Четко определите цели (goals), которые необходимо достичь. • Определите подход (approach) для проведения ворк­шопа. • Определите, как вы будете способствовать обсуждению (discussion). • Подумайте, как задействовать (engage) участников в ходе воркшопа. • Спланируйте, как вы будете оценивать (evaluate) результаты ворк­ шопа. • Определите варианты прекращения (termination) обсуждения запланированных тем. «Перезарядка батарей» Когда вы планируете провести воркшоп продолжительностью более 45 минут, подумайте о перерывах и двигательной активности, чтобы «перезарядить» участников. Перерывы необходимы для удовлетворения личных потребностей и для неотложных деловых звонков. Резервный пакет идей Совершенно нормально, что для ответов на некоторые вопросы требуется время. Лучший способ придерживаться графика — убрать в резерв/ отложить до лучших времен Основная идея такого пакета — собрать задачи, требующие дополнительных действий для их решения. С помощью него вы покажете участникам, что их вопросы замечены и их вклад ценится. СОВ ЕТ Включите в план воркшопа время, необходимое для перерывов и двигательной активности. Взаимодействие Авторитет Вовлекая окружающих в какое-либо дело, начинайте с себя. Будьте искренне заинтересованы в теме, которую обсуждаете. Это поможет вам продемонстрировать знания, полученные из собственного опыта или достоверных источников, подготовить примеры и выразить их доступно. Это повысит ваш авторитет. Развитие проектной группы Мы уже обсудили проектную группу в разделе «Обучение». Хочу поговорить об этом еще раз, потому что развитие группы может как помогать, так и мешать проведению воркшопа. 136 Часть I. Бизнес-анализ Основная цель воркшопа — создание синергии между участниками. Она реализуема только в дружественной обстановке. Следите за разногласиями и принимайте меры по предотвращению конфликтов между участниками. ВЗАИМОДЕЙСТВИЕ Покажите: Авторитет Развитие проектной группы: Участие Взаимодействие Влияние Атмосфера Синергия Применяйте: Простые сообщения Простой язык Действуйте: Мотивируйте Используйте эмоции Работайте сфильтрами Основывайтесь на приобретенном опыте Проверяйте новые знания Обсуждайте точки зрения Конфликты возникают по следующим причинам: • чьи-либо знания поставлены под сомнение; • кто-либо чувствует угрозу своему статусу или власти; • ощущение растущей рабочей нагрузки. Если конфликт произошел, ведите себя профессионально и спокойно — вы сможете работать эффективно, только если сохраните нейтралитет! Не вставайте на одну из конфликтующих сторон, вместо этого поймите причину разногласий и найдите приемлемое для обеих сторон решение. Если вы видите, что человек чувствует угрозу, успокойте его. Немного пошутите, чтобы разрядить ситуацию. Поощряйте взаимодействие между всеми участниками. Не оставляйте никого без внимания. Активно перенаправляйте вопросы тем, кто готов ответить. Узнайте мнение тех, кто молчит. Когда часть обсуждения завершена, спросите, не было ли что-то упущено, прежде чем перейти к следующей теме. Общие методики Не говорите в формальном академическом стиле. Используйте простой и понятный язык, исключающий двусмысленность. Выражайте эмоции, чтобы поддержать чью-то идею и побудить других участников на нее отреагировать (за или против). Модуль 5. Методы бизнес‑анализа: важное 137 Одна из проблем, с которой вы можете столкнуться, — фильтры. Фильтр представляет собой точку зрения одного субъекта встречи, которая настраивает вас отказаться от всего, что ей не соответствует. Например, носители фильтра считают ваши суждения основанными на неполной информации. Фильтры могут препятствовать распространению и принятию идей. Примерами фильтров являются мнения: «Все и так в порядке», «Системы ERP — это плохо», «IT-системы ограничивают меня» и т. д. Один из способов работы с фильтром — предложить другим участникам высказать свое мнение, чтобы подчеркнуть субъективность суждения. Другой способ — перестроить обсуждение, например направив его на преимущества для носителя фильтра или его коллег. Имейте в виду, что некоторые фильтры связаны с ценностями человека или его самовыражением. Если в ответ на ваши действия он станет сопротивляться и чувствовать себя притесненным, перестройте дискуссию, чтобы избежать такой реакции. Юмор очень полезен в дискуссиях. Он уменьшает напряжение при решении трудных задач или попытке достичь согласия, а также помогает избежать скуки. Но не злоупотребляйте им! Используйте юмор как отвлекающий прием, чтобы расслабить участников воркшопа, обсуждающих серьезную тему, создать синергию и чувство единства. Применяйте «резервный пакет идей» эффективно. Нередко в процессе обсуждения люди поднимают посторонние вопросы. Запишите хорошие предложения в резерв, чтобы обозначить их значимость. Однако выберите только те дополнения, которые относятся к запланированному обсуждению, чтобы не увязнуть в информации. Пресекайте посторонние разговоры Вежливо, но твердо прекращайте неуместные разговоры, поскольку они могут быстро сорвать дискуссию. Если вы их заметили, остановите основной разговор и обратитесь к участникам. Вы должны предоставить сторонникам беседы выбор: • если тема незапланированного разговора имеет отношение к основному обсуждению, обозначьте ее и дайте участникам возможность высказать свое мнение (возможно, на более позднем этапе); • если эта тема не относится к воркшопу, попросите участников остановить разговор и вернуться к нему во время перерыва. 138 Часть I. Бизнес-анализ Придерживайтесь графика Как долго будет идти воркшоп, всегда загадка, особенно когда вы новичок. Регулярно следите за временем. Когда вы видите, что двигаетесь слишком быстро или слишком медленно (как это часто случается на практике), соответствующим образом отрегулируйте темп встречи. Если вы уже получили ожидаемые материалы, подумайте о том, чтобы пропустить некоторые из запланированных действий. Всегда завершайте воркшоп вовремя. СОВ ЕТ Планируйте перерывы в соответствии с вашим расписанием. Завершение Заключительная часть воркшопа — это не просто формальность. Напротив, очень важно завершить воркшоп успешно. Ниже показаны основные шаги завершения. Итоги Обзор повестки дня и резюме проведенных обсуждений позволят участникам вспомнить воркшоп и сосредоточиться на следующих шагах. Оценка Оценка воркшопа вместе с участниками позволит удостовериться, что воркшоп соответствовал ожиданиям группы и запланированные цели достигнуты. Выделяйте хотя бы пять минут на оценку в каждом плане воркшопа. ЗАВЕРШЕНИЕ Итоги дискуссии Список действий: кто, что икогда Оценка: результаты vs. цели Последующие шаги Парковка: содержание Спасибо! Модуль 5. Методы бизнес‑анализа: важное 139 Резервный пакет идей Просмотрите содержимое резервного пакета идей, чтобы определить вопросы, требующие дальнейших действий, и распределите их между теми, кто может их решить. Подчеркните важность этих вопросов, поскольку они отражают вклад участников за пределами запланированной темы. Список действий Используйте список действий, чтобы напомнить о них участникам. Еще раз подчеркните, кто что должен делать и в какой срок. Последующие шаги Если ваш воркшоп был частью серии воркшопов, введите группу в курс дела о следующих встречах: чего ожидать, к чему готовиться. Определенность дает людям уверенность в своих действиях. Спасибо! Перед тем как завершить сеанс, не забудьте сказать «спасибо» всем участникам и выразить удовлетворение достигнутыми результатами. Не оставляйте людей в плохом настроении в конце воркшопа, потому что это настроение может перейти в следующий воркшоп с той же группой. Независимо от ваших собственных чувств относительно результатов мероприятия приложите усилия, чтобы стейкхолдеры уходили довольные. СОВ ЕТ Тщательно планируйте завершение воркшопа, чтобы стейкхолдеры не сбежали! После проведения воркшопа Прежде всего, поздравляю! Вы много узнали о том, как проводить успешные воркшопы. После завершения воркшопа задокументируйте собранную информацию и сообщите результаты основным стейкхолдерам (отправьте результаты стейкхолдерам из вашего списка рассылки). Через пару дней после воркшопа деликатно напомните людям о назначенных действиях и важности их вклада в достижение целей проекта. Пусть общение со стейкхолдерами остается активным, но не давите на людей, поскольку они совмещают работу над проектом со своими повседневными обязанностями. Когда все действия будут выполнены, напишите короткое сообщение всем стейкхолдерам. Сообщите им о достижении запланированных целей, о ключевых результатах, поблагодарите всех за помощь и ценный вклад. 140 Часть I. Бизнес-анализ Самопроверка Пришло время проверить, как вы усвоили терминологию и другие материалы. Отметьте вопросы, ответы на которые не вызовут у вас затруднения. Вопросы с пустыми полями потребуют повторения материала раздела. Из каких этапов состоит воркшоп? Назовите основные стили обучения. Через какие этапы развития проходит сформированная группа? Какие факторы влияют на качество воркшопа? Что делать, если люди задают вопросы, не связанные непосредственно с темой воркшопа? Что такое фильтр и как его обойти? Какие шаги следует предпринимать при завершении воркшопа? Какие действия необходимо выполнить после проведения воркшопа? Вы отметили все поля? Прекрасно, поздравляю! Применяйте полученные знания в изучении следующих разделов. Пусть постер на следующей странице служит вам карманным путеводителем, пока вы готовитесь к следующему воркшопу. Опасения, которые необходимо развеять Применяйте: Простые сообщения Простой язык Развитие проектной Действуйте: группы: Мотивируйте 3 Используйте эмоции Участие Взаимодействие Работайте сфильтрами Влияние Основывайтесь на Атмосфера приобретенном опыте Синергия Проверяйте новые знания Обсуждайте точки зрения Покажите: Авторитет ВЗАИМОДЕЙСТВИЕ Развитие проектной группы (F) Полный (U) Полезный (S) Четко определенный (E) Побуждающий квзаимодействию Стили обучения: (A) Действие (I) Иллюстрация (R) Чтение 1 Подход: Принципы обучения ЗНАНИЕ Парковка: содержание Оценка: результаты vs. цели Итоги дискуссии 4 Спасибо! Последующие шаги Список действий: кто, что икогда ЗАВЕРШЕНИЕ Помещение Цели(Goals) Схема помещения Подход(Approach) Приветствие Обсуждение (Discussion) Основные правила Взаимодействие(enGagement) Тема Оценка(Evaluation) 2 Сроки проведения Завершение(Termination) Провокационные или вступительные вопросы «Перезарядка батарей» Интересная история Резервный пакет идей ПЛАНИРОВАНИЕ Эффективный воркшоп Модуль 5. Методы бизнес‑анализа: важное 141 142 Часть I. Бизнес-анализ Пользовательская история Пользовательские истории (user story) — это самый популярный способ охватить первоначальные требования в Agile — гибкой методологии разработки. История представляет собой быстрый снимок желаемых возможностей, выраженных пользователем, который играет роль в бизнес-процессе. В отличие от традиционного подхода к разработке требований, пользовательские истории не требуют предварительной спецификации решения. Вместо этого они способствуют живому общению между клиентами и технической командой в процессе работы для поиска лучшего решения. Пользовательская история описывает клиентский опыт в конкретной роли. Эпик Пользовательская история Пользовательская история Пользовательская история Пользовательская история Пользовательские истории содержат достаточно информации для правильного планирования и оценки усилий, необходимых для разработки и тестирования требуемой функции. Рассмотрите, как пользовательские истории применяются в практике бизнес-анализа. Первоначальное общение со стейкхолдерами можно представить как серию эпиков (крупных этапов работы, которые можно разбить на несколько небольших заданий, epic), которая охватывает бˆольшую часть будущего решения и дает обзор бизнес-потребностей. Работая итеративно, бизнес-аналитик разбивает эпики на пользовательские истории, чтобы обеспечить более детальное планирование и оценку усилий, необходимых для разработки и тестирования каждой пользовательской истории. СОВ ЕТ Эпики определяют функциональные области желаемого решения. 143 Модуль 5. Методы бизнес‑анализа: важное Шаблон пользовательской истории Ниже представлен общий шаблон пользовательской истории с необходимой информацией. Я как <роль> использую <входные бизнес-данные> для выполнения <действий (действий бизнес-процессов)>, чтобы получить <выходные бизнес-данные, документы> в рамках <бизнес-процесса>. Желаемый результат можно получить после выполнения <условий>. Этот шаблон позволяет быстро получить целостное представление о бизнес-сфере. Каким образом? Посмотрите, что дает шаблон. • Роль определяет связи с другими ролями, применяемые средства связи и полномочия пользователей в рамках решения. • Бизнес-процесс дает ссылку на цепочку создания ценности внутри организации и способствует пониманию контекста, в котором выполняется процесс. • Использование входных бизнес-данных позволяет получить представление о потоках данных, используемых документах и моментах, когда данные становятся доступными (триггерах). • Выполнение действий вносит ясность в преобразование входных данных в выходные данные или элементы управления в пользовательском интерфейсе, необходимые для реализации требуемых действий. Данная часть истории также определяет пользовательский интерфейс (внешний вид). • Выходные данные дают нам представление о конечном результате бизнес-процесса (или одного из его этапов) и форме его представления. • Условия определяют измеримые критерии приемлемости, которые можно подтвердить тестированием встроенного решения. Должность ID Истории:0001 Роль Процесс Условия Входные данные Выполнение Заметки Применение Выходные данные <обратная сторона> 144 Часть I. Бизнес-анализ Хорошая практика • Используйте шаблон, позволяющий быстро обрабатывать собранную информацию. • Фиксируйте только ценную информацию, не записывайте каждое услышанное слово. • Больше размышляйте о роли пользователя, его действиях и используемых данных. • Добавляйте детали к истории итеративно. • Используйте ожидаемый пользовательский опыт (поведение решения) в своих интересах. • Сохраняйте истории в независимых блоках. • Используйте критерии приемлемости в своих интересах. ID Истории:0002 ID Истории:0003 ID Истории:0004 ID Истории:0005 ID Истории:0006 Модуль 5. Методы бизнес‑анализа: важное 145 Прецедент использования О прецедентах использования и их применении в бизнес-анализе написано много. Для разработки прецедентов использования, которые будут приносить пользу клиентам, необходимо понимание бизнес-контекста. Обсудим подход, позволяющий эффективно применять прецеденты использования и предоставлять бизнесу необходимые возможности. Подход уместен при внесении изменений в бизнес-процессы и поддерживающие бизнес-приложения. С чего начать? Ранее рассмотренные пользовательские истории — хорошая отправная точка для работы с прецедентом использования. В них определены действующие лица, их действия, входные данные, постусловия и как минимум лучший случай. Однако в пользовательских историях отсутствуют некоторые детали, необходимые для полной спецификации прецедента использования. Представьте, что проведена стартовая встреча по проекту, зафиксированы пользовательские истории и границы проекта прояснены. Цель руководителя проекта проста: своевременно выполнить работу в рамках бюджета проекта. Ваша задача — разработать прецеденты использования, быстро и качественно предоставить их в согласованные сроки. СОВ ЕТ Пользовательская история не охватывает обработку исключений, очень важную при разработке ПО. Возьмите завершенные пользовательские истории, чтобы зафиксировать имеющийся бизнес-контекст (бизнес-процессы и используемые программные средства). Затем разработайте модель прецедентов использования, в которой будут подробно описаны все прецеденты, попадающие в границы решения. Что дальше? Модель прецедентов использования Чтобы быстро двигаться вперед, используйте названия ранее созданных пользовательских историй для разработки модели. Сосредоточьтесь на действующих лицах и на том, что они хотят делать (глаголы) ради достижения своих целей. 146 Часть I. Бизнес-анализ UC1 UC2 UC3 Пользовательские истории UC4 UC5 Модель прецедентов использования Используйте разработанную модель прецедентов использования в качестве средства коммуникации со стейкхолдерами и специалистами в предметной области. С ее помощью они быстро укажут, какие моменты упущены, какие истории можно объединить, где сделаны ошибки, что нужно исправить, почему и каковы приоритеты для определенных прецедентов. Обновляйте модель прецедентов использования при получении обратной связи. Затем получите официальное утверждение на применение модели. СОВ ЕТ СОВ ЕТ Старайтесь объединять пользовательские истории в прецеденты, в которых одна и та же функциональность будет применяться разными действующими лицами. Применяйте модель, чтобы отчитываться о проделанной работе по прецедентам использования. Модуль 5. Методы бизнес‑анализа: важное 147 Спецификация прецедентов использования После заполнения модели прецедентов использования вы можете перейти к написанию их спецификаций. На этом этапе у вас должно быть четкое представление о взаимосвязях всех компонентов решения, порядке прецедентов использования и их зависимостей, входных и выходных данных, бизнес-правилах и времени их применения. С этого момента сложная задача становится проще. Разрабатывайте спецификацию прецедента использования, следуя структуре, представленной на схеме ниже. Определите лучший случай (из пользовательской истории) и его альтернативы. Обращайте внимание на проверку данных и фиксацию исключений, когда проверка не выполняется. Подумайте об атрибутах данных. Определите права доступа действующего лица. Нарисуйте экран пользователя, чтобы убедиться в отсутствии недоработок. Постарайтесь поставить себя на место пользователя и проверьте, все ли необходимые данные видны, а элементы управления расположены на экране эргономично и удобно. Спросите себя, будет ли комфортно работать с этим продуктом каждый день. Если нет, то пересмотрите его дизайн. СОВ ЕТ Не забывайте об интерфейсах! Распространенная ошибка бизнес-аналитиков заключается в том, что обычно они сосредоточены на описании взаимодействия пользователя с решением, а не решения — со своей средой. 148 Часть I. Бизнес-анализ Структура прецедента использования Заголовок прецедента использования _____ Идентификатор прецедента использования ______ Итоги прецедента использования: краткое описание функциональных возможностей Действующие лица: стейкхолдеры, выполняющие этапы в рамках прецедента использования Предусловия: триггеры событий и входные данные Основной поток: лучший случай Этап # | Описание | ссылка на бизнес-правила, если таковые имеются Альтернативный поток: <название> начинается с этапа # основного потока Этап # | Описание | ссылка на бизнес-правила, если таковые имеются Этап # | Вернитесь к этапу # основного потока ИЛИ перейдите к потоку исключений <название> Поток исключений: <название> Этап # |Обработка исключений| |Коммуникация с пользователем посредством сообщений на экране |Ссылка на бизнес-правила, если таковые имеются Этап # |Вернитесь к этапу # потока вызовов Постусловия: выходные данные и состояние компонентов решения Зависимости между прецедентами использования: ссылки на другие прецеденты использования Требования: Рыночные (внешние) требования, если таковые имеются Бизнес-правила Бизнес-требования | ссылка на рыночные правила / требования высокого уровня Функциональные требования | ссылка на бизнес-требования Коммуникация с действующим лицом (сообщения, уведомления электронной почты) Интерфейс пользователя (необязательно) Последовательность экранов Прототипы экранов Метаданные и значения данных Приложение СОВ ЕТ Совместите разработанные прецеденты использования с описаниями поддерживаемых бизнес-процессов, чтобы подтвердить целостность всего решения. 149 Модуль 5. Методы бизнес‑анализа: важное Анализ процесса В современных организациях люди взаимодействуют с бизнес-системами как структурированным, так и полностью динамическим образом, выполняя повседневные задачи. Задачи являются частями взаимосвязанных бизнес-процессов. Чтобы создать модель процесса «сверху вниз» (аналогично иерархической структуре), начните с описания функций высокого уровня, содержащих пулы процессов, затем определите процессы и их связи и, наконец, действия и их порядок внутри процессов. Функциональная декомпозиция — это метод, который позволяет разворачивать функции, а затем бизнес-процессы и действия в них. Почему? Гд е? а? гд Ко ? Что Кто? Для каждого действия укажите атрибуты, показанные на следующей схеме. Благодаря этим сведениям вы сможете эффективно общаться со стейкхолдерами. 150 Часть I. Бизнес-анализ Бизнес-функция Бизнес-процесс Действие Действие Бизнес-процесс Бизнес-процесс Действие Актер Действие Действие Бизнес-правила Действие Действие Обработка исключений Действие Действие Источник Назначение Событие Событие Ввод данных Действие Вывод данных Спецификация данных Спецификация данных Поддерживающие Шаги Добавленные Преобразование IT-услуги данные данных Действие 151 Модуль 5. Методы бизнес‑анализа: важное Отзывы (артефакты бизнес-анализа) Часто мне кажется, что все вокруг в курсе особенностей моего проекта. Но это не всегда так. У членов проектной группы создается общее представление о проектах, и не более того. Почему это имеет значение? Проходя жизненный цикл проекта, бизнес-аналитик работает с артефактами, описывающими различные требования: высокого уровня, бизнес-, функциональные и нефункциональные. Другой бизнес-аналитик (по возможности) или незаинтересованный бизнес-пользователь должен проверить артефакты бизнес-анализа перед отправкой ваших документов на утверждение. Это поможет вам убедиться, что ничего не упущено и расставлены точки над i. Покажите документы тем, кто мало знаком с вашими проектами. Обычно я использую следующую структуру отзыва для своих результатов по проектам: • проверка работоспособности; • мнение проектной группы; • анализ финансово-хозяйственной деятельности. Проверка работоспособности важна. Я начинаю собирать отзывы сразу после подтверждения требований: показываю документ коллеге, которому мало известно о проекте. После его первого отзыва сразу становится понятно, разъяснил ли я все используемые аббревиатуры и специальную терминологию, насколько четко я описал бизнес-проблему, возможное решение и т. д. Также проясняется целостность документа и качество его структуры. СОВ ЕТ Никогда не расстраивайтесь из-за отзывов и комментариев. Рецензенты оказывают вам услугу. Они помогают улучшить документацию. После доработки документа и получения одобрения от коллеги-рецензента я инициирую мнение проектной группы, чтобы убедиться, соответствуют ли мои документы результатам других членов группы. Их обратная связь бесценна, поскольку она позволяет мне: Бизнесутверждение Анализ финансово-хозяйственной деятельности Отзыв проектной группы Проверка работоспособности 152 Часть I. Бизнес-анализ • устранить любые обнаруженные проблемы, чтобы стейкхолдеры не сталкивались с ними; • обеспечить покрытие требований всей группой; • придерживаться стандарта качества проекта. Теперь я готов отправить документы бизнес-рецензентам, отзывы которых в основном будут направлены на уточнение требований. Собрав отзывы всех рецензентов, я провожу еще один бизнес-анализ с учетом их замечаний, а затем выпускаю окончательную версию документа для официального утверждения. СОВ ЕТ Не забывайте уведомлять всех стейкхолдеров об утверждении документов. Отправляйте утвержденные версии стейкхолдерам, включенным в списки рассылок. Установите временнˆые рамки для ответов. Электронные письма, которые я отправляю, выглядят примерно так: Уважаемый [имя стейкхолдера]! Благодарю вас за вклад в [название документа] на совещаниях. Пожалуйста, просмотрите прикрепленный [название документа] для [название проекта] и дайте обратную связь до [дата и время]. Если у вас возникнут вопросы, обращайтесь ко мне. Подтвердите, пожалуйста, документ, если у вас нет комментариев по содержанию. Обратите внимание, что предельный срок для подтверждения данного документа [дата и время]. С уважением, [ваше имя] СОВ ЕТ Установите для себя напоминание перед намеченной вами датой проверки или подтверждения, чтобы убедиться, что вы контролируете процесс. 153 Модуль 5. Методы бизнес‑анализа: важное Типы личностей Все люди разные, но у них все же есть общие сходства и различия, знание о которых поможет вам наладить общение и привлечь участников к бизнес-анализу. Как это сделать? При работе со стейкхолдерами применяйте иллюстрации, делайте заметки и используйте их позже для планирования подхода к взаимодействию с каждым типом личности. • Опирается на прошлый опыт • Медленно реагирует • Самоуверенный • Слабо вовлечен • Ищет логическое обоснование • Обращаться впоследнюю Последователь очередь Футурист • Смотрит вбудущее • Спешит действовать • Импульсивный • Мечтатель • Общительный • Действует водин клик • Ориентируется по ситуации • Нетерпеливый • Выносит наиболее важные аспекты на первый план • Обращаться впервую очередь • Энергичный Правитель Хороший парень СОВ ЕТ • Золотая середина • Ориентируется по ситуации • Всегда выслушает • Неконфликтный Имейте в виду, что некоторые люди сочетают в себе два и более типа личности, поэтому вам может потребоваться комбинация подходов к взаимодействию. 154 Часть I. Бизнес-анализ Соответствующий язык Стейкхолдеров можно классифицировать по ролям, под каждую из которых вам потребуется адаптировать язык общения: • конечные бизнес-пользователи; • специалисты в предметной области; • исполнители (любой уровень). Зачем общаться с разными стейкхолдерами по-разному? Дело в том, что сложность языка и контекста варьируется от аудитории к аудитории. Ваша способность настраиваться на аудиторию создаст эффективное общение и упростит работу. Общение с разными группами, построенное на их интересах, выглядит понятным и привлекательным. Конечных бизнес-пользователей интересует, как на их работу повлияет введение нового решения. Они обеспокоены изменениями текущего стабильного состояния, повседневной работой и ежедневной нагрузкой. Ваше общение с конечными пользователями должно вращаться вокруг этих тем. Используйте тот же язык и терминологию, которые применяют стейкхолдеры каждый день, постепенно добавляя новую терминологию. Так вы сделаете переход в будущее состояние более плавным. Говорите об этапах в рамках бизнес-процессов, интерфейсе пользователя и его функциях, способах улучшения текущего состояния. СОВ ЕТ Имейте в виду, что конечные пользователи часто не поддерживают изменения, поэтому обратите внимание на признаки сопротивления изменениям. Специалисты в предметной области — моя любимая аудитория. Они в курсе задач бизнес-пользователей, отраслевого делового оборота, внешних требований (в регулируемых отраслях), внутренних правил и эффективных подходов к пользовательскому опыту. Они видят в изменении возможность улучшить текущую ситуацию. Сосредоточьтесь на этих темах, когда вы общаетесь со стейкхолдерами. Вы можете использовать новую терминологию без особых разъяснений. Говорите об этапах изменения в контексте бизнес-процессов, сквозных бизнес-процессов, интерфейса пользователей, компонентов решения, бизнес-правил, способов улучшения текущего состояния, рыночных правил. Модуль 5. Методы бизнес‑анализа: важное 155 Руководители — интересная аудитория. Они сосредоточены на проблемах производительности, ключевых показателях эффективности, рентабельности и общем улучшении бизнес-процессов. Они видят в изменениях возможность улучшить свое положение внутри организации. Опять же это те темы, на которых вы должны сосредоточить свое общение с руководителями. Обычный язык с новой терминологией хорошо сработает. Говорите о бизнес-функциях высокого уровня, сквозных бизнес-процессах, границах решений (как указано в названиях прецедентов использования), рыночных правилах и преимуществах нового решения. Не забудьте упомянуть о собственной работе и проектной группе. Используйте возможность представить свою работу в хорошем свете. СОВ ЕТ СОВ ЕТ Всегда сопоставляйте информацию, полученную от специалиста в предметной области, с той, которую вы получили от конечного пользователя. Полезно знать информацию о руководителе. Иногда руководитель является бывшим специалистом в предметной области. 156 Часть I. Бизнес-анализ Оценка решения На этапе оценки решения бизнес-анализа основное внимание направлено на проверку того, чтобы утвержденные требования были выполнены, насколько это возможно. Это главное, но есть еще несколько проверок, которые я считаю бесценными во многих моих проектах. Подход показан на схеме ниже. Пригодность(Fit) Требования (Requirements) Согласованность (Alignment) Преимущества (Value) Инновации (Innovation) Пригодность Решение, которое предоставляет ваш проект, можно отнести к одной из трех категорий: • тактическое (патчинг неисправных деталей, замена устаревших деталей с минимальными затратами); • краткосрочное (охватывает текущие потребности и планирование для внедрения чего-то более стабильного в течение года или двух); • долгосрочное (предоставление новых возможностей на ближайшие два года — пять лет). Преимущества Решение должно покрывать бизнес-задачу. Но часто, приближаясь к решению, вы находите дополнительные вещи, которые еще больше улучшают текущее состояние. Рекомендуйте их стейкхолдерам как дополнительное преимущество и повышайте свой авторитет. Согласованность Помните, что ваш текущий проект функционирует в определенной среде. Если он согласован с другими проектами, запланированными инициативами и текущими изменениями внутри организации, вы Модуль 5. Методы бизнес‑анализа: важное 157 сможете скорректировать окончательное решение, обеспечив ему преимущество (см. разделы «Пригодность» и «Преимущества» выше). Инновации Иногда на старте проекта рассматривается единственная доступная технология. Тем не менее технологическое пространство сегодня стремительно развивается. Пока ваш проект продвигается, может появиться что-то новое и изменить всю концепцию решения. Также благодаря инновациям вы можете разработать новый способ выполнения некоторых задач, сэкономив время и повысив производительность. Модуль 6. АРТЕФАКТЫ БИЗНЕС‑АНАЛИЗА Введение............................................................................................ 159 6 Шаблоны бизнес-анализа..................................................160 План бизнес-анализа............................................................... 161 Анализ текущего состояния.............................................. 163 Экономическое обоснование......................................... 165 Концепция проекта.................................................................. 167 План управления требованиями................................ 168 Концепция решения............................................................... 170 Бизнес-требования....................................................................171 Модель прецедентов использования......................172 Спецификация прецедента использования......173 Разработка бизнес-процесса.......................................... 174 Нефункциональные требования..................................175 Глоссарий решения.................................................................. 176 Спецификация интерфейса.............................................. 177 Самопроверка...............................................................................180 Итоги.......................................................................................................180 Заметки................................................................................................ 182 Модуль 6. Артефакты бизнес‑анализа 159 Введение Новые agile-подходы к управлению проектами, в которых программный пакет является неотъемлемой частью решения, подразумевают передачу отзывов о рабочем решении непосредственно разработчикам вместо документирования. Эти подходы рассматривают документацию как замедление любого проекта. Тем не менее всегда хорошо документировать свои выводы, идентифицированные функции и требования (бизнес-, функциональные и нефункциональные) в той или иной форме. Преимущества документирования решений в том, что часто оно помогает быстрее выполнять задачи. Благодаря ему вы не потратите драгоценное время на изучение реализованного решения, упущенных функций во время последней реализации и дефектов, которые должен устранить текущий проект. Информацию, которая влияет на управление требованиями и общение со стейкхолдерами, лучше всего представлять в шаблоне. Бизнес-аналитик может выбрать метод сбора требований из методов, указанных в шаблоне плана управления требованиями. Шаблоны — это хороший инструмент коммуникации. Они представляют требования на разных уровнях детализации, и их можно использовать для целенаправленного общения с разными стейкхолдерами. Итак, рассмотрим ключевые шаблоны. СОВ ЕТ Требования необходимо документировать, чтобы решения не теряли экономической эффективности в процессе развития. СОВ ЕТ Вы можете редактировать указанные здесь шаблоны, чтобы отра­ зить характер вашего проекта и методологию, используемую для его выполнения. 160 Часть I. Бизнес-анализ Шаблоны бизнес-анализа Успех бизнес-аналитика зависит от нескольких факторов: знания предметной области, аналитических навыков, а также владения методами, навыками представления информации и документирования. Способность последовательно документировать результаты бизнес-­ анализа имеет решающее значение, особенно в средних или крупных компаниях. Крупная компания может потратить до 25 % времени, отведенного на проект, на бизнес-анализ. Повторное применение бизнес-требований и доступной документации из предыдущих проектов влияет на выбор решений и их представление в будущих проектах. Многие организации разрабатывают шаблоны для непрерывного представления информации и ее повторного использования. Шаблоны определяют, какая информация и на каком этапе проекта должна быть собрана и утверждена, чтобы решение о продолжения проекта было обоснованным. План управления требованиями План бизнес-анализа Наименование проекта: <xxx> Код проекта: <xxx> Анализ текущего состояния Наименование проекта: <xxx> Код проекта: <xxx> Наименование проекта: <xxx> Автор: <наименование> Код проекта: <xxx> Спецификация сценариев использования Статус: <xxx> Автор: <наименование> Видение решения Версия: <xxx> Статус: <xxx> Версия: <xxx> Наименование проекта: <xxx> Автор: <наименование> Наименование проекта: <xxx> Дата: Код проекта: <xxx> Статус: <xxx> Бизнес-требования Версия: <xxx> Код проекта: <xxx> Дата: Наименование проекта: <xxx> Автор: <наименование> Автор: <наименование> Статус: <xxx> Статус: <xxx> Версия: <xxx> Версия: <xxx> Код Дата: проекта: <xxx> Автор: <наименование> Статус: <xxx> Дата: Версия: <xxx> Дата: Дата: Модуль 6. Артефакты бизнес‑анализа 161 План бизнес-анализа План бизнес-анализа описывает порядок действий, которому будет следовать бизнес-аналитик в работе над проектом. В плане должны быть указаны: • рамки бизнес-анализа; • как и когда будут выполняться действия; • ожидаемые результаты действий; • допущения и ограничения при планировании. План также должен включать: • шкалу времени для бизнес-анализа; • продолжительность работы; • ключевые этапы достижения результатов; • отчеты о применении методов; • перечень ключевых стейкхоледров проекта; • матрицу связи со стейкхолдерами. Часто в организациях есть официальные или неофициальные стандарты, предписывающие, как выполнять бизнес-анализ и как его вписать в управление проектами. Моя практика показывает, что некоторые проекты не вписываются в существующие стандарты. В таких случаях шаблоны должны быть настроены в соответствии с требованиями проекта. Необходимо вместе со стейкхолдерами определить настройки шаблонов. Ниже приведено содержание плана бизнес-анализа. 162 Часть I. Бизнес-анализ Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. КОНТЕКСТ ПРОЕКТА................................... 5 2.1. ИСТОРИЯ ПРОЕКТА................................ 5 2.2. ЦЕЛИ ПРОЕКТА..................................... 5 2.3. ЦЕЛИ БИЗНЕС-АНАЛИЗА.......................... 5 2.4. РАМКИ РАБОТЫ БИЗНЕС-АНАЛИТИКА......... 5 2.5. ТО, ЧТО НЕ ВХОДИТ В РАМКИ................... 5 3. ПОДХОД.................................................. 6 4. ДАННЫЕ.................................................. 6 5. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 7 5.1. ДОПУСКИ............................................ 7 5.2. ОГРАНИЧЕНИЯ...................................... 7 6. ОЦЕНКА.................................................. 8 7. КЛЮЧЕВЫЕ СТЕЙКХОЛДЕРЫ......................... 9 8. МАТРИЦА КОММУНИКАЦИЙ.......................... 9 СОВ ЕТ Когда вы настраиваете шаблоны и ищете подход к бизнес-анализу, согласуйте изменения с руководителем и группой проекта, чтобы убедиться в возможности проведения изменений. 163 Модуль 6. Артефакты бизнес‑анализа Анализ текущего состояния Предположим, что проект был утвержден и руководитель проекта составил резюме проекта (project brief). С этого момента бизнес-аналитик может начинать сбор требований. Моя практика показывает, что лучший способ решить эту задачу — начать с анализа текущего состояния, чтобы понять потребности бизнеса, основные болевые точки, задействованные бизнес-процессы, роли стейкхолдеров в этих процессах и т. д. Текущее состояние может страдать от ярлыков предыдущего проекта, если прошлой проектной группе не хватило ни времени, ни денег, чтобы предоставить полное решение. Или необходима бизнес-реконструкция, чтобы догнать конкурентов: все в целом работает нормально, но требуются некоторые усовершенствования. Бизнес-функция Бизнес-процесс Бизнес-услуги IT-услуги IT-услуги IT-услуги Система Приложение Приложение Приложение Интерфейс Основной целью документа «Анализ текущего состояния» является представление текущего состояния организации на момент анализа: • существующие внешние и внутренние контексты; • краткая история проекта; • задействованные бизнес-процессы и бизнес-приложения; • роли стейкхолдеров в определенных бизнес-процессах. 164 Часть I. Бизнес-анализ В зависимости от характера проекта в документ можно включить некоторые компоненты базовой инфраструктуры. Важно перечислить ключевые болевые точки и задачи в определенных бизнес-процессах, а также указать области, требующие изменений. Содержание анализа текущего состояния представлено ниже. Содержание 1. ВВЕДЕНИЕ............................................... 3 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 3 1.2. УСЛОВИЯ............................................ 3 2. ТЕКУЩИЙ БИЗНЕС-КОНТЕКСТ....................... 3 2.1. ФУНКЦИИ И ПРОЦЕССЫ........................... 3 2.2. БИЗНЕС-УСЛУГИ.................................... 3 2.3. АНАЛИЗ СТЕЙКХОЛДЕРОВ........................ 3 3. БОЛЕВЫЕ ТОЧКИ....................................... 3 3.1. БИЗНЕС-ПРОЦЕССЫ................................ 3 3.2. БИЗНЕС-УСЛУГИ.................................... 3 4. РЕКОМЕНДАЦИИ........................................ 3 4.1. БИЗНЕС-ПРОЦЕССЫ................................ 3 4.2. ВЗАИМОДЕЙСТВИЕ СО СТЕЙКХОЛДЕРАМИ.... 3 4.3. БИЗНЕС-УСЛУГИ.................................... 3 Модуль 6. Артефакты бизнес‑анализа 165 Экономическое обоснование Этот документ «управляет» проектом, так как содержит причины, по которым проект выполняется. Экономическое обоснование оправдывает инвестиции денег, времени и ресурсов на уровне руководства. В нем также указаны преимущества, ожидаемые от проекта. Раздел Итоги составьте после остальных разделов. Опишите в нем бизнес-проблему, ее влияние на бизнес и то, как проект будет решать эту проблему. В разделе Предыстория уделите основное внимание выявленной проблеме, ее возникновению, а также последствиям, с которыми организация столкнется, если решение не будет найдено. Раздел Контекст проекта посвятите самому проекту, его целям и тому, что входит или не входит в его рамки. Включите в этот раздел список ожидаемых результатов и перечень стейкхолдеров, на которые может повлиять проект. Представьте целостную картину среды проекта в разделе Выполнение проекта, чтобы показать, как проект будет согласован с другими бизнес-инициативами. В разделе Бенчмаркинг уделите основное внимание подходам, с помощью которых другие организации решили аналогичные бизнес-проблемы. Так вы обоснуете выбранный подход к проекту. Трудно представить проблему с единственным решением. В разделе Альтернативы назовите все доступные варианты решения с оценкой их рисков и влияния на бизнес. Когда для каждого варианта будут определены риски, расскажите о них подробнее в разделе Оценка рисков и определите стратегии их снижения. В разделе Анализ затрат и преимуществ приведите финансовую оценку проекта в долгосрочной перспективе. Сравните преимущества и издержки предлагаемых и выбранных вариантов. После представления всей необходимой информации приведите рабочие варианты и их ключевые параметры в разделе Выводы и рекомендации. Назовите вариант, по которому проект будет продолжен, если будет одобрен. В крупных проектах может потребоваться обозначить фазы проекта и распределение ресурсов на фазу. В таких случаях составьте раздел Стратегия реализации. 166 Часть I. Бизнес-анализ В последний раздел экономического обоснования включите подписи ответственных стейкхолдеров и историю редакций документа. Содержание 1. ОТЧЕТ РУКОВОДИТЕЛЯ............................... 3 2. ИСТОРИЯ................................................ 4 2.1. ПРОБЛЕМА/ВОЗМОЖНОСТЬ...................... 4 2.2. ПРОБЛЕМА/ВОЗМОЖНОСТЬ...................... 4 3. КОНТЕКСТ ПРОЕКТА................................... 5 3.1. ПОСТАНОВКА ПРОБЛЕМЫ........................ 5 3.2. ОПИСАНИЕ ПРОЕКТА.............................. 5 3.3. ЦЕЛИ ПРОЕКТА..................................... 5 3.4. ГРАНИЦЫ ПРОЕКТА................................ 5 3.5. ТО, ЧТО НЕ ВХОДИТ В ГРАНИЦЫ ПРОЕКТА.... 5 3.6. ОЖИДАЕМЫЕ РЕЗУЛЬТАТЫ...................... 5 3.7. СТЕЙКХОЛДЕРЫ.................................... 6 4. ВЫПОЛНЕНИЕ ПРОЕКТА............................... 7 5. БЕНЧМАРКИНГ.......................................... 8 6. АЛЬТЕРНАТИВЫ........................................ 9 7. ОЦЕНКА РИСКОВ..................................... 10 8. АНАЛИЗ ЗАТРАТ/ПРЕИМУЩЕСТВ (CBA).......... 11 8.1. ДОПУЩЕНИЯ...................................... 12 8.2. ОГРАНИЧЕНИЯ.................................... 12 9. ВЫВОДЫ И РЕКОММЕНДАЦИИ..................... 13 9.1. ВЫВОДЫ........................................... 13 9.2. РЕКОММЕНДАЦИИ................................ 13 10. СТРАТЕГИЯ ВНЕДРЕНИЯ........................... 14 11. ЗАВЕРШЕНИЕ БИЗНЕС-СЛУЧАЯ................... 15 Модуль 6. Артефакты бизнес‑анализа 167 Концепция проекта Концепция проекта (project vision) — это документ, который доступен руководителю проекта и бизнес-аналитику. Они совместно работают над постановкой проблемы, принятием решений и оценкой эффективности проекта, определяют желаемое состояние. Документ содержит раздел с анализом стейкхолдеров, который определяет их обязанности и потребности. Бизнес-аналитик добавляет требования высокого уровня, которые входят в рамки проекта. Чтобы четко определить эти рамки, бизнес-требования высокого уровня, выходящие за пределы проекта, перечисляются в конце раздела. Документ является ключевым инструментом коммуникации при подтверждении целей проекта его спонсором и ключевыми стейкхолдерами. Основываясь на результатах анализа текущего состояния, бизнес-аналитик описывает существующий бизнес-контекст, ключевые бизнес-процессы и поддерживающие их службы. После этого он сопоставляет необходимые изменения с текущим бизнес-контекстом. Представьте это сопоставление в виде контекстной схемы, чтобы лучше понять связи предлагаемых изменений со стейкхолдерами. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. КОНТЕКСТ ПРОЕКТА................................... 5 2.1. ПОСТАНОВКА ПРОБЛЕМЫ........................ 5 2.2. ПОСТАНОВКА РЕШЕНИЯ.......................... 5 2.3. КРИТЕРИИ ПРИЕМЛЕМОСТИ..................... 5 2.4. АНАЛИЗ СТЕЙКХОЛДЕРОВ (RACIS).............. 6 3. ТРЕБОВАНИЯ ВЫСОКОГО УРОВНЯ.................. 7 3.1. ВХОДИТ В ГРАНИЦЫ............................... 7 3.2. НЕ ВХОДИТ В ГРАНИЦЫ........................... 7 4.1. ТЕКУЩЕЕ СОСТОЯНИЕ............................ 8 4.2. БУДУЩЕЕ СОСТОЯНИЕ............................ 8 168 Часть I. Бизнес-анализ План управления требованиями Этот артефакт управляет работой бизнес-анализа непрерывно. В нем описан подход для сбора и определения приоритетов и атрибутов требований. Он также определяет степень детализации требований и устанавливает взаимосвязи требований и прослеживаемости. Также описываются процессы управления изменениями и документами. Жизненный цикл требования Рассмотрите жизненный цикл требований в контексте плана управления требованиями, чтобы упростить понимание требований. Четкое объяснение жизненного цикла и того, какие этапы в нем способствуют общению со стейкхолдерами проекта, гарантирует, что при разработке решения будут точно использованы определенные требования. Фазы жизненного цикла требования Заявлено Требования описывают потребность бизнеса на высоком уровне. Они не ограничены, поскольку выражают точку зрения стейкхолдера и являются основой дальнейшего анализа. Подтверждено После первоначального анализа заявленных требований стейкхолдеры подтверждают их в обязательном порядке. Я называю это перекрестной проверкой, в то время как другие называют это проверкой работоспособности. Установлены приоритеты Требования могут проходить эту фазу несколько раз в течение жизненного цикла проекта. Я выполняю и заявленные, и подтвержденные требования, чтобы не пропустить важные. С точки зрения решения вы можете дать требованию характеристику: основное (без этого требования невозможно решение), критическое (требование по функциональности или процессу) и жизненно важное (требование пользователя). Эти характеристики помогут различать требования при общении с разными аудиториями. Упорядочено Выявить требования — это лишь половина работы бизнес-аналитика. Вторая половина — упорядочить отношения между требованиями, Модуль 6. Артефакты бизнес‑анализа 169 которые определяют прослеживаемость требований и их связь с компонентами решения. Разработано Проанализируйте требования с точки зрения архитектуры предприятия. Сопоставьте с ними существующие процессы, решения и интерфейсы, чтобы выявить новые возможности и компоненты многократного использования. Моделирование упростит общение с разными аудиториями, в том числе с поставщиками компонентов решения. Проверено Эта фаза важна, так как требования с этого момента считаются качественными и могут использоваться для реального построения решения. Утверждено Этап гарантирует, что усилия бизнес-аналитика не были напрасны: требования соответствуют новым возможностям и интерфейсам, а переход от текущего состояния к желаемому согласован с бизнес-целями. Просмотрено Чтобы подготовить требования для согласования, рассмотрите их со своими коллегами, а затем с ключевыми стейкхолдерами. Часто препятствием на заключительном этапе становится нарушение прослеживаемости, особенно в крупных проектах, где несколько бизнес-аналитиков работают над одними и теми же решениями. Согласовано Это заключительная фаза жизненного цикла, на достижение которой были направлены все усилия. Здесь требования организованы в пакеты, подходят для взаимодействия с различными стейкхолдерами, являются ясными и четкими. Эти требования станут ключом к построению решения. Содержание 1. ПРЕДИСЛОВИЕ.......................................... 4 1.1. ПРЕДПОЛАГАЕМАЯ АУДИТОРИЯ................. 4 1.2. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.3. АРТЕФАКТЫ БИЗНЕС-АНАЛИЗА.................. 4 2. ВВЕДЕНИЕ............................................... 6 2.1. ГРАНИЦЫ УПРАВЛЕНИЯ ТРЕБОВАНИЯМИ...... 6 2.2. НЕ ВХОДИТ В ГРАНИЦЫ........................... 6 3. УПРАВЛЕНИЕ ТРЕБОВАНИЯМИ....................... 7 3.3. ПРОСЛЕЖИВАЕМОСТЬ ТРЕБОВАНИЙ........... 7 3.4. РАСПРЕДЕЛЕНИЕ ИДЕНТИФИКАЦИОННЫХ ДАННЫХ..................................................... 8 4. ДОКУМЕНТИРОВАНИЕ ТРЕБОВАНИЙ............. 10 5. УПРАВЛЕНИЕ ДОКУМЕНТАЦИЕЙ................... 11 6. ПОВТОРНОЕ ПРИМЕНЕНИЕ ТРЕБОВАНИЙ........ 14 170 Часть I. Бизнес-анализ Концепция решения Как только документ «Концепция проекта» будет согласован, можно приступать к подготовке документа «Концепция решения» (solution vision). В нем бизнес-аналитик сначала кратко повторяет описание проблемы из концепции проекта. В описание решения он включает сведения о целевой аудитории, решения, удовлетворяемые потребности и ожидаемые выгоды. Также бизнес-аналитик указывает на отличие выбранного решения от возможных альтернативных вариантов. В целевую аудиторию решения включаются стейкхолдеры с указанием их ролей с помощью матрицы RASCI. Основная часть концепции решения — это подробный раздел, посвященный функциональным и нефункциональным возможностям решения, распределенным по приоритетам, заданным стейкхолдерами. Следующий раздел представляет будущее состояние бизнес-контекста. Создайте схему, иллюстрирующую ключевые изменения и дополнения к текущему состоянию, и кратко опишите предлагаемые изменения. Как и в концепции проекта, функции, выходящие за рамки проекта, перечислите в последнем разделе, но на одной странице с теми, которые будут реализованы. Содержание 1. ВВЕДЕНИЕ............................................... 2 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 2 1.2. УСЛОВИЯ............................................ 2 2. КОНТЕКСТ РЕШЕНИЯ.................................. 2 2.1. ПОСТАНОВКА ПРОБЛЕМЫ........................ 2 2.2. ОТЧЕТ О РЕЗУЛЬТАТАХ РЕШЕНИЯ.............. 2 2.3. АНАЛИЗ СТЕЙКХОЛДЕРОВ (RACIS).............. 2 3. ВОЗМОЖНОСТИ РЕШЕНИЯ............................ 2 3.1. ТО, ЧТО ВХОДИТ В ГРАНИЦЫ................... 2 3.2. ТО, ЧТО НЕ ВХОДИТ В ГРАНИЦЫ............... 2 4. КОНТЕКСТ РЕШЕНИЯ.................................. 2 4.1. ТЕКУЩЕЕ СОСТОЯНИЕ............................ 2 4.2. КАРТА ИЗМЕНЕНИЙ................................ 2 5. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 2 5.1. ДОПУСКИ............................................ 2 5.2. ОГРАНИЧЕНИЯ...................................... 2 Модуль 6. Артефакты бизнес‑анализа 171 Бизнес-требования В этом документе опишите текущие процессы и представьте достаточную информацию для описания бизнес-проблемы и того, как она вписывается в рамки проекта. В этом разделе повторяются выводы документа анализа текущего состояния, но здесь они согласуются с целями проекта. Бизнес-требования, которые будут удовлетворены решением, перечислите в разделе «В рамках». Бизнес-правила, применимые к описанным требованиям, представьте в отдельном разделе. Благодаря такому подходу стейкхолдерам будет проще изучить и подтвердить правила. Любые допущения и зависимости, выявленные в отношении бизнес-требований, перечислите в отдельном разделе. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. БИЗНЕС-ТРЕБОВАНИЯ................................. 5 2.1. ТЕКУЩИЙ БИЗНЕС-КОНТЕКСТ................... 5 2.2. БУДУЩИЙ БИЗНЕС-КОНТЕКСТ................... 5 2.3. БИЗНЕС-ПРАВИЛА.................................. 5 2.4. БИЗНЕС-ТРЕБОВАНИЯ (В ГРАНИЦАХ)........... 5 2.5. БИЗНЕС-ТРЕБОВАНИЯ (ВНЕ ГРАНИЦ)........... 6 3. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 7 3.1. ДОПУСКИ ........................................... 7 3.2. ОГРАНИЧЕНИЯ...................................... 7 172 Часть I. Бизнес-анализ Модель прецедентов использования В модели перечислите все возможные прецеденты использования в рамках проекта, дайте их краткое резюме, назовите субъекты, участвующие в каждом прецеденте, частоту использования прецедентов, время их запуска событий и два их возможных результата — успех и неудачу. Одним из ключевых атрибутов прецедента будет ссылка на требования высокого уровня и возможности, которые позволят установить их прослеживаемость. При внесении изменений в спецификации прецедентов использования не забудьте обновить соответствующую модель прецедентов использования. Содержание 1. ВВЕДЕНИЕ....................................................................... 2 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ..................................... 2 1.2. УСЛОВИЯ.................................................................... 2 2. ОБЗОР РЕШЕНИЯ............................................................... 2 2.1. АКТЕРЫ...................................................................... 2 2.2. ЗАДАЧИ...................................................................... 2 2.3. КОМПОНЕНТЫ РЕШЕНИЯ................................................. 2 2.4. ФУНКЦИОНАЛЬНЫЕ ОБЛАСТИ РЕШЕНИЯ.............................. 2 3. ДИАГРАММА СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ.............................. 2 4. СЦЕНАРИИ ИСПОЛЬЗОВАНИЯ................................................ 2 4.1. СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ <Id, наименование>.................. 2 4.2. СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ <Id, наименование>.................. 2 4.3. СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ <Id, наименование>.................. 2 4.4. СЦЕНАРИЙ ИСПОЛЬЗОВАНИЯ <Id, наименование>.................. 2 Модуль 6. Артефакты бизнес‑анализа 173 Спецификация прецедента использования В этом документе представлена более подробная информация о прецедентах использования, перечисленных в документе «Модель прецедентов использования». Каждая спецификация включает: • краткий обзор прецедента использования; • ссылку на функциональную область; • предусловия; • список действующих лиц; • основной поток; • альтернативные потоки; • потоки обработки изменений; • функциональные требования к решению; • прослеживаемость бизнес-требований; • рыночные и бизнес-правила, применимые к прецеденту; • пользовательский интерфейс, элементы управления, данные. Содержание 1. ВВЕДЕНИЕ...................................................................4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ.................................4 1.2. УСЛОВИЯ................................................................4 2. РЕЗЮМЕ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ................................5 3. ПОТОКИ СЦЕНАРИЕВ ИСПОЛЬЗОВАНИЯ...............................6 3.1. ОСНОВНОЙ ПОТОК.....................................................6 3.2. АЛЬТЕРНАТИВНЫЙ ПОТОК <наименование>....................6 3.3. АЛЬТЕРНАТИВНЫЙ ПОТОК <наименование>....................6 3.4. ПОТОК ИСКЛЮЧЕНИЙ <наименование>...........................6 3.5. ПОТОК ИСКЛЮЧЕНИЙ <наименование>...........................7 4. ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ......................................8 4.1. БИЗНЕС-ПРАВИЛА......................................................8 4.2. ТРЕБОВАНИЯ............................................................8 4.3. СООБЩЕНИЯ............................................................8 4.4. ИНТЕРФЕЙСЫ ПОЛЬЗОВАТЕЛЯ......................................8 5. ЭКРАНЫ......................................................................9 5.1. ЭКРАН <наименование>..............................................9 5.1.1. КОНФИГУРАЦИЯ ЭКРАНА............................................9 5.1.2. ЭЛЕМЕНТЫ ДАННЫХ..................................................9 5.1.3. НАВИГАЦИОННЫЕ ЭЛЕМЕНТЫ УПРАВЛЕНИЯ.....................9 174 Часть I. Бизнес-анализ Разработка бизнес-процесса В этом документе основное внимание уделите масштабам изменений бизнес-процессов: предоставьте подробную информацию о текущем бизнес-контексте, существующих бизнес-процессах и стейкхолдерах, участвующих в них. Также опишите будущее состояние: предлагаемые бизнес-процессы и будущую информационную среду. Подробно разберите новые процессы для стейкхолдеров и конечных пользователей. Возьмите из документа «Анализ текущего состояния» описание текущего состояния и согласуйте его с изменениями поддерживающих бизнес-услуг. Любые допущения и зависимости, выявленные в отношении изменений бизнес-процессов, перечислите в соответствующем разделе. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. ТЕКУЩЕЕ БИЗНЕС-СОСТОЯНИЕ...................... 5 2.1. ТЕКУЩИЙ БИЗНЕС-ПРОЦЕСС..................... 5 2.2. ИНФОРМАЦИОННАЯ СРЕДА....................... 5 2.3. СТЕЙКХОЛЕДРЫ.................................... 5 3. БУДУЩЕЕ БИЗНЕС-СОСТОЯНИЕ...................... 6 3.1. БУДУЩИЙ БИЗНЕС-ПРОЦЕСС..................... 6 3.2. НОВАЯ ИНФОРМАЦИОННАЯ СРЕДА............. 6 3.3. СТЕЙКХОЛДЕРЫ.................................... 6 3.4. ИЗМЕНЕНИЯ, ПРЕДЛОЖЕННЫЕ НА КАЖДУЮ РОЛЬ СТЕЙКХОЛДЕРА................... 6 4. ДОПУСКИ И ОГРАНИЧЕНИЯ.......................... 7 4.1. ДОПУСКИ............................................ 7 4.2. ОГРАНИЧЕНИЯ...................................... 7 Модуль 6. Артефакты бизнес‑анализа 175 Нефункциональные требования Этот документ составляется после того, как бизнес-требования, а также модели и спецификации прецедентов использования сформированы. Основная цель документа — представить качественную сторону решения. Интересен раздел «Паттерны использования», который показывает, как решение будет применимо в течение рабочего дня. Эта информация дает представление о бизнес-требованиях с нефункциональной стороны и помогает уточнить их по необходимости. Поскольку решения часто основаны на информационных технологиях, необходимо обратить внимание на устойчивость решения. Подходы к смягчению последствий катастроф и требования к восстановлению решений играют здесь важную роль. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 2. НЕФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ............... 5 2.1. ДОСТУПНОСТЬ...................................... 5 2.2. ПРОИЗВОДИТЕЛНОСТЬ........................... 5 2.3. ВОССТАНОВЛЕНИЕ................................. 5 2.4. БЕЗОПАСНОСТЬ..................................... 5 2.5. СВЯЗЬ/ВЗАИМОДЕЙСТВИЕ....................... 5 2.6. МАСШТАБИРУЕМОСТЬ............................. 6 2.7. ПОДДЕРЖКА........................................ 6 3. ПРИМЕНЕНИЕ РЕШЕНИЯ.............................. 7 3.1. ПОЛЬЗОВАТЕЛИ.................................... 7 3.2. ИНТЕРФЕЙСЫ....................................... 7 3.3. ШАБЛОНЫ/ПАТТЕРНЫ ИСПОЛЬЗОВАНИЯ..... 7 3.4. ШАБЛОН/ПАТТЕРН ПОДДЕРЖАНИЯ ФУНКЦИОНИРОВАНИЯ РЕШЕНИЯ....................... 8 3.5. ВЛИЯНИЕ ПРОСТОЯ НА РЕШЕНИЕ............... 8 4. ДОКУМЕНТАЦИЯ РЕШЕНИЯ........................... 9 5. ДОПУСКИ И ОГРАНИЧЕНИЯ........................ 10 5.1. ДОПУСКИ.......................................... 10 5.2. ОГРАНИЧЕНИЯ.................................... 10 176 Часть I. Бизнес-анализ В настоящее время редко встречается совершенно новое решение. Общей практикой является интеграция старого решения в существующую бизнес-среду. В документе «Нефункциональные требования» опишите интерфейсы с внутренними и внешними системами и решениями, данные, передаваемые между ними, их форматы и элементы. Если решение будет взаимодействовать с внешними системами, представьте образцы данных в приложениях. В решении должна быть предусмотрена не только бизнес-отчетность, но и мониторинг работы этого решения. Компоненты решения должны быть документированы в целях надлежащего использования решения. Требования к документации укажите в последнем разделе документа. Глоссарий решения Стейкхолдеры часто используют термины и профессиональный сленг в общении. Чтобы понять терминологию (вам она может быть не знакома), используйте глоссарий решения. Он поможет установить общую терминологию для проектной группы и ключевых стейкхолдеров в рамках решения. Эффективнее всего разделить решение на функциональные области, которые послужат небольшими областями знаний для стейкхолдеров проекта. Глоссарий будет ориентиром для всех предыдущих документов. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 Модуль 6. Артефакты бизнес‑анализа 177 Спецификация интерфейса Любое новое решение должно быть интегрировано в информационную среду организации. То есть решение или его компоненты должны взаимодействовать с другими системами и решениями. Каналы их связи часто называют интерфейсами. Шаблон спецификации интерфейса поможет вам описать все детали интерфейса. В первом разделе опишите компоненты, которые будут подключаться через интерфейс на высоком уровне. В следующем разделе опишите протокол для обмена данными. В разделе «Сообщения» опишите все сообщения, которые могут проходить через интерфейс. Раздел «Структура сообщений» нужно корректировать для каждого проекта. Распространенным экономичным способом обмена данными являются отправка и получение CSV-файлов. Шаблон содержит образец заголовка такого файла. Содержание 1. ВВЕДЕНИЕ............................................... 4 1.1. СООТВЕТСТВУЮЩИЕ ДОКУМЕНТЫ............. 4 1.2. УСЛОВИЯ............................................ 4 1.3. ДОПУСКИ И ОГРАНИЧЕНИЯ...................... 4 1.3.1. ДОПУСКИ . ......................................... 4 1.3.2. ОГРАНИЧЕНИЯ..................................... 5 2. ИНТЕРФЕЙС............................................. 6 2.1. АРХИТЕКТУРА....................................... 6 2.2. МЕТОДИКА ОБМЕНА ДАННЫМИ................. 6 2.3. ПЕРЕДАЧА СООБЩЕНИЙ И УСТАНОВЛЕНИЕ ПОСЛЕДОВАТЕЛЬНОСТЕЙ............................... 6 2.4. СТАНДАРТНАЯ СТРУКТУРА СООБЩЕНИЙ...... 6 2.5. ТИПЫ ДАННЫХ В СООБЩЕНИИ.................. 7 2.6. ПРАВИЛА ОБРАБОТКИ............................. 7 3. СТРУКТУРА ДАННЫХ.................................. 8 3.1. ТАБЛИЦЫ ДАННЫХ................................ 8 3.2. ТАБЛИЦЫ ЖУРНАЛОВ............................. 8 4. ОШИБКИ................................................. 9 4.1. ОБРАБОТКА ОШИБОК............................. 9 4.2. ЖУРНАЛ ОШИБОК.................................. 9 5. СРЕДА.................................................. 10 5.1. ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ................. 10 5.2. АППАРАТНОЕ ОБЕСПЕЧЕНИЕ................... 10 5.3. ТРЕБОВНИЯ К ВНЕШНЕЙ СИСТЕМЕ........... 10 178 Часть I. Бизнес-анализ Раздел «Правила обработки» посвятите проверке полученных файлов и их структуры, чтобы для обновления соответствующих таблиц данных использовались только корректные и проверенные данные. Обмен данными с внешними системами часто требует указания названий файлов, содержащих определенную информацию, дату и время. Для документирования соглашений по этому вопросу используйте раздел «Соглашения о названиях». В разделе «Структура данных» опишите таблицы данных в качестве источника бизнес-данных для отправки и получения сообщений. Чтобы вести контрольный журнал, опишите использование таблиц журналов. В разделе «Ошибки» поместите информацию о кодах ошибок, их причинах и протоколировании ошибочных записей по необходимости. В последнем разделе опишите требования к внешней системе и программному и аппаратному обеспечению, необходимому для реализации интерфейса. SDLC NFR GUI - - - - - - IT- - - - - - - Артефакты бизнес-анализа 180 Часть I. Бизнес-анализ Самопроверка Пришло время проверить, как вы усвоили определения и детали. Уделите несколько минут, чтобы проставить галочки рядом с теми пунктами, которые вам понятны. Вопросы с пустыми чекбоксами будут служить картой отображения изложенного материала. Что определяет рамки бизнес-анализа? Что является первым результатом бизнес-аналитика? Что не касается изменений в программных инструментах? Что содержит терминологию решения? Что содержит требования высокого уровня? Что содержит необходимые возможности решения? Вы поставили галочки во всех чекбоксах? Молодцы, поздравляем! Итоги Вы завершили первый этап своего путешествия в бизнес-анализ. Поздравляю! Надеюсь, вы приобрели много знаний, идей и полезных навыков для подъема по карьерной лестнице. Бизнес-анализ применим к огромному разнообразию проектов, поэтому всегда продолжайте учиться. Одна из целей книги — дать вам направление для дальнейших исследований. Разумно подходите к выбору того, что намереваетесь начать, а затем работайте над этим. Совершенствуйтесь! Желаю удачного путешествия! Начните делать то, что можете, или то, о чем мечтаете. Действуйте прямо сейчас! Иоганн Вольфганг фон Гете Модуль 6. Артефакты бизнес‑анализа 181 182 Часть I. Бизнес-анализ Заметки _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ Часть II За пределами бизнес-анализа Модуль 7. Архитектура предприятия.................................................................... 186 Модуль 8. Управление проектом.............................................................................. 198 Модуль 9. Управление IT-услугами..........................................................................215 Модуль 10. Управление безопасностью.............................................................227 Модуль 11. Регулирование..............................................................................................240 Модуль 12. SDLC........................................................................................................................255 Ч II 184 Часть II. За пределами бизнес-анализа Введение Навигатор Бизнес-Анализа Теперь, когда мы обсудили сам бизнес-анализ, пришло время повторить основной посыл этой книги: аналитик должен быть подкован не только в бизнес-анализе, но и в других дисциплинах. Разберитесь в управлении проектами, архитектуре предприятия, управлении услугами, управлении безопасностью и регулировании. Благодаря знаниям в этих областях вы будете лучше подготовлены к выполнению своих обязанностей и станете ценным членом проектной группы. Ваш голос услышат, ваше мнение будет иметь значение, а ваше сотрудничество с стейкхолдерами проекта станет более эффективным. Понимание IT-услуг, управления операциями и жизненного цикла разработки ПО поможет вам общаться с IT-персоналом и командой разработчиков вашей организации. Вы увидите, какими могут быть технические подводные камни и каким образом будет внедрено решение. Но это еще не все преимущества. Знания улучшат ваши коммуникативные возможности, потому что вы сможете общаться с разными стейкхолдерами, используя привычную им терминологию. Кроме того, вам будет легче выполнять анализ, если вы рассмотрите проблему с разных точек зрения. Архитектура предприятия Управление проектом Регулирование Жизненный цикл разработки программного обеспечения Бизнесанализ Управление IT-услугами Управление безопасностью Часть II. За пределами бизнес-анализа 185 Путешествовать по «терра инкогнита» лучше с экскурсией, чем самостоятельно. Aotea Studios ЧАСТЬ II ЗА ПРЕДЕЛАМИ БИЗНЕС‑АНАЛИЗА Модуль 7. Архитектура предприятия Модуль 8. Управление проектом Модуль 9. Управление IT-услугами Модуль 10. Управление безопасностью Модуль 11. Регулирование Модуль 12. SDLC Модуль 7. АРХИТЕКТУРА ПРЕДПРИЯТИЯ Архитектура предприятия................................................. 187 7 Архитектура предприятия глазами бизнес-аналитика......................................................................190 Точки анализа................................................................................190 Принципы архитектуры предприятия.................... 192 Фреймворки архитектуры предприятия.............. 193 187 Модуль 7. Архитектура предприятия Архитектура предприятия Несомненно, вы слышали о термине «архитектура предприятия» (EA, еnterprise аrchitecture). Я делю термин на две части: «предприятие» и «архитектура». Давайте посмотрим, к чему относится каждая часть. Термин «предприятие» описывает организацию и ее структурные подразделения или группу организаций, которые стремятся к общим целям и совместно разрабатывают конкретные продукты и услуги для клиентов. На сегодняшний день термин «архитектура» применяется к различным типам организаций независимо от их размера, формы собственности, операционной модели или географического положения. Он описывает «экосистему» организации, которая включает людей, информацию, процессы и технологии. Высокий уровень архитектуры предприятия можно представить как концептуальный план, определяющий структуру и деятельность организации. Подход к архитектуре предприятия Архитектура предприятия согласовывает сложность бизнеса и сложность технологий и обеспечивает устойчивое функционирование организации. Aotea Studios Архитектура предприятия задает следующие вопросы для решения проблемы изменения текущего состояния организации: • Чем вызвано изменение? • Каков характер изменения? • Как и на что изменение повлияет? • Как изменения вписываются в «экосистему» организации? • Какие новые возможности требуются? • Когда требуются новые возможности? • Как изменения согласуются с руководящими принципами организации (бизнес-и технологическими целями)? 188 Часть II. За пределами бизнес-анализа Точки зрения архитектуры предприятия Архитектура предприятия рассматривает «экосистему» организации со следующих точек зрения: • бизнес-архитектура; • архитектура приложений; • информационная архитектура; • технологическая архитектура. Бизнес-архитектура Бизнес-архитектура согласовывает операционную модель, стратегии и цели предприятия с его информационно-технологическими возможностями. Архитектура приложений Архитектура приложений обеспечивает сервис-ориентированное представление организации, которое объединяет бизнес-функции с технологическими услугами и вспомогательными процессами. Информационная архитектура Информационная архитектура описывает все подвижные части эффективного управления информацией по всей организации и охватывает качественный обмен информацией между ролями, выбранными верно и вовремя. Технологическая архитектура Технологическая архитектура описывает, как организована и структурирована технологическая инфраструктура, и сводит к минимуму нарушения в работе организации. Модуль 7. Архитектура предприятия 189 Перспективы архитектуры предприятия Рассматривая «экосистему» организации с нескольких точек зрения, архитектура предприятия предоставляет требуемый уровень детализации: • бизнес-функций; • моделей процессов; • модели технологического процесса; • информационных систем и их функций; • модели технологической инфраструктуры; • информационной модели организации; • интерфейсов с «экосистемой» организации. 190 Часть II. За пределами бизнес-анализа Архитектура предприятия глазами бизнес-аналитика Бизнес-аналитик рассматривает «экосистему» организации с точки зрения архитектуры предприятия, чтобы получить как можно больше информации, выявить и четко определить требования, а также обеспечить необходимые бизнес-результаты. Приведенная ниже схема поможет вам задать подходящие вопросы о масштабах изменений. Внешняя cреда (экосистема) Отрасль производства Бизнес-единицы Отделы/команды Организация Заинтересованные стороны Функции Бизнес-функции Бизнес-процессы Деятельность Процессы Роли Бизнес-объекты События Бизнес-данные Бизнес-данные Потоки данных Данные о данных Преобразование данных Услуги обеспечивающих систем Услуги Безопасность Приложения Компоненты Сети Интерфейсы Хранилища данных Системное ПО Системы Инфраструктура Безопасность Устройства Виртуальная/физическая среда Протоколы передачи данных Точки анализа Я применил точки зрения архитектуры предприятия к бизнес-анализу и составил схему, которая помогает выявить точки анализа (analysis points), а затем указать требования для устранения обнаруженных болевых точек. AP - LAN/WAN GUI AP - A AP AP AP - AP э - AP - AP C AP п б - - 192 Часть II. За пределами бизнес-анализа Принципы архитектуры предприятия При сборе требований бизнес-аналитики применяют следующие принципы архитектуры предприятия: • целостность; • конфиденциальность; • доступность; • подход «встроенная безопасность» (security by design); • повторное применение; • оперативная совместимость; • технология «включай и работай» (plug-n-play); • виртуализация; • стандартизация; • масштабируемость; • сбор данных и обмен данными; • обмен данными в реальном времени; • возможность автоматизации; • соответствие требованиям (внутренним, внешним); • аварийное восстановление. Модуль 7. Архитектура предприятия 193 Фреймворки архитектуры предприятия СОВ ЕТ Посетите веб-сайт www.zachman.com для дополнительной информации. Существует несколько фреймворков архитектуры предприятия. Самыми популярными являются: • модель Захмана™; • фреймворк TOGAF (the open group architecture framework); • архитектура федерального предприятия (FEA, federal enterprise architecture). Модель Захмана™ Джон Захман провел аналогию между строительной отраслью и миром информационных технологий, чтобы объяснить сложность последнего. Архитектурные артефакты этой отрасли организованы в двух измерениях. В первом измерении находятся различные участники. Для каждого из них архитектор разрабатывает артефакты, каждому из них нужна полная информация, но все участники воспринимают полный объем по-разному. Например, владельцу требуется полное описание особенностей здания и его эстетики, тогда как строителю нужны все технические характеристики материалов и порядок строительства. Второе измерение определяет аспекты, по которым можно гарантировать полноценность строительных артефактов. Назовем эти аспекты что, как, где, кто, когда и почему. Второе измерение не зависит от первого, и все участники должны воспринимать его одинаково. Ответы на вопросы-аспекты зависят от того, кто их задает. Модель Захмана™ — это матрица размером 6 × 6, в строках которой расположены шесть точек зрения: • границы организации (контекстная точка зрения) — для планировщика; • точка зрения со стороны бизнес-модели (концептуальная) — для владельца; • системная (логическая) точка зрения — для проектировщика; • технологическая (физическая) точка зрения — для строителя; • точка зрения детального представления (вне контекста) — для субподрядчика; • точка зрения функционирующей организации. 194 Часть II. За пределами бизнес-анализа Данные Что Функции Как Сеть Где Люди Кто Время Когда Мотивация Почему Цель/рамки (контекст) Роль: планировщик Список важных понятий и объектов в бизнесе Список бизнеспроцессов Список мест расположения бизнеса Список важнейших организаций Список событий Список бизнес-целей и стратегий Модель предприятия (концептуальная) Роль: владелец Концептуальная модель данных/ объекта Модель бизнеспроцессов Система бизнеслогистики Модель потока работ Мастерплан реализации Бизнес-план Системная модель (логическая) Роль: конструктор, архитектор Логическая модель данных Архитектурная модель системы Модель распределенной архитектуры Архитектура интерфейса пользователя Структура процессов Модель бизнесправил Технологическая модель (физическая) Роль: проектировщик Физическая модель данных/классов Технологическая модель разработки Технологическая архитектура Архитектура презентации Структура управления Правила разработки Детали реализации (вне контекста) Роль: разработчик Описание структуры данных Программа Архитектура сети Архитектура безопасности Архитектура временных привязок Спекуляция правилами Работающее предприятие Роль: пользователь Используемые данные Работающие функции Используемая сеть Функцио­ нальная организация Применяемый график Рабочая стратегия В колонках представлены шесть следующих вопросов-аспектов: • описание данных — Что? • описание функциональности — Как? • описание размещения компонентов — Где? • описание участников и ролей — Кто? • описание времени — Когда? • описание мотивации — Почему? Фреймворк представляет исчерпывающую логическую структуру моделей или артефактов проектирования любого сложного организационного объекта. Сила этого фреймворка в том, что он дает структурированное представление об организации, которое позволяет описывать и анализировать все ее элементы. Также с помощью фреймворка вы можете сосредоточиться на выбранных аспектах организации, не теряя из вида общий контекст организации. При проектировании и создании сложных корпоративных систем присутствует слишком много деталей и связей, которые нужно учесть одновременно. С точки зрения бизнес-анализа фреймворк облегчает понимание организационной структуры, бизнес-функций и процессов, бизнес-данных в этих процессах, а также ролей стейкхолдеров и их взаимодействие в организации. 195 Модуль 7. Архитектура предприятия Фреймворк TOGAF • Бизнес-архитектура описывает бизнес-процессы, используемые для достижения целей. • Архитектура приложений описывает разработку и взаимодействие определенных приложений. • Архитектура данных описывает организацию корпоративных хранилищ и доступ к ним. • Техническая архитектура описывает оборудования и ПО, которые поддерживают работу приложений. Архитектура бизнеса Архитектура приложений Архитектура данных Техническая архитектура Метод разработки архитектуры (ADM, architecture development method) — самая важная часть TOGAF, из-за чего я считаю TOGAF архитектурным процессом, а не фреймворком (как описывает его архитектурная группа The Open Group) или методологией (как он описан в ADM). TOGAF рассматривает мир архитектуры предприятия как архитектурные описания, начиная от общих и заканчивая специфическими. ADM TOGAF обеспечивает процесс перехода от общего к частному. Согласно TOGAF, все архитектурные описания включены в концепцию континуума предприятия (Enterprise continuum). Второе, наиболее общее архитектурное описание называется базовой архитектурой (Foundation architectures). Следующий уровень — Common systems architectures. Четвертый набор архитектурных описаний называется архитектурой предприятия (Industry architectures). Наконец, TOGAF называет некий специфический уровень архитектурой предприятия. Континуум предприятия Фундаментальные архитектуры Архитектуры Организаций организаций Общесистемные архитектуры Отраслевые архитектуры 196 Часть II. За пределами бизнес-анализа ADM описывает фазы создания архитектуры предприятия. Они перечислены ниже: ФАЗА A Видение архитектуры ФАЗА B Архитектура бизнеса ФАЗА C Архитектура информационных систем ФАЗА D Технологическая архитектура ФАЗА H Управление изменениями в архитектуре ФАЗА G Управление реализацией ФАЗА F Планирование перехода ФАЗА E Возможности и решения Фреймворк TOGAF обеспечивает процессу создания архитектуры предприятия гибкость. Фазы могут быть реализованы не полностью, пропущены, объединены, переупорядочены или изменены, чтобы соответствовать вашей ситуации. Согласно его собственному стандарту, TOGAF — «архитектурно-агностический» фреймворк. TOGAF описывает, как создать архитектуру предприятия с помощью набора четко определенных этапов, но не дает указаний, как сделать эту архитектуру лучше. С точки зрения бизнес-аналитика, метод ADM направлен на поиск требований, которые нужно удовлетворить, и способов перехода от текущего состояния к будущему. Архитектура федерального предприятия FEA объединяет в себе комплексную таксономию предприятия (модель Захмана) и архитектурный процесс (TOGAF). FEA состоит из пяти эталонных моделей: • модель бизнеса; • модель услуг; • модель компонентов; • техническая модель; • модель данных. 197 Модуль 7. Архитектура предприятия Служебный сегмент Основная задача Служба предприятия Согласно FEA, предприятие представляет собой набор сегментов — основных направлений бизнеса, которые разделяются на два типа: сегменты основной миссии и сегменты бизнес-услуг. Сегмент основной миссии является одним из центральных элементов миссии и цели организации. Служебный сегмент является основой многих организаций. В дополнение к этому существует еще один вид услуг — корпоративная служба. Это четко определенная функция, которая находится на пересечении границ внутри организации. С точки зрения бизнес-анализа фреймворк FEA помогает подробно описать необходимые компоненты будущего состояния. Модуль 8. УПРАВЛЕНИЕ ПРОЕКТОМ Управление проектом............................................................ 199 Окружение управления проектом............................ 202 8 Совместное управление проектом...........................204 Метод управления проектом..........................................208 Матрица ответственности................................................... 210 Взаимодействие с участниками....................................212 199 Модуль 8. Управление проектом Управление проектом Современный фреймворк управления проектами PRINCE2*® использует гибкий и регулируемый подход к проектам разного типа и масштаба. Он обеспечивает надежное управление и своевременное принятие решений, даже когда показатели времени, качества или стоимости не соответствуют установленным допустимым значениям. Фреймворк PRINCE2® хорошо функционирует с такими современными подходами к решению задач, как Agile и Scrum, так как он направлен на доставку продукта. Фреймворк легко поддерживает короткие итерации и поэтапную доставку компонентов продукта. УПРАВЛЕНИЕ ПРОГРАММЫ УПРАВЛЕНИЕ ПРОГРАММОЙ Обнаружение потребностей РУКОВОДСТВО РУКОВОДСТВО И УПРАВЛЕНИЕ И УПРАВЛЕНИЕ ПРОЕКТОМ ПРОЕКТОМ Мандат Мандат проекта Проекта Утверждение проекта Проекта Утверждение этапов проекта ПРЕДОСТАВЛЕНИЕ ПРОДУКТА ПРОДУКТА Краткое изложение Проекта проекта ПРЕДВАРИПРЕДВАР ИТЕЛЬНЫ ТЕЛЬНЫЙ Й ЗАПУСК ЗАПУСК ЗАПУСК ЗАПУСК Планирование следующего Этапа этапа УПРАВЛЕНИЕ УПРАВЛЕНИЕ ГРАНИЦАМИ ГРАНИЦАМИ ЭТАПОВ ЭТАПОВ ИНИЦИАЦИЯ ИНИЦИАЦИЯ Отчёт Отчет оо закрытии Проекта проекта ЗАКРЫТИЕ ЗАКРЫТИЕ УПРАВЛЕНИЕ ЭТАПАМИ ПЛАНИРОВАНИЕ ПЛАНИРОВАНИЕ Привлечение Привлечение бизнес-аналитиков Бизнес -аналитиков СОВ ЕТ Контроль этапов, доставка продукта и рамки управления этапами воспроизводят спринты Agile/Scrum при разработке ПО. * Managing Successful Projects with PRINCE2 («Управление успешными проектами при помощи PRINCE2»), OGC, Edition 2009, ISBN-13: 9780113310593. 200 Часть II. За пределами бизнес-анализа Как бизнес-аналитик в документации по управлению проектами вы стараетесь найти доступные артефакты, которые помогут вам выполнить работу. Ключевыми артефактами являются: • бизнес-потребность; • резюме проекта (project brief); • подход к проекту; • финансово-экономическое обоснование; • план коммуникаций (сommunication plan); • план проекта (с учетом планов каждого этапа); • рабочие пакеты (work packages). Будьте уверены, что прочтете документы, содержащие информацию об этих артефактах, поскольку они служат основой вашего планирования и взаимодействия со стейкхолдерами. Другие артефакты будут созданы на более позднем этапе по мере продвижения проекта. Документы, создаваемые и доступные на каждом этапе проекта, показаны ниже. Рассмотрим, как управление проектом взаимодействует с бизнес-анализом. Ниже приведена карта, показывающая сосуществование этих двух дисциплин. Как видите, между двумя дисциплинами есть четкие связи. Информация, связанная с проектами, служит вкладом в бизнес-анализ. По мере продвижения проекта между этими двумя дисциплинами начинается обмен информацией, обогащающий картину текущего и будущего состояний, возможных вариантов, существующих препятствий и ограничений. - - ф э Управление жизненным циклом требований Планирование и мониторинг бизнес-анализа - - 202 Часть II. За пределами бизнес-анализа Окружение управления проектом Я говорю об управлении проектами и бизнес-анализе как о двух тесно связанных дисциплинах. Думаю, вы догадались, что управление связано еще со многими дисциплинами. Окружение управления проектом сложное. Управление проектом функционирует в более обширной среде, чем сам проект. Поскольку современные организации в значительной степени полагаются на технологии и могут придерживаться правил в своей отрасли, они должны управлять технологическим ландшафтом (ITIL), разрабатывать новые решения (жизненный цикл разработки системы) и согласовывать их с существующей бизнес-средой (архитектурой предприятия) и процессами (управлением бизнес-процессами). Рассмотрите схему далее. СОВ ЕТ Более подробную информацию о различных дисциплинах вы найдете в других модулях книги. Четкое понимание управления проектами, его методов и связи с другими дисциплинами повысит эффективность вашего сотрудничества со стейкхолдерами для достижения целей проекта. EA - (BPM) - Управление жизненным циклом требований Планирование и мониторинг бизнес-анализа Промышленный контекст UAT & QA Бизнес-анализ ITIL BPM SDLC 204 Часть II. За пределами бизнес-анализа Совместное управление проектом Уверен, вы сталкивались со множеством бурных дискуссий о взаимоотношениях между руководителем проекта и бизнес-аналитиком. Такие обсуждения чаще ведутся о разногласиях сторон, а не о взаимных усилиях, направленных на успех проекта. Я склонен верить, что оба специалиста должны работать над проектом вместе, поскольку «одна голова — хорошо, а две — лучше». Сложность проектов со временем только растет, ведь необходимость изменения бизнес-процессов обусловлена заменой устаревших бизнес-приложений, IT-инфраструктуры и интерфейсов. За последние двадцать лет я участвовал в более чем 60 проектах разного масштаба и характера. И в каждом из них руководитель проекта и бизнес-аналитик были двумя сторонами одной медали. Их навыки и совместные усилия приносили успех проекту и бизнесу. Хотел бы продемонстрировать, как они работали над проектом, и более подробно изучить каждый этап проекта. Запуск проекта Руководитель проекта и бизнес-аналитик работают со стейкхолдерами на протяжении всего жизненного цикла проекта. Перед стартом руководитель проекта узнает у спонсора проекта и стейкхолдеров бизнес-потребности высокого уровня. Результатом этого взаимодействия становится документ «Инициирование проекта», в котором описаны бизнес-потребности, влияние текущего состояния на бизнес, желаемое будущее состояние, сложность и предполагаемая продолжительность проекта и ожидаемые преимущества. СОВ ЕТ Обратите внимание, что этапы проекта и документация связаны с PRINCE2®. Инициирование проекта Руководитель проекта вместе с бизнес-аналитиком обозначает цели и бизнес-потребности, ожидаемый результат проекта и критерии приемлемости. В то время как руководитель проекта работает над составлением плана проекта, бизнес-аналитик разрабатывает план бизнес-анализа, в котором излагаются ожидаемые результаты бизнес-анализа, модели взаи- Модуль 8. Управление проектом 205 модействия со стейкхолдерами, подход к управлению требованиями и оценка усилий. Бизнес-аналитик согласовывает план бизнес-анализа и управления требованиями с руководителем проекта. После согласования планов бизнес-аналитик тесно сотрудничает со стейкхолдерами проекта, чтобы уточнить бизнес-потребности. Он определяет бизнес-требования высокого уровня, проводит анализ стейкхолдеров, документирует пользовательскую историю и прецеденты использования (где это применимо), идентифицирует риски, допущения и ограничения. Бизнес-аналитик определяет область решения, требования высокого уровня, подход к решению, компоненты многократного использования и новые компоненты, которые будут использоваться в окончательном решении. Руководитель проекта и бизнес-аналитик согласовывают сферы применения и объем работ, упрощают план проекта. Бизнес-аналитик информирует руководителя проекта обо всех выявленных и потенциальных рисках. Руководитель проекта ведет реестр рисков и разрабатывает стратегии их смягчения. Результатом общих усилий становятся два ключевых документа: «Концепция проекта» и «Концепция решения». Первый документ содержит постановку проблемы, желаемые результаты, критерии допустимости для результатов, анализ стейкхолдеров, бизнес-контекст, допущения, ограничения и рамки (что в рамках/что за рамками). Во втором документе описаны постановка проблемы, утверждение и обзор решения, матрица стейкхолдеров (RASCI), будущие возможности и бизнес-контекст, а также определение, что находится в рамках решения и за их пределами. Эти документы становятся основой для финансово-экономического обоснования в средних и крупных проектах и принятия решения спонсором проекта о том, следует ли продолжать проект. Руководитель проекта и бизнес-аналитик совместно работают над созданием декомпозиции работ (WBS, work breakdown structure), чтобы гарантировать, что решение будет собрано таким образом, чтобы обеспечить экономическую эффективность в определенные сроки. Выполнение проекта Эта фаза требует еще большего сотрудничества руководителя проекта и бизнес-аналитика. Они работают на воркшопах по требованиям, чтобы обозначить приоритеты и утвердить требования, и проводят воркшопы с поставщиками компонентов решения (если нужно). 206 Часть II. За пределами бизнес-анализа Изменения в области решений приводят к изменению объема работ проекта, поэтому руководитель проекта применяет управление изменениями, чтобы гарантировать принятие только обоснованных изменений, и следит за реестром изменения запросов в течение всего проекта. Руководитель проекта и бизнес-аналитик ведут отчетность достигнутых результатов для спонсоров и других стейкхолдеров проекта. Руководитель проекта помогает бизнес-аналитику общаться с архитекторами решений, разработчиками ПО и другими стейкхолдерами на тему проверки решений и во время приемочных тестирований. Поддержка руководителя проекта здесь неоценима. Руководитель проекта и бизнес-аналитик стараются гарантировать, что критерии приемлемости решения будут соответствовать заранее оговоренным допущениям. Бизнес-аналитик облегчает реализацию решения, чтобы переход к режиму «как обычно» был плавным. Границы, требуемые возможности, риски , допуски и ограничения Границы решения, требования, допуски и ограничения Вендоры PM Документ инициации проекта План бизнес-анализа, План управления требованиями Рамки решения, требования, риски, допуски и ограничения Воркшопы по требованиям Обзор проектного решения Планирование UAT Внедрение решения Закрытие проекта Потребность, ожидаемые преимущества, критерии допустимости проекта Отчеты о ходе работы, запросы на одобрение изменений Потребность, требуемые возможности, критерии допустимости решения Заинтересованные Отчёты о ходе работы, информирование об изменениях BA Модуль 8. Управление проектом 207 Закрытие проекта После того как артефакты одобрены организацией, руководитель проекта работает над закрытием проекта. Бизнес-аналитик обеспечивает обратную связь и окончательный обзор и сообщает о том, насколько решение соответствует бизнес-требованиям. Руководитель проекта и бизнес-аналитик включают в журнал «Извлеченных уроков» всю ценную информацию для дальнейшего использования в будущих проектах. Бизнес-аналитик передает такие артефакты, как бизнес-, функциональные и нефункциональные требования, прецеденты использования и техническую спецификацию решения предприятию. В этих артефактах описано, как использовать решение. Бизнес-аналитик регистрирует все утвержденные артефакты бизнес-­ анализа в центральном репозитории кода, когда проект официально закрыт. Резюме Мои наблюдения за современными проектами свидетельствуют о том, что сложность проектов в значительной степени возросла. Изменения в бизнес-процессах связаны с изменениями устаревших бизнес-приложений, IТ-инфраструктуры и интерфейсов среды компании. PM и BA должны работать более продуктивно в проектах различной природы. Согласно моему опыту, полученному более чем в 60 проектах, для того чтобы удовлетворить изменение спроса и создавать успешные проекты, BA и PM должны работать в тандеме, эффективно продвигаясь к финишной черте. 208 Часть II. За пределами бизнес-анализа Метод управления проектом Часто бизнес-аналитику достается проект, в котором нужно многое сделать, и он не знает, с чего начать, чтобы достичь результата в срок. Воспользуйтесь методологией управления проектом. Представьте, что собираете модель самолета. Сначала открываете коробку, видите в ней кучу маленьких деталей, приклеенных к пластиковой раме, и инструкцию по сборке. Если инструкция напечатана плохо, вам придется разработать свой собственный план действий. Вы знаете, что должно получиться в итоге, да? Вернитесь к этому моменту позже, а сейчас разложите детали в таком порядке, как если бы вы разбирали самолет. Почему нужно вернуться? Потому что сейчас вы используете метод, называемый оценкой. Приступая к заданию, вы не знаете, сколько времени уйдет на его выполнение. Действуя в обратном порядке, вы отметите этапы соединения частей, требующие дополнительного времени. Дополнительное время называется буфером и должно быть учтено в вашем графике. Наличие нескольких буферов в плане сборки гарантирует, что вы завершите задание вовремя и в надлежащем качестве. Далее представлена схема, объясняющая этот метод. Как видите, все детали нужно достать из коробки (начинайте снизу и отметьте потраченное время) и положить на стол в определенном порядке. Затем надо разложить детали по группам (отметьте потраченное время). Каждая деталь должна быть верно подогнана (отметьте потраченное время). И нужно убедиться, что все готово (отметьте потраченное время). И это только подготовка к сборке модели! Ух, эти действия заняли больше времени, чем вы ожидали! В реальном проекте будет так же. Разбейте аналитическую работу на сегменты, спланируйте их выполнение (шаг за шагом), добавьте время для обзора, внесите исправления и последние штрихи в каждый шаг и затем составьте реальный график аналитических действий. Согласуйте свой график с графиком руководителя проекта. Если потребуется внести в ваш график изменения, перепроверьте буферы и обоснуйте их длину, а затем еще раз рассмотрите сегменты. Для проведения фактического анализа всегда должно быть предусмотрено достаточно времени. Этот метод очень полезен при планировании времени, необходимого для завершения итераций в рамках проекта. Правый Оценка буфера Оценка фактической работы Фазы/комплексы операций Ярлыки Буфер Краска Буфер Правый Элероны (Ailerons) Лопасти (Blades) Крылья Левый Элероны (Ailerons) Лопасти (Blades) Буфер Ниша (Dome) Кабина (Cockpit) Фюзеляж Больше времени на высыхание Структура перечня работ Корпус Оценка времени Буфер Пропеллер Вал (Shaft) Лопасти (Blades) Двигатель (Engine) Корпус Левый Элементы сборки Время на выполнение Конечный продукт Направление планирования Буфер Педаль поворота (Rudder) Хвост Киль (Фин) Руль (Elevator) ПРАВИЛО: Планируемое время завершения = Предполагаемый объем работы + Предполагаемые буферы времени. 210 Часть II. За пределами бизнес-анализа Матрица ответственности Матрица ответственности, более известная как матрица RASCI, описывает уровни ответственности различных стейкхолдеров в рамках проекта. Также в матрице описаны зоны ответственности, связанные с выполнением задач и результатами. Матрица RASCI R (responsible) — ответственные стейкхолдеры, выполняющие работу по достижению поставленной задачи. К каждой задаче или артефакту должна быть прикреплена хотя бы одна роль с таким уровнем ответственности. A (accountable) — распределяющие стейкхолдеры, отвечают за правильное и полное завершение задачи или артефакта. Могут делегировать работу другим стейкхолдерам. S (support) — сподвижники-стейкхолдеры, помогающие другим стейк­ холдерам выполнять задачу. C (consulted) — стейкхолдеры, консультирующие других стейкхолдеров по выполнению задач, мнение которых должно учитываться при выполнении задачи или артефакта. Они также помогают анализировать, насколько результаты работы соответствуют поставленным целям. Как правило, являются специалистами в предметной области. I (informed) — информированные стейкхолдеры, которые находятся в курсе прогресса работы и получают уведомления только о результатах и готовых артефактах. Матрица ответственности — отличный способ закрепить разные уровни ответственности за каждым этапом бизнес-процесса. Оптимизация процесса Матрица ответственности текущего состояния дает много полезной информации для оптимизации бизнес-процесса и помогает выявить его потенциальные трудности. При разработке новых потоков процессов вы составите новую матрицу, а сравнение старой и новой матриц поможет вам гарантировать, что никакие задачи, этапы или стейкхолдеры не исключены из нового процесса. 211 Модуль 8. Управление проектом Построение матрицы Создание матрицы ответственности — это относительно простой процесс, включающий четыре этапа. 1 Определите задачи или артефакты, которые требуется выполнить для достижения результата. Начните с использования структуры WBS, если результат уже был достигнут. 2 Решите, распределите ли вы ответственность по ролям или назначите конкретных ответственных лиц. Затем в верхней части матрицы отведите каждой роли или имени отдельный столбец. 3 Распределите обязанности стейкхолдеров по конкретным ролям. Затем рассмотрите поочередно каждую задачу, чтобы удостовериться, что назначенная ответственность соответствует роли. 4 Отнеситесь к этому шагу максимально серьезно. Вы должны убедиться, что все стейкхолдеры, участвующие в проекте, осознают свой уровень ответственности и согласны с ним. Когда вы закончите матрицу, проверьте ее целостность. Чтобы обнаружить потенциальные проблемы, задайте следующие вопросы: • Отсутствуют ли какие-либо роли? • Отсутствуют ли какие-либо задачи? • Следует ли разбить задачи на подзадачи? • Распределены ли роли для каждой задачи? • Ответственным за задачу назначен только один человек? И т. д. 5 МАТРИЦА RASCI ЗАДАЧА ЗАДАЧА 1 ЗАДАЧА 2 ЗАДАЧА 3 Обновите подтвержденную матрицу по мере необходимости и представьте ее в виде таблицы, как показано ниже: РОЛЬ Спонсор A I PM R A BA S R SME1 C S SME2 I S Вендор C I 212 Часть II. За пределами бизнес-анализа Взаимодействие с участниками Суть сотрудничества — это командная работа над задачами для достижения общих результатов. В любом проекте есть круг стейкхолдеров. Они могут быть как раз­ общенной, так и сплоченной группой. Вообще, в число стейкхолдеров проекта попадает КАЖДЫЙ, кому важен результат проекта. Занимаясь задачами проекта, легко потерять контакт с членами проектной группы. Чтобы избежать этого, внимательно следите за стейкхолдерами, которые влияют на вашу деятельность, одобряют артефакты, и теми, кто может прекратить финансирование проекта. Не забывайте и о более широком круге: людях, которые влияют на проектную группу. Предлагаю идентифицировать и классифицировать стейкхолдеров в зависимости от уровня их влияния на вашу деятельность и результат. СОВ ЕТ Используйте матрицу RASCI, описанную выше. Мотивация стейкхолдеров Рекомендую привлекать участников финансирования проекта на ранних этапах планирования. Узнайте, что, по их мнению, важно в проекте. Заинтересуйте их как можно скорее и сохраните этот импульс на протяжении всего проекта. Людям нравится высказывать свое мнение. Слушая их, вы узнаете разные точки зрения на проблему. Воспринимайте советы серьезно, чтобы проявить уважение. Относитесь к другим людям так, как они хотели бы, чтобы к ним относились, а не так, как вы хотите, чтобы относились к вам. Будьте честны: хвалите, когда кто-то принес пользу проекту. Хвалите по заслугам. Чтобы заинтересовывать людей, нужно их понять. Узнайте что-нибудь о стейкхолдере и используйте это для его мотивации. Работая над задачами, лично знакомьтесь с участниками проекта, проявляйте живой интерес к их уязвимым местам и стремлению к успеху. Во избежание неожиданностей и недопонимания всегда устанавливайте ясные ожидания и информируйте о них стейкхолдеров. Определите, что они должны делать и почему. Активно участвуйте в проекте. Модуль 8. Управление проектом 213 Неопределенность играет с людьми злую шутку, поэтому старайтесь предоставлять последовательные обновления с реальными цифрами и результатами, ориентированными на интересы стейкхолдеров. Пусть НЕ ВЫ, а исполнители будут в центре внимания, когда есть хорошие новости. СОВ ЕТ Когда есть хорошие новости, пусть вместо вас в центре внимания будут исполнители. Избежание ошибок Рекомендую использовать методологию управления рисками. Всегда будьте готовы к чрезвычайным ситуациям. Представьте худшие случаи и попытайтесь разработать возможные решения. Изучите уроки, извлеченные из прошлых аналогичных проектов, и по возможности используйте данные прошлых историй. Не стесняйтесь собирать информацию о потенциальных проблемах членов проектной группы — они помогут вам увидеть то, что скрыто. В общем, доверяйте себе. Если чувствуете, что что-то идет не так, исследуйте проблему и устраните ее. Паттерны коммуникации Основной способ удержать всех в круге прост: чаще общайтесь! Вам необходимо общаться как неформально, так и в официальной форме. Помните, что нужно учитывать манеру общения стейкхолдера. Для этого потребуются, например: СОВ ЕТ • личные встречи; • регулярные телефонные звонки; • обмен электронными письмами; • запланированные еженедельные отчеты; • коллективные встречи каждый месяц. Предоставляйте отчеты повторно и общайтесь, даже если «нет ничего нового». 214 СОВ ЕТ Часть II. За пределами бизнес-анализа Избегайте встреч по обновлению статуса проекта, которые тратят впустую время каждого. Опыт подсказывает мне, что бизнес-аналитик должен адаптировать свое общение под каждый проект так, чтобы соответствовать потребностям стейкхолдеров. Слушайте мнение стейкхолдеров внимательно и старайтесь улучшить коммуникации на следующей встрече с ними. СОВ ЕТ Работайте в команде, чтобы повысить уровень информированности и ускорить внедрение инноваций для достижения лучших результатов. Модуль 9. УПРАВЛЕНИЕ IT-УСЛУГАМИ 9 Введение............................................................................................ 216 Стратегия............................................................................................ 219 Проектирование........................................................................ 220 Преобразование..........................................................................221 Эксплуатация..................................................................................222 Каталог IT-услуг.............................................................................223 Итоги...................................................................................................... 226 216 Часть II. За пределами бизнес-анализа Введение Сегодня компании немыслимы без информационных технологий. Все шире используются услуги, способствующие функционированию бизнес-процессов и интеграции различных систем в современный бизнес-ландшафт. У каждого сотрудника есть гаджеты. Многие из них подключены к корпоративной сети. Но несмотря на развитие IT-услуг, до сих пор на проекты и артефакты могут повлиять не полностью сформированные требования (poor requirements). Сокращение разрыва Неполное понимание бизнес-целей приводит к появлению неэффективных требований, ведущих проект к провалу. Требования должны зависеть от краткосрочных и долгосрочных целей и соответствовать реальным потребностям бизнеса. Личные пожелания к требованиям не относятся. Итак, если вы участвуете в проекте, решение в котором создано при поддержке IT-услуг, то концепция и модель ITIL могут быть вам полезны. Жизненный цикл услуг — это основа модели ITIL, в которой показано, как бизнес-цели формируют базу стратегии услуг и преобразуются в бизнес-требования (как функциональные, так и нефункциональные), которые легко внедрить в существующую бизнес-среду, проверить и вывести на производство, а затем поддерживать во время эксплуатации. Дополнительные знания Думаю, каждый бизнес-аналитик должен знать, что происходит внутри бизнеса. • Что считается услугой? • Какие вспомогательные элементы предоставляет услуга для изменяемого бизнес-процесса? • Как услуга повлияет на бизнес в обычные рабочие часы? • Существуют ли рабочие часы, когда услуга должна быть обязательно доступна? • Какие возможные сбои повлияют на бизнес-процесс? На такие вопросы нельзя ответить однозначно с точки зрения бизнес-анализа. Бизнес-пользователь тоже вам с ответами не поможет. Вам нужно будет заговорить еще на одном языке, чтобы задать эти вопросы людям, предоставляющим услуги. 217 Модуль 9. Управление IT-услугами Многоуровневая структура Услуга состоит из нескольких компонентов. Модель ITIL позволяет бизнес-аналитику обнаружить их, а также найти причину насущной бизнес-проблемы и обеспечить надлежащую связь со стейкхолдерами. Бизнес-функция Бизнес-процесс Бизнес-услуги IT-службы IT-службы IT-службы Система Приложение Приложение Приложение Интерфейс Сервер Хранилище Сеть Схема выше служит картой в мире ITIL. Для бизнес-процессов, реализующих бизнес-функцию, требуется поддержка информационных технологий. Бизнесмены работают с электронными таблицами, документами, бизнес-приложениями, используют онлайн-сервисы для взаимодействия со сторонними организациями и партнерами. Чтобы помочь им решить проблемы, модернизировать процессы и бизнес в целом, вы можете использовать информацию, доступную в рамках процессов ITIL. Это поможет вам улучшить один из ключевых артефактов проекта — время завершения проекта. Знание ключевых концепций ITIL, жизненного цикла услуг, процессов и потоков информации помогут вам в любом проекте. Ваши результаты станут ясными и объективными. Вы будете лучше разбираться в информационных технологиях и их компонентах и, наконец, усовершенствуете профессиональные навыки. 218 Часть II. За пределами бизнес-анализа ITIL® — наиболее распространенный подход к управлению IT-услугами. Его основным звеном является жизненный цикл услуги, включающий стратегию, проектирование, преобразование, эксплуатацию и постоянное совершенствование. Многие организации используют этот подход, однако разрыв между потребностями бизнеса и их удовлетворением IT-провайдерами по-прежнему довольно велик. Вас уже назначали ответственным за проект, целью которого является улучшение функционирования IT-провайдера? Независимо от исходных данных проекта (собственный IT-отдел или внешний IT-аутсорсер) прочитайте о способе сократить разрыв. Используйте структуру ITIL для более продуктивной работы поставщика IT-услуг. Рассмотрите модели каждого этапа жизненного цикла услуги. 219 Модуль 9. Управление IT-услугами Стратегия Осознание того, что IT-провайдер понимает под бизнес-требованиями и как соотносит их со стоимостью бизнес-услуг, является первым шагом к сокращению разрыва. Начнем с первого этапа — стратегии. Бизнес Бизнес-процессы Профили загрузки Прочие услуги Ожидаемые преимущества Пользователи услуг Предполагаемые модели доступности Возможные сбои Требуемые результаты деятельности Драйвер: модернизация, соответствие, конкурентоспособность Артефакты «что»и«как» Стратегия услуг Концепция обеспечения непрерывности бизнеса Вопросы аварийного восстановления Планирование ресурсов Портфель услуг Плановые услуги Плановые услуги Бизнесмодель Анализ влияния Управления рисками Утвержденные BC Проектирование услуг В бизнесе есть краткосрочные и долгосрочные цели, связанные с развитием предприятия, соблюдением нормативных требований или выживанием на конкурентном рынке. IT-провайдер должен понимать эти цели, чтобы сформировать собственную стратегию. Для документирования бизнес-целей и требуемых возможностей используйте простой шаблон. Цель Срок Бизнесфункция Бизнес-процессы Требуемые возможности Увеличение продаж на 10% за 12 месяцев Короткий Продажи и услуги Обработка заказа, кредиторская задолженность, управление ресурсами, контракты на поставку Электронная торговля и локальные точки продаж, консолидированный взгляд на рынок, транспарантная цепочка поставки, доступно 18х6 Выражайте цели и возможности через ожидаемые результаты и способы их достижения (опишите «что» и «как» нужно получить). Эти результаты станут отправной точкой для предоставления услуг и осно­ вой для появления плановых услуг, определяющих верхнюю часть портфеля услуг, дадут IT-провайдеру дополнительную информацию об услугах и запустят переход к следующим этапам жизненного цикла обслуживания. 220 Часть II. За пределами бизнес-анализа Проектирование Второй этап — преобразуйте ответы на вопросы «что?» и «как?» в функциональные требования и обеспечьте поддержку с помощью нефункциональных требований. Кроме того, определите, какие изменения необходимы в существующих бизнес-процессах и IT-услугах и какие из имеющихся услуг могут быть выведены из эксплуатации. Всю эту деятельность сопровождает информация о текущих услугах, доступных в портфеле услуг (каталог IT-услуг, средняя часть портфеля услуг). Портфель услуг Проектирование услуг Функциональные требования Нефункциональные требования Изменения существующих процессов Изменения существующих услуг Вывод услуг из эксплуатации Текущие услуги Разработанные услуги Архитектура, инфраструктура Компоненты: повторное использование и совместимость Оперативные требования (интеграция, измерения, KPI Требования преобразования (предусловия/постусловия) SLA, OLA (услуги, стороны, обязанности, целевые уровни) Проектные документации услуг Завершено и утверждено Преобразование услуг Результатом второго этапа станут разработанные (новые или измененные) услуги, имеющие вид проектной документации услуг, в которой содержится вся необходимая информация по введению услуг в эксплуатацию. Официально завершенные и одобренные услуги перейдут на следующий этап — преобразование. 221 Модуль 9. Управление IT-услугами Преобразование На третьем этапе, имеющем решающее значение, вы должны передать информацию о новых услугах клиентам и оправдать их ожидания. Переход к этому этапу гарантирует, что изменения существующих услуг регистрируются, документируются и выполняются под контролем, то есть сбои в работе сведены к минимуму. Формальные процедуры используются при тестировании, проверке услуг и обеспечении стабильности и целостности дистрибутивов. Порфтель услуг Преобразование услуг Ожидания заказчиков Управление релизами и изменениями Проверенные и подтвержденные услуги Связь новых услуг Дистрибутивы Дистрибутив Услуги Документация Компоненты: оборудование и ПО Точки интеграции Развертывание Вспомогательные услуги услуг Поддержка услуг (служба поддержки пользователей, база известных ошибок) SLA (целевые уровни) Успешный дистрибутив Новые/измененные услуги Выведенные из эксплуатации услуги Изменения CIs CMS CMDB CMDB KEDB Функционирование услуг Успешное развертывание утвержденных дистрибутивов подтверждают бизнес-пользователи. Изменения существующих услуг записываются в систему управления конфигурацией (CMS, configuration management system), включающую базы данных управления конфигурацией (CMDB, configuration management databases), в которой находится описание элементов конфигурации и их взаимосвязи. Изменения должны быть внесены в каталог IT-услуг, чтобы отобразить обновленные доступные на данный момент услуги. Все известные ошибки развертываемых услуг должны быть записаны в базу известных ошибок (KEDB, known errors database), чтобы убедиться, что у службы поддержки пользователей (service desk) достаточно знаний для поддержки оперативного использования услуг. Любые услуги, вышедшие из эксплуатации, отразите в нижней части портфеля услуг. 222 Часть II. За пределами бизнес-анализа Эксплуатация На данном этапе происходит поддержка успешно развернутых услуг, координация и выполнение действий, обеспечивающих доступ к услугам и управление услугами на согласованных целевых уровнях. Здесь выполняются запросы от предприятий на получение учетных данных (ID пользователя, пароль, разрешения) и доступа к услугам для изменения функциональности услуги в целом. Служба поддержки при помощи ранее рассмотренного портфеля услуг, CMDB, KEDB решает возникающие инциденты и проблемы. KEDB Эксплуатация услуг Управление событиями Управление инцидентами Выполнение запросов Управление проблемами Управление доступом Известные ошибки CIs и взаимосвязи CMDB CMDB Текущие услуги Получение дополнительной выгоды в соответствии с SLA (соглашением об уровне услуг) Портфель услуг Обходные решения Служба поддержки Запросы Бизнес Эффективность обслуживания регулярно контролируется в форме отчетов, которые затем помогут совершенствовать услуги. Приоритетные направления для анализа определяются с точки зрения времени восстановления услуги и потери данных. Недостатки услуг, выявленные с помощью инцидентов и проблем, становятся причиной перехода к следующему циклу предоставления услуг. Описания четырех этапов показывают потоки информации между бизнесом и IT-провайдером и ключевые моменты ее анализа. Полученные сведения позволяют: • уточнить соответствие между потребностями бизнеса и доступными IT-услугами; • модернизировать разработку решений; • улучшить поддержку бизнес-процессов; • улучшить коммуникацию со стейкхолдерами; • оправдывать ожидания стейкхолдеров. Также вы увидели, какую информацию требуется использовать по усло­ виям IT-провайдера для поддержки предоставления услуг. 223 Модуль 9. Управление IT-услугами Каталог IT-услуг В дополнение к четырем представленным этапам хочу познакомить вас с каталогом IT-услуг. Он играет важную роль в связи бизнес-услуг с базовой технологической инфраструктурой, поддерживаемой внешними поставщиками и внутренними IT-отделами. Информация о текущих услугах доступна в каталоге IT-услуг, который входит в портфель услуг. Каталог IT-услуг помогает взаимодействовать с организациями и знать о доступных IT-услугах, совместимых с поддерживаемыми бизнес-процессами. Эффективность коммуникации повышается благодаря отлаженной структуре и четкости предоставления информации в каталоге IT-услуг для бизнес-пользователей и IT-провайдеров. Бизнес-услуги IT-услуги IT-услуги IT-услуги Прежде всего запомните, что в каталоге IT-услуг есть две абсолютно разные части: бизнес- и IT-услуги. Стейкхолдеры бизнеса видят только бизнес-услуги, а IT-провайдер видит обе части. Одна услуга может поддерживаться одной или несколькими IT-службами. Основой услуги может быть один или несколько компонентов. Рассмотрите, как эти две части можно проиллюстрировать иначе. Системные IT-службы должны оказывать поддержку требуемым бизнес-услугам. В системе может быть одно или несколько приложений, серверов, интерфейсов и базовых сетевых инфраструктур. Взаимосвязь между этими компонентами, выраженная в каталоге IT-услуг, позволяет оценить влияние изменений. 224 Часть II. За пределами бизнес-анализа Бизнес-представление (Бизнес-процессы и их критичность, подключение IT-услуг и их доступность (рабочие часы, безопасность, служба поддержки, стоимость) Подключение и формирование компонентов услуг, SLAs Элементы конфигурации (CIs), Этапы жизненного цикла CI, гарантия, график обновлений, тип мониторинга / инструмента, зависимости, основные средства Оценка и измерение качества ITпроцессов (методы) и отчетность (KPIs, показатели, затраты ) Устойчивость обслуживания (инциденты, серьезность, влияние, точки эскалации, BCP, DR, допустимые значения производительности услуг, допустимое время восстановления услуг (планы действий) IT-представление Почему каталог IT-услуг так важен? У многих организаций его нет, и они все еще в игре. Однако сложность бизнеса растет, как и потребность в информации об IT-ландшафте. Поэтому я уверен, что для организаций, обеспокоенных своим будущим, каталог IT-услуг — единственный способ удержаться на плаву. Каталог IT-услуг — это хаб для всех действий, связанных с информационными технологиями, поддерживающими бизнес. Как видите, каталог IT-услуг — это ключевой источник информации для разных пользователей, который позволяет применять услуги, а также поддерживать, улучшать и проектировать их по мере изменения потребностей бизнеса. Связь с репозиторием бизнес-процессов имеет важное значение, так как позволяет отрегулировать IT-услуги относительно фактических бизнес-процессов внутри организации. 225 Модуль 9. Управление IT-услугами Служба поддержки – L1 Корпоративный пользователь Решенные проблемы/ обходные решения Функционирование услуг Решенные проблемы/ обходные решения Нужные услуги Выполнение поиска Доступность услуг и поддержка Сбои /обслуживание связи Подтверждение серьезности Детали услуг Репозиторий бизнеспроцессов Каталог услуг CMDB Детали услуг Функционирование услуг Новые услуги Стратегия и проектирование услуг Рекомендации База знаний службы поддержки Изменения Зависимость CI Требуемые действия Улучшение услуг Управление инцидентами Управление проблемами Служба поддержки – L2 Обратная связь по спросу и качеству Ссылка на базу знаний службы поддержки позволяет быстро классифицировать проблемы, их решение и связь с определенными пользователями, а не с неизвестными людьми. Ссылка на CMDB обеспечивает точные записи управления ресурсами и быструю навигацию по взаимозависимостям IT-систем, компонентов и IT-инфраструктур на более низком уровне детализации. Анализ влияния изменений становится легкой задачей! Каталог IT-услуг также способствует эффективной коммуникации внутри организации, поскольку унифицированный язык описания и таксономия услуг используются и предпринимателями, и IT-персоналом. 226 Часть II. За пределами бизнес-анализа Итоги Многие организации по-прежнему считают управление IT-услугами технологической проблемой. ITIL предлагает комплексный подход к управлению IT-услугами, который объединяет разрозненные технологии в центре передового опыта. Обратите внимание на движущиеся части внутреннего устройства IT-отделов, ориентированных на ITIL. Знание этих частей поможет вам эффективно взаимодействовать со стейкхолдерами. Понимание каталога IT-услуг и его структуры поможет вам быстро получить ценную информацию и использовать ее для аналитических действий. Вы можете использовать систему управления конфигурацией (включая CMDB) для изучения взаимозависимостей в IT-инфраструктуре и смотреть, какие компоненты можно повторно использовать для повышения экономической эффективности решений. Предварительный обзор ITIL V3. Модуль 10. УПРАВЛЕНИЕ БЕЗОПАСНОСТЬЮ Введение........................................................................................... 228 Пирамида управления......................................................... 229 10 Теория 4P.......................................................................................... 230 Фреймворк SABSA®..................................................................231 Результативный вклад........................................................... 239 Итоги...................................................................................................... 239 228 Часть II. За пределами бизнес-анализа Введение Мы живем в эпоху тесной интеграции предприятия с его средой, и эта интеграция сопряжена с дополнительными рисками и угрозами безопасности бизнеса. Еще десять лет назад информационная безопасность не вызывала большого интереса у бизнес-аналитиков. Но ее важность повысили невероятные темпы развития мобильных технологий и проникновение мобильных вычислений в корпоративную среду. Защита интересов организаций и конфиденциальной информации является ключевым элементом современных решений. Это привело меня к изучению архитектуры прикладной безопасности бизнеса — SABSA (sherwood applied business security architecture). Хотя я обнаружил много ценного в применении инфраструктуры ITIL, считаю, что структура SABSA направлена на то, чтобы заполнить пробелы вокруг информационной безопасности в рамках ITIL. В этом модуле я покажу, как SABSA® может применяться для защиты информации в контектсе бизнес-анализа. 229 Модуль 10. Управление безопасностью Пирамида управления В первую очередь рассмотрим вопросы управления. Управление в отношении любого бизнеса — это не просто набор внутренних правил. У каждого бизнеса есть свои политика и процедуры, регулирующие функционирование бизнеса. Они образуют нижний уровень пирамиды управления. Чтобы бизнес лучше функционировал, необходимы внедрение передовых методов, повышение конкурентоспособности и устойчивости. Эти методы составляют средний уровень пирамиды управления. Верхний уровень пирамиды управления представлен промышленным регулированием и законами в сочетании со стандартами, которые должны соблюдать организации. Каждый из этих уровней отвечает требованиям информационной безопасности. Но требования не согласованы между уровнями, поскольку нет базовой системы, переводящей множество требований в единый набор, применимый к конкретному бизнесу и охватывающий бизнес-цели. Управление, стандарты Передовая практика Политики, процедуры, процессы Фреймворк SABSA® служит базовой системой, гарантирующей, что потребности в информационной безопасности организации будут полностью поняты, спроектированы, предоставлены и затем поддержаны наряду с IT-инфраструктурой. 230 Часть II. За пределами бизнес-анализа Теория 4P Успешное обеспечение информационной безопасности — это не просто использование лучших оборудования и ПО. Требуется более широкий подход, включающий теорию 4P: люди, процессы, продукты и партнеры (people, processes, products, partners). Сотрудники руководствуются внутренней политикой в том, как осуществлять информационную безопасность. Процессы, спроектированные с учетом информационной безопасности, гарантируют, что риск разоблачения конфиденциальной информации под контролем. Правильно настроенные аппаратные и программные продукты защищают организацию от внешних угроз и кибератак. Хорошо поддерживаемые отношения с партнерами и поставщиками создают согласованный набор методов защиты информации в бизнесе. Люди Продукты Процессы Партнеры 231 Модуль 10. Управление безопасностью Фреймворк SABSA® Поскольку SABSA® — это фреймворк архитектуры предприятия, его можно использовать для разработки бизнес-решений на любом уровне детализации и сложности. Чтобы SABSA® принес пользу, до начала проектирования решения ответьте на вопросы, которые помогут точно определить решение и избежать дорогостоящих ошибок и низкой удовлетворенности пользователей. Каждый уровень модели SABSA® представляет набор вопросов, заданных с разных точек зрения. Контекстный уровень защищает бизнес-аналитиков от прыжков к завершению в начале проекта. Он обеспечивает бизнес-аналитика следующими данными: • бизнес-контекст; • таксономия ресурсов организации; • заинтересованность в предпринимательской деятельности; • неэффективные процессы; • пользователи, участвующие в процессах; • места, где требуется решение; • момент, когда решение будет доступно. Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности 232 Часть II. За пределами бизнес-анализа Вопросы, которые уместно задать: • Зачем предприятию это решение? • Решение какого типа должно быть спроектировано? • Какие аспекты бизнеса должны быть оговорены? • Как решение будет использовано? • Какие бизнес-процессы и данные требуют информационной безопасности? • Кто является пользователями решения (их тип, мобильность, число)? • Какие учетные данные можно предоставить пользователям, чтобы они применяли решение безопасно? • Где должно быть расположено решение? • Какие меры обеспечат безопасное использование решения? • Какова связь решения с существующим бизнес-ландшафтом? • Когда будет использовано решение (паттерны использования, важные дни и т. д.)? Концептуальный уровень подразумевает выбор логических и физических компонентов, которые будут использованы для последующего создания решения. Здесь бизнес-аналитик получает следующие данные: • стратегии бизнес-рисков; • задачи; • фреймворк построения карты процессов; • архитектурные IT-стратегии; • роли и зоны ответственности стейкхолдеров (пользователей, поставщиков услуг). Вопросы здесь касаются принципов безопасности, которые будут использованы в рамках решения: • Какая бизнес-информация должна быть защищена в рамках решения? • Почему важна защита идентифицированной информации? • Как можно обеспечить необходимую защиту на уровне бизнес-процессов? 233 Модуль 10. Управление безопасностью • Кто будет участвовать в управлении безопасностью во время использования решения? • Где должна применяться защита (границы)? • Когда защиты достаточно (измерение)? Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности Логический уровень помогает бизнес-аналитику раскрыться, так как к его знаниям добавляются: • текущая инвентаризация IT-ресурсов; • политика управления рисками; • IT-услуги процессов и поддерживающих систем (каталог IT-услуг); • люди и модели доверия; • потоки взаимодействия между местами расположения решения; • график событий (время начала, продолжительность, время завершения). 234 Часть II. За пределами бизнес-анализа Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности На практике контекстный и логический уровни являются самыми сложными. Немногие организации готовы продемонстрировать то, что у них есть, поскольку нередко у IT-отдела отсутствуют бизнес-каталог услуг и дополнительная система управления конфигурацией, содержащей все IT-ресурсы. Что вы можете сделать, чтобы описать эти два уровня? Нарисуйте цепочку создания стоимости и перенаправьте потоки данных в организацию. Это упражнение даст контекстуальную картину и прочную основу для сотрудничества со стейкхолдерами по вопросам безопасности данных. Затем на высоком уровне реализуйте ключевые функции в цепочке создания стоимости и сопоставьте IT-услуги (решения и небольшие приложения) с этими потоками. Упражнение даст видимость логических взаимосвязей (внутренних потоков данных) и областей, где бизнес-данные требуют защиты. СОВ ЕТ Используйте базу данных управления конфигурацией, чтобы узнать больше об IT-ресурсах. На данном этапе требуется задать следующие вопросы: • Почему требуемые бизнес-данные нужно защитить (политика, регулирование)? • Какие бизнес-данные нужно защитить? 235 Модуль 10. Управление безопасностью • Как защитить бизнес-данные? • Кто будет участвовать в обеспечении безопасности данных? • Каковы будут взаимосвязи участников? • Где будут применены меры безопасности (области безопасности и их границы)? • Когда начнут действовать меры безопасности (предельные сроки, графики)? Логическая модель гарантирует, что решение соответствует бизнес-цели и является реализуемым с технической точки зрения. Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности Как только логическая модель безопасности будет понятна, настанет время перейти на физический уровень. Логическая модель информационной безопасности впоследствии преобразуется в механизмы физической безопасности. Уровень помогает бизнес-аналитику узнать следующие данные: • словарь бизнес-данных; • объекты бизнес-данных; • правила и процедуры управления рисками; • существующие приложения, промежуточное ПО и механизмы безопасности; 236 Часть II. За пределами бизнес-анализа • пользовательские интерфейсы IT-услуг; • механизмы контроля доступа в действии; • IT-инфраструктура (платформы, сети и их расположение). Необходимо задать следующие вопросы: • Почему должна применяться конкретная логика (процедуры, усло­ вия, правила)? • Какие структуры данных, связанные с безопасностью (модели бизнес-данных), должны находиться в области решений? • Как будут применены механизмы безопасности (шифрование, контроль доступа, цифровые подписи)? • На кого повлияют механизмы безопасности? • Где будет размещена инфраструктура безопасности (места, макеты, линии связи)? • Когда в процессы будут внедрены определенные механизмы безопасности? Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности Теперь рассмотрим существующую среду и выберем элементы, которые будут повторно использоваться в решении. Компонентный уровень основан на подходе, который гарантирует, что все части сочетаются и способствуют достижению цели, как ожидалось. 237 Модуль 10. Управление безопасностью Логический и физический уровни передают собранную информацию в компонентный уровень. Благодаря этому уровню бизнес-аналитик получает следующие данные: • IT-продукты (бизнес-приложения, серверы, репозитории); • данные анализа рисков, инструменты мониторинга, записи и отчеты; • протоколы, поддерживающие бизнес-процессы; • роли пользователей, их функции, действия и полномочия. Требуется задать следующие вопросы: • Какие IT-компоненты (приложения, серверы и репозитории) находятся в области решений? • Как будут использоваться указанные IT-компоненты? • Кто объединит компоненты (личности, роли, полномочия)? • Где будут расположены объединенные компоненты? • Когда должен начаться процесс объединения? • Каков график объединения решения? Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности Последний уровень — управление службой безопасности — связан с постоянным обслуживанием решения и встроенными механизмами безопасности при использовании решения. 238 Часть II. За пределами бизнес-анализа Результаты, полученные на этом уровне, способствуют процессу передачи полномочий в конце проекта. Здесь необходимо задать следующие вопросы: • Какая практика предоставления услуг будет применяться для обеспечения непрерывной работы? • Почему используются методы (оценка риска, планирование непрерывности бизнеса, мониторинг рисков и отчетность)? • Как будут выполняться операции, связанные с обеспечением безопасности (администрирование безопасности пользователей, резервное копирование данных, мониторинг безопасности и т. д.)? • Кто будет отвечать за управление учетными записями и поддержку пользователей? • Где будет выполняться управление службой безопасности (места, объекты, здания)? • Когда будет активировано управление службой безопасности решения (календарь или график обеспечения безопасности)? Архитектура концептуальной безопасности Архитектура логической безопасности Физическая архитектура безопасности Компонентная архитектура безопасности Архитектура управления службами безопасности Контекстная архитектура безопасности Модуль 10. Управление безопасностью 239 Результативный вклад Судя по описанным выше уровням, бизнес-аналитик будет сотрудничать с IT-архитекторами, IT-менеджерами, специалистами IT-инфраструктуры и партнерами, чтобы: • собранная информация была точной и недвусмысленной; • политики и процедуры функционировали; • существующий IT-ландшафт был известен IT-архитекторам; • существующие компоненты были известны и готовы для повторного использования для снижения затрат на решение и эксплуатационных расходов; • требования организации были понятны партнерам для обеспечения надежных отношений. Итоги Одна из основных функций бизнес-анализа — это преобразование бизнес-потребностей в бизнес-требования и подтверждение того, что решение соответствует намеченной цели. Часто бывает недостаточно объединить требования к решению, чтобы удовлетворить заявленную потребность бизнеса. При этом так легко упустить требования к безопасности бизнеса, бизнес-процессам и данным, помещениям, в которых находится бизнес, надежным отношениям с бизнес-партнерами. По опыту я знаю, что стейкхолдеры верят во всеобъемлющие технологии. Описывая уровни и задавая рекомендуемые вопросы, вы сможете получать финансовую поддержку от высшего руководства организации, так как им тоже необходимы надежность и поддержка информационной безопасности. Фреймворк SABSA® побуждает бизнес-аналитиков задавать больше вопросов, благодаря чему требования становятся более четкими и полностью определенными. SABSA® помогает бизнес-аналитикам узнать больше об организации и повысить ее потенциал. Модуль 11. РЕГУЛИРОВАНИЕ Политика (внутреннее регулирование)................ 241 Объяснение....................................................................................246 11 Итоги......................................................................................................248 Внешнее регулирование................................................... 249 Объяснение......................................................................................251 Итоги...................................................................................................... 254 Модуль 11. Регулирование 241 Политика (внутреннее регулирование) Мы все живем в управляемых средах. Они начинаются дома, где мы придерживаемся неписаных правил и моделей, продолжаются на дорогах, где мы следуем правилам дорожного движения. Пользуясь кредитной картой, мы находимся в среде ее поставщика. Организации не исключение. Они существуют в среде, определяемой правительством, законодательством, отраслевым регулированием и внутренней политикой. Вы спросите, как это связано с бизнес-анализом. Дело в том, что бизнес-аналитики занимаются комплаенс-проектами. Эти проекты могут быть направлены на соблюдение либо как внешних, так и внутренних правил, либо только внутренних правил. Первые отслеживают реакцию организации на новые условия регулирования отрасли, а вторые направлены на соблюдение новых корпоративных политик и стандартов. Учтите, что в большинстве случаев регулирование (внешнее или внутреннее) изменяет или расширяет существующие правила игры. Совершенно новое регулирование проводится в соответствии с существующим, но в гораздо меньших масштабах. С точки зрения бизнес-анализа успех проекта во многом зависит от того, как выделены части регулирования, которые относятся к проекту. Чтение исходных документов может отнять много времени и не дать результата. СОВ ЕТ Термин «регулирование» в данном случае описывает регулирование рынка и корпоративное управление (директивы, политика и стандарты). Читая каждый нормативный документ, старайтесь ответить на следующие вопросы: • Каковы цели регулирования? — Будущее состояние. • Какова область регулирования? — Масштаб изменений в текущем состоянии. • К кому относится это регулирование? — Стейкхолдеры. • Каковы роли и ответственность? — Кто, как и что делает. • Каковы нормативные требования? — Бизнес-данные, подлежащие уточнению и обработке. 242 Часть II. За пределами бизнес-анализа • Каковы границы отклонения от регулирования? — Исключения. • Кто и как контролирует соблюдение правил? — Органы управления должны быть установлены. • Каковы ключевые определения? — Глоссарий. Рассмотрим пример, который отвечает на эти вопросы. Компания разработала новую политику и находится на стадии инициирования проекта. Вам нужно указать требования высокого уровня, которые должны соответствовать новому решению. Чтобы вам помочь, я предоставлю выдержку из отчета управления политикой и документами фиктивной компании CapStor, чтобы показать структуру фактического документа. Я выделил части, связанные с бизнес-анализом, курсивом. Затем я покажу, как выделенный материал можно преобразовать в ответы на вопросы, приведенные выше. Вы можете использовать их для разработки артефактов бизнес-анализа. Давайте начнем. Перед вами отрывок из фактической политики, обратите внимание, на каких моментах следует сосредоточиться. Цель Политика устанавливает фреймворк, согласно которому создаются и контролируются официальные отчеты и документы CapStor. В нем перечислены обязанности сотрудников и сформулированы принципы, лежащие в основе процессов, изложенных в документах и руководствах по управлению документами. Цель настоящей политики — обеспечить бизнес-направления CapStor надлежащей структурой управления и поддержкой, а также ресурсами, позволяющими управлять отчетами и документами в порядке, который планируется, контролируется, отслеживается, регистрируется и проверяется с использованием централизованной системы. В этой политике изложены основные стратегические и оперативные требования к надлежащему ведению документации и управлению документами в CapStor. Таким образом будут удовлетворены бизнес-потребности CapStor в доказательствах, отчетности и информации о бизнес-деятельности. Рамки Эта политика применима ко всем сотрудникам CapStor и ко всем официальным корпоративным отчетам и документам в любом формате и из любого источника. Например, документы на бумаге, электронные Модуль 11. Регулирование 243 сообщения, цифровые документы и отчеты, видео, DVD, веб-контент, планы и карты. Политика не распространяется на общедоступные материалы или данные, хранящиеся во внутренних бизнес-системах, таких как основные бизнес-приложения CapStor. Заявление о политике Отчеты и документы, созданные, полученные или используемые сотрудниками CapStor в ходе обычной деятельности, являются собственностью CapStor, если не согласовано иное. Официальные отчеты CapStor составляют ее корпоративную память и являются жизненно важным активом текущих бизнес-операций, а также для доказательства деловой активности организации и операционных транзакций. Они помогают руководству CapStor принимать более обоснованные решения и совершенствовать деловую практику посредством точной записи прошедших событий. Отчеты К отчетам необходимо применить: • структурированное и последовательное управление; • управление в соответствии с инструкциями CapStor; • безопасное хранение в соответствии с Руководством по учету и управлению документами — раздел «Доступ к записям и безопасность»; • удаление или постоянное архивирование в соответствии с Руководством по учету и управлению документами — раздел «Архивирование и удаление отчетов»; • регистрацию с помощью целевой централизованной системы в соответствии с Руководством по учету и управлению документами. Документы К документам необходимо применить: • создание уполномоченными должностными лицами, управление в центральном и контролируемом репозитории, система электронного документооборота (СЭД) в соответствии с Руководством по учету и управлению документами; • контроль версий уполномоченными должностными лицами в соответствии с Руководством по учету и управлению документами — раздел «Доступ к записям и безопасность». 244 Часть II. За пределами бизнес-анализа Ответственность Делопроизводитель несет ответственность за помощь коллегам в общем управлении отчетами и документами, включая: • управление СЭД; • контроль делопроизводства; • помощь другим сотрудникам в вопросах внедрения и интерпретации инструкций и руководящих принципов ведения документации; • поддержание, развитие и распространение политики организации среди коллег; • определение требований к хранению и удалению оперативных и административных записей; • подготовку кадров для процессов управления документами и СЭД. Система электронной документации СЭД помогает сотрудникам CapStor собирать записи, защищать целостность и подлинность данных, обеспечивать доступ к записям по времени, удалять ненужные записи и бессрочно хранить ценные данные. Система также облегчает создание и контроль версий, авторизацию официальных корпоративных документов. Отдел делопроизводства контролирует СЭД, обеспечивает постоянную поддержку, развитие и обучение в подразделениях и следит, выполняет ли организация свои обязанности на законодательном, деловом и общественном уровнях. Централизованная СЭД компании называется DataSafe. Комплаенс Все сотрудники должны использовать DataSafe, чтобы: • официальные отчеты и документы регулярно фиксировались совместно с предопределенными метаданными и соответствовали полномочиям по хранению и удалению; • доступ к отчетам и документам управлялся в соответствии с авторизацией и сроком хранения независимо от места отправки запроса; • отчеты и документы были защищены от несанкционированного изменения или удаления; • контроль над документами осуществлялся версиями по мере необходимости; • существовал только один авторитетный и надежный источник информации, документирующий решения, бизнес-операции и операционные транзакции CapStor. Модуль 11. Регулирование 245 Все сотрудники CapStor, которые ежедневно создают, получают и ведут отчеты и документы, должны работать в соответствии с установленными политиками, инструкциями и стандартами. Сотрудники могут удалять документы только после необходимого разрешения и в соответствии с утвержденными графиками. Определения DataSafe: централизованная система электронной документации CapStor. Документ: записанная информация или объект, которые можно рассматривать как единицу. (Источник: ISO 15489, часть 1, пункт 3.10) Email: передача текстовых сообщений и дополнительных вложений файлов по сети. СЭД: система электронного документооборота — информационная система, которая фиксирует записи, управляет ими и обеспечивает доступ к ним спустя время. (Источник: AS ISO 15489.1 2002, Information and documentation — Records management 3.17) Метаданные: структурированная или полуструктурированная информация, которая позволяет создавать, управлять и использовать записи по времени внутри подразделений и между подразделениями. (Источник: ISO 23081 — 1: 2006, пункт 4). Отчеты: информация, созданная, полученная и содержащаяся в качестве доказательств. Информация организации или лица в соответствии с юридическими обязательствами или при совершении сделки. (Источник: AS ISO 15489.1 2002, Information and documentation — Records management 3.15) Управление отчетами: область управления, отвечающая за эффективный и систематический контроль над созданием, получением, обслуживанием, использованием и распоряжением отчетами, включая процессы для сбора и хранения доказательств и информации о деятельности и транзакциях в форме отчетов. (Источник: AS ISO 15489.1 — 2002) 246 Часть II. За пределами бизнес-анализа Объяснение Теперь у вас есть все необходимое для начала бизнес-анализа и определения бизнес-требований. Цели Политика устанавливает официальную основу для сбора и управления официальными отчетами и документами в CapStor и определяет принципы поддержки отчетов и процессов управления документами в будущем. В политике также указано, что централизованная система будет использоваться для поддержки установленных бизнес-процессов. Рамки Политика применима ко всем официальным корпоративным отчетам и документам независимо от их формата и источника. Она исключает общедоступные материалы или данные, хранящиеся во внутренних бизнес-системах CapStor. Стейкхолдеры Политика касается всех сотрудников CapStor. Роли и ответственность Делопроизводитель поддерживает работу СЭД, определяет требования по хранению и удалению данных, проводит обучение использованию СЭД. Данные, подлежащие уточнению и обработке • бумажные документы (отсканированные); • цифровые документы и отчеты; • электронные сообщения; • видео; • DVD; • веб-контент; • планы; • карты. Исключения В политике не указаны исключения. Модуль 11. Регулирование 247 Ключевые определения См. подраздел «Определения» в разделе «Политика (внутреннее регулирование)». Требования Отчеты и документы необходимо: • регистрировать в рабочем порядке; • сопровождать предопределенными метаданными; • сопровождать сроками хранения и удаления; • хранить в центральном и контролируемом репозитории; • делать доступными только авторизованным пользователям; • делать доступными в соответствии с ролями; • делать доступными (для авторизованных пользователей) из любого места в бизнес-среде CapStor; • защищать от несанкционированного изменения и удаления; • защищать контролем версий; • хранить только в СЭД (DataSafe); • разрешать удалять только авторизованным пользователям; • удалять в соответствии с утвержденными графиками удаления. Контроль соблюдения требований В данном тексте явно не указано, но мы можем предположить, что делопроизводитель будет следить за соблюдением требований с помощью СЭД. 248 Часть II. За пределами бизнес-анализа Итоги Как видите, анализ политики дает полноценные результаты. Теперь вы знаете: • терминологию; • где найти описание новых процессов; • типы бизнес-данных, подлежащих обработке; • как данные нужно поддерживать в СЭД; • приоритеты требований (должно, следует, желательно); • что не входит в рамки политики; • кто несет ответственность за СЭД; • кто несет ответственность за обучение работе в СЭД и т. д. Используя вышеуказанный подход, вы сможете извлекать основную информацию, просматривая длинные нормативные документы. Организуйте собранную информацию в предполагаемые разделы, чтобы упростить бизнес-анализ. Ваше общение с руководителем проекта и стейкхолдерами будет легким, а также вы будете уверены в фактических объемах работы. Вы сможете управлять отклонениями в требованиях, обращаясь к политике, когда это необходимо. Модуль 11. Регулирование 249 Внешнее регулирование В предыдущем разделе мы говорили о внутреннем регулировании и о том, как анализировать его содержание. Давайте посмотрим, как можно проанализировать внешнее регулирование, чтобы поддержать изменения в бизнес-контексте. Регулирующие органы определяют, как организации в отрасли должны соблюдать нормативные требования. Нормативные требования определяют, например, какие выгоды получат потребители от конкурирующих организаций. В других случаях нормативные требования определяют, как следует хранить и защищать потребительские данные для обеспечения без­ опасности потребителей, использующих платежную систему с помощью карт (стандарт PCI DSS). Я рассматриваю нормативные требования как рыночные правила, чтобы отличать их от внутренних бизнес-требований и бизнес-правил. Также такое разделение позволяет увидеть, как правила рынка организация переводит в бизнес-правила, которые, в свою очередь, являются подгруппой внутренних бизнес-правил, по которым работает организация. Я хотел бы познакомить вас с SOX (законом Сарбейнза — Оксли) — примером регулирования, влияющего на работу организаций. Этот пример покажет, что бизнес-аналитик должен учесть при работе с комплаенс-задачами. Внутренний контроль Выполнение требований SOX к финансовому аудиту и отчетности — большая проблема для открытых акционерных обществ. Хотя SOX в основном применяется в США, Европейский союз тоже скоро к нему придет. Уроки, извлеченные из применения SOX (разделы SOX 302, 404 и 409) в средних и крупных предприятиях, показывают, что для удовлетворения требований SOX требуется последовательная система контроля. Рассмотрим, что это значит. Согласно разделу 302, высшее руководство (генеральный и финансовый директор) каждые 6 и 12 месяцев обязано отвечать за достоверность финансовой отчетности организации и надежность средств внутреннего контроля. 250 Часть II. За пределами бизнес-анализа Согласно разделу 404, открытые акционерные общества каждые 12 месяцев должны предоставлять отчет об эффективности внутреннего контроля, который также требует, чтобы внешние аудиторы подтвердили итоги работы. Согласно разделу 409, государственные организации обязаны предоставлять отчетность в режиме, близком к режиму реального времени. Смысл перечисленных выше правил рынка заключается в том, что финансовые операции должны быть точными, отражать фактический характер бизнес-транзакций и быть доступными для периодической отчетности и внешнего аудита в режиме, близком к режиму реального времени. Модуль 11. Регулирование 251 Объяснение Архитектура системы контроля Моя интерпретация правил рынка такова: элементы эффективного управления должны находиться в контролируемой среде, которая определяет стиль функционирования организации. Эта среда является платформой для всех компонентов внутреннего контроля, поддерживающих определенную организационную структуру и внутреннюю дисциплину, которая основана на следующих ключевых принципах: • политики; • разделение ответственности и финансовых полномочий; • пороговые значения оперативного контроля; • пороговые значения финансового контроля; • безопасность и доступ; • оценка и управление рисками; • матрица компетенций; • контрольные величины (в рамках бизнес-процессов); • средства мониторинга (отчеты и KPI). Система контроля должна поддерживаться интегрированной информационной системой, позволяющей своевременно регистрировать все транзакции, распространять полученную информацию среди конкретных пользователей с четко определенными обязанностями и строго ограниченным доступом к оперативной информации. Для обеспечения надлежащего контроля и длительной поддержки эффективности внедрите стандарты внутреннего соответствия, чтобы затем преобразовать их в бизнес-требования и использовать при определении функциональных требований к решению. Объем бизнес-анализа для комплаенс-проектов включает в себя разработку средств контроля функционирования организации и обеспечения эффективного аудита. Хорошо спроектированные и внедренные средства контроля гарантируют, что аудиторские проверки организации, проводимые рыночными органами, будут безболезненными для организации, поскольку внутренние проверки заранее выявят, что должно быть исправлено. 252 Часть II. За пределами бизнес-анализа Соблюдать внешние требования будет просто, если ваши внутренние требования соответствуют внешним. Преимущества для организации от наличия описанной системы управления, встроенной в решение: • четкое внутреннее управление (политики и процедуры); • четкие бизнес-цели и показатели производительности; • четко определенная производственно-сбытовая цепь; • эффективные бизнес-процессы; • четкие контрольные величины бизнес-процессов; • сбор, отслеживание и передача информации о бизнесе в режиме, близком к режиму реального времени; • согласованные и достоверные бизнес-данные внутри организации (финансовые данные поддерживаются операционными транз­ акциями); • компетентный и мотивированный персонал; • своевременные предупреждения о событиях, которые могут негативно повлиять на организацию; • устойчивые отношения со средой организации (клиентами, поставщиками и руководящими органами). На примере общей структуры организации я показал, какие средства контроля должны быть реализованы для соответствия требованиям SOX. Но некоторые из этих элементов управления могут быть рассмотрены вне сферы бизнес-анализа, например политики (настоятельно рекомендую вам прочитать и изучить их). Политики предоставляют два значимых преимущества: 1. Устанавливают внутреннее функционирование организации. 2. Помогают придерживаться определенного бизнес-процесса и использовать инструменты автоматизации. Рассмотрите архитектуру высокого уровня системы управления. Отдел кадров (начисление заработной платы) Аудит внутренний | внешний Заказчики Фиксированные активы Инвентарь Проекты Соблюдение внутреннее | внешнее Вендоры /партнеры Запросы и заказы на поставку Кредиторская задолженность Контроль среды сущности Регулирование рыночных органов Учет (главная бухгалтерская книга) Задолженность на счетах Котировки и заказы на продажу Рыночная среда Модуль 11. Регулирование 253 Средства мониторинга (отчеты и KPI) Контрольные пункты Матрица компетенций Управление рисками Разрешение безопасности и доступа Контроль пороговых значений (финансы) Контрольные пороговые значения (эксплуатация) Распределение обязанностей и финансового управления Политики 254 Часть II. За пределами бизнес-анализа Итоги Понимание внешних нормативных требований помогает выявить возможности высокого уровня, которые должны быть реализованы для удовлетворения этих требований. Это отправная точка для дальнейшего анализа и согласования внутренних бизнес-требований, бизнес-правил и существующей информационной инфраструктуры для выполнения комплаенс-проектов. Нормативные требования также определяют объем изменений текущего состояния организации. Понимание этого объема помогает верно направлять организационные изменения в отношении людей, процессов и технологий. Модуль 12. SDLC Введение........................................................................................... 256 Концепция SDLC.........................................................................257 12 SDLC и бизнес-анализ........................................................... 258 Анализ бизнес-процессов................................................ 259 Требования...................................................................................... 261 Требования к разработке систем............................... 263 Разработка системы................................................................ 267 Пользовательский опыт.......................................................268 Пользовательский интерфейс........................................273 Юнит-тестирование................................................................. 276 Интеграционное тестирование................................... 277 Тестирование производительности......................... 278 Приемочное пользовательское тестирование................................................................................. 279 Документация...............................................................................280 Развертывание.............................................................................. 281 Итоги....................................................................................................... 281 Заметки............................................................................................... 282 256 Часть II. За пределами бизнес-анализа Введение Уверен, вы много раз встречали термин SDLC. Он есть в любом списке необходимых навыков бизнес-аналитика, руководителя проекта, разработчика ПО и др. Итак, что лежит в основе этого термина? Что это понятие дает бизнес-аналитику? Термин SDLC относится к жизненному циклу разработки системы или ПО. Это подход к созданию или изменению информационных систем различной сложности. Термин также охватывает модели и методологии, используемые для разработки информационных систем. Концепция SDLC является основой многих видов методологий разработки ПО, которые помогают планировать и контролировать создание информационной системы. SDLC используется при создании или изменении решения — от определения концепции решения до окончания его жизненного цикла. Традиционным подходом к разработке систем является модель Waterfall, ориентированная на полное и правильное планирование крупных проектов и минимизацию рисков для достижения успешных и прогнозируемых результатов проекта. Основным недостатком этого подхода является отсутствие обратной связи от пользователей решения. Если требования не будут полностью поняты, правильность решения окажется под угрозой. Поэтому сегодня популярны гибкие подходы, такие как XP (eXtreme programming), Agile и Scrum, которые сосредоточены на коротких итерациях, позволяющих быстро вносить изменения в течение цикла разработки. Недостаток этих подходов — ограниченная документация о функциональности, доступной в решении. 257 Модуль 12. SDLC Концепция SDLC Концепция SDLC может быть представлена, как показано ниже, независимо от подхода к разработке систем. Результаты бизнес-анализа, охватывающие разработку бизнес-процессов, требования к системе и необходимый пользовательский опыт, являются входными данными для разработки программного пакета (компонентов, пользовательского интерфейса, бизнес-логики, бизнес-правил, обработки исключений и настроек конфигурации). Пользовательский интерфейс Опыт пользователя Пользователя Кодирование Бизнес-требования Проектирование бизнесБизнесПроцесса процесса Модульное тестирование Интеграционное Тестирование тестирование Документация Тестирование производительности Производительности Приемочное пользовательское тестирование Окончательное Решение решение 258 Часть II. За пределами бизнес-анализа SDLC и бизнес-анализ Методология SDLC устанавливает процедуры, методы и руководящие принципы, регулирующие такие этапы жизненного цикла информационных систем, как инициирование, создание концепции, планирование, анализ требований, разработка, интеграция и тестирование, внедрение и эксплуатация, обслуживание и удаление. Ниже приведен пример жизненного цикла современной информационной системы. Такие фазы, как определение требований, проектирование и разработка, позволяют сократить время создания продукта за счет интенсивных итераций (в Agile или Scrum). На приведенной ниже схеме показано, как бизнес-анализ сочетается с SDLC. - Технические характеристики программного обеспечения Управление жизненным циклом требований - UAT - 259 Модуль 12. SDLC Анализ бизнес-процессов Современные организации все больше осознают, что первым шагом любого изменения бизнес-деятельности или проекта является анализ существующих бизнес-процессов, а затем определение их будущего состояния. «Будущие» процессы служат прочной основой требований к разработке поддерживающего ПО. Эффективная разработка бизнес-процесса происходит с использованием модели, изображенной ниже, как для существующих процессов, так и для их будущих состояний. Бизнес-функция Бизнес-процесс Деятельность Деятельность Деятельность Бизнес-процесс Деятельность Деятельность Деятельность Объект Бизнесправила Деятельность Деятельность Назначение Событие Деятельность Ввод СОВ ЕТ Деятельность Обработка исключений Источник Спецификация данных Бизнес-процесс Событие Вывод ДополниITуслуги Этапы тельные данные Преобразование данных Спецификация данных Не создавайте программный пакет (систему), если не понимаете действия пользователя, которые должен поддерживать этот пакет. Понимание бизнес-процессов и их взаимозависимостей значительно влияет на разработку эффективной информационной системы. Эти знания дадут вам сведения о: • входных данных; • преобразовании данных; • выходных данных; 260 Часть II. За пределами бизнес-анализа • точных метаданных для данных, с которыми сталкиваются бизнес-пользователи; • бизнес-правилах, в соответствии с которыми будет определена бизнес-логика решения. Такой подход имеет ряд преимуществ. Информация о процессах, зафиксированная в простой форме, поможет вам быстрее определить пользовательские истории, прецеденты использования и бизнес-требования. Также вы сможете эффективно донести до стейкхолдеров все нюансы предлагаемого решения и сократите количество резервных полей в пользовательском интерфейсе и базе данных приложения. Команда проекта начнет говорить на одном языке со стейкхолдерами, обсуждая процессы или пользовательский опыт. Разработчики и тестировщики ПО будут благодарны вам за составленную документацию, которая позволит им работать без дополнительных усилий. СОВ ЕТ У всех программных решений есть дополнительная проблема — создание отчетов по данным, доступным в решении. Не забудьте указать требования к отчетности для каждого процесса. 261 Модуль 12. SDLC Требования Реагирование на бизнес-потребности приводит к изменению текущего состояния бизнес-процессов и поддерживающих решений. Понятые потребности становятся требованиями, которые: • описывают, как можно решить существующую проблему; • определяют функциональность возможного решения. Управление Развитие рынка Соблюдение Угрозы/возможность ПОТРЕБНОСТИ Требуемое решение Agile, Scrum Требования высшего уровня (набор функций) Бизнес-процессы Пожелания пользователей, темы Waterfall Бизнестребования Деятельность, связанная с бизнес-процессами Сценарии (основной, альтернативный, обработка исключений) Прототипы GUI Объекты и их метаданные Производительность, масштабируемость, доступность, безопасность… Требуемая IT-инфраструктура Артефакты BA Варианты использования , Функциональные требования Нефункциональные требования Бизнес-анализ строится вокруг определения требований. Термин «требования» понимается по-разному. Некоторые люди не различают нормативные и внутренние (бизнес-) требования, называя их все «бизнес-требованиями». Другие более детально подходят к определению требований. Создание системы начинается с определения требований высокого уровня, отражающих бизнес-потребности, указывающих на возможности системы и позволяющих создать ее концептуальную модель, чтобы проверить целесообразность системы для стейкхолдеров. После формирования концепции системы выделите более конкретные бизнес-требования, чтобы обозначить функциональность, бизнес-логику, применяемые бизнес-правила и пользовательский интерфейс определенных бизнес-процессов. 262 Часть II. За пределами бизнес-анализа Функциональные (программные) требования, позволяющие кодировать указанную функциональность, задайте после завершения разработки системы. Одновременно с этими действиями разработайте тестовые сценарии для проверки встроенной системы. При документировании требований важно составить матрицу прослеживаемости, которая позволит прослеживать все указанные требования и будет гарантировать, что они не пропадают и не добавляются в список изначально заявленных требований. Функции и требования без метаданных ни о чем вам не скажут. Атрибу­ ты метаданных станут важной частью отчетов, как только вам потребуется сообщить о выполнении требований. Рассмотрим, какие атрибуты включены в метаданные требований и какие значения могут быть присвоены этим атрибутам: Уникальный идентификатор (поддержка соответствия требований) Статус (Заявлено ... Утверждено) Приоритет (высокий/ средний/низкий) Функциональная сфера Сложность (высокая/средняя/ низкая) Компонент решения Тип (MRL, BRL, HLR, BR, FR, NFR) Набор функций / требования Отслеживание (см. выше — правила рынка, см. ниже — в зависимости от уровня) Описание Дата последнего изменения Владелец Последнее изменение — заинтересованная сторона Контрольный журнал (история изменений) Пакет требований (Use Case Id) Комплекс операций (где будет реализовано требование) ID проекта Модуль 12. SDLC 263 Требования к разработке систем Технология стала неотъемлемой частью нашей жизни. Мы просыпаемся и засыпаем с гаджетом в руках. Восхищаемся интересными опциями пользовательского интерфейса, совместным использованием, простотой навигации и скоростью передачи данных. Но, думаю, мало кого из обычных пользователей интересует, как были созданы эти чудесные вещи. Бизнес-аналитики все больше участвуют в проектах, поставляющих программные приложения в качестве основного продукта, чтобы удовлетворить бизнес-потребности. Неважно, используют ли они традиционный подход Waterfall или модный Agile — метод указания функций ПО однотипен. Вспомнив несколько недавних проектов такого рода, я решил обобщить идеи, которые использовал при определении функций ПО для ускорения разработки проекта. Почему мы здесь об этом заговорили? Нужно подчеркнуть, какую информацию собирать и анализировать, чтобы определить рамки, указать правильные требования к разработке ПО и обеспечить высокое качество конечного продукта. Цель Подумайте о предметной области, о который пользователь должен иметь представление. Язык, который вы используете при обсуждении желаемых опций, ярлыки в пользовательском интерфейсе для общения с пользователем, функции, доступные пользователю, взаимодействие с другими пакетами ПО и т. д. Контент Если вы разрабатываете мобильное приложение, подумайте о том, как представить его пользователю, сколько места на экране оно должно занимать и как на оставшемся пространстве расположить элементы управления, чтобы пользователь мог выполнять какие-либо действия. Экосистема ПО никогда не будет функционировать самостоятельно — оно будет следовать правилам информационного ландшафта устройства, на котором оно установлено. 264 Часть II. За пределами бизнес-анализа Язык бизнес-области, паттерн навигации Рассмотрите способы представления информации, доступные пользователю. Совместите пользовательский интерфейс с бизнес-процессом, разработанным для поддержки ПО. Подумайте о кнопках на экране, которые предоставят дополнительную информацию, и вкладках, раскрывающих информацию о выбранном элементе. Разрабатываете мобильные приложения? Помните, что современные пользователи предпочитают сенсорные экраны. Сегодня эргономичность ценится выше, чем в эпоху настольных компьютеров. Пользователь выбирает устройство, требующее меньше нажатий при эксплуатации. Я вспоминаю первые мобильные телефоны с меню по типу карусели, которое было быстрым и интуитивно понятным. Милый конец 90-х! СОВ ЕТ Постарайтесь быть требовательным пользователем — это поможет вам обнаружить уязвимые и раздражающие области в пользовательском интерфейсе намного быстрее. Локализация Учитывайте терминологию пользователей при переводе текста в приложении, особенно для элементов управления. Паттерны безопасности Независимо от типа приложения (настольное или мобильное), вам может потребоваться применить некоторые паттерны безопасности. Первичная регистрация, имя пользователя, пароль, особенный аватар, права доступа, вход в систему, выход из системы — все это примеры того, что вы должны учитывать. Значок Любому программному приложению требуется значок. Чем он информативнее, тем лучше. В мобильных приложениях используются звуки и изображения для привлечения внимания. Подумайте, как пользователь найдет ваше приложение и будет ссылаться на него при общении с другими пользователями. Модуль 12. SDLC 265 Входные данные Подумайте, какую информацию должен передать пользователь, чтобы начать использовать приложение. Например, в мобильном банковском приложении пользователь должен указать свой номер клиента и пароль доступа к своим учетным записям. Веб-службы Рассмотрите возможность взаимодействия с другими приложениями с помощью веб-служб. Подумайте, как реализовать взаимодействие, какая информация потребуется от обеих сторон, каков поток данных и куда он направлен, как завершится сеанс в конце взаимодействия. Интерфейсы Налаживание связи между новым и старым приложением — это всегда проблема. Поскольку в организациях существует огромное количество устаревших систем, подумайте о доступных данных, типах данных и способах обмена данными. Внешний вид устройства Разнообразные гаджеты, доступные пользователям, — это огромная проблема для индустрии разработки ПО. На большом и миниатюрном экране нужно отобразить одинаковый контент. Существуют различные способы решения этой задачи, поэтому рекомендую вам изучить их самостоятельно, когда потребуется. Готовые элементы Повторно применяемые компоненты относятся к ПО, которое расширяет функциональность существующих приложений. Независимо от того, работаете ли вы над расширением устаревшей системы или улучшаете мобильное приложение, часто можно найти что-то, за счет чего вы сэкономите на усилиях разработчиков (время — деньги) и, следовательно, ускорите вывод продукта на рынок. Технологическая инфраструктура Технологии стремительно развиваются, поэтому, выбирая из доступных технологий, постарайтесь, чтобы в будущем приложение оправдало инвестиции, направленные на его разработку. 266 Часть II. За пределами бизнес-анализа Выходные данные Это то, что пользователь ожидает от приложения: данные, документы, отчеты определенного формата. Дизайн пользовательского интерфейса Цель Контент Экосистема Значок Данные ввода Веб-службы Локазлизация Паттерны навигаци Паттерны безопасности Система/программное приложение Данные вывода Повторно Интерфейсы Форм-фактор устройства применяемые компоненты Технологическая инфраструктура Отчеты Документы 267 Модуль 12. SDLC Разработка системы Разработка системы определяет ее построение. При разработке системы учитываются применяемые стандарты, существующая и планируемая техническая инфраструктура, бизнес-правила, регулирующие систему. Разработка системы — это верхний уровень архитектуры системы, который идентифицирует все компоненты (аппаратные средства и ПО), которые будут использоваться при ее построении. На этапе разработки также определяются способы интеграции системы с ее средой и соответствие требований компонентам системы. Помните, что разработка системы должна соответствовать текущим и возможным будущим состояниям инфраструктуры организации. Технологии стремительно меняются, поэтому систему необходимо разрабатывать с учетом перспектив ее развития. GUI Модель данных IT-инфраструктура Интерфейсы 268 Часть II. За пределами бизнес-анализа Пользовательский опыт Пользовательский опыт привязан к пользователю. Изменение пользователя приводит к изменению опыта. Aotea Studios Пользовательским опытом (UI, user experience) называется впечатление пользователя от применения завершенной системы (ее эргономичность, удобство использования, функциональная целостность) и компоненты, необходимые для этого применения. Позитивный опыт, построенный на нескольких блоках, показан ниже. Экосистема До мобильной эры пользовательский опыт в основном определялся двумя экосистемами: Windows и Apple. Эти компании установили в своих продуктах шаблоны, определяющие пользовательский опыт. Локальная терминология Язык приложения должен отражать терминологию бизнес-области и способствовать процессу адаптации пользователя к продукту. Неправильная терминология создает ощущение стресса, если пользователь не может связать надписи на экране с явлениями, которые они обозначают. Навигация (интерфейс пользователя) Плохо продуманная навигация создает путаницу и вызывает разочарование. Пользователь, который безуспешно пытается научиться применять продукт, в итоге выразит сопротивление принятию продукта. СОВ ЕТ Попытайтесь посмотреть на продукт глазами пользователя, чтобы понять недостатки в эргономичности, представлении данных, расположении элементов управления и т. д. Разработка взаимодействия определяет, как система будет отвечать на действия пользователя, представлять запрашиваемые у нее данные и устанавливать транспарентность потоков задач. Неожиданное 269 Модуль 12. SDLC поведение системы вызывает у пользователя разочарование и, следовательно, снижает производительность пользователя. Приложите усилия для разработки сообщений-уведомлений о недостающих данных, ошибочно введенных значениях или системных ошибках. Подумайте о средствах управления, позволяющих пользователю эффективно взаимодействовать с системой. Перемещение между окнами, раскрытие списка, добавление нового значения в текстовое поле, открытие другого окна или запуск запроса или отчета должны быть организованы на экране логично и удобно. Представьте путь, который должен пройти пользователь. ТРАДИЦИОННЫЕ ЭЛЕМЕНТЫ Экосистема Локальная терминология Навигация Информационный дизайн Юзабилити Соответствие целевому назначению Функциональная интеграция СОВ ЕТ Прототипируйте интерфейс пользователя, чтобы представить пользовательский опыт. 270 Часть II. За пределами бизнес-анализа Информационный дизайн Когда информация не сгруппирована логически, это также оказывает давление на бизнес-пользователя, поскольку требует от него дополнительных усилий по сбору необходимой информации для формирования целостной картины. Удобство использования Простота использования, логическая последовательность действий в сочетании с хорошо понятным поведением продукта положительно влияют на удобство использования продукта. Графические элементы пользовательского интерфейса определяют эффективность манипуляций и обработки данных. Разбросанные кнопки и флажки не создают позитивного ощущения и заставляют человека перемещать взгляд назад и вперед в поисках необходимого элемента. Пригодность для определенных целей Все вышеупомянутые элементы направлены на результат, который нужен пользователю. Несоответствие потребностям пользователя уменьшает стоимость продукта, даже если другие параметры в порядке. Пользовательский опыт в мире мобильных устройств основан на элементах, показанных ниже. Мобильная экосистема Мобильные экосистемы более разнообразны, чем традиционные. Ключевые игроки здесь iOS и Android, затем следует Windows Mobile, а также медленно умирающие Blackberry и Symbian. Основной значок Это «лицо» программного продукта в цифровом мире. Важно, чтобы значок был представительным и производил приятное впечатление. Графический дизайн Это способ представления контента и элементов управления пользователю. Однажды установив плохо разработанное ПО, пользователь может удалить его навсегда. Хороший дизайн настраивает пользователей на длительное применение приложения. 271 Модуль 12. SDLC Экосистема Значок продукта Графический дизайн Локальная терминология Навигация Информационный дизайн Юзабилити Соответствие целевому назначению Функциональная интеграция Социальный интерфейс СОВ ЕТ Избегайте дизайнов с горизонтальной и вертикальной прокруткой для поиска или ввода данных. Мобильная навигация При разработке мобильного решения подумайте об увеличении числа возможных действий на относительно небольшом экране мобильного устройства. Касания (двойные касания) экрана в разных направлениях должны быть интуитивно понятными в зависимости от характера представленных данных. 272 Часть II. За пределами бизнес-анализа Социальные интерфейсы Связь с социальными сетями стала новой нормой для мобильных устройств. Поэтому пользовательский опыт будет позитивнее, если продукт будет интегрирован с социальными сетями (публичными или частными). Модуль 12. SDLC 273 Пользовательский интерфейс Пользовательский интерфейс — это танцпол для пользователя и ПО, где бизнес-процесс отвечает за музыку. Aotea Studios Пользовательский интерфейс (UI, user interface) определяет продуктивность пользователя во время его деятельности. Лучший подход к дизайну пользовательского интерфейса — применение шаблонов, которые являются общими для многих программных продуктов. Обеспечивайте согласованность и используйте общие элементы внутри пользовательского интерфейса, чтобы пользователи чувствовали себя комфортно и быстрее выполняли работу. Также важно создавать шаблоны в языке, макете и дизайне, общие для всего программного продукта, чтобы, изучив элементы выполнения одного действия, пользователи смогли применить эти знания к другим частям программного продукта. Выбор элементов интерфейса Старайтесь быть последовательными в выборе и расположении элементов интерфейса, чтобы результат их использования был предсказуем. Элементы интерфейса • Элементы управления вводом: кнопки, текстовые поля, флажки, зависимые клавиши, выпадающие списки, списки (сетки), переключатели, поля данных, поля времени и т. д. • Навигация: слайдеры, поля поиска, значки, гиперссылки, свайпы, касания и т. д. • Информационные компоненты: значки, индикаторы, сообщения-уведомления (предупреждения и сообщения об ошибке), обязательные поля и окна. Передовые методы разработки пользовательского интерфейса Хороший дизайн — это хорошее понимание пользователей: их целей, навыков, предпочтений и задач, которые им необходимо выполнить. При разработке пользовательского интерфейса примите во внимание следующие характеристики: 274 Часть II. За пределами бизнес-анализа Простота. Лучший интерфейс практически невидим для пользователя. Он содержит только необходимые элементы и знакомый пользователям язык. Последовательность. Используя общие для всего продукта элементы, вы помогаете пользователям чувствовать себя комфортно. Язык шаблонов и расположение значков должны помогать пользователю в работе с продуктом. Палитра. Стратегически используйте цвет и текстуру. Вы можете направлять или перенаправлять внимание с предметов, используя цвет, свет, контраст и текстуру. Оформление текста. Используйте типографические приемы для со­ здания иерархии и ясности. Различные кегли, шрифты и расположение текста повысят его читабельность. Средства коммуникации Убедитесь, что система вовремя сообщает о происходящем. Всегда уведомляйте пользователей о действиях, изменениях состояния или ошибках. Сообщать пользователю статус или последующие шаги лучше всего с помощью элементов пользовательского интерфейса. Настройки по умолчанию На устройстве должны быть опции, настроенные по умолчанию, чтобы пользователь мог сразу эксплуатировать программный продукт. Путем тщательного изучения и прогнозирования целей, которых можно достичь с помощью продукта, создавайте настройки по умолчанию, которые уменьшат нагрузку на пользователя. Уделите внимание предварительному выбору или заполнению полей. Навигационное управление (клавиатура, мышь, кнопки) Создайте программный продукт с возможностью подключения и клавиатуры, и мыши. Если это мобильный продукт, используйте общие доступные кнопки. Понаблюдайте, как люди работают за компьютером, и вас удивят вариации действий, которые могут быть выполнены с помощью клавиатуры или мыши. Некоторые люди используют клавишу Tab для перемещения между полями и изредка применяют мышь. Другие используют клавиатуру только для ввода текста, а все остальные задачи выполняют с помощью мыши. Мобильные устройства подразумевают касания экрана или нажатия кнопок управления. Модуль 12. SDLC 275 СОВ ЕТ Проверьте правописание. Ошибки в интерфейсе путают пользователей и ухудшают их впечатление о приложении. СОВ ЕТ Следуйте установленному порядку использования элементов управления. Не удивляйте пользователя! Отмена действия Всегда будьте готовы к тому, что пользователи совершают ошибки. Чтобы защитить целостность данных приложения и предотвратить их потерю, обеспечьте функцию отмены. Хорошо разработанная функция отмены делает ненужными некоторые диалоговые окна. Панель меню Основная проблема разработки главного меню — это выбор элементов и их расположения. Подумайте о задачах и целях пользователя, представьте, удобно ли над ними работать. Индикатор Для выполнения одной задачи может потребоваться решение нескольких других. В таких случаях требуются индикаторы. Сообщите пользователю, что ваш продукт не остановился на середине выполнения его задачи! Кнопки Некоторые люди ненавидят вкладки, которые требуют больше кликов мыши. Однако в некоторых продуктах вкладки необходимы для отображения более подробной информации. СОВ ЕТ СОВ ЕТ Организуйте панель меню в соответствии с задачами, которые выполняет пользователь. Взгляните на веб-браузеры — они полны вкладок! 276 Часть II. За пределами бизнес-анализа Юнит-тестирование Созданную систему необходимо протестировать, чтобы убедиться, что встроенная функциональность соответствует утвержденным требованиям. Процесс испытания обычно включает следующие этапы: • юнит-тестирование; • интеграционное тестирование; • тестирование производительности; • пользовательское тестирование. Юнит-тестирование — это метод тестирования отдельных модулей исходного кода или программных модулей вместе с соответствующими контрольными данными для определения, готовы ли эти модули к использованию. Другими словами, юнит-тестирование ориентировано на проверку функциональности самых маленьких тестируемых частей системы. В объектно ориентированном программировании наименьшей функциональной единицей является класс (а также отдельный метод). Разработчики ПО, как правило, создают и проводят юнит-тесты, чтобы программный код соответствовал дизайну и функционировал, как предполагалось. Модуль 12. SDLC 277 Интеграционное тестирование Интеграционное тестирование направлено на проверку ожидаемых: • функционального поведения; • производительности; • взаимодействия основных модулей. Интеграционное тестирование представляет собой поэтапный подход: новые проверенные части системы постепенно добавляют в пул старых проверенных частей и затем используют для поддержки тестирования системы. Существуют различные типы интеграционного тестирования: • метод big bang («Большой взрыв»); • восходящее; • нисходящее. Метод тестирования «Большой взрыв»* Все разработанные модули связаны и формируют полноценную систему, которая будет использована для интеграционного тестирования. Такой метод очень эффективен, так как он экономит время, отведенное для интеграционного тестирования. Восходящее тестирование Идея подхода состоит в том, чтобы проверить детали первого уровня в первую очередь и создать прочную основу для дальнейшего тестирования, а затем использовать тестируемые детали для проверки деталей более высокого уровня до тех пор, пока не будут протестированы все части высшего уровня иерархии. Нисходящее тестирование Такой подход к интеграционному тестированию полезен, когда при тестировании интеграционных модулей между компонентами имеются разорванные связи. Элементы неисправной части проверяют шаг за шагом, пока связь не будет обнаружена и зафиксирована. * Вид интеграционного тестирования, в котором элементы программного или аппаратного обеспечения или и то и другое собираются в компонент или в целую систему сразу, а не по этапам. — Примеч. ред. 278 Часть II. За пределами бизнес-анализа Тестирование производительности Помимо тестирования функциональности, созданную систему тестируют под нагрузкой, чтобы обнаружить ее уязвимые части. Существует несколько методов тестирования производительности: • нагрузочное тестирование; • стрессовое тестирование; • тестирование износостойкости. Нагрузочное тестирование Нагрузочное тестирование — это простейшая форма проверки производительности, при которой для изучения поведения системы используется нагрузка: подключение конкретного количества пользователей, обработка части данных, формирование отчетов за определенный период и т. д. Тест обнаруживает время отклика системы и облегчает идентификацию плохо работающих частей. Стрессовое тестирование Стрессовое тестирование обычно используется для определения верхнего предела (экстремальной нагрузки) производительности системы. Тестирование износостойкости Этот тест показывает, может ли система поддерживать непрерывную ожидаемую нагрузку. Испытания на износостойкость сопровождаются контролем использования компьютерной памяти (для обнаружения потенциальных утечек) и общей производительности (для выявления любых признаков снижения производительности). Это часто приводит к увеличению времени реакции системы после длительного периода непрерывной нагрузки. Модуль 12. SDLC 279 Приемочное пользовательское тестирование Приемочное пользовательское тестирование (UAT) — это заключительный этап тестирования созданной системы. Он направлен на подтверждение того, что система отвечает согласованным требованиям. В разработке ПО этот этап предшествует приемке системы клиентом или заказчиком. Это окончательная проверка требуемой функциональности и стабильности системы, эмуляция реальных условий использования и данных. Если ПО работает по назначению и серьезных проблем при нормальной эксплуатации нет, специалисты в предметной области подписывают протокол тестового выхода с отказом от формального принятия системы. СОВ ЕТ Всегда заостряйте внимание на определении критериев приемки в процессе обнаружения требований. 280 Часть II. За пределами бизнес-анализа Документация Удивительно, как много энергии вкладывается в создание рабочей системы и как мало — в ее документальное сопровождение. Сторонники Agile-методов утверждают, что документация является рудиментарной для разработки ПО и скорость выхода на рынок намного важнее. Да, время — деньги. Но невозможность использовать систему должным образом также стоит денег. Итак, что можно считать достаточной документацией? Исходя из моего опыта, документация начинается с: • описания разработки «будущих» бизнес-процессов; • требований (высокого уровня, бизнес- и функциональных требований); • пользовательских историй или паттернов использования; • нефункциональных требований; • описания разработки системы; • встроенной системной спецификации; • известных ошибок и дефектов в выходных данных в результате тестирования (для поддержки пользователей); • официального руководства пользователя (лучший вариант!). Артефакты могут быть максимально упрощены. Единственное требование — они должны помочь читателю документа точно представить функционирование решения. СОВ ЕТ Приложите усилия для документального оформления решения, поскольку в будущем могут потребоваться изменения системы для удовлетворения новых требований. Вы сэкономите много усилий, когда наступит время перемен. Модуль 12. SDLC 281 Развертывание В процессе развертывания основное внимание уделяется перемещению завершенной и успешно протестированной системы в производственную среду. Выполненное пользовательское тестирование — это триггер процессов развертывания. Эти процессы подразумевают готовность: • среды организации; • организации; • полной системной документации; • стратегии перехода; • материалов для обучения. Итоги Благодаря этому обзору системы SDLC вы должны почувствовать суть движущихся частей жизненного цикла разработки системы. Теперь вы знаете о связях между бизнес-анализом и SDLC. Вам известно, где разработчикам ПО понадобится ваша помощь для предоставления необходимого решения. Эти знания помогут вам эффективно сотрудничать с другими стейкхолдерами для достижения целей проекта и предоставления качественного решения. 282 Часть II. За пределами бизнес-анализа Заметки _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ _________________________________________________________________________________ Часть III Вверх по карьерной лестнице Модуль 13. Повысить свою значимость..............................................................284 Модуль 13. ПОВЫСИТЬ СВОЮ ЗНАЧИМОСТЬ Введение...........................................................................................286 Система ценностей.................................................................. 287 13 Сосредоточенность на pосте..........................................288 Переговоры....................................................................................290 Устойчивость.................................................................................. 293 Руководство....................................................................................298 Изучение бизнес-области.................................................. 301 Уроки, извлеченные из ошибок................................... 305 В курсе событий.......................................................................... 307 Выстраивание деловых отношений.........................308 Продуманное общение.......................................................309 Поведенческие модели........................................................ 310 Доминирующий тип..................................................................312 Влияющий тип...............................................................................313 Постоянный тип........................................................................... 314 Соответствующий тип..............................................................315 Привлечение участников................................................... 316 Электронное руководство.................................................. 318 Требования: паттерны выявления..............................322 Требования: паттерны........................................................... 326 Модуль 13. Повысить свою значимость 285 Неточные требования: последствия........................ 330 Управление изменениями................................................332 Управление рисками............................................................. 334 Разрешение проблем........................................................... 336 Универсальная функциональная бизнес-модель............................................................................. 338 Пользовательский опыт....................................................... 339 Создание карты клиентского опыта......................... 342 Паттерны анализа: большие данные.......................346 ЧАСТЬ III ВВЕРХ ПО КАРЬЕРНОЙ ЛЕСТНИЦЕ Модуль 13. Повысить свою значимость 286 Часть III. Вверх по карьерной лестнице Введение Профессия бизнес-аналитика набирает популярность среди предприятий. Профессией интересуются больше людей, и спрос на бизнес-­ аналитиков уже превышает предложение. Пора подумать, как выделиться из толпы и быть востребованным. В вакансии бизнес-аналитика пишут, что от кандидата требуется знание бизнес-областей, различные умения и личные качества. Чтобы сделать резюме заметным, вам нужно описать уникальное сочетание ваших навыков и опыта. Как добиться этого уникального сочетания? Какие ключевые компоненты в него входят? Читайте далее. Модуль 13. Повысить свою значимость 287 Система ценностей Независимо от того, откуда вы родом (место рождения и культурная среда), вы должны обладать определенными чертами, которые ценят окружающие. Эти черты выходят за рамки социальных, экономических и религиозных норм. Среди них: 1 СОВ ЕТ Честность Будьте честны. Говорите правду; будьте искренны; не вводите людей в заблуждение, не утаивайте важную информацию, поддерживайте доверительные отношения. 2 Порядочность 3 Уважение 4 Лояльность 5 Ответственность Отстаивайте свои убеждения, сопротивляйтесь социальному и рабочему давлению, подталкивающему вас принять то, с чем вы не согласны. Всегда будьте вежливы к окружающим. Не судите книгу по обложке. Будьте терпимы, цените и принимайте индивидуальные и культурные различия. Относитесь к людям справедливо, будьте открыты, слушайте мнения других и стремитесь понять, что они чувствуют и стараются донести. Поддерживайте своих коллег и работодателя. Не говорите о людях за спиной. Всегда подумайте дважды, прежде чем действовать. Помните о последствиях. Отвечайте за результаты. Стремитесь к совершенству. Максимально используйте все ваши навыки, будьте готовы к отказам. Не сдавайтесь легко. 288 Часть III. Вверх по карьерной лестнице Сосредоточенность на pосте 1 Вы сами управляете своим карьерным ростом. Развивайте личные и профессиональные качества, чтобы добиться успеха. Учитесь всегда. 2 Не ждите подходящего момента. Ваш рост не в чужих руках. Да, вам будут встречаться формальные возможности для роста, но считайте каждое полученное задание бесплатным уроком. Тогда вы обретете такой опыт, который не даст ни одна подготовка. Продолжайте обучение постоянно и улучшайте навыки. 3 Если я попрошу вас задать ваш самый наболевший вопрос, что вы напишете? Скорее всего, он будет связан с тем, что вы хотите сейчас понять или узнать. Подумайте над вашим наболевшим вопросом и поищите ответ на него. Спросите себя, чему вы хотите научиться и в чем стать лучше. Этот вопрос поможет определить текущий этап пути вашего развития. СОВ ЕТ Ответ на один вопрос часто приводит к появлению другого вопроса. Поймите, что сложные вопросы помогают вашему росту. 4 Проблемы стимулируют вас расти. Работайте над пониманием проблем, с которыми сталкиваетесь в работе. Эти проблемы — я уверен, что в вашей карьере их много, — могут стать поворотными моментами на пути вашего развития. Я всегда относился к проблемам в работе как к новым возможностям получения дополнительных навыков, превосходства в чем-либо и повышения профессионализма. 5 Не бойтесь борьбы за рост. Все, что достойно изучения, потребует от вас времени, усилий в доведении дела до конца и, конечно, некоторой борьбы с собой. Иногда вы будете ошибаться или даже терпеть неудачу — все в порядке, поверьте. Помните, ваше развитие — это путешествие. Не бывает путешествий без кочек и выбоин на дороге. Итак, будьте готовы к ударам. Планируйте заранее, чтобы свести неудобство вашего состояния к минимуму. Когда настанет момент удара, вспомните, что вы этого ожидали, и продолжайте двигаться вперед. Всегда извлекайте уроки из проблем. Модуль 13. Повысить свою значимость 6 СОВ ЕТ 289 Ваш профессиональный рост происходит, когда вы задаете вопросы, тестируете новые идеи и методы, размышляете о применении концепций из других дисциплин и экспериментируете. Методом проб и ошибок вы покоряете новые вершины. Вы можете увидеть новые перспективы роста, стоя на вершине. Накапливайте опыт, который позволит вам подняться выше и увидеть возможности обучения с наиболее выгодной точки зрения. Подумайте о своем росте так: если вы хотите быстрого роста, ищите способы помочь окружающим расти. 7 Наслаждайтесь вашей работой. Знаю, работа бизнес-аналитика может быть трудной. Тем не менее всегда помните о том, что мотивирует вас продолжать эту деятельность. Сосредоточьтесь на том, что приносит вам профессиональный восторг, — это будет подпитывать вашу стойкость в трудные времена. 8 Определите, к чему вы стремитесь. Каждый из нас хочет достичь определенной цели в карьере. Работа по достижению этой цели повышает профессиональный потенциал за счет опыта, приобретенного в завершенных проектах. Всегда извлекайте опыт, чтобы обрести профессиональную мудрость. 290 Часть III. Вверх по карьерной лестнице Переговоры Умение вести переговоры — важный навык бизнес-аналитика, который вы используете в повседневной работе с коллегами, руководителями и представителями других организаций. Переговоры часто происходят без продуманной стратегии. Люди общаются в соответствии с индивидуальным стилем общения, приобретенным в их семьях и культурах. Процесс переговоров часто проходит без подготовки и основан на привычках, интуиции, стереотипах о других людях. Рассмотрим, как можно улучшить навыки ведения переговоров. СОВ ЕТ 1 Поймите, является ли для вас вопрос предметом переговоров или нет. Вы должны иметь четкое представление о том, чего хочет каждая сторона и какая степень сотрудничества может потребоваться от других участников. 2 Примите тот факт, что у других участников есть свои цели. Будьте готовы обсудить ряд возможных решений, которые могут удовлетворить и ваши, и чужие цели. 3 Представьте свой идеальный результат и изложите его на ранних этапах переговоров. Уделите время обозначению своих принципов и критериев ведения переговоров. Обозначьте то, что не может быть предметом переговоров ни при каких обстоятельствах. Каждый должен понимать, что переговоры приносят либо выгоду, либо убытки. Разработайте стратегию, чтобы выйти сухим из воды после переговоров (с минимальными или нулевыми потерями). Но не используйте ее до того момента, пока все попытки достичь соглашения не окажутся неудачными. Для эффективного участия в переговорах применяйте различные подходы в зависимости от ситуаций. Вот три стратегии, которые помогут вам начать. Вы можете изменить их позже, чтобы удовлетворить конкретные возникающие требования. Модуль 13. Повысить свою значимость 1 291 Стратегия сотрудничества (soft) Этот подход сводит к минимуму разногласия, создавая надежную среду совместной работы. Ищите точки соприкосновения и общие интересы и находите то, что принесет пользу каждому участнику. Предлагая компромисс для достижения своих целей, в ответ вы ожидаете то же самое. 2 СОВ ЕТ СОВ ЕТ Это трудные переговоры, в которых вы только требуете, но ничего не даете. Вы оказываете давление на участников, чтобы получить желаемое. Этот подход полезен, когда вам нужна только победа, даже если другие проиграют. Подход хорошо работает, когда оппонент слаб или готов уступить. Возможно, придется часто корректировать стратегию выхода сухим из воды, потому что ее варианты, как правило, появляются и исчезают с динамикой переговоров. Не применяйте данный подход, когда необходимо поддерживать долгосрочные отношения. 3 СОВ ЕТ Стратегия конкуренции (hard) Стратегия продвижения предложения Этот подход, благодаря которому переговоры выгодны обеим сторонам, позволяет вам: • сосредоточиться на проблеме, чтобы избежать влияния личных мнений и предпочтений; • сосредоточиться на интересах сторон, а не на их позициях; • создавать взаимовыгодные предложения; • использовать объективные и согласованные критерии принятия решений. Переговоры будут невозможны, если какая-либо из сторон попытается уничтожить другую (то есть выиграть любой ценой). Вы не сможете вести переговоры с людьми, которые не позволяют узнать их мнение. 292 Часть III. Вверх по карьерной лестнице Пора представить контрольный список вопросов, который поможет вам подготовиться к переговорам: Что я хочу получить от переговоров? Каковы цели других участников? Чем я должен торговать с другими? Что я могу легко отдать, если взамен получу желаемое? Каким еще образом я могу получить желаемое? Как я отреагирую на неудачные переговоры? Что я могу или не могу ставить под угрозу? Могут ли отношения с другими участниками влиять на переговоры? У кого сила в отношениях? Кто принимает окончательное решение? Существуют ли скрытые проблемы, которые могут повлиять на переговоры? Могу ли я с ними справиться? Каковы желаемые и ожидаемые результаты? Для меня? Для других участников? Каковы возможные последствия успеха или провала переговоров? Как я выйду сухим из воды? Сколько у меня альтернативных путей отхода? Используя этот список, продумайте каждый пункт выше, прежде чем начинать переговоры. СОВ ЕТ Не полагайтесь только на план A. В запасе всегда должны быть планы Б, В, Г и т. д. Модуль 13. Повысить свою значимость 293 Устойчивость Я увидел слово «устойчивость» в сообщении от стейкхолдера после закрытия сложного проекта. Мне было любопытно, почему это слово было применено ко мне. Слово отражало тот факт, что я остался терпеливым и был готов работать со сложными стейкхолдерами, несмотря на давление, проблемы коммуникации и сложность проекта. Я также мог предложить креативные идеи и возможные решения проблем, с которыми столкнулся проект в течение своего жизненного цикла. Я хорошо знаю, что бизнес-аналитик испытывает огромное давление при работе над срочными проектами с ограниченными сроками выполнения. Мне также известно, что некоторые люди просто рождаются стрессоустойчивыми. Ничто их не беспокоит. Тем не менее большинству из нас нужно учиться навыкам стрессо­ устойчивости, чтобы выжить и преуспеть в быстро меняющемся мире бизнеса. Хорошо, что можно научиться справляться со стрессом и давлением. Вот советы по «устойчивости», которые помогут вам справиться практически с любой стрессовой ситуацией. Устойчивость — это способность быстро возвращаться в форму после стрессов. Словарь Webster 1 СОВ ЕТ Начните со своего тела. Поддерживайте хорошую физическую форму, улучшайте выносливость. Физические упражнения и спорт дают возможность расслабляться регулярно. Когда вы тренируетесь, ваш мозг занят тем, что вы делаете, и не пытается решить рабочий вопрос или головоломку. Давайте себе отдохнуть, чтобы успокоить разум и восстановить энергию. 294 Часть III. Вверх по карьерной лестнице 2 Будьте гибким. Посмотрите на деревья: они гнутся от ветра, чтобы избежать повреждений. Узнайте, как работать с потоком назначений, чтобы не сломаться. Научитесь идти на компромисс, чтобы разрешать конфликты, не создавая дополнительной нагрузки для себя и не ухудшая отношений со стейкхолдерами. Не изливайте стресс на свою семью и друзей. Старайтесь не чувствовать себя жертвой, чтобы не усугубить стрессовое состояние. Одна голова хорошо, а две — лучше. Древняя китайская мудрость 3 Не изолируйте себя от общества. Ваши коллеги, стейкхолдеры, руководитель и близкие могут помочь выдержать любой шторм. Поговорите с ними! Не прячьтесь в себе! Не бойтесь рассказать, что происходит. Будьте честными и объективными. Поделитесь тем, что вас беспокоит, чтобы набраться сил. Найдите устойчивость в их советах и поддержке. 4 СОВ ЕТ Все мы любим подливать масла в огонь, приукрашивать и драматизировать. Нам кажется, что текущий сценарий — единственно возможный и теперь он будет повторяться постоянно. Попытайтесь понять, что вы перегружены или подавлены временно. Старайтесь изо всех сил пережить стресс. Помните, что в итоге проект будет завершен и вы приобретете новые опыт и знания. 5 Не позволяйте проблемам одержать над вами верх. Делайте то, что помогает двигаться вперед, пусть и медленно. Мой проверенный подход справиться со стрессом — найти новую отправную точку для дальнейшего обучения. Примите меры, не сидите сложа руки. 6 Смейтесь над собой и над ситуациями. Юмор уменьшает стресс, сводит его к минимуму, помогает разрешать конфликты и снимать напряжение во время длительных воркшопов. Он также способствует установлению доверительных отношений с людьми. Модуль 13. Повысить свою значимость 295 7 Взгляните на стрессовые ситуации с точки зрения будущего. Возможно, потом они будут не так важны для вас, как сейчас. Поговорите с руководителем проекта и стейкхолдерами, чтобы понять причину ограниченных сроков выполнения задач. Обсудите, как преодолеть коммуникативные преграды, которые могут быть источником стресса. 8 Позвольте себе немного помечтать. Мечты перемещают вас в будущее, и вы можете спланировать, как преодолеть текущую проблему. Я считаю фантазию полезной техникой, поскольку она позволяет мне найти новый способ решения бизнес-задачи. СОВ ЕТ Примите ваши стрессовые ситуации и посмотрите на них как на новые возможности для личного и профессионального роста. СОВ ЕТ Запомните, что долгие часы в офисе, кофе и сигареты не снижают стресс, а только увеличивают его. Вы изучили основы стрессоустойчивости. Теперь предлагаю разобрать способы дальнейшего совершенствования мастерства. Представьте, что вы за рулем и автомобиль получает удар от ямы на дороге. Бам! Но вы чувствуете, что сцепление не потеряно, как будто ничего не произошло. Наша способность принять удар, но все равно сохранять стабильность называется устойчивостью. Откуда стоит ожидать удара? Вы проделали хорошую работу и рады представить результат. Но реакция публики может не оправдать ваших ожиданий. Давайте посмотрим, что можно сделать, чтобы справиться с неудачей. С точки зрения психологии люди могут работать только над ОДНОЙ задачей единовременно. Отсюда следует важный вывод: сосредоточившись на негативе, мы НЕ можем принимать во внимание ничего другого. 296 Часть III. Вверх по карьерной лестнице Как реагировать на отрицательный отзыв о своем результате? Ответ: не начинайте спорить с человеком, который высказывает мнение. Кроме того, не прокручивайте в голове услышанное снова и снова. Не идите по бесконечной спирали из повторения слов — сосредоточьтесь на движении вперед. Создание брони Отрицательные замечания могут резко повлиять на вашу работу. Создайте броню против них. Во-первых, когда вы услышите что-то негативное, сначала мысленно примите это как факт, а не как оценку ваших усилий. Во-вторых, подумайте, как извлечь из критики пользу. Начните смотреть на негатив с разных точек зрения так, будто вы пытаетесь найти хороший ракурс для фотографии. Компоненты ситуации Запомните, в любой ситуации присутствуют три компонента: • триггер (событие, сказанное слово и т. д.); • ваша реакция (мысли, произнесенные слова); • последствия (позитивные или негативные). Как видите, МЫСЛИ являются центром, где ВЫ определяете, какие последствия вызовет ваша реакция на триггер. Например, ваше понимание предмета было оценено как плохое. Отрицательное мнение? Безусловно! Подождите, еще раз взгляните на ситуацию. Человек, который это сказал, возможно, знает о предмете гораздо больше. Примите меры: спросите его, что было не так, что было правильно. Убедитесь, что все поняли, и поблагодарите человека за обратную связь. СОВ ЕТ Не спрашивайте почему. Потому что ваше мнение субъективно, искажает факты и может привести к конфликту. Вы заметили, что спираль больше не действует на вас? Чувствуете? Хорошо. Теперь вы СПОСОБНЫ работать как обычно. Модуль 13. Повысить свою значимость 297 Попытайтесь также не видеть в критике негатива: «О, правда? Я думаю, что мое восприятие отличается от вашего. У меня создалось впечатление, что это правильно. Но теперь я вижу, где ошибался. Спасибо, что указали на это (улыбаясь). Могу ли я услышать ваше мнение?» Чтобы уберечь себя от негатива, вспомните свои прошлые неудачи. Теперь проанализируйте, как вы реагировали на каждую из них. Выберите несколько наиболее ярких и подумайте, как извлечь из негатива пользу. Я настоятельно вам рекомендую больше не использовать прошлые реакции. Помните, что вы создаете броню для будущего, поэтому забывайте о прошлом. Посмотрите, сможете ли вы увидеть другую точку зрения в ситуациях, которые вы вспомнили. Смотрите на негативный опыт как на проверку ваших способностей и навыков. Он поможет вашему обучению и постоянному совершенствованию. Вы спросите, почему я так уверен? После каждой неудачи я понимал, что мне не хватало знаний. По­ этому вместо того, чтобы настраиваться на негатив, я всегда старался восполнить пробелы в знаниях, улучшить свои навыки и способности. Это сработало! Заставьте себя быть счастливым, не будьте несчастным. Помните: не существует того человека, кому известно все. И вы не тот, у кого есть ответы на все вопросы. Неудача — это просто возможность начать сначала, но уже более мудро. Генри Форд Помните о двух преимуществах неудач. Во-первых, если вы потерпите неудачу, то поймете, что именно не работает. Во-вторых, неудача дает возможность попробовать новый подход. Роджер фон Эйк СОВ ЕТ Всегда оставайтесь спокойным и позитивным, будьте вежливы. 298 Часть III. Вверх по карьерной лестнице Руководство Я часто сталкивался с необходимостью руководить, не имея официальных полномочий для этого, при работе над несколькими проектами. Мой способ завоевать авторитет и вести людей состоял в создании дружественной и безопасной атмосферы, в которой члены проектной группы могли бы внести свой вклад в успех проекта. Доверительная среда помогает людям раскрываться, создавать идеи, выявлять слабые места и требования для устранения бизнес-проблем. Какими качествами должен обладать успешный руководитель? Я считаю, что следующие качества являются основными (3C: curiosity, credibility, creativity): • любопытство; • уверенность; • креативность. Эти качества последовательно связаны. Любопытные люди постоянно спрашивают: «Почему все так, как есть?» и «Как можно сделать лучше?» Хорошее знание бизнес-областей, отраслей, надежные отношения со стейкхолдерами, поощрение инициативных сотрудников (их опыта, знаний, точки зрения на будущее состояние) — все это составляет основу уверенности. Креативность — это стремление выбирать инновационные способы выполнения бизнес-задач с использованием доступных решений и ресурсов в рамках существующих ограничений. Руководство — это способность влиять на других для достижения общей цели. Джон Адер Обладать перечисленными характеристиками (3С) недостаточно. Профессиональный дресс-код, деловая этика и навыки ведения переговоров — дополнительные качества, которые выделяют лидеров из коллектива. На мой взгляд, дополнительные навыки создают положительный фон для вышеупомянутых 3C. 299 Модуль 13. Повысить свою значимость R T L E A D E R S H I P E E W R A I U O N E A S A I M S P N N O D U R V K P E O L L E E O S V E T N R T A E T Y T S I S O N Могу указать ключевые навыки, благодаря которым я стал руководителем, исходя из завершенных мной успешных проектов. Назовем сводку ниже «большая Т». Воображение Направлять Взаимодействие Ведение переговоров Содействие Обучение Достигать Воображение Четкое понимание текущего состояния организации, ее внешней и внутренней сред и организационной культуры позволяет представить будущее состояние. 300 Часть III. Вверх по карьерной лестнице Взаимодействие Создание проектной группы, в которую входят стейкхолдеры из разных отделов, обладающие разными уровнями полномочий, для обеспечения открытого общения в команде проекта. Содействие Создание надежной среды для всех стейкхолдеров, участвующих в проекте, и их сотрудничество способствуют достижению целей проекта. Ведение переговоров Большинство переговоров по выявленным требованиям происходит из-за приоритетов, не согласованных стейкхолдерами. Наставничество Внедрение изменений в текущее состояние с помощью персональных воркшопов со стейкхолдерами, поддержка в планировании внедрения изменений, помощь другим в выполнении задач в согласованные сроки. Неуклонность Уверенность в будущем состоянии означает способность управлять проектом и строить решение в правильном направлении для удовлетворения бизнес-целей. Результативность Своевременное предоставление артефактов бизнес-анализа и проектной документации высокого качества в соответствии с согласованными условиями. Соблюдение сроков. Постоянное повышение эффективности бизнеса. СОВ ЕТ Применяйте навыки «большой T» последовательно, чтобы быть уверенным, что вас признают в организации в качестве руководителя. Тогда ваши услуги всегда будут востребованы. Модуль 13. Повысить свою значимость 301 Изучение бизнес-области Деловой мир развивается с невероятной скоростью, поэтому наша способность быстро адаптироваться к изменениям важна. Начало карьеры бизнес-аналитика и переход в новую отрасль для реализации новых возможностей связаны с общей проблемой — необходимостью обладать знаниями или практическим опытом в новой бизнес-области. К сожалению, материалы о бизнес-областях практически отсутствуют. Опыт можно получить, работая в специализированных отраслях, таких как автопромышленность, розничная торговля, банковское дело, страхование, телекоммуникации и т. д. Если вы обладаете необходимыми знаниями, то станете находкой для любого рекрутера. Но что делать, если у вас таких знаний нет? Как получить специализированные знания? Как правило, знания о бизнес-области приобретаются в процессе работы, и это занимает определенное время. Например, банковский сотрудник получает знания о различных типах счетов, с которыми работают клиенты (физического или юридического лица). Аналогичным образом страховой агент узнает об этапах, связанных с подготовкой страхового полиса. СОВ ЕТ Представьте, что вы бизнес-пользователь. Подумайте о его работе: какие инструменты он использует, какие данные обрабатывает, с кем общается и т. д. Некоторые бизнес-аналитики получают знания о бизнес-областях, тестируя бизнес-приложения и работая с бизнес-пользователями. Используя навыки межличностного общения и анализа, они создают благоприятную среду для обучения. На форумах БA мне часто задают вопросы, с чего начать. Уверен, что вы видели множество вакансий, в которых упомянуты знания бизнес-области или опыт работы. Почему это так важно? Потому что недостаточно иметь только хорошие навыки бизнес-анализа (общение, выявление требований, сбор пользовательских историй и т. д.) для реализации быстроразвивающихся проектов. Требуется еще много навыков, например знание различных отраслей, их специфики и терминологии. Как быстро получить новые знания о бизнес-области? Некоторые скажут, что все отрасли и их бизнес-области очень разные, поэтому невозможно получить эти знания простым способом. На самом деле 302 Часть III. Вверх по карьерной лестнице эти области не так уж отличаются: их объединяют общие принципы, которые помогут вам быстро все понять. Эти принципы применимы к любой бизнес-области: розничной или оптовой торговле, финансовым услугам, производству, коммунальным услугам и т. д. Анализируя свой опыт изучения новых бизнес-областей, я заметил, что применяю один и тот же подход снова и снова, особенно в начале пути. Назову его «десятиэтажным деревом». Я разбиваю незнакомую бизнес-область на уровни, в которых смогу быстро разобраться. Итак, на мой взгляд, вы можете узнать все о любой новой бизнес-области, используя следующие составные ориентиры: Терминология Бизнес-процессы Объекты/данные Цепочка поставок Цепочка спроса Продукты/услуги Специализация Сектор Рынок Индустрия Рассмотрим в качестве примера автопромышленность. Модуль 13. Повысить свою значимость 303 Индустрия Автомобильная. Рынок Глобальный/локальный, регулируемый/нерегулируемый, конкуренты, партнеры. Сектор Оптовый, розничный, производственный. Специализация Розничная торговля: легкие автомобили, микроавтобусы, запчасти, послепродажное обслуживание. Терминология Бренды, марки, модели, линейка моторов, модификации, аксессуары, аренда, трейд-ин, тест-драйв, страхование и т. д. Продукты/услуги Зависит от марки автомобиля и локального рынка. Цепочка спроса Индивидуальные клиенты, коммерческие клиенты (парк транспортных средств). СОВ ЕТ У каждого автопроизводителя есть своя система обозначения марок и моделей. Эта система определяет терминологию, используемую для связи с клиентами и вендорами. Цепочка поставок Производители автомобилей, прямые и сторонние производители запасных частей и аксессуаров. 304 Часть III. Вверх по карьерной лестнице Бизнес-процессы Продажа автомобилей, трейд-ин автомобилей, аренда автомобилей, продажа запасных частей, продажа аксессуаров, послепродажное обслуживание, бухгалтерия, снабжение. Объекты/данные • Предложения, заказы на продажу (клиент, условия поставки/оплаты, марка автомобиля/модель/модификация, стоимость, валюта, количество). • Заказы на закупку (дилер, условия поставки/оплаты, марка автомобиля/модель/модификация, стоимость, валюта, количество). • Платежи (клиент/поставщик, сумма, валюта, заказ на продажу/ссылка на заказ на покупку, реквизиты банковского счета). • Счет-фактура клиента (...), счет-фактура поставщика (...), инвентаризационная опись (...) и т. п.). Как видите, «дерево» помогает получить базу знаний, которую можно легко расширить. Пользуясь этим подходом, вы соберете и структурируете знания о новой бизнес-области и изучите ее быстрее. Модуль 13. Повысить свою значимость 305 Уроки, извлеченные из ошибок Никто не идеален. В какой-то момент вы не сможете выполнить обязательства, и неудача может оказаться для вас болезненной. Мысль о том, что все могло быть лучше, будет жалить каждый день. Однако на ошибках учатся. Как лучше всего встретить неудачу? Вот несколько способов справиться с неудачей и превратить ее в ступень на пути к успеху. Простите себя за неудачу Прекратите обвинять себя в том, что вы должны были знать и могли бы избежать. Абсолютно бесполезно продолжать говорить себе: «Если бы я знал тогда то, что знаю сейчас». Избавьтесь от этой мысли, освободите свой мозг, чтобы работать над чем-то более продуктивным. Как только вы это сделаете, вы сможете объективно проанализировать то, что не удалось. Определите причины, путь к неудаче и убедитесь, что вы заметили предпосылки, которые в следующий раз предупредят вас о возможном сбое. Поделитесь своей неудачей Обратитесь к проверенному человеку (коллеге, другу, родственнику), которому вы можете рассказать о своих проблемах. Делитесь только с теми, кто прошел через неудачи. Люди, считающие себя неудачниками, вряд ли окажут вам поддержку. Будьте честны относительно 3W (что пошло не так) Как только вы потерпели неудачу, вернитесь в начало. Серьезные ошибки, которые в итоге уничтожили проект, могли быть предвестниками крупных проблем, изначально присутствовавших в нем. Возможно, с руководителем проекта, стейкхолдерами или разработчиком ПО общение складывалось не лучшим образом. Вы, вероятно, сделали неточные предположения, которые не оправдали ваш подход к работе. Извлеченный урок поможет вам внимательнее обдумывать предположения, сотрудничать со стейкхолдерами, выбирать клиентов и проекты. Извлекайте уроки не из деталей выполнения неудачного проекта, а из вашего отношения к неудачам. 306 Часть III. Вверх по карьерной лестнице Возьмите на себя ответственность Будьте взрослым, не спешите обвинять окружающих! Подумайте, в чем может быть причина неудачи. Вероятно, с самого начала вы не согласовали с проектной группой ожидаемые результаты. Или не задали стейкхолдерам некоторые вопросы, потому что хотели выполнить работу досрочно. Или, хуже того, не уточнили у стейкхолдеров, что им действительно нужно. Что бы вы ни делали, никого не обвиняйте. Я знаю, как приятно верить, что в следующий раз окружающие будут вести себя иначе. Но контролировать других людей не получится. Поэтому примите тот факт, что люди останутся прежними, и вы единственный, кто должен учиться и исправлять ошибки, если хотите успешно осуществить свой следующий проект. Продолжайте пытаться Не тяните время. Сразу выполняйте следующие поручения. Да, усилия не гарантируют, что вы добьетесь успеха. Но если не пытаться, то точно ничего хорошего не произойдет. Учитесь на своих ошибках, есть шанс, что вторая попытка будет успешнее первой. Хотите добиться успеха? Продолжайте пытаться. Модуль 13. Повысить свою значимость 307 В курсе событий Вы заняты поручениями, общаетесь с стейкхолдерами и пытаетесь свое­временно выполнить работу, поэтому кажется, что у вас нет времени контролировать то, что происходит вокруг вас в отрасли. Знакомо? Хотя отслеживание последних новостей отрасли может показаться вам просто еще одним пунктом в вашем напряженном графике, оно даст вам преимущества. 1 Вы будете в курсе потенциальных изменений в отрасли и сможете прогнозировать новые проекты, которые будут вам назначены. 2 Вы будете видеть угрозы и возможности заранее и принимать правильные решения. Это даст вам конкурентное преимущество среди коллег, что особенно важно, если вы работаете над преобразованием бизнеса или комплаенс-проектом. Информированность о делах отрасли даст вам больше возможностей на переговорах с поставщиками. 3 Знание последних тенденций является ключевым моментом в развитии экспертных навыков. Накапливая опыт работы в отрасли, вы получаете доверие и уважение стейкхолдеров. Ваше мнение будет иметь значение на воркшопах. С точки зрения руководства это просто бесценно! 4 Чаще ищите и читайте полезные источники информации. Важно регулярно уделять время чтению, иначе вы можете пропустить что-то важное. 5 Зная о приближающихся изменениях, вы можете захотеть рассмотреть другие отрасли, а также выяснить, какую еще ценную информацию можно получить и использовать, чтобы ваш вклад в бизнес был более значимым. 308 Часть III. Вверх по карьерной лестнице Выстраивание деловых отношений На мой взгляд, продуктивные деловые отношения — это половина работы бизнес-аналитика. Такие отношения способствуют гораздо более быстрому выполнению работы. Насколько сложно строить такие отношения во время работы над проектом? Со временем я понял, что для продуктивных отношений необходимы следующие элементы: • искреннее желание помочь; • желание делиться знаниями; • уважение к опыту людей; • желание учиться у других; • уважение к другой точке зрения; • общие ценности; • деловой этикет; • регулярные встречи; • время, проведенное вместе; • общие интересы, хобби (лучше всего). Эти компоненты способствовали становлению эффективных деловых отношений со стейкхолдерами во многих моих проектах. Теперь каждую неделю я обмениваюсь новостями со стейкхолдерами, с которыми раньше сотрудничал. Вы сэкономите много времени, если знакомый вам стейкхолдер присоединяется к новой проектной группе. Для поддержания отношений время от времени подходите к коллегам и обменивайтесь с ними несколькими фразами. СОВ ЕТ Попытайтесь найти общие интересы со стейкхолдером, чтобы укрепить доверие и обогатить отношения. 309 Модуль 13. Повысить свою значимость Продуманное общение Очень легко упустить из виду взаимодействие со стейкхолдерами, когда вы работаете над несколькими проектами. Основная причина этого в том, что ваша нагрузка высока, вы находитесь в состоянии стресса и свободного времени у вас нет. В этой ситуации нужно добавить некую структуру, которая поможет поддерживать определенный уровень общения со всеми стейкхолдерами. Шаги, показанные ниже, позволят вам ее построить. 1 4 7 Составьте список людей, с которыми вы собираетесь общаться Укажите способы общения — каналы Зафиксируйте время, когда произойдет следующее общение 2 5 8 Определите, что будет сказано каждому выбранному лицу Укажите, на каком уровне будет происходить общение Используйте информацию с умом — заносите в таблицу и обновляйте своевременно 3 Определите, когда произойдет/ потребуется общение 6 Зафиксируйте время последнего общения 9 Готово! Используйте простую таблицу, аналогичную приведенной ниже, для отслеживания вашей коммуникации в рамках проекта. Заинтересованная сторона, имя О чем общаться Когда общаться Как общаться Детализация Последнее общение Последующее общение Вы можете изменять представленный шаблон в зависимости от ваших потребностей. СОВ ЕТ Работая над несколькими проектами, создайте таблицу для каждого из них. 310 Часть III. Вверх по карьерной лестнице Поведенческие модели Бизнес-аналитики должны уметь распознавать в стейкхолдерах признаки из типологии DISC®*. Понимание этой системы типов поможет вам проводить беседы и встречи, получать ценную информацию и достигать запланированных результатов. Несколько лет назад я прошел обучение и тестирование по DISC®, что позволило мне увидеть свои сильные и слабые стороны. Глядя на опыт моих коллег, я понимаю, почему иногда не мог выстроить с ними диалог. Думаю, эти знания помогут вам мотивировать людей выполнять порученные им задачи. Вы сможете эффективно общаться и избегать ошибок при работе с разными руководителями. Далее я объясню почему. * DISC® — это квадрантная поведенческая модель, созданная на основе работы доктора Уильяма М. Марстона (1893–1947). Модель исследует поведение людей в их среде или в конкретной ситуации, поэтому основное внимание уделяется стилям и предпочтениям поведения. 311 Модуль 13. Повысить свою значимость Личностные черты Доминирующий тип (D) описывает, как вы решаете проблемы, отстаиваете свою точку зрения и контролируете ситуацию. Влияющий тип (I) описывает, как вы ладите с людьми, общаетесь и относитесь к другим. Постоянный тип (S) описывает ваш темперамент через терпение, настойчивость и предусмотрительность. Соответствующий тип (C) описывает ваш подход к деятельности и ее организации, процедурам и обязательствам. Подход, описанный ниже, даст вам представление о личности. Профили системы DISC полезны для определения стиля общения с руководителями. На приведенных после профилей схемах показано, чего можно достичь при работе со стейкхолдерами разных типов. 3 1 2 312 Часть III. Вверх по карьерной лестнице Доминирующий тип Профили системы DISC полезны при работе с менеджерами для определения стиля общения. На приведенной ниже диаграмме показано, чего можно достигнуть при работе со стейкхолдерами типа D. D Пропаганда и получение бай-ина Покажите, как ваши идеи могут принести конкретные результаты Покажите общую картину просто и прямо Признайте их власть Предложите пакет акций совместно с решением Показывайте уверенность в ваших идеях Четко отстаивайте интересы команды Спрашивайте их совета Не обобщайте Не повторяйтесь Сосредоточьтесь на решении, а не на проблеме Урегулирование конфликта Будьте осторожны, чтобы не сдаться во избежание конфликта Не принимайте давление лично на себя Будьте объективны Не скрывайте свои чувства в споре Не стесняйтесь говорить, пусть ваше мнение услышат Приоритеты и предпочтения Особый акцент на стремлении Сосредоточьтесь на результате Приоритеты действий Быстрый темп Конкурентоспособность Бросайте вызов окружающим Цените людей, который способствуют быстрому достижению успеха Твердые решения Сильная воля 313 Модуль 13. Повысить свою значимость Влияющий тип Профили системы DISC полезны при работе с менеджерами для определения стиля общения. На приведенной ниже диаграмме показано, чего можно достигнуть при работе со стейкхолдерами типа I. I Пропаганда и получение бай-ина Чувствуйте себя в восторге от новых идей Ищите энтузиазм и страсть Показывайте то, что у вас на уме Показывайте уверенность в своем мнении Покажите, как ваше решение может воодушевить людей Работайте над созданием открытого диалога Покажите общую картину и убедитесь, что результат может быть достигнут быстро после получения бай-ина Выделите время, чтобы люди могли задать вопросы и поговорить между собой Не нужно излишних подробностей Не перебивайте собеседника Используйте юмор Урегулирование конфликта Будьте осторожны с конфронтацией Занимайтесь непосредственно решением задач Сделайте так, чтобы стейкхолдеры были рады Озвучьте ваши потребности, будьте уверены в своем мнении Объясните им, что разногласия не повлияют на отношения в будущем Осознайте важность чувств каждого, но не забывайте о проблемах Убедите всех, что ваши отношения останутся крепкими Не скрывайте собственные потребности Приоритеты и предпочтения Особый акцент на сотрудничестве и поддержке Командная работа в приоритете Сосредоточьтесь на действиях Быстрый темп работы в приоритете Высокая ценность личных взаимоотношений Цените людей, которые разделяют командный дух Самовыражение 314 Часть III. Вверх по карьерной лестнице Постоянный тип Профили системы DISC полезны при работе с менеджерами для определения стиля общения. На приведенной ниже диаграмме показано, чего можно достигнуть при работе со стейкхолдерами типа S. S Пропаганда и получение бай-ина Будьте индивидуальными и любезными Покажите, как ваши идеи могут способствовать достижению результатов Четко обозначайте потенциальные риски Не будьте слишком робким Уверенно выражайте свое мнение Продемонстрируйте, как ваше решение положительно влияет на потребности людей Стройте планы методично Убеждайте всех в надежности Находите время, чтобы все разъяснить Избегайте конфронтации и агрессии Урегулирование конфликта Не избегайте конфронтации, чтобы скрыть ваши чувства Выражайте свое мнение непосредственно, но дипломатично Выслушивайте их точку зрения и проявляйте сочувствие к их ситуации Выразите свою озабоченность их чувствами и желанием работать в конфликте Покажите, что их чувства вам важны и вы хотите работать, преодолев конфликт Следите за тем, чтобы проблема была решена Напрямую работайте с ситуацией Приоритеты и предпочтения Стабильная и дружелюбная культура Надежность в приоритете Сосредоточьтесь на сотрудничестве и поддержке Цените тех, кто умеет работать в команде Избегайте высоких нагрузок и быстрого темпа работы Цените безопасность рабочей среды Избегайте давления, быстрых изменений и напряжения Работайте систематично 315 Модуль 13. Повысить свою значимость Соответствующий тип Профили системы DISC полезны при работе с менеджерами для определения стиля общения. На приведенной ниже диаграмме показано, чего можно достигнуть при работе со стейкхолдерами типа С. C Пропаганда и получение бай-ина Покажите, как ваши идеи приведут к качественному решению Представьте вашу идею четко и систематично Будьте готовы предоставить данные и факты, чтобы подтвердить ваш план Будьте точными и сфокусированными Спокойно реагируйте на их требования о дополнительных доказательствах Будьте настойчивы в выражении своих потребностей, но предоставьте достаточно информации и времени для ее обработки Опирайтесь на логику и данные для поддержки Будьте терпеливы, настойчивы и дипломатичны Урегулирование конфликта Непосредственно разрешайте сам конфликт Избегайте нерешенных проблем Основывайте ваши аргументы на фактах Не сдавайтесь только ради того, чтобы прекратить конфликт Дайте им возможность обработать информацию перед решением задач Приоритеты и предпочтения Уделите особое внимание объективности и надежности Логическая культура в приоритете Поощряйте точность Цените личную независимость Решайте проблемы автономно Применяйте тщательный анализ Цените людей, которые проявляют общую заинтересованность в результатах высокого качества Проверяйте дважды 316 Часть III. Вверх по карьерной лестнице Привлечение участников Будучи бизнес-аналитиками, мы имеем дело с разными типами стейкхолдеров. Но не все типы любезно взаимодействуют с нами. Как с ними работать? За годы практики бизнес-анализа я пришел к простой идее, которая помогала мне много раз в прошлом. Это проверенная идея: СНАЧАЛА нужно ОТДАТЬ, чтобы ПОЛУЧИТЬ. Смысл в том, что вы делитесь своими знаниями, прежде чем требуете ответы. Сделайте домашнее задание, чтобы подготовиться к встрече со стейкхолдером. Вы должны четко понимать: • бизнес-контекст; • среду; • специальную терминологию; • текущие задачи и болевые точки. Наглядные материалы значительно улучшают понимание сложных задач. Используйте всю известную, относящуюся к теме информацию, чтобы сделать хороший рисунок, отражающий контекст темы, которую вы хотели бы изучить. Не создавайте много страниц и не превышайте размер A3. Ограничьтесь указанием ключевых элементов, связанных с предстоящей встречей со стейкхолдерами. Вы можете подробно обсудить детали на более позднем этапе. Помните, что текущий рисунок является основой вашего дальнейшего анализа. Перед началом встречи кратко изложите повестку дня, ключевые темы для обсуждения, известные болевые точки и задачи на сегодняшний день. Затем представьте свой рисунок для наглядности. Сделайте паузу, чтобы стейкхолдеры могли усвоить представленную информацию и рисунок. Теперь пришло время запросить дополнительную информацию. Используйте рисунок в качестве основного элемента обсуждения. Рисунок на столе позволит вам: • подтвердить предположения; • разъяснить текущее состояние; • выявить скрытые проблемы; Модуль 13. Повысить свою значимость • обнаружить новые болевые точки; • создать набросок желаемого будущего состояния. 317 У стейкхолдеров появятся новые вопросы благодаря вашему рисунку. Подведем итоги того, чего вы достигли с помощью подхода. Отдавать • Представили полную картину предмета, который вы хотите изучить подробнее. • Продемонстрировали вашу готовность и знание бизнес-области. • Перечислили известные болевые точки и проблемы. • Сэкономили ценное рабочее время для текущей встречи и дальнейших переговоров. Получать • Завоевали внимание стейкхолдеров. • Привлекли стейкхолдеров к конкретной дискуссии. • Обнаружили новые темы дальнейшего анализа. • Поставили перед стейкхолдерами еще несколько вопросов для размышления. • Подтвердили предварительные выводы. Это серьезный список достижений! Поздравляю! 318 Часть III. Вверх по карьерной лестнице Электронное руководство Электронное руководство применимо к географически распределенным командам. Возможно, вы уже бывали членом виртуальной группы. В моей бизнес-области группы становятся все более культурно разнообразными. Уверен, что эти изменения требуют новых подходов к командному сотрудничеству. Хочу поделиться мыслями о том, как создать сплоченную и успешную виртуальную группу. Роли и зоны ответственности Как известно, работа с новой проектной группой начинается с изучения списка лиц, входящих в нее. Руководитель должен создать из этих людей эффективную и самоуправляемую команду. Для этого необходимы: • общая цель; • обмен мнениями; • взаимопонимание и обмен навыками и знаниями. Когда связь налажена, руководитель должен выполнить две ключевые функции: управление эффективностью и дальнейшее развитие группы. Руководитель связывается со всеми членами группы, чтобы согласовать их деятельность с целями проекта и меняющимся бизнес-контекстом. В то же время руководитель выступает в качестве координатора, обес­ печивающего доступность и надлежащее применение ресурсов. Задачи виртуального руководителя Непонимание между членами проектной группы может вызвать следующие проблемы: • отсутствие физического взаимодействия; • отсутствие личного контакта на встречах и переговорах; • недоверие (из-за двух вышеперечисленных факторов); • неуверенность в надежности друг друга; • отсутствие социального взаимодействия. Модуль 13. Повысить свою значимость 319 Качества виртуального руководителя При общении сосредоточьтесь на: • построении отношений, поддержке и сотрудничестве; • определении индивидуальных целей и задач; • поддержании осведомленности в группе о прогрессе; • изменениях в согласованных задачах; • доступности ресурсов; • поддержании позитивного поведения в группе. При выстраивании отношений сосредоточьтесь на своих: СОВ ЕТ СОВ ЕТ • открытости; • гибкости; • толерантности; • стрессоустойчивости. Прислушайтесь к тому, чего не можете увидеть. Используйте весь потенциал доступных коммуникационных технологий. Дополнительные качества виртуального руководителя Организаторские качества: • быть готовым работать в самых разных средах; • создавать удобство в любом доступном рабочем пространстве. В проектах повышенной сложности сосредоточьтесь на: • многозадачности; • управлении развивающимися средами (бизнесом, проектом). 320 Часть III. Вверх по карьерной лестнице Для развития личных качеств сосредоточьтесь на: • навыках, знаниях и опыте, которые повышают ваш авторитет; • умении учиться; • применении новых навыков; • стабильной личной жизни; • поддержке семьи в трудные времена. Чего следует избегать руководителю Виртуальные настройки вызывают множество невидимых проблем, которые могут поставить под угрозу вашу работу. При виртуальном руководстве не следует: • задерживать время ответа; • оставлять предложения без благодарности; • завышать требования к выполнению задач и срокам; • командовать и демонстрировать превосходство; • не уметь использовать доступные коммуникационные технологии. Навыки руководителя Успешный руководитель в электронном рабочем пространстве должен: • быть хорошим слушателем; • быть хорошим координатором (встречи, отчеты, распределения задач и т. д.); • уважать культурные взгляды и графики окружающих; • четко понимать нормы взаимодействия и язык (иногда жаргон допустим); • быть надежным и разрешать конфликты; • быть оптимистичным и устойчивым (ко времени, нагрузке и дефициту ресурсов); • эффективно работать с доступными коммуникативными ресурсами; • признавать успех окружающих и их вклад в командную работу; 321 Модуль 13. Повысить свою значимость • быть готовым пошутить, чтобы наладить взаимоотношения с членами группы; • быть готовым предоставить обратную связь и оказать помощь, если необходимо. Рекомендуемый подход Интересы, хобби Личные ценности Социальные предпочтения Язык (1 и 2) Культура Пол Часовой пояс Геолокация Периодичность предоставления отчетности Уровень активности Уровень терпимости Артефакты Стиль управления Шаблоны коммуникации Квалификация Ожидания Выделенная мощность Роль Ранг Имя Должность Я занимался электронными рабочими пространствами пару лет. Разработанная мной матрица представляет виртуальную команду. Думаю, вам она тоже будет удобна. 322 Часть III. Вверх по карьерной лестнице Требования: паттерны выявления Мы живем в эпоху постоянных перемен, о которых постоянно слышим из новостей о технологиях и бизнесе. Организации совершенствуются, стремятся идти в ногу со временем. Все больше проектов должны были быть завершены «вчера», то есть имеют сжатые сроки выполнения и высокий приоритет. Какие инструменты использует бизнес-аналитик, чтобы предоставлять своевременные и качественные результаты? Хотел бы представить вам паттерны выявления. По сути, это способы анализа бизнес-контекста организации. Каждый паттерн предоставляет информацию, которая поможет вам собрать все необходимые данные, чтобы верно указать требования и создать качественное решение. Уровни для исследования Как известно, ни одна организация не работает сама по себе. Бизнес-контекст распространяется на следующие уровни: • государственное регулирование; • отраслевые правила; • внутреннее управление. В рамках самого бизнеса необходимо рассмотреть еще несколько уровней внутреннего контекста: • бизнес-цели (краткосрочные и долгосрочные); • технологические цели (краткосрочные и долгосрочные); • формы взаимодействия (интерфейсы) с партнерами и вендорами; • деятельность конкурентов. Государственное регулирование Прежде чем перейти к записи требований, выясните, связаны ли с проектом какие-либо правительственные постановления. Возможно, Модуль 13. Повысить свою значимость 323 правительство провело аудит отрасли и выступило с инициативой по обновлению. У данного паттерна есть два преимущества. Первое заключается в том, что у вас есть основной ориентир для определения бизнес-потребности в изменении, потому что правительственная инициатива определяет масштаб изменений в регулировании отрасли. Второе преимущество заключается в том, что вы можете легко обсуждать этот масштаб изменений со стейкхолдерами проекта. Отраслевые правила Так называемые рыночные правила зависят от отраслевого регулирования. Эти правила определяют, как индустрия будет функционировать в новом режиме, какие методы, процессы и механизмы контроля должны быть внедрены, какой рыночный орган будет контролировать соответствие требованиям рынка. Изучайте отраслевое регулирование, чтобы узнать, как обработать внутри организации доступную информацию и выполнить комплаенс-требования отрасли. Вы поймете, какие данные следует собирать, какой формат данных можно получить и т. д. Также отраслевое регулирование устанавливает график рыночных процессов: когда (дата/время) и что (информация) доступно, кто может предоставить информацию (представители рынка или отрасли) или кому ее нужно передать (представителю рынка или отрасли). Внутреннее управление Внутреннее управление — это дополнительная область для выявления требований и бизнес-правил, регулирующих бизнес-процессы. Оно отражает интерпретацию рыночных правил в бизнес-правилах и определяет внутренние бизнес-правила, контролирующие выполнение бизнес-процессов. Понимая внутреннее управление, вы будете знать бизнес-правила, которые относятся к вашему проекту, роли бизнес-пользователей, их права доступа к деловой информации, а также конкретные требования к отчетности. 324 Часть III. Вверх по карьерной лестнице Бизнес-цели Слишком очевидно соблюдать рыночные правила так, как указано. Тем не менее, внимательно рассмотрев бизнес-цели, вы поймете, что потенциальное решение требует дополнительных действий для поддержки стабильности бизнеса при долгосрочном сотрудничестве. Например, организация может расширить некоторые операций в будущем, чтобы решение могло обеспечить масштабируемость и функционирование бизнеса в будущем. Технологические цели Любое требуемое решение будет находиться в пределах существующей информационной среды, созданной организацией. Таким образом, нужно учитывать знание текущего состояния технологии и ее улучшений (модернизация/замена/новая технология) при обнаружении требований. Бизнес-аналитик должен учитывать операционную среду (операционные системы и другие компоненты) будущего решения. Изучив технологические цели, вы сможете определить требования к разрабатываемому решению. Например, обычная Windows XP не поддерживается с апреля 2015 года. Целью технологии может быть переход к Windows 8.1 или 10, поэтому вам нужно добавить требование, определяющее совместимость решения с Windows 8.1 или Windows 10. Или для хранения данных организации может потребоваться совместимость с Windows Server 2012, поскольку Windows 2008 R2 сегодня применяется во многих организациях, и т. д. Интерфейсы Настало время поговорить о взаимодействии организации с ее парт­ нерами, конкурентами и вендорами. Слово «интерфейс» в данном случае используется в широком смысле. Организация взаимодействует с вендорами и партнерами посредством технологических интерфейсов и бизнес-процессов для обмена информацией. Паттерн выявления здесь основан на поиске события, запускающего действия обеих сторон, коммуникации между сторонами, входных и выходных данных, форматах данных и применяемых протоколах обмена данными. 325 Модуль 13. Повысить свою значимость Деятельность конкурентов Конкуренты и их действия образуют еще один паттерн выявления. Знания о решениях и управлении бизнесом в отрасли, которые они используют, могут помочь вам определить требования для создания конкурентных преимуществ вашей организации. На следующей схеме проиллюстрированы описанные паттерны. Пользуйтесь ей в качестве вспомогательного инструмента. СОВ ЕТ Изучайте новости отрасли внимательно, следите за тенденциями в области применения бизнес-технологий, анонсами новых подходов, несоблюдением требований или установлением требований к качеству. Граница организации Цепочка ценности Государственное регулирование Регулирование отрасли Внутренний контекст Внутренне управление Бизнес-цели Бизнес-процессы Партнеры Рабочие потоки, доступ, разрешения Роли (персонал) Развитие технологий Приложения, хранилища, операционная среда Интерфейсы Поставщики Технологии Конкуренты 326 Часть III. Вверх по карьерной лестнице Требования: паттерны Работая над несколькими проектами в прошлом году, я заметил между ними сходство (требовались эволюционные улучшения). В результате я применил к решениям аналогичные наборы требований. Другими словами, паттерны. Стивен Уитхолл впервые представил идею паттернов требований в своей книге Software Requirement Patterns («Паттерны требований к программному обеспечению», Microsoft Press, 2007). Паттерн требований — это шаблон, помогающий написать какой-либо тип требований. Каждый паттерн определяет, какую информацию нужно собрать для выбранного типа требований, какие элементы следует включить и чего нельзя упускать. Цель использования паттернов — экономия времени. С помощью паттерна вы не изобретаете что-то, а берете то, что уже сделано. Многие организации, например, постоянно совершенствуют свои устаревшие системы, чтобы избежать крупных инвестиций в новые решения «c нуля». Поэтому ко многим проектам в них применяют сходные требования. Даже вновь созданные системы этих организаций будут иметь со старыми системами общие черты из-за устоявшейся практики и характера бизнеса. Три категории паттернов В своей работе я применяю три категории паттернов: • функциональные; • пользовательского опыта; • нефункциональные. Функциональные паттерны Работу над новым решением я начинаю с первого паттерна — определения компонентов. Довольно часто всего несколько компонентов решения оказываются новыми, а остальные используются повторно. У этого паттерна есть два преимущества. Во-первых, меньше времени требуется на разработку четкого обзора решения. Оно становится понятным, менее сложным. Во-вторых, вы можете легко передать концепцию и сферу применения решения стейкхолдерам проекта. Второй паттерн — это идентификация объектов, которые будут использоваться в решении. Например, следующие объекты могут быть Модуль 13. Повысить свою значимость 327 частью решения: клиент, поставщик, счет-фактура, место на складе и т. д. Важно отметить, что метаданные, связанные с этими объектами, будут использоваться во многих функциональных и бизнес-требованиях. Любое решение находится в информационном ландшафте, используемом организацией. Таким образом, интеграция с существующей средой (входы и выходы) является следующим используемым паттерном. Существующий ландшафт определяет доступные паттерны, и вы просто применяете их к новому решению. Подтверждение интеграции данных в информационном потоке необходимо при коммуникации между системами. Вы можете повторно применять установленные правила, но убедитесь, что новые данные последовательно проверены. Транспарентность данных может показаться расплывчатым понятием. Этот паттерн подразумевает доступ к данным из разных частей решения. Например, доступ к финансовым операциям должен быть частично открыт из клиентской базы, если это необходимо сотрудникам для выполнения работы. СОВ ЕТ Довольно часто существующие решения определяют объекты, которые будут использоваться, поэтому уточните, какие изменения потребуются для согласования дополнений к текущему решению. Преобразование данных более известно как бизнес-логика. Вы можете повторно использовать некоторые подходы для отражения бизнес-логики, но обычно это совершенно новые функции, вводимые в решение для поддержки изменений в бизнес-среде. Паттерн обработки ошибок подразумевает использование существующих обработчиков. Повторно применяйте существующие конструкции к новым элементам. Наконец, паттерн ведения учета позволяет указать требования к хранению бизнес-данных в репозитории. Существующие технологии и внутренние стандарты помогут вам в работе с требованиями. Паттерны пользовательского опыта Паттерны пользовательского интерфейса определяют способ взаимодействия пользователя с новым решением. Интерфейс пользователя должен обеспечить результативность ввода данных вручную. Эргономические стандарты, применяемые к существующим частям решения, могут организовать последовательное подключение экранов и «скрытых» элементов управления. 328 Часть III. Вверх по карьерной лестнице Довольно часто организации применяют фирменные темы (например, внешний вид). Если вы расширяете фирменное решение, то источником паттерна будет руководство по бренду. Наконец, паттерны автоматического вывода определяют, как создавать запросы данных, отчеты и параметры их поиска, что и как можно распечатать, какие информационные панели должны быть доступны и кому. СОВ ЕТ С точки зрения бизнес-процессов вы можете повторно применять существующие пути расширения по мере необходимости. Нефункциональные паттерны Нефункциональные требования считаются неважными и часто остаются в тени. Это приводит к нежелательным последствиям после ввода решения в эксплуатацию. В этот момент проблемы возникают довольно быстро. Универсального списка нефункциональных требований нет, но хочу поделиться теми, которые я применял в своих многочисленных проектах. Надеюсь, они будут вам полезны. Вот мой список (неполный): • доступ пользователей (безопасность, авторизация, администрирование аккаунта, полномочия по ролям); • доступность и надежность (например, 24×7 @ 99.99 %, по режиму / в нормальное рабочее время); • аварийное восстановление данных (время на восстановление, допустимая потеря данных, возврат к полноценному функционированию системы); • резервное копирование (график, срок хранения); • производительность (конкурентное использование, время ожидания) и ее мониторинг; • совместимость и интеграция (с текущим/будущим IT-ландшафтом и инфраструктурой); • портативность (функционирование на нескольких платформах); • аудиторский след (соблюдение рыночных требований и внутренний аудит); 329 Модуль 13. Повысить свою значимость СОВ ЕТ • техническое обслуживание и поддержка (частота обновлений/патчей, часы работы службы поддержки); • окна сбоев/изменений (продолжительность, уведомления); • удаленный доступ (безопасность, доступность, надежность, аварийное восстановление данных); • документация решения (исполнительная (обязательно!) и руководство пользователя); • локализация (если требуется). Вы можете расширить или изменить представленный список в соответствии с вашими потребностями. Компоненты Производительность Объекты Доступность (в рабочее время) Проверка данных Транспарентность данных Восстановление Преобразование данных Обработка ошибок Функциональные Нефункциональные Безопасность Интеграция Ведение учета Аудит ТЕКУЩЕЕ РЕШЕНИЕ(Я) ТЕКУЩЕЕ РЕШЕНИЕ(Я) НОВОЕ РЕШЕНИЕ Автоматическая интеграция (ввод) Автоматическая интеграция (вывод) Опыт пользователя CSV XML Пользовательские настройки в режиме реального времени CSV XML Пользовательские настройки в режиме Смотри и чувствуй реального времени Автоматический вывод Ввод данных вручную Запросы Отчеты Вывод Панель приборов данных на экран 330 Часть III. Вверх по карьерной лестнице Неточные требования: последствия Качество требований может сильно повлиять на результаты проекта. И это влияние увеличивается, когда бизнес-аналитик переходит от пользовательских историй к требованиям высокого уровня, а затем к функциональным и нефункциональным требованиям. Доработка функциональных требований стоит дорого, поскольку эти требования определяют дизайн и техническую спецификацию решения. Рассмотрим влияние неточных требований с двух точек зрения. Организации осуществляют проекты, чтобы достичь стратегических целей. Неточные требования влияют на проект в отношении следующих аспектов: • масштаб проекта (неконтролируемое разрастание границ проекта); • бюджет проекта (пустая трата времени и денег); • ресурсы (низкий коэффициент использования или накладные расходы); • разработка бизнес-процессов (неполная информация о деятельности); • интерфейс пользователя (плохой дизайн и низкая эргономичность); • спецификация ПО (неточные требования к функциональности); • тестирование решения (негативный эффект плохой спецификации); • представление решения (трудоемкая и дорогостоящая доработка!); • интеграция решения (низкокачественные дизайн интерфейса и его спецификация). Неточные требования влияют на бизнес: • стратегические цели (упущенные возможности); • конкурентная позиция (потерянное преимущество); • соблюдение требований рынка (нарушения); • привлечение стейкхолдеров (потеря доверия); • производительность бизнес-процессов (неудачная разработка решения); • положительный пользовательский опыт (громоздкий дизайн пользовательского интерфейса); • увеличение расходов (пустая трата денег); • целостный IT-ландшафт (плохая интеграция). 331 Модуль 13. Повысить свою значимость Пути улучшения ситуации Необходимым условием успеха является согласование требований высокого уровня со стратегическими целями. Вы как бизнес-аналитик должны тесно сотрудничать со стейкхолдерами, строить доверительные отношения. Необходимо убедиться, что требования высокого уровня понятны стейкхолдерам, приняты и полностью согласованы, прежде чем перейти к бизнес-требованиям. Время, потраченное на определение и согласование требований высокого уровня, многократно окупится к концу проекта. Ниже я наглядно представил аспекты, на которые влияют неточные требования. Бизнес Проекты Бизнеснеобходимость Стратегические цели Конкурентная позиция Разработка бизнеспроцессов Привлечение заинтересованных с торон Пользовательский и нтерфейс Эффективные деловые отношения Спецификация ПО Положительный опыт пользователя Тестирование решения Влияние на Целостный IT-ландшафт Влияние более менее Требования высокого уровня Бюджет проекта ($/время) Ресурсы проекта Соблюдение рыночных требований Увеличение доходов Масштаб проекта Влияние на Бизнес-аналитик Бизнестребования Функциональные требования Плохо определенные требования Доработка кода Интеграция решения Нефункциональные требования 332 Часть III. Вверх по карьерной лестнице Управление изменениями Управление изменениями — это подход к планированию перехода от текущего состояния к желаемому будущему. Этот шаг требует тщательного планирования, основанного на хорошем понимании нескольких характеристик изменений. Управление изменениями За годы моей практики я пришел к выводу, что обнаружить характеристики изменений может быть нелегко. Сотрудничество с проектной группой и основными стейкхолдерами помогает определить эти характеристики и составить правильную картину того, что должно быть реализовано для успешного перехода. Используйте иллюстрацию, представленную ниже, в качестве удобного инструмента для оценки изменений. Управление изменениями включает следующие основные этапы: • определение причин; • определение масштаба; • оценка влияния; • определение источников сопротивления; • разработка стратегии внедрения; • повторное использование существующих компонентов; • привлечение стейкхолдеров; • организация переходного периода; • упрощение внесения. Расположение Матрица заинтересованных сторон Процессы Технологии Новые технологии Рыночный спрос Деловые потребности Укажите и документально зафиксируйте требуемые изменения Определить, что и как следует изменить Определить и документально зафиксировать существующий контекст Тайминг Продолжительность Культура Организация Риски Ограниченные возможности Причина изменений Масштаб изменений Оценка воздействия Источник сопротивления Управление изменениями Регулирование Показать эффективность измененных процессов Продемонстрировать добавленную стоимость изменений Повторное применение Поощрение быстрых результатов посредством демонстрации улучшений в рамках всего предприятия Использовать матрицу заинтересованных сторон Поддерживать изменение убеждений и ценностей Продемонстрировать преимущества изменений в крупных масштабах Развертывание новых инструментов и процессов Технологические процессы Принять меры, направленные на получение отклика Мониторинг быстроты реакции Применение информационных мер Изменение организационной культуры Внедрение изменений Привлечение заинтересованных сторон Содействие принятым изменениям Поведенческие изменения Разработка стратегии изменений и действий Перенаправить движущие силы Устранить хаос Действия, которые необходимо предпринять Страх сокращения Неопределенность Отсутствие доверия Причины личного характера Отсутствие гибкости Масштаб Важность Предложить новое состояние Определить повторно применяемые части Тактика Стратегия общения Матрица влияния Отсутствие навыков Потеря мощности Модуль 13. Повысить свою значимость 333 334 Часть III. Вверх по карьерной лестнице Управление рисками В целом управление рисками — это двухэтапный процесс. Во-первых, вы определяете, какие риски или изменения могут произойти во время работы над проектом; во-вторых — находите способы обработки этих рисков, которые наилучшим образом подходят для вашего проекта или изменения. Управление рисками осуществляется во всем деловом мире и необходимо для достижения желаемого результата. Используйте иллюстрацию структурированного подхода к управлению рисками при работе над оценкой рисков. В управлении рисками есть следующие ключевые этапы: • планирование; • обнаружение; • анализ; • создание профиля; • смягчение; • мониторинг и контроль. Установить методы, которые будут использоваться Определите основание для оценки рисков Категории тяжести риска Устойчивость к рискам Классы риска: угрозы Возможности Предупреждающий знак Источник(и) Качественный анализ, ранг Анализ риска Плановый подход Смягчение рисков Создание Риск Профиль Взаимодействие рисков Коррекционная деятельность Используйте профили рисков для повышения осведомленности Соблюдение плана Временное решение Принимать И ТО И ДРУГОЕ Непредвиденные условия Планирование реагирования на риски Применять Делиться Укреплять ПОЗИТИВНОЕ Избегать Перевод Смягчать НЕГАТИВНОЕ Регулярные отчеты о степени риска Регулярные отчеты о профилях риска Обновлять план реагирования по необходимости Мониторинг и контроль рисков Выявление рисков Класс Источник Степень Область воздействия Владелец Область, на которую оказано воздействие (верхняя/нижняя) Степень риска Управление рисками Анализ влияния Определение риска Количественный анализ (подобие) Общие/ индивидуальные риски Модуль 13. Повысить свою значимость 335 336 Часть III. Вверх по карьерной лестнице Разрешение проблем Эффективное разрешение проблем (issue management) всегда было важно для успешного внедрения изменений. И оно необходимо в современных условиях, когда развивающийся мировой рынок напрямую влияет на организации и проекты. Разрешение проблем осуществляется в соответствии со структурированным подходом, который проиллюстрирован ниже. Рисунок может быть полезен при оценке проблем и разработке способов их разрешения. Разрешение проблем включает следующие основные этапы: • планирование; • определение; • анализ; • создание профиля; • разрешение; • мониторинг и контроль. Участие заинтересованных сторон в решении задачи Определение - подходов к решению задач - категории серьезности задачи Категории задач: Коммуникации Требования Разработка ... Источник(и) Владелец Характер Причина(ы) Степень Привлеченные заинтересованные стороны Плановый подход Определение задачи Анализ задачи Анализ влияния Осуществлять резолюцию Корректирующие действия Планирование реагирования на риски Эскалация Решить Сообщать о разрешении для повышения осведомленности Следование плану реагирования Id задачи Категория Источник Степень Область воздействия Владелец Тот, кому назначено Дальнейшие действия Решить до определенного срока Регулярные отчеты о степени риска Регулярные отчеты о профилях риска Мониторинг/ контроль задачи Решение задачи Создание профиля задачи Создание реестра задачи Управление задачами если решена Область, на которую оказано воздействие (верхняя/нижняя) Время Бюджет Масштаб Модуль 13. Повысить свою значимость 337 338 Часть III. Вверх по карьерной лестнице Универсальная функциональная бизнес-модель Помните, что мы говорили о способах изучения новой области знаний (С. 21). Существует еще один эффективный способ для новичков начать анализировать бизнес и его функционирование. Обычно я использую модель, которую создал при работе над проектом внедрения ERP. Она описывает ключевые функции организации независимо от характера бизнеса. Включайте в нее конкретные детали, если знаете, какие услуги и товары организация продает и потребляет. Конечно, ваша организация может иметь больше функций, чем показано в модели. Можете добавить детали. Модель — это удобный инструмент для работы. Уникальность организации заключается в ее конкретных товарах и услу­ гах. Процессы, как правило, в организациях одинаковы, но управление может включать некоторые дополнительные шаги и внутренние бизнес-правила. На следующей схеме показана универсальная функциональная бизнес-модель. Цепочка поставок Клиенты Поставщики/партнеры Сущность Управление взаимоотношениями с клиентами Заказы клиентов Товары Услуги Задолженность на счетах Заказ на поставку Инвентаризация Бухгалтерский учет и налогообложение Банковское дело Руководящие органы (управление) Банки и инвесторы Управление взаимоотношениями с поставщиками Неликвидные активы Кредиторская задолженность Модуль 13. Повысить свою значимость 339 Пользовательский опыт Начнем с цитаты: «Опыт пользователя — это то, что пользователь чувствует в результате использования системы. Опыт пользователя включает эмпирические, аффективные, значимые и ценные аспекты взаимодействия человека и компьютера и права собственности на продукт. Опыт пользователя также охватывает восприятие человеком таких аспектов, как полезность, простота использования и эффективность системы. Опыт пользователя носит субъективный характер, поскольку речь идет о производительности, чувствах и мыслях человека о системе. Пользовательский опыт динамичен, поскольку он изменяется по мере смены обстоятельств» (Википедия). Перед проведением бизнес-анализа нужно убедиться, что в решении присутствуют все элементы, оказывающие влияние на пользовательский опыт. Итак, каковы эти элементы? • Ориентированный на задачи дизайн; • желаемая функциональность для выполнения задачи; • простота ввода данных, удобство использования; • видимость реакции системы на пользовательский ввод; • последовательная реализация интерфейса пользователя; • язык предметной бизнес-области, соответствующий реальному миру; • эффективная обработка ошибок; • конкретные и полезные системные сообщения; • эргономичность; • интеграция с социальными сетями. Уверен, у каждого из вас есть одно или два устройства, решающих множество задач. В наши дни технические возможности смартфонов создают серьезную проблему для бизнес-аналитика. Трудно, например, правильно определить множество функций, охватывающих навигацию, связь, фотографию, возможности оплаты, NFC и т. д. Давайте рассмотрим потребности пользователей, чтобы убедиться, что решение обеспечит позитивный пользовательский опыт: • связь — работает везде, в любое необходимое время; • надежность — работает, когда захочу; 340 Часть III. Вверх по карьерной лестнице • визуальное воздействие — мне нравятся внешний вид и ощущение; • многоязычный — установлен мой язык, есть возможность переключать языки по необходимости; • быстрое обучение — могу эксплуатировать его практически сразу; • производительность — просто выполняет работу, для которой предназначен; • обмен сообщениями — позволяет реагировать, когда мне это нужно; • быстрый ввод данных — угадывает, что я хочу; • развлечение — получаю развлечения, которые хочу; • социальная активность — могу делиться тем, чем хочу. Паттерны навигации становятся наиболее сложными, поскольку устройства теперь могут обрабатывать различные уровни давления на экран. В старые добрые времена бизнес-аналитик мог указать, какую кнопку нажать. Теперь он изучает, где вы можете свайпнуть и коснуться экрана и с какой силой. Открывается совершенно новое измерение при проработке требований. Давайте рассмотрим, какие паттерны навигации мы можем использовать, чтобы правильно указать необходимые возможности. Панели команд Панели команд предоставляют пользователям быстрый доступ к часто используемым действиям, таким как поиск, обмен данными и создание нового контента в приложении. Уведомления Люди потребляют много информации каждый день. В то же время пользователи заняты, не могут постоянно эксплуатировать свои мобильные устройства и хотят получать уведомления о новостях в интересующих их областях, но читать содержание позже. Модуль 13. Повысить свою значимость 341 Скрытые элементы управления Мне они нравятся, поскольку не загромождают экран. У мобильных приложений есть элементы управления, которые активны в определенной части приложения. Паттерн разработки скрытых элементов управления позволяет пользователям находить дополнительные элементы управления с помощью жестов: прокрутка, быстрое нажатие, двойное нажатие, длительное нажатие и т. д. Руководство по эксплуатации Практическая польза продукта — ключ к его востребованности. Хороший способ научиться эффективно использовать приложения — это пройти начальное пошаговое руководство, чтобы увидеть, как работает каждая функция. Контентная навигация Контентная навигация — это паттерн разработки, используемый для плавного перехода от обзора к подробному описанию состояния. Использование этого паттерна направлено на то, чтобы сделать работу пользователя и поток содержимого максимально плавными. Выдвижное и боковое меню У современных смартфонов небольшие экраны по сравнению с компьютерами и телевизорами. Чтобы собрать большое количество полезной информации на малой пощади и избежать помех, вы можете использовать выдвижное и боковое меню для навигации между разными частями приложения. Эти паттерны являются второстепенными разделами таких приложений, как карты, чаты, пользовательские профили и т. д. Дополнительные функции находятся в многоуровневых разворачивающихся меню, кнопках со стрелкой, которые выдвигаются, или боковых панелях. Таким образом, пользователи могут взаимодействовать с наиболее важной информацией на каждом экране, выбирая раздел на скрытых панелях. СОВ ЕТ Не забудьте активировать доступные пошаговые руководства и советы пользователю. 342 Часть III. Вверх по карьерной лестнице Создание карты клиентского опыта Создание карты клиентского опыта (CEM, сustomer experience map­ ping) — ценный метод бизнес-анализа. Однако он не включен в список методов, рекомендованных системой BABOK®. CEM — это визуальное представление ожидаемого использования решения отдельными лицами. Решение рассматривается с точки зрения высокого уровня, чтобы проверить его осуществимость и получить поддержку стейкхолдеров. Суть этого метода — в сокрытии технической и функциональной сложности искомого решения и концентрации внимания на потребностях клиента. Благодаря этому мощному методу работа с решением будет согласованной и заявленные потребности клиентов будут удовлетворены. Также метод поможет наладить общение стейкхолдеров на многофункциональных воркшопах. Рассмотрим практический пример. Представьте проект, задачей которого является предоставление цифровых сервисов существующим клиентам организации. Клиент должен подписаться на использование продукта. Следующие принципы станут основой для открытия решения и положительного пользовательского опыта: • просто регистрироваться; • легко использовать; • безболезненный опыт. Компоненты карты клиентского опыта • Жизненный цикл использования продукта (решения). Основные этапы, через которые проходит клиент, используя продукт (решение). • Точки взаимодействия. Точки взаимодействия, в которых клиент и продукт (решение) обмениваются входными и выходными данными во время жизненного цикла использования продукта (решения). • Happy path (от края до края). Путь приобретения нового клиента и удерживания его как довольного клиента. • Альтернативные пути. Пути прекращения использования продукта (решения) клиентом с указанием точек взаимодействия, в которых это произошло. Модуль 13. Повысить свою значимость • 343 Партнеры (необязательно). Деловые партнеры, ответственные за доставку товара. • Коммуникационные потоки между организацией и ее партнерами (необязательно). Общение организации с ее партнерами. СОВ ЕТ Всего точек взаимодействия должно быть от 6 до 10, чтобы сосредоточиться на опыте клиента, а не на дизайне решения. Компоненты карты клиентского опыта: подробно • Жизненный цикл использования продукта (решения). Может состоять из следующих этапов для предложенного примера: • ♦ формулировка желания; ♦ оценка; ♦ регистрация; ♦ доставка; ♦ использование; ♦ прекращение использования. Точки взаимодействия. Точки взаимодействия, соответствующие фазам жизненного цикла продукта (решения), можно назвать так: • ♦ любопытство; ♦ обучение; ♦ «Я в деле!»; ♦ получение продукта; ♦ «У меня есть вопрос...»; ♦ «Я ухожу». Happy path* (кольцо). Для данного примера понятие happy path будет включать в себя следующие этапы: ♦ любопытство; ♦ обучение. * Счастливый путь — это сценарий по умолчанию, не содержащий исключительных условий или условий ошибки. — Примеч. ред. 344 Часть III. Вверх по карьерной лестнице ♦ «Я в деле!»; ♦ получение продукта; ♦ «У меня есть вопрос...» Если вы представите дополнительный продукт, то этап «У меня есть вопрос ...» вернет клиента на начальный этап, образуя закольцованный путь использования. • Альтернативные пути. В реальности бывает, что клиента не заинтересовывает предложенная идея. Или по другим причинам клиент решает прекратить использование продукта. В таких случаях альтернативные пути идут прямо до конца работы с клиентами. • Партнеры. Довольно часто организация взаимодействует с внешними организациями для доставки продуктов (решений) клиентам. Если хотите, добавьте сведения о партнерах в карту. • Коммуникационные потоки между организацией и ее партнерами. Последний штрих — показать ключевые взаимодействия между организацией и ее партнерами. Потоки данных в этом случае сделают картину более полной и помогут укрепить сотрудничество с партнерами. Карта клиентского опыта: итоги На карте отображаются следующие результаты: • ключевые точки взаимодействия; • действия, данные и потоки данных (входных и выходных) в точках взаимодействия; • организация и ее партнеры; • процесс согласования между организацией и ее партнерами; • процессы, на которые оказано влияние (текущие); • требуемые бизнес-процессы (будущее); • текущие роли, на которые было оказано влияние; • личный опыт в жизненном цикле продукта; • поддерживающие системы (текущие и будущие). Карта клиентского опыта показана ниже. Кампании Обеспечение и поддержка установочный пакет и активирует продукт 4 Клиент загружает Организация Клиент решает зарегистрироваться через интернет портал Жду не дождусь! Мой аккаунт (через портал) Приветственный пакет Партнеры Клиент пользуется продуктом, но иногда возникают вопросы Партнеры 5 У меня есть вопрос... Годовая плата Альтернативный путь 3 Я в деле! Использование Мой аккаунт (через портал) Сеть Happy Path Получение Основные этапы работы с клиентами Подписка Жизненный цикл продукта Ключи регистрации Легенда Клиент может быть не заинтересован предложением Маркетинговые кампании об объявлении нового продукта и его пробы 2 1 Маркетинговые кампании сообщают о новом продукте и запускают его Дайте взгялнуть... Оценка Вам понравится... Генерация желания Карта опыта пользователя 6 Клиент решает прекратить использование продукта Я ухожу... Завершение использования Прекратить поддержку и отписаться Обновление Поддержка Варианты исследований 346 Часть III. Вверх по карьерной лестнице Паттерны анализа: большие данные Популярное в сети с 2012 года словосочетание «большие данные» стало общеизвестным термином. Большие данные везде. Социальные взаимодействия, личные и рабочие документы, электронные письма и т. д. Поскольку обмен данными становится проще, с каждым днем он применяется все больше. Что такое большие данные? Хороший вопрос. Термин означает огромное количество доступных данных. Это всего лишь данные, но в очень больших объемах. Горные хребты, огромные водопады, безбрежные океаны. Большие данные — это наборы данных, которые настолько огромны или сложны, что традиционные приложения не подходят для их обработки. Большие данные не связаны с объемом данных. Все дело в аналитике, раскрывающей скрытые ценности бизнес-информации. Aotea Studios Проблемы обработки больших данных: • сбор данных; • источники данных; • синхронизация данных; • анализ; • поиск; • обмен; • хранение; • передача; • визуализация; • информационные модели; • конфиденциальность информации. Как бизнес-аналитики могут использовать большие данные? 347 Модуль 13. Повысить свою значимость Как видите, список проблем довольно внушительный. Как бизнес-­ аналитик справится с большими данными, чтобы помочь решить бизнес-проблему? Бизнес-проблемы позволяют применять разные точки зрения, которые определяют, какие данные необходимы, как их классифицировать, какие измерения и инструменты использовать для получения желаемой информации. Рассмотрим эти точки зрения более подробно. Решаемые задачи Проблемы в основном ограничены рамками отрасли, поэтому для начала вы можете использовать отраслевую классификацию. ЗАДАЧИ Утилиты Потоки доходов, отток клиентов, модели потребления, прогнозирование, принятие решений Розница Уход клиентов, модели потребления, сегментация, обработка вызовов, оптимизация продаж, оптимизация логистики Энергия Модели спроса, оптимизация нагрузки, обнаружение сбоев, исследование и разработка Безопасность Нарушения безопасности, утечка данных, активность вредоносного ПО, попытки несанкционированного доступа Финансирование Мошенничество, отмывание денег Аудитория информационных пользователей Стейкхолдеры, которые требуют понимания причины проблемы, бывают разные, и их точки зрения тоже. Вот несколько примеров. ПОТРЕБИТЕЛИ Процессы Слабые места, исключения, задержки, отставание Интерфейсы Потеря данных, производительность, обнаружение сбоев Приложения Производительность, обнаружение сбоев, несанкционированный доступ Хранилище данных Потеря данных, качество данных Сетевой трафик Слабые места, потеря пакетов, обнаружение сбоев 348 Часть III. Вверх по карьерной лестнице Форматы данных Данные могут быть доступны в разных форматах, определяющих способ сбора и обработки информации. Общие форматы данных: ФОРМАТ Структурированные Реляционные базы данных (например, MS SQL, Oracle) Слабоструктурированные данные Текст, документы Неструктурированные Изображения, аудио, видео Скорость обработки данных Данные могут быть доступны в разное время, что определяет способ сбора, хранения, предварительной обработки, а затем разделения собранных данных. Общие частоты данных: СКОРОСТЬ По требованию Социальные сети В реальном времени Биржевые данные, датчики, погода Временные ряды Временные пакеты Источники данных Данные могут быть доступны из разных источников, определяющих правила сбора и обработки информации. Общие источники данных: ИСТОЧНИК Созданные человеком Сеть и социальные сети Созданные машиной Датчики, триггеры, счетчики, CCTV Смешанные Приложения 349 Модуль 13. Повысить свою значимость Инструменты обработки Данные в зависимости от категории могут быть обработаны по-разному. Вот некоторые примеры: ИНСТРУМЕНТ BW Библиотека деловых данных SAP RD B M S Oracle, MS SQL, DB2 Ad-h o c SAS, Hadoop, R, Pentaho BI Заключение Ниже описаны основные функции бизнес-аналитика: • понять бизнес-потребности; • прояснить текущую сложность; • составить из бизнес-потребностей требования; • подтвердить, что решение соответствует намеченной цели. Бизнес-анализ применяется в различных отраслях, поэтому, чтобы оставаться востребованными, бизнес-аналитики должны постоянно учиться. Одна из целей этой книги заключалась в том, чтобы предоставить вам направления для дальнейших действий. Хочется верить, что благодаря этой книге вы хорошо представляете инструменты и методы бизнес-анализа и необходимые навыки успешного бизнес-аналитика. Надеюсь, вы убедились, что необходимо изучать дисциплины за пределами бизнес-анализа. Обязательно добавьте несколько полезных инструментов, изученных в книге, на панель инструментов бизнес-анализа. Желаю вам отличных проектов и успехов в карьере. Чтобы успешно стартовать в любом деле, постройте себе трамплин из проверенных знаний и инструментов. Aotea Studios Глоссарий, а также список английских терминов и аббревиатур можно найти и скачать по ссылке:
