Вадим Миронов Профессия «бизнесаналитик». Краткое пособие для начинающих Текст предоставлен правообладателем Профессия «бизнес-аналитик». Краткое пособие для начинающих. 3-е изд., испр. и доп.: Олимп-Бизнес; Москва; 2023 ISBN 978-5-9693-0515-1 Аннотация Бизнес-анализ – востребованная и увлекательная дисциплина, без которой невозможно представить современный ИТ-проект. Но каждого, кто решит начать работу в этой сфере, ждет множество вопросов. Где учиться на бизнес-аналитика? Что нужно знать и уметь? Каковы ключевые задачи аналитика и инструменты для их решения? На эти и многие другие вопросы в своей книге отвечает Вадим Миронов, бизнес-аналитик с опытом работы в банковском и ИТ секторах. В третьем издании автор затрагивает тему принятия взвешенных управленческих решений, рассказывает о главной книге бизнес-анализа – BABOK, а также освещает разные точки зрения на профессию бизнес-аналитика. Читатель познакомится с краткой историей развития бизнес-анализа и возможными перспективами этого направления. Если вы задумались о карьере в бизнес-анализе или просто хотите лучше понимать его роль в современной организации – эта книга для вас. Издание будет интересно широкому кругу специалистов из бизнеса и ИТ-сферы, а также студентам и преподавателям соответствующих специальностей. Содержание Предисловие к третьему изданию Предисловие ко второму изданию От автора Глава 1 1.1. Суть аналитики, или Зачем аналитик в бейсбольной команде? 1.2. Важность причинно-следственного контекста 1.3. Виды аналитики 1.4. Еще раз о размытости границ 1.5. Краткая история бизнес-анализа[10] 1.6. BABOK. Главная книга бизнес-анализа Глава 2 2.1. Роль бизнес-анализа в современной организации 2.2. Ключевые задачи бизнес-аналитика 2.3. В чем бизнес-аналитик участвует? 2.4. Роль бизнес-аналитика в ИТ-проекте 2.5. Моделирование бизнес-процессов как ключевой инструмент аналитика 2.6. Формулирование требований к программному обеспечению 2.7. Десять этапов создания требований к ИТ- 7 9 14 18 18 22 24 37 39 65 75 75 85 120 125 129 154 160 решению 2.8. Особенности коммуникации в бизнесанализе, или При чем здесь телешоу из девяностых «Пойми меня» 2.9. Электронная нервная система 2.10. Принцип ближайшей атомарной задачи, или Как обеспечить поступательный прогресс в параллельных проектах 2.11. Бизнес-аналитик и тестирование программного обеспечения 2.12. Принятие решений в бизнес-анализе Глава 3 3.1. Где учиться на бизнес-аналитика? 3.2. Десять советов начинающим бизнесаналитикам 3.3. Гибкие навыки бизнес-аналитика 3.4. Психологический настрой бизнесаналитика 3.5. От чего зависит успех бизнес-анализа 3.6. Инструментарий бизнес-аналитика 3.7. Собеседование Как создавалась эта книга. Вместо заключения Приложение Благодарности 197 204 210 224 237 248 248 250 259 266 272 283 293 300 303 306 Вадим Миронов Профессия «бизнесаналитик». Краткое пособие для начинающих 3-е издание, исправленное и дополненное © Миронов В., 2023 © Издание, оформление. Издательство «Олимп – Бизнес», 2022, 2023 *** Предисловие к третьему изданию Вы держите в руках третье издание книги «Профессия „бизнес-аналитик“. Краткое пособие для начинающих». С момента выхода первого издания в конце 2020 года книга претерпела существенные изменения: появилось семь новых разделов, а количество небольших дополнений и уточнений измеряется десятками. Отчасти это связано с обратной связью от читателей – вопросами, комментариями, предложениями. Кроме того, спустя время я старался критически оценить написанное в стремлении лучше донести до читателя ту или иную мысль. Это стремление: понять и быть понятым другими – и составляет квинтэссенцию работы бизнес-аналитика. Периодически у меня возникали новые идеи о том, что еще может оказаться для читателя интересным и полезным. На мой взгляд, книгу о бизнес-анализе можно писать бесконечно: настолько широки и разнообразны границы этой профессии. Бизнес-анализ всегда ориентирован на деятельность предприятия. А предприятие не существует в вакууме: непрерывно изменяется внешнее окружение, меняется сама компания, а со временем – и подходы к бизнес-анализу. Мир вокруг нас преображается с огромной скоростью. Сегодня в авангарде этих перемен – сфера информационных технологий. Еще каких-то 15–20 лет назад ИТ воспринима- лись, скорее, в качестве поддерживающей функции бизнеса. Сегодня многие его направления без ИТ не способны существовать в принципе. Большинство организаций, будь то завод, банк или государственное учреждение, стремительно переходят в «цифру». Подобный переход требует огромных интеллектуальных усилий множества людей: профильных специалистов, менеджеров, аналитиков, разработчиков и тестировщиков. Успех напрямую зависит от того, насколько все заинтересованные стороны четко понимают друг друга и осознают цель своего проекта. Недаром опытные аналитики говорят, что самое трудное в создании информационных систем – точно определиться с тем, что мы создаем. Именно поэтому профессия бизнес-аналитика так востребована сегодня. Бизнес-анализ – ключевой инструмент для осмысленной, взвешенной, практичной цифровой трансформации, нацеленной на развитие организации. Умение задать правильные вопросы, взглянуть на ту или иную задачу с разных точек зрения, а также здоровый скептицизм – вот для чего в ИТ-проектах нужны бизнес-аналитики. И совершенствоваться в этом направлении можно бесконечно. Предисловие ко второму изданию Мы живем в эпоху цифровой трансформации. За этими словами скрывается всё более стремительное проникновение информационных технологий в нашу жизнь. Всего за 10–15 лет появилось поколение людей, которые не знают, почему иконка «Сохранить» в офисных приложениях выглядит как дискета. Гибкий магнитный диск как носитель информации быстро и незаметно исчез из нашей жизни. Смартфоны приходят на смену настольным компьютерам, а стриминговые платформы – телевидению. За покупками теперь и вовсе не нужно выходить из дома: специализированные сервисы доставят всё что угодно – от продуктов питания до дорогостоящей бытовой техники. Перемены затронули и профессии: одни изменяются, другие исчезают, и на их место приходят новые. Окружающая нас среда становится всё более цифровой, а значит, растет и потребность в специалистах с соответствующими навыками и компетенциями. Нехватка кадров в российской ИТ-индустрии в 2021 году составила от 500 тысяч до одного миллиона человек. Согласно прогнозам экспертов, к 2027 году нехватка ИТ-специалистов может достигнуть двух миллионов человек. Несмотря на то что конкурсы на соответствующие специальности бьют все рекорды, вузы не справляются с потребностями рынка. Каждый год в России заканчивают обучение не более 80 тысяч молодых айтишников 1. Нехватку кадров в ИТ-индустрии и потребность в цифровизации осознаёт и государство. Население России стареет: аналитики компании McKinsey подсчитали, что численность занятого населения на горизонте в 50 лет сократится в нашей стране на 29 %. При сохранении текущей производительности труда это грозит сокращением среднегодового прироста экономики на 60 %. Страны, столкнувшиеся с проблемой старения населения, делают ставку на цифровизацию, рассчитывая за счет нее повысить эффективность труда и стимулировать развитие экономики 2. В России запущена масштабная национальная программа «Цифровая экономика Российской Федерации». В рамках этой программы реализуются такие проекты, как «Кадры для цифровой экономики» и «Цифровые профессии». Данные проекты нацелены как на подготовку молодых специалистов, так и на обучение цифровым навыкам состоявшихся профессионалов из других отраслей. Сегодня ИТ-индустрия – это не только профильные ИТ-компании. Информа1 См.: Глинкин А. Кадровый голод. России не хватает миллиона IT-специалистов. На кого пойти учиться, чтобы обеспечить себе будущее? // Lenta.ru (https:// lenta.ru/). 27 июля 2021. URL: https://lenta.ru/articles/2021/07/27/golod/ (дата обращения: 16.11.2021). 2 См.: Кирьянова А., Нургазиева А. Что известно о «цифровой экономике»: текущий статус // CNews. № 78. 2.11.2017. URL: https://filearchive.cnews.ru/ mag/2017/11/CNews_78.pdf (дата обращения: 16.11.2021). ционные технологии стали неотъемлемой частью финансового сектора, промышленности, здравоохранения и многих других отраслей. И где бы вы ни работали, умение найти общий язык с разработчиками и инженерами становится всё более востребованным. Так что же, нам всем теперь дорога в программисты? Вовсе нет. Программирование – весьма специфический вид деятельности, требующий определенного склада ума и черт характера. Конечно, для волевого и упорного человека нет ничего невозможного, но очевидно, что написание кода – работа далеко не для всех. Вместе с тем в ИТ-индустрии существует множество других профессий. В Минцифре России отмечают, что, помимо «Java-разработчика», одними из самых популярных направлений проекта «Цифровые профессии» стали «Data Science», «Тестировщик ПО» и «Бизнес-аналитик»3. Именно профессии бизнес-аналитика и посвящена эта книга. Так кто же такой бизнес-аналитик? Обратимся к классике. В своем фундаментальном труде «Разработка требований к программному обеспечению» Карл Вигерс определил бизнес-аналитика как основное лицо, отвечающее за выявление, анализ, документирование и проверку требований к ИТ-проекту. Бизнес-аналитик – это основной канал коммуникации между группой бизнес-заказ3 См.: Глинкин А. Кадровый голод… чиков и командой разработки4. Не важно, как называется должность или какая методология разработки используется, – потребность в формулировании требований к ИТ-продукту в том или ином виде будет существовать всегда. От того, насколько качественно и обстоятельно проведен бизнес-анализ, во многом зависит успех любого проекта. Задача бизнес-аналитика – повысить вероятность получения заказчиком именно той функциональности, которая ему действительно необходима. Если в ИТ-проекте бизнес-анализу не уделяется должного внимания, неизбежно возникают ошибки, переделки, растут временнбые и финансовые затраты. И, конечно, усиливается взаимное недовольство. Вы держите в руках второе издание книги «Профессия „бизнес-аналитик“. Краткое пособие для начинающих». В него добавлены новые главы, а также внесено множество небольших исправлений и уточнений. Так, из нового издания вы узнаете: • какие сложности возникают во время коммуникации в бизнес-анализе; • какую часть тестирования ПО бизнес-аналитик может взять на себя; • как организовать свою работу так, чтобы контролировать сроки и потоки информации по нескольким параллель4 Вигерс К., Битти Д. Разработка требований к программному обеспечению. – СПб.: БХВ, 2021. ным проектам. В этой книге я постарался простым, не академическим языком поделиться с читателями личным опытом работы в роли бизнес-аналитика. Искренне надеюсь, что книга окажется интересной и полезной, а ваши проекты сделают мир лучше. Удачи! От автора Как и всякий молодой специалист, я довольно смутно представлял себе, кем буду работать после окончания университета. В середине нулевых моя специальность – «бизнес-информатика» – была новым направлением на стыке экономики и ИТ. Нас готовили к работе в области проектирования, создания и применения информационных систем в бизнесе. В университетском буклете перечислялось, по каким профессиям смогут работать будущие выпускники: веб-администратор, бизнес-консультант, контент-менеджер, программист. Был в их числе и бизнес-аналитик. Университет дал мне хорошие теоретические знания, но при этом у меня не было ни малейшего представления о практических аспектах работы бизнес-аналитика: как устроены рабочие процессы, какие инструменты необходимо использовать, как выстраивать коммуникацию с людьми. Всё это я узнавал на практике, уже устроившись на работу в банк. В то время в компаниях почти не встречалось системного, пошагового обучения молодых специалистов. Вопросы адаптации нового сотрудника полностью отдавались на откуп непосредственным руководителям. Мне повезло: руководство посвятило довольно много времени тому, чтобы ввести меня в курс дела. Погружение в работу по большей части заключалось в решении реальных практических задач. Поскольку цельного понимания профессии у меня на тот момент еще не было, смысл некоторых задач оставался для меня туманным. Ясность приходила по мере накопления опыта. Поговорив с людьми из разных направлений бизнеса и информационных технологий, я понял, что многие мои коллеги оказались в похожей ситуации. Все они в начале карьеры довольно смутно представляли себе суть будущей профессии. Какие задачи им предстоит решать? Где проходят границы их ответственности? Какие навыки необходимо развивать? Любой организации, будь то банк, завод или ИТ-компания, требуется время на погружение нового специалиста в работу. И, конечно, организация заинтересована в том, чтобы данный процесс проходил максимально быстро и эффективно. Моя книга задумана как настольное пособие для начинающих бизнес-аналитиков. Неважно, пришли ли вы в эту увлекательную профессию со студенческой скамьи или имеете за плечами солидный опыт работы в других областях. Задача книги – помочь вам сориентироваться в профессии и как можно быстрее вникнуть в рабочие процессы. Иными словами, сделать ваше погружение в мир бизнес-аналитики последовательным и осознанным. Кроме того, мне всегда казалось, что бизнес-аналитикам уделяется незаслуженно мало внимания. Взять хотя бы про- фессиональные праздники в индустрии ИТ. День программиста есть, День тестировщика тоже. А Дня бизнес-аналитика нет! Я уж и не говорю о профессиональной литературе. Сколько замечательных книг посвящено разработке и тестированию программного обеспечения, дизайну приложений и управлению проектами. А вот книг по бизнес-анализу практически нет. «Видимо, придется писать самому», – подумал я. На мой взгляд, профессия бизнес-аналитика – одна из самых интересных в ИТ-индустрии. Дело в том, что анализировать можно деятельность любой компании: здесь нет жесткой отраслевой привязки. Сегодня вы работаете над проектом для крупного банка, а завтра – для энергетической компании или завода. Это позволяет вам общаться со множеством интересных людей и расширять свой кругозор, каждый раз сталкиваясь с чем-то новым. И даже если бизнес-аналитик фокусируется на проектах из одной отрасли, двух одинаковых банков или заводов не бывает. Книга, которую вы держите в руках, – не учебник и не претендует на истину в последней инстанции. Понимание целей и задач бизнес-анализа различно в каждой конкретной организации. Данная книга отражает мой личный взгляд на профессию бизнес-аналитика, сформировавшийся после многих лет работы. Надеюсь, читатель найдет в ней что-то полезное для себя. Должен отметить, что не вся информация собрана мною лично. Несколько разделов из глав 1 и 2 я написал, опираясь на лекции опытных аналитиков: Владислава Исмагилова 5 из «Яндекс. Маркет» и Дениса Бескова 6 из Школы системного анализа и проектирования ИТ-систем. Искренне надеюсь, что вы быстро перейдете от изучения азов к реальной, «боевой» работе бизнес-аналитиком. Если книга поможет вам в этом – значит, цель ее создания достигнута. Вадим Миронов 5 Владислав Исмагилов – руководитель службы аналитики «Яндекс. Маркет», автор семинаров по продуктовой аналитике. 6 Денис Бесков – ИТ-предприниматель и методист, основатель и руководитель Школы системного анализа и проектирования ИТ-систем. Основной автор федерального профстандарта «Системный аналитик». Глава 1 Аналитика как сфера деятельности 1.1. Суть аналитики, или Зачем аналитик в бейсбольной команде? Рассказ об аналитике как сфере деятельности начнем с примера из кино. В 2011 году вышел фильм «Moneyball» с Брэдом Питтом в главной роли. В российском прокате фильм известен под названием «Человек, который изменил всё». Это история о спортивном менеджере, который пытается добиться больших высот с заурядной бейсбольной командой. Билли Бин (герой Питта) разочаровывается в классическом подходе к подбору игроков – на основе наблюдений скаутов и их экспертных оценок. Так, при обсуждении кандидатур Бин слышит от коллег аргументы в духе: «У этого игрока кривые ноги», «Он не нравится моей жене» – и прочие «профессиональные» суждения. В команде полностью отсутствует системный подход. Однажды в офисе у знакомого Бин встречает молодого специалиста по статистике и анализу данных. Вместе они начинают анализировать большие объемы информации о технических действиях сотен игроков. По результатам статистического анализа Бин собирает команду из спортсменов, которые хороши только в одном или двух игровых действиях: броске, приеме, перемещениях между базами и т. д. Как менеджер команды Билли Бин использует игроков лишь в наиболее выгодных для них ситуациях. Таким образом, он становится первым, кто отказывается от субъективного поиска игроков, опирающегося на личный опыт и впечатления. Взяв в союзники аналитику и статистику, менеджер за значительно меньшие деньги формирует боеспособный коллектив. Впоследствии такой подход перенимают и другие команды. Как видно из этого примера, суть аналитики – помощь в принятии решений на основе данных. Данные, используемые аналитиком в работе, могут представлять собой всё что угодно: статистические таблицы, карты бизнес-процессов, техническую документацию и т. д. Соответственно, задача аналитика состоит в том, чтобы собрать необходимые данные, проанализировать их и представить руководителю для принятия взвешенного, а главное – обоснованного управленческого решения. Обратите внимание на два ключевых действия: «собрать» и «проанализировать». Остановимся на них чуть подробнее. Говоря о сборе данных для анализа, важно помнить о принципе разумной достаточности. Джефф Безос, один из богатейших людей мира и основатель сайта Amazon.com, говорил: Если собирать всю необходимую информацию для принятия решений, вы никогда не ошибетесь, но всегда будете отставать. В условиях современных технологий и жесткой конкуренции счет часто идет на минуты. В бизнес-сообществе даже появилось выражение «Быстрый съедает крупного». Это значит, что аналитику важно искать золотую середину между обстоятельным сбором данных и скоростью подготовки аналитических материалов. Об источниках данных для анализа мы поговорим в следующих разделах. Что же означает «проанализировать»? Для начала вспомним, что «анализ» – термин из науки логики. Так называется один из логических приемов. Его классическое определение звучит следующим образом: АНАЛИЗ – ЛОГИЧЕСКИЙ ПРИЕМ, С ПОМОЩЬЮ КОТОРОГО МЫ МЫСЛЕННО РАЗБИРАЕМ ПРЕДМЕТЫ И ЯВЛЕНИЯ, ВЫДЕЛЯЯ ИХ ОТДЕЛЬНЫЕ ЧАСТИ, СВОЙСТВА. Обратный анализу логический прием называется «синтез». Маленький ребенок, разбирая машинку, чтобы посмотреть, как она устроена, занимается анализом. А его родители, собирающие машинку обратно, – синтезом. Таким образом, аналитик стремится разложить на составные части сложный предмет или явление, чтобы понять, как они устроены. Если аналитик работает в компании, занимающейся производством программного обеспечения или автоматизацией деятельности, то объектом его анализа будут бизнес-процессы заказчика. Подробнее мы поговорим об этом в следующих главах. 1.2. Важность причинноследственного контекста Важный аспект работы аналитика – причинно-следственный контекст. В разных условиях одни и те же данные могут приводить к принятию совершенно разных решений. Отсюда два главных вопроса аналитика – «почему это произошло?» и «что с этим делать?». Рассмотрим пример из книги Карла Андерсона «Аналитическая культура»7. Во время дежурства системный администратор интернет-магазина видит на мониторе предупреждение: «Внимание! Нагрузка на сервере приложений за последние пять минут выросла на 95 %». Казалось бы, подобное сообщение – причина для серьезного беспокойства. Что это? Проблемы с сетью? Атака хакеров? Внезапный наплыв пользователей? Первое, что нужно сделать администратору, – понять причинно-следственный контекст. Администратор изучает информацию в системе мониторинга, анализирует log-файлы, где фиксируются все действия на сервере, смотрит на дату и время и понимает, что ситуация абсолютно штатная – на часах два часа ночи, среда. В это время на сервере по рас7 Андерсон К. Аналитическая культура. От сбора данных до бизнес-результатов. – М.: Манн, Иванов и Фербер, 2017. писанию запустилась автоматическая процедура резервного копирования информации. Через десять минут копирование завершится – и нагрузка нормализуется. Таким образом, никаких действий системному администратору предпринимать не нужно. В этом и состоит важность понимания причинно-следственного контекста. Случись та же ситуация в понедельник в три часа дня – вполне возможно, что и причина нагрузки, и действия администратора были бы совсем иными. 1.3. Виды аналитики Видов аналитики великое множество, и каждый заслуживает отдельной книги. В этом разделе представлена краткая характеристика наиболее распространенных из них на сегодняшний день. Раздел не претендует на всесторонний охват аналитики как сферы деятельности. Его задача – дать читателю общее представление о том, чем может заниматься аналитик в современной организации. БИЗНЕС-АНАЛИЗ Бизнес-анализу посвящена бóльшая часть данной книги. Трактовок этого термина, пожалуй, не меньше, чем разновидностей аналитики в целом. Классическое определение из Business Analysis Body of Knowledge8 звучит так: БИЗНЕС-АНАЛИЗ – ДЕЯТЕЛЬНОСТЬ, КОТОРАЯ ПОЗВОЛЯЕТ ВНЕДРЯТЬ ИЗМЕНЕНИЯ В КОМПАНИИ ПУТЕМ ОПРЕДЕЛЕНИЯ ПОТРЕБНОСТЕЙ И РЕКОМЕНДАЦИИ РЕШЕНИЙ, ОБЕСПЕЧИВАЮЩИХ ЦЕННОСТЬ ДЛЯ ЗАИНТЕРЕСОВАННЫХ ЛИЦ. 8 BABOK. A guide to the business analysis body of knowledge. – International Institute of Business Analysis, 2015. Это очень общая формулировка. Раскроем ее чуть подробнее. С точки зрения бизнес-анализа у организации есть два состояния. 1. Текущее состояние. Это положение дел, которое по тем или иным причинам не устраивает руководство организации. Проблемы могут касаться длительности выполнения процессов, высоких затрат, неясных зон ответственности в организации и т. д. Для анализа подобных проблем и привлекается бизнес-аналитик. 2. Целевое состояние. Состояние, при котором организация проанализировала свои слабые места и оптимизировала бизнес-процессы: повысила их прозрачность и эффективность. Роль бизнес-аналитика – помочь организации определить проблемные зоны в ее текущем состоянии и предложить варианты перехода к состоянию целевому. В условиях стремительной цифровизации всех отраслей экономики в большинстве случаев переход из текущего состояния в целевое связан с реализацией ИТ-проекта по автоматизации процессов. Таким образом, на практике бизнес-аналитик становится посредником между бизнес-заказчиком и блоком ИТ-разработки. В задачи бизнес-аналитика входит: • изучение предметной области бизнес-заказчика и выяв- ление проблемных зон в бизнес-процессах; • формулирование требований к ИТ-решению, призванному обеспечить переход организации из текущего состояния в целевое. Таким образом, бизнес-аналитик объясняет ИТ-инженерам на понятном им языке, что необходимо сделать для решения задачи бизнес-заказчика. Подробнее о задачах бизнес-аналитика и способах их решения мы поговорим в главе 2. СИСТЕМНЫЙ АНАЛИЗ Если бизнес-аналитик отвечает на вопрос «что нужно сделать?», то системный аналитик определяет, «как сделать то, что нужно заказчику, используя информационную систему». Задача системного аналитика – предложить варианты реализации требований, полученных от бизнес-аналитика, с использованием той или иной информационной системы. Как правило, системный аналитик – эксперт по работе конкретного программного продукта или информационной системы. Он знает основные технологические процессы системы, принципы хранения информации в ней, нюансы интеграции с другими системами и т. д. Системный аналитик формирует техническое задание, в котором на более детальном, техническом уровне, неже- ли бизнес-аналитик, описывает требования к будущему ИТрешению. Если бизнес-аналитик говорит о том, что должно произойти при нажатии на определенную кнопку, то системный аналитик фиксирует, за счет чего достигается необходимый результат: как происходит обращение к серверу, как обрабатывается ответ, как хранится информация в базе данных и т. д. В некоторых организациях роль системного и бизнес-аналитика выполняет один человек. Но чем сложнее и масштабнее ИТ-решения, тем выше необходимость в разделении функций системного и бизнес-анализа между разными специалистами. ПРОДУКТОВАЯ АНАЛИТИКА Как следует из названия, продуктовая аналитика посвящена разработке и развитию какого-либо продукта. Продукт – понятие многогранное. Например, в банковской сфере это может быть кредит или пластиковая карта с кешбэком. В промышленности продуктом будет автомобиль, станок или слиток металла. Говоря о продуктовой аналитике, мы будем рассматривать термин «продукт» с точки зрения ИТ. Иными словами, продукт для нас – это мобильное приложение, информационная система или онлайн-сервис. Например, продуктовый аналитик может заниматься созданием и развитием интер- нет-магазина. Поскольку бизнес всё больше переходит в онлайн, продуктовый аналитик может работать в любой организации с цифровыми продуктами. Например, в банке он может развивать банковское мобильное приложение. При работе с цифровыми продуктами главным инструментом продуктового аналитика становится A/B-тестирование. Чтобы лучше понять его суть, рассмотрим упрощенный жизненный цикл нового продукта или сервиса. Стадия 1. «А может, не надо?» Задумав новый сервис, «который перевернет мир», важно спросить себя: действительно ли существует необходимость в подобном сервисе? Аналитик отвечает на десятки вопросов типа: • Каковы перспективы сервиса с учетом тенденций развития отрасли? • Почему мы считаем, что сервис понравится потребителям? • Нет ли похожих сервисов у конкурентов? Если есть, то каковы их успехи? Если сервис «не взлетел», то по какой причине? Если ответы на эти вопросы даны и энтузиазм не испарился, можно переходить к этапу 2. Стадия 2. Пилотный проект На втором этапе аналитик должен определиться: как дешево проверить, что от внедрения нового сервиса или продукта будет польза? На этом этапе проектируются и запускаются примитивные прототипы – простые приложения, сайты и т. п. Стадия 3. А/B-тестирование и вилка решений Суть А/ B-тестирования лучше пояснить на примере. Допустим, у вас есть интернет-магазин. Вы хотите добавить ему пару новых функций – например, красивую кнопку оформления заказа и 3D-обзор товара. Для удобства назовем их «Функция 1» и «Функция 2» соответственно. Текущее состояние магазина без новых функций будет служить контрольным показателем. Итак, вы создаете несколько версий магазина: только с «Функцией 1», только с «Функцией 2» и с обеими «Функциями» сразу, а потом демонстрируете новые версии сайта фокус-группам пользователей. Ваша цель – понять, как новые изменения и их комбинации повлияли на работу магазина по сравнению с контрольным показателем. Возможно, смена цвета кнопки с синего на красный приведет к оттоку пользователей. Или, наоборот, заказов станет больше. Подобные тесты позволяют сформировать набор данных, на основе которых и принимается решение: добавлять новую функцию в сервис или нет. На данном этапе возникает так называемая вилка реше- ний. Перед началом работ вы должны однозначно определиться с критериями принятия решения. Иными словами, организаторы тестирования «на берегу» договариваются: если новая функция приведет к увеличению интересующего показателя на X % – значит, работы по внедрению продолжаются. А если функция понизит интересующую метрику на Y % – значит, от функции отказываемся и придумываем чтото еще. Стадия 4. Запуск в промышленную эксплуатацию Если А/B-тестирование показало приемлемые результаты, то новая функция внедряется в полном объеме. Стадия 5. Сопровождение На последнем этапе анализируется востребованность новых функций со стороны пользователя, работа обновленного сервиса, подводятся итоги проведенной работы. Кроме того, аналитик в течение определенного времени сопровождает обновленный сервис во избежание непредвиденных инцидентов. Интересный факт В 2010 году в компании Google разработчики провели свыше 8000 A/B-тестов, касающихся исключительно функции поиска9. 9 Роулинг С. Я хочу больше идей. Более 100 практик и упражнений для развития творческого мышления. – М.: Манн, Иванов и Фербер, 2018. АНАЛИТИКА ДАННЫХ Аналитик данных решает следующие задачи: • построение прогнозных моделей на основе больших массивов данных – например, прогноз оттока клиентов на основе анализа данных об их активности с момента появления в клиентской базе; • разработка механизмов персональных рекомендаций на основе анализа больших объемов данных; • выявление скрытых аномалий и закономерностей в данных; • проверка гипотез, выдвинутых бизнес-подразделениями. Для решения подобных задач аналитику данных нужны хорошие, глубокие знания в области математики и статистики. Эффект «большого брата», следящего за вами, – заслуга аналитика данных. Речь о ситуации, когда сервис формирует персональные рекомендации буквально через минуту после возникновения потребности у клиента. Вы послушали всего несколько песен на «Яндекс. Музыке», а вам уже предлагают индивидуальные плейлисты, которые с высокой вероятностью соответствуют вашим предпочтениям. ПРИВЛЕЧЕНИЕ ПОЛЬЗОВАТЕЛЕЙ Задача аналитика, работающего над привлечением пользователей, – привести на сервис как можно больше людей и обеспечить максимальную коммуникацию с каждым из них. В данном направлении аналитик работает с: • инструментами поисковой оптимизации; • сегментацией клиентов и точечными предложениями; • инструментами управления взаимоотношениями с клиентами (CRM – от англ. Customer Relationship Management); • программами лояльности; • скорингом пользователей: как часто клиент посещает сервис, какие действия предпринимает, сколько товаров заказывает и т. п. После привлечения нового пользователя аналитик ищет варианты стимуляции потребительской активности. Цель этой работы – окупить затраты компании на привлечение клиента. МАРКЕТИНГОВЫЕ ИССЛЕДОВАНИЯ В ходе маркетинговых исследований аналитик проводит глубинные интервью с клиентами и старается «залезть» им в голову. Главное в таких исследованиях – коммуникации и искусство правильно задавать вопросы. Суть маркетинговой аналитики станет яснее из примера. ИСТОРИЯ ПРО ПЛЕЕРЫ Исследователи собрали студентов в аудитории, и преподаватель задал им один-единственный вопрос: какого цвета вы хотели бы плеер Sony Walkman? Ответ нужно было написать на листочке. Собрав и проанализировав ответы, исследователи пришли к выводу, что преобладают яркие цвета: желтый, красный, зеленый. На выходе из аудитории студенты увидели стенды, на которых бесплатно раздавали плееры всевозможных цветов. Парадокс в том, что, несмотря на результаты опроса, большинство студентов выбрали черные плееры, а вовсе не яркие, как указали ранее. Этот кейс продемонстрировал, насколько результаты опроса зависят от формулировки вопроса и как сильно они могут отличаться от реальности. UX И UI UX – от англ. user experience – пользовательский опыт. UI – от англ. user interface – пользовательский интерфейс. UX/UI – дизайн взаимодействия с пользователем. Цель данного направления – повышение удовлетворенности пользователя за счет удобства, доступности и эффективности решения стоящих перед ним задач. В ходе UX/UI-тестирования проверяются гипотезы, связанные с удобством использования программного продукта или онлайн-сервиса. Для подобных тестов характерны короткие итерации и создание примитивных прототипов. Кроме того, анализируются пользовательские сценарии и истинные потребности клиента. В ходе тестирования в интерфейсе перемещаются элементы, меняются их форма, размер, цвет и десятки других параметров. Всё для того, чтобы пользователь получил максимальное удовлетворение от взаимодействия с продуктом или сервисом. Вы наверняка не раз сталкивались с тем, что некоторыми мобильными приложениями очень приятно пользоваться: все элементы на своих местах, интерфейс интуитивно понятен, а от вас требуется минимум действий для решения своей задачи. Это и есть результат работы UX/UI-аналитиков. Рассмотрим простейший пример задачи, стоящей перед UX/UI-аналитиком: выбор элемента интерфейса. Представим себе, что аналитик работает над сервисом заказа справки из отдела кадров. Количество копий одной справки варьируется от одной до пяти. Аналитику необходимо выбрать, с помощью какого элемента пользователь будет указывать нужное количество копий. Вариантов два: ра- диокнопка и двунаправленный список (см. рис. 1). Что же выбрать? Рисунок 1. Радиокнопки и двунаправленный список На самом деле оба ответа допустимы, но при определенных обстоятельствах. В первом варианте пользователю нужно совершить всего один клик мышкой, чтобы заказать пять копий справки. Удобно! Во втором же варианте придется кликнуть мышкой целых четыре раза. Но! Что если речь идет об интерфейсе мобильного приложения? В этом случае каждый квадратный сантиметр экрана на вес золота. Очевидно, что первый вариант займет на экране больше места. Это означает, что при определенных условиях и второй вариант имеет право на существование. Выбор – на усмотрение аналитика. ФИНАНСОВЫЙ АНАЛИЗ Финансовый анализ связан с изучением финансово-хозяйственной деятельности предприятия. Финансовый аналитик постоянно сталкивается в своей работе с: • планами развития компании; • разработкой и контролем ключевых показателей эффективности деятельности; • управлением запасами; • ассортиментной и ценовой политикой; • подготовкой отчетов для контролирующих органов; • формированием бюджета организации. Иногда финансовый анализ путают с бизнес-анализом, ориентируясь на слово «бизнес» в названии последнего. И действительно, финансовый анализ – наиболее приближенное к экономическим аспектам деятельности направление аналитики. Тем не менее я предлагаю свое понимание задач, стоящих перед бизнес-аналитиком, и призываю не смешивать их с финансовым анализом. О путанице в понимании задач различных направлений аналитики читайте в следующем разделе. 1.4. Еще раз о размытости границ Разобраться во всех хитросплетениях профессии аналитика непросто. Анализировать можно всё что угодно, отсюда и многообразие видов аналитики. Кроме того, каждый посвоему называет специалистов-аналитиков, исходя из собственного понимания стоящих перед ними задач. Вот и получается, что специалист на должности бизнес-аналитика в разных организациях может заниматься совершенно разными задачами. Один – настройкой информационной системы заказчика. Другой – анализом финансовых показателей, планов развития компании и ключевых показателей эффективности деятельности. Третий – моделированием и анализом бизнес-процессов, а также разработкой требований. И у всех в трудовой книжке будет написано «бизнес-аналитик». На бизнес-анализ можно смотреть с двух наиболее распространенных точек зрения – информационно-технологической и финансовой. С точки зрения ИТ бизнес-аналитик занимается изучением предметной области заказчика, описывает бизнес-процессы и формирует требования к ИТ-решениям. Данной позиции я и придерживаюсь. Подробнее эти вопросы раскрыты в главе 2. С финансовой точки зрения бизнес-аналитик занимается оценкой состояния бизнеса и его способностью исполнять обязательства. Помимо этого, аналитик определяет факторы, сильнее всего влияющие на финансовый результат. На мой взгляд, решение таких задач корректнее называть финансовым анализом. Кроме того, зоны ответственности специалистов по аналитике сильно зависят от принятых в организации подходов к работе. Бывает, что системный аналитик берет на себя часть функций бизнес-аналитика, а бизнес-аналитик активно участвует в разработке интерфейсов информационных систем. Я хотел бы, чтобы моя книга помогла закрепить в сознании читателя роль бизнес-аналитика как посредника между миром бизнеса и миром информационных технологий. Бизнес-аналитик для меня – переводчик с языка бизнеса на язык ИТ и обратно. За счет этого он и выполняет главную задачу бизнес-анализа – способствует переходу организации из текущего состояния в целевое при помощи ИТ-решения. 1.5. Краткая история бизнес-анализа10 В замечательной книге «Хронология искусства» 11 есть показательный пример того, как новые технологии в свое время повлияли на живопись. Такой жанр, как импрессионизм, обязан своим появлением… жестяным тюбикам. Дело в том, что для импрессионизма важной составляющей является пленэр – написание картин на свежем воздухе. До изобретения красок в тюбиках пленэр был крайне хлопотным, а порой и невозможным: краски в громоздких коробках занимали много места и быстро сохли. Появление же тюбиков не только решило эти проблемы, но и привело к возникновению новых техник рисования. Так, художники начали выдавливать краску прямо на холст. В итоге новая технология привела к развитию принципиально нового направления в живописи. Подобную взаимосвязь с технологиями можно проследить во всех сферах деятельности человека, в том числе и в дисциплине «бизнес-анализ». Снова обратимся к ее классическому определению: БИЗНЕС-АНАЛИЗ 10 – ДЕЯТЕЛЬНОСТЬ, Раздел подготовлен с использованием материалов сайта Business Analysts Handbook (https://businessanalyst.fandom.com/wi-ki/Main_Page). 11 Зачек Й. Хронология искусства. Как история влияет на культуру с начала времен до наших дней. – М.: Манн, Иванов и Фербер, 2018. КОТОРАЯ ПОЗВОЛЯЕТ ВНЕДРЯТЬ ИЗМЕНЕНИЯ В КОМПАНИИ ПУТЕМ ОПРЕДЕЛЕНИЯ ПОТРЕБНОСТЕЙ И РЕКОМЕНДАЦИИ РЕШЕНИЙ, ОБЕСПЕЧИВАЮЩИХ ЦЕННОСТЬ ДЛЯ ЗАИНТЕРЕСОВАННЫХ ЛИЦ. Исходя из широты данного определения, можно сделать вывод: бизнес-анализ как сфера человеческой деятельности существует столько же, сколько и осмысленный подход к труду, производству и деловой активности. Иными словами, сотни и даже тысячи лет. На сегодня бизнес-анализ – это комплексная дисциплина на стыке экономической науки, математики и информационных технологий. В данном разделе мы рассмотрим краткую историю развития бизнес-анализа как совокупности технологий, экономических и управленческих концепций с древнейших времен до наших дней. С ДРЕВНИХ ВРЕМЕН ДО НАЧАЛА XX ВЕКА С древних времен владельцы предприятий стремились к совершенствованию своего дела: сокращению издержек, повышению прибыли, снижению трудоемкости производства. Для решения данных задач предприниматели работали в тесном взаимодействии с учеными: экономистами, математиками, физиками, механиками. Самые ранние приспособления для вычислений возник- ли из чисто практических соображений: необходимости пересчитывать скот и зерно, а также вести меновую торговлю. Человечество постоянно совершенствовало вычислительные инструменты: счетные палочки превратились в счеты, появились сложные понятия типа нуля, натуральных чисел, дробей и т. д.; возникла отдельная наука – алгебра. Во взаимодействии с математикой развивалось и инженерное направление. Появились первые станки: печатные, текстильные, металлообрабатывающие. Вместе с развитием вычислительного аппарата и появлением новых технологий естественным образом встал вопрос об оптимизации деятельности предприятия. Как ускорить производство? Как обойти конкурентов? Как снизить затраты и увеличить прибыль? Все эти и многие другие вопросы легли в основу экономической науки. Проблемы эффективной организации труда занимали общество еще во времена Аристотеля. Фундаментальным с точки зрения современного бизнес-анализа является понятие бизнес-процесса. В 1776 году Адам Смит опубликовал описание первого бизнес-процесса – производства булавки. Он показал, что, четко определив этапы процесса, можно использовать принцип разделения труда. Иными словами, назначить узкопрофильного специалиста на каждый конкретный этап, тем самым повысив и качество продукции, и скорость ее изготовления. Одним из толчков к дальнейшему развитию вычислитель- ных средств, необходимых для решения прикладных задач, стала перепись населения США в 1890 году. Существовавшие на тот момент подходы к переписи были крайне трудоемкими: сбор и обработка данных заняли бы не один год. Поэтому американский инженер и изобретатель Герман Холлерит разработал специальный аппарат на основе электромеханических реле. В качестве устройств памяти он использовал перфокарты. В итоге вместо нескольких лет сбор данных занял всего шесть недель. К слову, это была одна из первых попыток получить более детальные данные о населении, нежели сведения о возрасте, поле и месте проживания. По сути, перепись населения 1890 года стала предтечей глубокого анализа данных. Вдохновленный успехом, Генри Холлерит создал компанию, которая в дальнейшем стала одной из основательниц IBM. Конец XIX века также ознаменовался появлением теории научной организации труда и теории менеджмента. В своих работах американские инженеры Генри Таун и Фредерик Уинслоу Тейлор разрабатывали концепцию управления бизнесом, рассматривая ее в качестве научной дисциплины. В данной концепции основное внимание уделялось составлению схем процессов, планированию оптимального подхода к работе, обучению персонала, устранению интуитивных подходов и их замене логикой и вычислениями. Теория Тейлора, нацеленная на повышение производительности труда, была названа в его честь «тейлоризмом». 1900–1930 ГОДЫ С 1900-х по 1930-е годы технологический уклад общества стремительно менялся. Достижения в физике, математике, химии и электронике привели к созданию принципиально новых изобретений. Появилось радио, радары, телевидение. Был заложен фундамент для создания в конце 1930х годов первых ламповых компьютеров. Двигателем развития вычислительных средств стали оборонно-промышленные комплексы разных стран. В тот период вычислительная техника использовалась для расчета траектории полета артиллерийских снарядов, в приборах радиопеленгации и системах противовоздушной обороны, а также для обмена зашифрованной информацией. Идеи Тейлора оказали влияние на Генри Форда, который разработал собственный управленческий подход, названный позднее «фордизмом». Основой фордизма стали: • максимальное разделение труда; • высокая стандартизация и взаимозаменяемость производимых деталей; • эффективное и логичное использование рабочего пространства, основой которого стал конвейер; • регламентация процессов производства: этапности и длительности соответствующих операций. Теории Тейлора и Форда значительно повлияли на подходы к организации труда, практиковавшиеся в первые годы существования Советского Союза: 1920-е – 1930-е годы. С 1900 по 1939 год возник ряд теорий, принципов и методов, актуальных для бизнес-анализа и по сей день. В начале XX века итальянский экономист и социолог Вильфредо Парето выявил закономерность, согласно которой 20 % населения Италии владеют 80 % собственности. Позже на данную закономерность обратили внимание и другие экономисты, применившие ее к вопросам организации труда и эффективности процессов. С течением времени этот принцип был обобщен и сформулирован как «принцип Парето». В общем виде он звучит так: «20 % усилий дают 80 % результата, а остальные 80 % усилий – лишь 20 % результата». Данный принцип широко применяется в экономике, менеджменте и политологии. Нашел он свое отражение и в бизнес-анализе и программной инженерии. Так, в проектах по созданию программного обеспечения разработчики стремятся сосредоточиться на 20 % функциональности, которая удовлетворит 80 % потребностей пользователя. Вместе с тем 80 % дефектов обнаруживаются в 20 % программного кода. Естественно, в данном случае о процентах мы говорим образно, а не буквально. В 1910 году американский инженер-технолог Генри Гант предложил первый вариант диаграммы, которая впоследствии стала всемирно известна как «диаграмма Ганта». Данная диаграмма и сегодня используется в качестве стандартного инструмента для визуального представления плана-графика работ в рамках управления проектом. Стоит отметить, что Генри Гант был сотрудником и ближайшим соратником Фредерика Уинслоу Тейлора, основателя тейлоризма. В 1916 году французский инженер Анри Файоль выпустил свою книгу «Общее и промышленное управление». В ней он сосредоточился на вопросах управления людьми и командами в горнодобывающей отрасли. Принципы, изложенные в работе Файоля, легли в основу классической административной школы менеджмента. В конце 1930-х годов вышли работы британского экономиста Линдалла Урвика и американского политолога, эксперта по государственному управлению Лютера Гулика. Они обобщили идеи теоретиков-предшественников, таких как Анри Файоль, и внесли вклад в развитие общей теории менеджмента. В частности, им принадлежит идея выделения департаментов, объединяющих узкопрофильных специалистов по выполняемым функциям, выпускаемой продукции, профилю клиента, географическим принципам и т. д. Выбор критериев, согласно которым сотрудники объединяются в департаменты, зависит от стабильности работы компании и необходимости быстрой реакции на изменения. 1940-е ГОДЫ На протяжении 1940-х годов последние достижения науки и техники использовались для создания новых вычислительных устройств. Эти устройства применялись в криптографии, аэродинамике, метеорологии и физике. Разработки в области физики привели к появлению ядерного оружия. Во второй половине 1940-х годов благодаря изобретению электронной памяти и появлению новых высокоуровневых языков программирования активно развивались компьютеры. В годы Второй мировой войны британское правительство ввело стандарт управления BS 5750. Его целью было сокращение несчастных случаев на производстве в военно-промышленном комплексе. Стандарт не указывал, что и как производить, однако определял ряд обязательных функций, таких как ведение записей и оформление отчетов, сопровождающих производство. Считается, что BS 5750 взяли за основу при разработке первых стандартов, известных сейчас как ISO 9000. В конце 1940-х также начали развиваться кибернетика и теория информации. Это были две важные дисциплины, изучавшие закономерности получения, хранения, преобразования и передачи информации в сложных системах: живых организмах, машинах, обществе. Конец 1940-х годов – время активного развития в СССР информатики и вычислительной техники для решения государственных задач в области обороны и народного хозяйства. Днем рождения отечественной информатики неофициально считается 4 декабря 1948 года. В этот день Государственный комитет Совета министров СССР по внедрению передовой техники в народное хозяйство зарегистрировал новое изобретение: цифровую электронную вычислительную машину. Авторами изобретения стали ученые Исаак Брук и Башир Рамеев. 1950-е ГОДЫ В 1951 году в компании Lyons Tea появился первый бизнес-компьютер для обработки платежных ведомостей. В середине 1950-х в мире, по некоторым оценкам, насчитывалось всего около 100 компьютеров. В основном это были специализированные вычислительные машины, принадлежавшие научным институтам, университетам, правительственным и оборонным организациям. В 1957 году IBM выпустила FORTRAN – первый язык высокого уровня, а в 1958 году появился LISP – язык программирования, задуманный его создателями для разработок в области искусственного интеллекта. В те же годы были изобретены первый матричный принтер и интегральные схемы. В конце 1950-х годов американский бизнесмен Арманд Фейгенбаум заложил основы концепции тотального управления качеством (Total Quality Management). Данная концепция сосредотачивалась на вопросах качества продукции, организации процессов и квалификации персонала. В то же самое время в СССР усилилось внимание к использованию вычислительных средств для решения задач армии и народного хозяйства. Осенью 1959 года Н. С. Хрущеву был представлен проект «Пути автоматизации управления в вооруженных силах и в народном хозяйстве». Данный проект предполагал создание единой государственной территориальной сети вычислительных центров 12. 1960-е ГОДЫ Термин «программная инженерия» начали применять в конце 1950-х – начале 1960-х годов. Именно тогда концепция разработки программного обеспечения и стала формироваться в качестве самостоятельной инженерной дисциплины. Новое направление опиралось как на строгие научные подходы, так и на творческий поиск для решения прикладных задач. Каждый программный проект – это работа над новым изобретением, которой присуща некоторая степень неопределенности. Тем не менее в своей основе подоб12 См.: Зараменских Е. П. Основы бизнес-информатики: монография. – Новосибирск: Издательство ЦРНС, 2014. ное изобретение зачастую строится на общих, базовых принципах. Поскольку разработка программных продуктов обычно рассматривалась в качестве инженерной дисциплины, предпринималось множество попыток применить к ней традиционные управленческие подходы. Успех этих попыток оказался ограниченным. Существует мнение, будто сфера разработки ПО слишком изменчива, так как существенные технологические сдвиги происходят в ней каждое десятилетие. И действительно, история последних 50 лет это полностью подтверждает. За прошедшие годы так и не появилось универсального инструмента для проектирования программного обеспечения. Впрочем, многие подходы и техники, разработанные десятки лет назад, применяются при создании ПО и сегодня. Шестидесятые годы XX века – эра транзисторных и интегральных компьютеров. В этот период появились такие языки, как COBOL и Simula. Крупные корпорации начали пользоваться компьютерами для расчета заработной платы. Первую компьютерную игру создали в 1961 году, а первая компьютерная мышь появилась в 1968-м. В СССР в сентябре 1962 года Госкомитет по науке и технике подготовил масштабное предложение о создании «Общегосударственной системы автоматического сбора и обработки экономической информации» 13. Это стало импульсом 13 См.: Зараменских Е. П. Основы бизнес-информатики… к разработке и широкому внедрению автоматизированных систем управления (АСУ) в нашей стране 14. В 1969 году Министерство обороны США с целью изучения сетевых технологий создало ARPANET – предшественник нынешнего интернета. 1970-е ГОДЫ В 1970-е годы появляются первые микросхемы оперативной памяти, а также первый портативный электронный калькулятор. Создаются микропроцессоры, которые станут основой для появления персональных компьютеров. Сеть ARPANET становится международной. Выходят в свет языки программирования Pascal и C, широкую популярность обретает операционная система Unix. Распространение более дешевых и компактных компьютеров за пределами научных институтов и оборонных предприятий привело к росту рынка аппаратного и программного обеспечения. Это, в свою очередь, повысило спрос на профильных ИТ-специалистов: инженеров, разработчиков, тестировщиков, менеджеров. В 1970 году американский ученый Уинстон Ройс опубликовал статью, описывающую так называемую каскадную (или «водопадную») модель разработки программного обес14 Там же. печения. Данная модель широко используется и по сей день. 1970-е – время широкого распространения АСУ в нашей стране. Их число увеличилось с 400 в 1970-м до 3000 в 1975м, и это без учета оборонной промышленности15. К середине 1970-х начала формироваться концепция информационной экономики. Всё большее значение стало уделяться извлечению полезной, практически применимой информации из имеющихся данных. Это, в свою очередь, привело к появлению первых хранилищ данных и информационных систем управления. Так возникло направление «Информационный менеджмент». В рамках данного направления были разработаны процессы ручного документооборота для управления движением рабочих бумаг в организациях. В последующие десятилетия подобные процессы всё больше перекочевывали на ИТ-платформы, работающие с системами электронного документооборота и инструментами оптического распознавания. Процесс перехода на электронный документооборот активно продолжается и сегодня. 1980-е ГОДЫ В 1980-е годы на рынке появились первые устройства и операционные системы с графическим интерфейсом: Apple Lisa в 1983 году и Microsoft Windows в 198515 См.: Зараменских Е. П. Основы бизнес-информатики… м. В 1989 году Тим Бернерс-Ли предложил гипертекстовый проект, который позднее назвали «Всемирная паутина» (World Wide Web). Начался расцвет персональных компьютеров. В этой гонке лидерами стали IBM PC, Apple и ZX Spectrum. Распространение компьютеров для обработки информации приняло такие масштабы в восьмидесятых годах XX века, что для описания этого явления даже пришлось сформулировать концепцию «информационной революции», или «информационной эры». Ключевой задачей бизнес-анализа в связи с этим стало понимание того, какие данные можно использовать для получения практически применимой информации. Иными словами, такой информации, которая необходима для принятия обоснованных управленческих решений. Бизнес-аналитику важно понимать, как использовать эту информацию для совершенствования процессов, увеличения доходности бизнеса и предложения новых инициатив. В начале 1980-х годов в англоязычном профессиональном сообществе получили распространение руководства по управлению производственной системой, внедренной в компании Toyota. Так был введен в оборот термин «бережливое производство». Это концепция управления производственным предприятием, основанная на постоянном стремлении к устранению всякого рода потерь. Широкое распространение данного термина пришлось на 1990-е годы, после публикации ряда книг о производственной системе Toyota. Кроме того, в начале восьмидесятых в правительственных учреждениях Великобритании разработали метод структурированного системного анализа и проектирования (SSADM). Данный метод является, по сути, каскадной методологией разработки программного обеспечения и ориентирован на сбор требований к ПО, их предварительную оценку и проектирование программного продукта. Элияху Голдратт в 1984 году представил свою теорию ограничений, влияющих на управляемость систем, в книге «Цель». Он предложил вести учет не только на основе используемых ресурсов и полученных результатов (входов и выходов) процессов, но также учитывать пропускную способность процессов и их узкие места. Это, в свою очередь, позволяет проанализировать целесообразность устранения выявленных узких мест с точки зрения потенциальных выгод. В 1986 году корпорация Motorola разработала управленческую концепцию «Шесть сигм». Эта концепция создавалась как средство контроля заводского брака в рамках определенного допуска. В 1987 году была разработана серия международных стандартов ISO 9000, нацеленная на построение системы менеджмента качества. Активную роль в появлении этих стандартов сыграла Великобритания. Правительство Маргарет Тэтчер выступило с инициативой о принятии стандарта BS 5750, разработанного еще в годы Второй мировой войны, в качестве международного. Кроме того, на ISO 9000 повлияли военные стандарты Министерства обороны США и других оборонных ведомств. Сегодня стандарты серии ISO 9000 применяются в том числе для контроля качества процессов разработки программного обеспечения. В конце 1980-х годов популярность обрел термин Business Intelligence, подразумевающий сбор, интерпретацию и последующее использование информации, необходимой для принятия решений. Затраты на получение такой информации зачастую превышали выгоду от самих решений. Это обстоятельство инициировало исследования и разработку инструментов для снижения затрат на получение информации. 1990-е ГОДЫ В 1991 году вышла первая версия ОС Linux, которая впоследствии получила широкое распространение в качестве серверной системы. В 1995 году компания Microsoft выпустила Windows 95. Девяностые годы – время бурного развития интернета: растет популярность интернет-браузеров (Netscape Navigator, Interner Explorer); совершенствуются электронная почта и поисковые системы типа Yahoo и Google. В начале 1990-х широкое распространение получила концепция моделирования, анализа и реинжиниринга биз- нес-процессов. Два американца – специалист по программной инженерии Гради Буч и ученый в области информатики и объектной методологии Джеймс Рамбо – совместно со шведским ученым-информатиком Иваром Якобсоном опубликовали в 1997 году первую версию унифицированного языка моделирования – UML 1.0. Этот язык получил широкое распространение в среде бизнес- и системных аналитиков и фактически стал стандартом в сфере проектирования программного обеспечения. В 1990-е годы появилось несколько новых концепций разработки программного обеспечения. Среди них: Scrum, Rational Unified Process (RUP), XP (eXtreme Programming) и Feature Driven Development (FDD); набирает популярность концепция итеративной разработки ПО как инструмента снижения неопределенности. 2000-е ГОДЫ – НАШЕ ВРЕМЯ Начало 2000-х годов ознаменовано «кризисом доткомов» – лопнувшим экономическим пузырем, раздутым благодаря бурному росту акций интернет-компаний, и произошедшим затем обвалом котировок. Этот обвал вызвало осознание неэффективности новых бизнес-моделей, которые настойчиво продвигались с середины 1990-х. В двухтысячные годы зарождается система управления бизнес-процессами. Соответствующие концепции и инструменты моделирования развиваются и сегодня. Благодаря появлению данных систем и инструментов возникла новая дисциплина – «Процессное управление». Эта дисциплина увязывает стратегические цели компании с ожиданиями и потребностями клиентов путем построения соответствующих сквозных бизнес-процессов. Внедрение процессного подхода начинается с определения уровня зрелости организации. Для этого в университете Карнеги – Меллона была создана интегрированная модель технологической зрелости (Capability Maturity Model Integrated, CMMI). Данная модель получила широкое распространение в начале 2000-х. В 2003 году в Канаде был создан Международный институт бизнес-анализа (IIBA) – профессиональная ассоциация для поддержки и продвижения бизнес-анализа как самостоятельной дисциплины. IIBA оказывает информационную и консультационную поддержку бизнес-аналитикам с целью развития их навыков и карьеры в целом. В 2005 году Институт выпустил первую версию «Свода знаний по бизнес-анализу» – Business Analysis Body of Knowledge (BABOK). В этом «Своде» воплотилось стремление профессионального сообщества бизнес-аналитиков сформулировать всемирный стандарт в области практики бизнес-анализа и дать определение бизнес-анализу как профессии. С тех пор IIBA регулярно публикует обновленные версии своего «Свода знаний». Каждая следующая версия пополняется и актуализируется в соответствии с современными тенденциями ведения бизнеса и с учетом новых технологий. С середины 2010-х годов наблюдается устойчивая тенденция отхода от специализированного разделения труда, которая, в свою очередь, влияет на традиционную систему управления. Команды становятся всё менее иерархичными и всё более кросс-функциональными. В чисто технические команды, состоящие из разработчиков, аналитиков и тестировщиков, начинают входить представители бизнес-подразделений и эксперты в той предметной области, которую предполагается автоматизировать. Управление членами таких команд осуществляется, как правило, согласно матричному принципу. Иными словами, у каждого сотрудника есть два руководителя: руководитель подразделения, в котором он числится, и руководитель проекта, на котором этот сотрудник занят. Отличительная особенность последних 10–15 лет – переход от «бизнеса, движимого ИТ» к «ИТ, движимому бизнесом». Если раньше предприятия и организации думали над тем, как внедрить в работу существующую технологию, то теперь бизнес всё чаще выступает в роли заказчика необходимой ему технологии. Иными словами, теперь не задачи придумываются под технологии, а технологии под задачи. Слияние профильной экономической деятельности предприятий с ИТ становится всё интенсивнее. Как следствие, у бизнеса появляются новые направления работ, реализация которых в отрыве от ИТ невозможна в принципе. БИЗНЕС-АНАЛИЗ В ЭПОХУ НЕЙРОСЕТЕЙ И ИСКУССТВЕННОГО ИНТЕЛЛЕКТА. ЧТО НАС ЖДЕТ ДАЛЬШЕ? Даже столь краткое погружение в историю эволюции бизнес-анализа позволяет заметить, что на подходы к ведению и совершенствованию бизнеса неизбежно влияют технологии, развивающиеся в соответствующий исторический период. Изобретение в разные годы книгопечатных станков, телеграфа, электронных вычислительных машин и интернета существенно изменило принципы ведения бизнеса. Однако между новыми технологиями и их широким внедрением в бизнес всегда существует временной разрыв – от одного-двух до десяти лет и более. Во все времена рынку требовалось время для осознания потенциала новой технологии и способов извлечения из нее выгоды. Организации, способные сделать это раньше конкурентов, получают существенное преимущество, что заставляет пересматривать привычные подходы к ведению бизнес-анализа. На смену ранее актуальным техникам приходят новые, востребованные в текущих условиях. Еще важнее то, что бизнес-аналитики могут начать изучение некоторых подходов заранее, с прицелом на будущее, исходя из понимания требований, предъяв- ляемых новой технологией к уровню технологической зрелости организации. Осознавая взаимозависимость подходов к ведению и развитию бизнеса и новых технологий, поразмышляем о том, какие компетенции в области бизнес-анализа будут особенно востребованы в ближайшем будущем. Для этого можно обратиться к материалам, ежегодно публикуемым компанией Gartner. Gartner – американская исследовательская и консалтинговая компания, специализирующаяся на рынках информационных технологий. Она наиболее известна введением в употребление понятия ERP и регулярными исследовательскими отчетами в форматах «магический квадрант» (Magic quadrant) и «цикл развития» (Hype cycle)16. Согласно компании Gartner, цикл развития любой технологии состоит из пяти фаз. 1. Толчок к инновациям (Innovation trigger). Потенциальный технологический прорыв. Первые признаки того, что использование новой технологии может принести выгоду, привлекают внимание СМИ и вызывают значительную огласку. На этой фазе часто не существует пригодных для использования продуктов, а их коммерческая жизнеспособность не доказана. 2. Пик завышенных ожиданий (Peak of inflated 16 См.: Gartner Hype Cycle // Gartner, Inc. and/or its affiliates (https:// www.gartner.com/en/research/methodologies/gartner-hype-cycle). expectations). На ранних стадиях рекламы новой технологии появляется множество историй успеха, которые часто сопровождаются десятками неудач. Некоторые компании начинают действовать, многие – нет. 3. Впадина разочарования (Trough of disillusionment). Интерес ослабевает по мере того, как эксперименты и внедрения не приносят результатов. Производители технологии теряют деньги или разоряются. Инвестиции не прекращаются только в том случае, если оставшиеся в живых компании-разработчики продолжают развивать продукт, чтобы удовлетворить потребности ранних последователей. 4. Подъем просвещения (Slope of enlightenment). Появляется всё больше понятных, конкретных примеров того, как новая технология приносит пользу предприятию. Поставщики этой технологии создают продукты второго и третьего поколений. Всё больше предприятий финансируют пилотные проекты; консервативные компании сохраняют осторожность. 5. Плато продуктивности (Plateau of productivity). Начинается массовое внедрение технологии. Критерии оценки жизнеспособности поставщика определяются более четко. Широкое применение технологии на рынке и ее актуальность приносят свои плоды. Предполагается, что новая технология проходит через все перечисленные фазы и оказывается на плато продуктивно- сти, будучи широко признанной и используемой в бизнес-сообществе. Однако пройти этот путь суждено далеко не каждой технологии: темпы их развития настолько высоки, что некоторые устаревают задолго до достижения плато. В отношении каждой рассматриваемой в цикле развития технологии аналитики Gartner прогнозируют, как скоро она достигнет своего плато продуктивности. Если внимательно приглядеться к циклу развития новых технологий, то можно заметить: подавляющее их большинство – информационные. Иными словами, главная задача этих технологий – сбор, обработка, хранение, накопление и передача данных для получения новой, практически применимой информации. Таким образом, современному бизнесу для развития и приобретения экономических выгод требуются качественные исходные данные и умение их анализировать. Это ключевой момент с точки зрения того, какие техники бизнес-анализа будут востребованы как сегодня, так и в ближайшем будущем. Среди технологий, которые, согласно ожиданиям, достигнут плато продуктивности в перспективе ближайших 2– 10 лет, – такие, например, как «объясняющий» искусственный интеллект, предиктивная аналитика, технологии формирования запросов на естественном языке. Вопрос качества входных данных для подобных технологий – важнейший, поскольку заложенные в них идеи не дадут нужный бизнесу результат без качественной исходной информации. С учетом тенденций развития технологий в целом и технологий аналитики в частности, можно сделать два прогноза относительно того, как будет видоизменяться бизнес-анализ в недалеком будущем. 1. В ближайшие 10 лет потребность в специалистах, владеющих техниками ИТ-бизнес-анализа, будет только возрастать. 2. Согласно материалам компании Gartner, для бизнес-аналитиков всё более востребованными станут специальные навыки анализа бизнес-данных и владение соответствующими техниками и инструментами. Что касается техник ИТ-бизнес-анализа, то фокус их применения будет сосредоточен на разработке ИТ-решений: с одной стороны, удовлетворяющих потребности бизнеса, а с другой – обеспечивающих сбор, хранение и обработку качественных исходных бизнес-данных для их последующего использования. Всестороннее, обстоятельное проектирование ИТ-решений с учетом потребностей всех заинтересованных сторон, включая аналитиков данных, – фундаментальное условие для развития современного бизнеса. В случае, если ИТ-решение проектируется без учета потребностей в последующей аналитике хранящейся в нем информации, работа над повышением качества этих данных может существенно усложниться. Более того, мероприятия по обработке и «очистке» данных могут оказаться настолько трудоемкими, что поставят под сомнение целесообразность их последующего анализа. Эта проблема стала актуальной с момента возникновения понятия Business Intelligence, упоминавшегося ранее. Таким образом, техники, связанные с проектированием ИТ-решений (сбор и анализ требований, выявление заинтересованных сторон, моделирование и анализ бизнес-процессов, составление матриц ролей и прав и т. д. и т. п.), останутся весьма востребованными. Что же касается специализированных навыков в области BI-аналитики, востребованных в ближайшем будущем, то они таковы: • экспертиза в предметной области, в рамках которой создаются бизнес-данные (включая терминологию и регуляторные ограничения); • анализ сложных структур данных и перевод их в стандартизированный формат; • техники анализа данных, включая основы статистики, профилирование и агрегирование; • владение инструментами BI-отчетности; • лучшие практики ETL (Extract, Transform, Load – извлечение, преобразование, загрузка), включая отслеживание исторических данных. Итак, бизнес-анализ как дисциплина непрерывно изме- няется. Наибольшее влияние на него оказывают актуальный уровень развития технологий и управленческие концепции, призванные извлечь из этих технологий максимум выгоды. Одни техники бизнес-анализа более общие – их можно применять в разных проектах и предметных областях. Другие же нацелены на работу с конкретными технологиями. Так или иначе, для работы бизнес-аналитика важно иметь представление и о базовых принципах ведения бизнеса, и о современных технологиях и тенденциях их развития. Подобные знания помогают аналитику налаживать взаимопонимание между всеми заинтересованными сторонами, а это – обязательное условие реализации любого ИТ-проекта. 1.6. BABOK. Главная книга бизнес-анализа В конце XX века в англоязычном профессиональном сообществе зародилось такое явление, как BOK – от английского body of knowledge, или «свод знаний». Классический свод знаний представляет собой серьезный многостраничный труд. Его основная цель – дать определение некой профессиональной деятельности и утвердить ее базовую методологию: термины, практики, инструменты и т. д. За несколько последних десятилетий появилось множество сводов знаний, посвященных различным сферам деятельности. Например: • PMBOK (Project Management Body of Knowledge) – управление проектами; • DMBOK (Data Management Body of Knowledge) – управление данными; • SEBOK (System Engineering Body of Knowledge) – системная инженерия и т. д. Первым BOK, о котором я услышал, был PMBOK – свод знаний по управлению проектами. Чуть позднее я узнал о существовании BABOK – своде знаний о бизнес-анализе. Ему и посвящен данный раздел. Но для начала давайте познакомимся с таким явлением, как свод знаний, чуть подробнее. Своды знаний создают профильные организации и институты, такие как Институт проектного менеджмента (PMI) или Международный институт бизнес-анализа (IIBA). По моим субъективным впечатлениям, до начала 2010-х годов этот тип справочников не был широко распространен в России. Предположу, что причин тому было две. 1. Все организации, занимающиеся разработкой и продвижением сводов знаний, изначально возникли за рубежом – в США, Канаде и т. д. В России же региональные отделения соответствующих институтов не открывались довольно долго. Так, PMI был основан в 1969 году, а его московское отделение открылось лишь в 1997-м. IIBA появился в Канаде в 2003-м, а российское представительство создали только в 2015-м. 2. Продолжительное время своды знаний существовали исключительно на английском языке, что затрудняло их распространение в русскоязычном профессиональном сообществе. По сети гуляли любительские переводы, качество которых оставляло желать лучшего. Перевести свод знаний на русский – нетривиальная задача. Вопрос не только в грамотном переложении текста с одного языка на другой: важнее всего – обеспечить корректную передачу смысла. Один и тот же термин в России и США может иметь разную трактовку, глубину, контекст использования. Первое русское издание BABOK увидело свет в издатель- стве «Олимп – Бизнес» в 2021 году. BABOK, как и любой другой свод знаний, – кладезь полезной информации и источник пищи для размышлений. При этом важно отметить, что начинать знакомство с дисциплиной «бизнес-анализ» именно с BABOK будет непросто. Это фундаментальный труд, создатели которого стремились систематизировать сложный и многогранный мир бизнес-анализа. Данная книга – однозначно не легкое чтиво, которое можно пролистать за пару выходных. Первая ассоциация, возникающая при знакомстве с книгой, – кодексы: обстоятельные фолианты, систематизирующие нормы определенных сфер жизни общества. Едва ли кто скажет, что чтение, допустим, гражданского кодекса – увлекательное занятие. Тем не менее оно необходимо профильным специалистам. BABOK требует вдумчивого, обстоятельного чтения. Многое из этого свода знаний становится понятным лишь при наличии богатого личного опыта, а у начинающего специалиста его как раз таки нет. Взять хотя бы термин «решение». В контексте ИТ-проекта под «решением» обычно понимают информационную систему, внедрение которой преследует определенные цели бизнеса. И если у начинающего специалиста еще нет опыта участия в подобных проектах, если ему не приходилось сталкиваться со всем многообразием сопутствующих ситуаций, вопросов и трудностей, то термин «решение» для него – не бо- лее чем абстракция: умное слово в окружении других умных слов. Как правило, новичок обращается к профессиональной литературе в надежде быстро получить ответы на свои вопросы, а в идеале – и четкую программу действий, которую можно применить на практике. BABOK не дает такой программы. В книге, скорее, делается попытка охватить всё многообразие информации, при помощи которой подобную программу действий можно сформулировать. BABOK вводит ключевые понятия и очерчивает области знаний бизнес-анализа. Кроме того, книга рассказывает об элементах, из которых состоит та или иная область знаний. У читателя появляется понимание того, какая информация должна подаваться на вход и что должно получиться в результате. Всё это описано на верхнем уровне, без погружения в детали, что совершенно естественно. Задача BABOK – обозначить структуру бизнес-анализа как сферы деятельности, разложить по полочкам ее ключевые составляющие. Даже при том, что уровень абстракции в книге довольно высок, труд получился весомый: более 600 страниц. В книге неоднократно подчеркивается, что выбор тех или иных практик и инструментов бизнес-анализа зависит от множества факторов: отраслевой принадлежности компании, ее финансового состояния, поставленных сроков, выделенных бюджетов, корпоративной культуры и т. д. Поэтому BABOK – не универсальный ответ на вопрос «что делать?» и не набор готовых рецептов на все случаи жизни. Тем не менее этот свод знаний может натолкнуть на полезную мысль и задать направление дальнейшего поиска. Данный справочник охватывает очень широкий спектр направлений в деятельности бизнеса. Упомянуты и работа с требованиями, и финансовый анализ, и управление рисками, и работа с KPI и т. д. и т. п. Из-за этого может сложиться впечатление, будто бизнес-аналитик должен знать и уметь практически всё, что так или иначе касается бизнеса. Конечно, стремление стать всесторонне развитым специалистом похвально. Однако существование подобных универсалов в реальности сомнительно. В крупной компании для каждого из перечисленных видов деятельности может существовать по отдельному департаменту, а иногда и не по одному. Чем же BABOK полезен для начинающего специалиста? БАЗОВЫЕ ПОНЯТИЯ БИЗНЕС-АНАЛИЗА Начнем с модели базовых понятий бизнес-анализа – BACCM. Очень крутая и лаконичная вещь. Фактически – универсальная шпаргалка бизнес-аналитика. Модель базовых понятий – это шесть терминов и их обстоятельное описание: Изменение, Потребность, Решение, Заинтересованные стороны, Ценность, Контекст. Каким бы проектом ни занимался бизнес-аналитик, он всегда может задать себе проверочные вопросы типа: • Какого рода изменения мы осуществляем? • Какие потребности мы пытаемся удовлетворить? • Какие решения мы создаем или изменяем? • Какие заинтересованные стороны вовлечены? • Что представляет ценность для заинтересованных сторон? • В каких контекстах находимся мы и решение? Отвечая на эти и похожие вопросы, бизнес-аналитик делает свою работу более последовательной и осмысленной. БАЗОВЫЕ КОМПЕТЕНЦИИ И ТЕХНИКИ Для начинающих не менее ценными и практически применимыми будут разделы 9 и 10. Раздел 9 – «Базовые компетенции» – дает представление о том, какие знания и навыки будут востребованы в карьере бизнес-аналитика. При помощи данного раздела можно составить краткую интеллект-карту и периодически сверяться с ней на пути своего профессионального развития. В разделе 10 – «Техники» – дается обзор 50 (!) методов решения задач бизнес-анализа. Описание техник составляет почти 30 % всей книги, а это примерно 200 страниц. Особенно удобно то, что для каждой области знаний и решаемых в ее границах задач приводится рекомендуемый набор методов. Именно эта взаимосвязь задач и методов их решения позволяет использовать BABOK в качестве настольного справочника бизнес-аналитика. Обзоры техник краткие: по итогам их прочтения не всегда складывается четкое понимание того, как использовать тот или иной метод на практике. Это нормально: детально разобрать 50 техник в одной книге – нереально. О некоторых из них, таких как «Построение бизнес-моделей», специалисты пишут отдельные книги. Тем не менее описаний ряда техник может быть вполне достаточно для их практического применения. РАКУРСЫ БИЗНЕС-АНАЛИЗА Отмечу также раздел 11 – «Ракурсы». Здесь приводится описание работы бизнес-аналитика в разных контекстах: • Agile; • IT; • Управление процессами; • Business intelligence; • Бизнес-архитектура. В своих материалах я неоднократно отмечал, насколько широки границы профессии бизнес-аналитика. Имея аналогичные записи в трудовой книжке, специалисты могут заниматься абсолютно разными задачами: один работает над со- вершенствованием информационной системы, второй – описывает бизнес-процессы, третий ищет скрытые связи и закономерности в больших объемах данных и т. д. И всё это называют бизнес-анализом. Из-за такого многообразия деятельности у начинающего бизнес-аналитика могут возникнуть сложности с профессиональной самоидентификацией. Закрадывается сомнение: а бизнес-анализом ли он занимается? Ведь коллеги с аналогичными должностями в других подразделениях и организациях решают совершенно другие задачи. Разрешить подобные сомнения как раз и помогает 11-й раздел BABOK. В нем приводится описание наиболее распространенных направлений работы в бизнес-анализе, в том числе с учетом последних тенденций развития отрасли – гибких методологий и анализа бизнес-данных. Важная оговорка: в рамках конкретной инициативы или проекта могут применяться любые из перечисленных ракурсов и в любой комбинации. Например, одна инициатива потребует только одного подхода к бизнес-анализу, в то время как другая – использования всех пяти ракурсов. Конечно, и указанные пять ракурсов не охватывают полного многообразия бизнес-анализа как сферы деятельности. Это наиболее распространенные представления о данной работе на момент написания книги. Поэтому начинающему специалисту будет полезно изучить 11-й раздел BABOK, чтобы понять, какие ракурсы бизнес-анализа применяются в его организации для решения конкретных задач. Это позволит ему сформировать для себя четкую картину того, чем занимается подразделение – и можно ли применять иные ракурсы и техники для повышения разнообразия и продуктивности работы. Как уже отмечалось ранее, прелесть профессии бизнес-аналитика – в широчайшем спектре вариантов развития карьеры и расширения кругозора. Можно расти в сторону проектного управления, создания цифровых продуктов, оптимизации процессов и информационных систем, анализа данных и т. д. и т. п. Ракурсы бизнес-анализа помогут понять, какое направление работы ближе именно вам. Подводя итоги, можно сказать, что BABOK – прекрасный тренажер для вдумчивого чтения. По сути, эту книгу нужно не читать, а штудировать: тщательно изучать, перечитывая и обдумывая каждую фразу. При таком подходе чтение BABOK займет не менее нескольких месяцев. Средний темп чтения составит всего 5–10 страниц в день. Будет ли заниматься штудированием молодой специалист, вчерашний выпускник вуза? Вероятнее всего, нет. Конечно, можно пробежаться по тексту за пару выходных, не вникая и не усваивая материал. Но смысла в этом немного. Повторюсь, BABOK – книга для регулярного изучения и обдумывания. Объем информации, представленный в ней, настолько велик, что, возвращаясь к прочитанным разделам, вы всегда имеете шанс открыть для себя что-то новое, иначе взглянуть на, казалось бы, понятную ситуацию. Сложность и длительность чтения отчасти связаны с высоким уровнем абстракции понятий, рассматриваемых в BABOK, а отчасти – с трудностями перевода и сухим стилем изложения. Через некоторые словесные конструкции буквально приходится продираться. Думаю, многие читатели решат, что тратить несколько месяцев на одну книгу – роскошь. Современная аудитория привыкла к информационному стилю – его легко читать, в нем нет сложных фраз и канцелярита. Для того чтобы упростить чтение BABOK без потери сути, нужно проделать титаническую редакторскую работу. Однако BABOK не стоит воспринимать как литературное произведение, всё-таки это профессиональный справочник. Допускаю, что последовательное чтение «от корки до корки» – не лучший вариант изучения этой книги. Возможно, разумнее будет выбрать наиболее актуальную для вас область знаний, а затем перейти к соответствующим техникам. В данном случае BABOK станет чем-то вроде кодекса на книжной полке, к которому обращаются по мере возникновения вопросов. Глава 2 Практика бизнес-анализа. От описания процессов до постановки требований 2.1. Роль бизнес-анализа в современной организации В данной главе мы поговорим о том, что представляет собой профессия «бизнес-аналитик». Вы узнаете, какие задачи решают эти специалисты и в чем ценность их участия в ИТпроектах. Но начнем мы с обсуждения роли бизнес-анализа в работе современной организации. Условно деятельность любой организации можно разбить на три блока: «Финансы», «Развитие» и «Клиенты». Каждому блоку соответствуют свои ключевые задачи, а также виды аналитики, помогающие в их решении. Как видно из рисунка 2, бизнес-анализ относится к блоку «Развитие». Это логично, ведь его ключевая задача – обеспечить переход организации из текущего состояния в целевое. Рисунок 2. Блоки и задачи разных видов аналитики Обратите внимание, что бизнес-анализ используется при решении двух классов задач: «Оптимизация процессов» и «Внедрение новых технологий». Здесь важно отметить, что с течением времени понимание роли бизнес-аналитика в организации существенно расширилось. Раньше его воспринимали исключительно как специалиста по моделированию и анализу бизнес-процессов. Иными словами, задача бизнес-анализа заключалась по большей части в описании текущего и определении структуры целевого, «идеального» бизнес-процесса. Еще 10–15 лет назад трансформация бизнес-процессов могла не иметь никакого отношения к технологиям: просто изменялись зоны ответственности, порядок выполнения действий, вводились контрольные процедуры и т. д. При этом технологическая платформа бизнес-процессов практически не менялась. Однако с течением времени развитие технологий привело к тому, что любой проект по совершенствованию работы организации стал включать в себя ИТ-составляющую. Для решения поставленных задач бизнес-аналитикам приходилось всё больше работать бок о бок с техническими специалистами: системными аналитиками, разработчиками, инженерами по тестированию, что потребовало от бизнес-аналитиков расширения компетенций в области информационных технологий. В связи с этим бизнес-аналитика начали воспринимать как посредника между миром бизнеса и миром ИТ. С тех пор как любой проект по оптимизации процессов стал связан с ИТ, организациям срочно потребовались специалисты, способные найти общий язык со всеми заинтересованными сторонами. Так бизнес-аналитик стал своеобразным «универсальным солдатом», который в своей работе общается со всеми – начиная с ИТ-инженеров и бизнес-заказчиков и заканчивая высшим руководством компании. На мой взгляд, это один из ключевых плюсов данной профессии. С течением времени специалист по бизнес-анализу становится экспертом с широким кругозором, развитыми коммуникативными навыками и экспертизой по самым разным вопросам. Конечно, глубина этой экспертизы не сравнится с компетенциями узкопрофильных специалистов. Но это обстоятельство компенсируется широтой взглядов. У опытного бизнес-аналитика множество вариантов продолжения карьеры в зави- симости от личных предпочтений. Проработав в компании несколько лет, он начинает понимать внутреннюю кухню ИТ-разработки, тестирования, управления проектами и процесса продаж. Обладая подобными знаниями, а также налаженными связями, бизнес-аналитик с большей легкостью, чем специалисты извне, развивается в смежных областях. Что же такое ИТ-проект? Классический ИТ-проект – это комплекс взаимосвязанных мероприятий по разработке и (или) внедрению информационной системы для бизнес-заказчика. Напомню: цель ИТ-проекта – обеспечить переход компании из текущего состояния в целевое путем автоматизации и оптимизации процессов. Инструментом для автоматизации и оптимизации в данном случае выступает информационная система. Как и у любого другого, у ИТ-проекта есть план мероприятий с ограниченными сроками, бюджетом и трудовыми ресурсами. Приведу пример. Практически в любом крупном банке найдутся десятки бизнес-процессов, которые можно улучшить: сделать прозрачными, эффективными, уменьшить количество ручных операций. Даже в крупных банках встречаются отделы, бóльшая часть рабочего времени которых уходит на перенос данных вручную из одной системы в другую. Причина этого в отсутствии информационного обмена между разными банковскими системами. Конечно, процесс процессу рознь – некоторые из них имеют десятки нюансов или слишком дороги для автоматизации. В этом случае бан- ку проще содержать целый отдел для выполнения рутинных работ, нежели внедрять ИТ-решение. Однако возможна частичная автоматизация таких процессов, которая если и не заменит человека полностью, то сильно облегчит его работу. Кроме того, в любой крупной организации существуют процессы, обладающие всеми признаками, говорящими о том, что их можно полностью автоматизировать, а именно: • работа выполняется вручную; • работа повторяется изо дня в день; • выполняемые процессы линейные: работа выполняется шаг за шагом, нет сложной, разветвленной логики принятия решения; • наборы полей, откуда нужно брать данные и куда переносить, – известны. Так или иначе, любой ИТ-проект, в котором участвует бизнес-аналитик, посвящен автоматизации, систематизации и оптимизации какой-либо деятельности. Цель бизнес-аналитика – понять, в чем проблема текущих процессов и каковы варианты их усовершенствования. Теперь важно сказать несколько слов о понятии «заказчик» или «бизнес-заказчик». При реализации любого ИТ-проекта возникает система взаимоотношений «заказчик – исполнитель». Зона ответственности заказчика: 1. Доступным языком рассказать о своей предметной области и бизнес-процессах: чем занимается подразделение, какие задачи решает, какие цели перед собой ставит, кто и за какие участки работ отвечает. 2. Объяснить аналитику, каковы ключевые сложности, с которыми сталкивается заказчик в текущих бизнес-процессах. 3. Сообщить о своем понимании целевого бизнес-процесса и ожидаемых результатах. Исполнитель же, в свою очередь, отвечает за создание ИТрешения, призванного устранить проблемы в бизнес-процессах заказчика. Главное, о чем стоит помнить при делении специалистов на «заказчиков» и «исполнителей»: заказчик говорит на языке бизнеса, исполнитель – на языке ИТ. Бизнес-аналитик может быть как представителем заказчика, так и представителем исполнителя. Как же такое возможно? Рассмотрим варианты взаимоотношений заказчика и исполнителя в ИТ-проекте. Вариант 1: и заказчик и исполнитель – сотрудники одной организации. Для примера возьмем уже полюбившийся нам крупный банк. В нем существует Департамент розничного бизнеса (ДРБ), отвечающий за работу с физическими лицами. Предположим, ДРБ хочет оптимизировать свои процессы – и для этого ему необходимо ИТ-решение. Если банк крупный и обладает достаточными техническими компетенциями, то ДРБ совершенно не обязательно обращаться к внешней ИТ-компании для разработки необходимого решения. Вместо этого ДРБ обращается в Департамент информационных технологий (ДИТ) в своем же банке, и специалисты ДИТ реализуют необходимую бизнесу доработку в рамках текущей деятельности. В данном случае ДРБ – заказчик, а ДИТ – исполнитель. Но кто же из них формулирует требования к ИТ-решению, без которых не обойтись в процессе разработки? Бизнес-аналитик, ответственный за разработку требований, может быть как сотрудником ДРБ, так и сотрудником ДИТ. Как правило, в первом случае аналитик больше специализируется на процессах розничного бизнеса, а во втором – на технических моментах. Кроме того, в банке может существовать отдельный Департамент аналитики, не входящий в состав ДРБ и ДИТ. В этом случае заказчик обращается в Департамент аналитики за содействием в реализации ИТ-проекта. Как правило, здесь работают универсальные специалисты, обладающие знаниями в области бизнеса и ИТ, но не специализирующиеся на чем-то конкретном. Вариант 2: заказчик и исполнитель – представители разных организаций. Если у того же банка недостаточно компетенций или ресурсов для самостоятельной разработки требуемого ИТ-решения, то многие компании на рынке го- товы предложить ему свои услуги. В этом случае ДРБ обращается к представителям той или иной ИТ-компании и объясняет, как они хотели бы оптимизировать свои процессы. Банк даже может провести тендер, чтобы выбрать исполнителей, предлагающих наилучшие условия. Но, с тендером или без, заказчику необходимо подготовить четкие требования к будущему ИТ-решению. И здесь, опять же, возможны два варианта работы бизнес-аналитика. 1. Бизнес-аналитик – сотрудник банка из ДРБ, ДИТ или Департамента аналитики. В этом случае он проводит исследование предметной области подразделения-заказчика (возможно, своего собственного) и готовит требования к будущему ИТ-решению. В эти требования включаются карты бизнес-процессов, таблицы, диаграммы – всё, что может пригодиться системным аналитикам и разработчикам при знакомстве с предметной областью заказчика. Требования становятся частью технического задания, которое затем отправляется на оценку в ИТ-компании. На основании их ответов о сроках и стоимости проекта банк выбирает исполнителя. Кроме того, в дальнейшем требования используются при разработке самого ИТ-решения. При таком сценарии анализ предметной области и подготовка требований не создают банку дополнительных затрат, так как выполняются его же сотрудниками, получающими зарплату. 2. Бизнес-аналитик – сотрудник ИТ-компании. В этом случае исследование предметной области заказчика проводится внешним по отношению к банку специалистом. Это исследование может проводиться как до заключения официального договора между заказчиком и исполнителем, так и после старта проекта. Всё зависит от достигнутых договоренностей. Так или иначе, результатом работы аналитика становятся те же требования к ИТ-решению: карты процессов, диаграммы, таблицы и т. д. На основе сформулированных требований ИТ-компания оценивает сроки и стоимость работ, а также организует процесс разработки и (или) настройки ИТ-решения. Далее в книге, говоря о бизнес-анализе, я по умолчанию буду иметь в виду именно такой вариант взаимоотношений между заказчиком и исполнителем. Переходя к обсуждению ключевых задач бизнес-аналитика, важно помнить: в основе любого ИТ-проекта лежит некая проблема. Не будь проблемы, у заказчика не было бы и повода обращаться к исполнителю для создания или доработки ИТ-решения. Чтобы устранить данную проблему, ее для начала нужно сформулировать. Казалось бы, очевидно: как решать задачу, которой не понимаешь? Парадоксально, но многие команды именно так и поступают, особенно на ранних стадиях работы над проектом. Естественно, это сказывается на итоговых результатах и порой приводит к необходимости переделывать всю работу. Следовательно, одна из ключевых задач аналитика – минимизировать ве- роятность подобной ситуации за счет скрупулезного фиксирования информации по проекту и стремления не оставить ни одного вопроса без ответа. Подробнее об этом – в следующей главе. 2.2. Ключевые задачи бизнес-аналитика Итак, какие же основные задачи решает бизнес-аналитик? Всего их девять (см. рис. 3). Рассмотрим подробнее каждую из них. МОДЕЛИРОВАНИЕ БИЗНЕСПРОЦЕССОВ AS IS И TO BE Первое, с чего начинается работа бизнес-аналитика в ИТпроекте, – изучение предметной области заказчика. Рисунок 3. Ключевые задачи бизнес-аналитика Невозможно оптимизировать какую-либо деятельность, не понимая ее сути. Тем более невозможно четко поставить задачу разработчикам решения, если до конца не ясен контекст его использования в будущем. Создание карт бизнес-процессов – удобный и наглядный инструмент для описания текущей работы заказчика и его представлений о целевом процессе. С точки зрения моделирования бизнес-процессов бизнес-аналитик всегда находится в двух плоскостях: «as is» («как есть») и «to be» («как должно быть»). Выстраивая карты процессов «как есть», бизнес-аналитик погружается в предметную область заказчика. Ему становятся понятны логика и цель действий, выполняемых участниками процесса. Если специалист имеет на руках наглядную схему текущей деятельности, ему намного проще зафиксировать проблемные зоны процесса, в том числе так называемые «бутылочные горлышки». «Бутылочное горлышко» – это узкое место в процессе: функция или набор функций с низкой пропускной способностью. Русская пословица гласит: «Где тонко, там и рвется». В случае же с бизнес-процессами можно сказать: «Где узко – там потеря времени и денег». Рассмотрим «бутылочное горлышко» на примере. Представим себе банк с разветвленной филиальной сетью из десятков офисов. В каждом офисе менеджеры обслуживают клиентов и принимают заявки на выдачу кредитов. Каждую заявку менеджер заводит в информационную систему и отправляет на проверку в центральный офис, где их обрабатывает кредитный аналитик. Допустим, у него нет удобных инструментов для выяснения всех деталей заявки: кредитной истории клиента, оценки рисков и т. д. Из-за этого кредитный аналитик тратит уйму времени на проверку. Представьте себе, что в день ему поступают десятки кредитных заявок, но скорость предоставления клиенту ответа о выдаче кредита полностью зависит от скорости работы кредитного аналитика. Неважно, насколько быстро и качественно клиента об- служили в офисе, – это практически не влияет на скорость получения ответа. В данном случае все ждут кредитного аналитика. Таким образом, функция кредитного анализа становится в процессе тем самым «бутылочным горлышком», из-за которого резко снижается уровень клиентского обслуживания. Если у бизнес-аналитика имеется на руках карта процесса «как есть», ему гораздо проще выявлять подобные проблемы. Их можно выделять на карте процесса и обсуждать на встречах с заказчиком. Вторая плоскость описания процессов – «как должно быть». При создании карт процессов этого типа бизнес-аналитик предлагает заказчику представить идеальный в его понимании целевой процесс. Карта этого процесса должна отвечать на вопрос о том, как будет организована деятельность заказчика с учетом необходимых изменений, в том числе с учетом внедрения новой информационной системы. Например, если карта «как есть» описывает сложный, бюрократизированный бизнес-процесс с обилием ручных операций, то карта «как должно быть» отражает светлое будущее, где уже внедрена информационная система, а недостатки работы устранены. Конечно, «идеальный» процесс должен подчиняться здравому смыслу и соответствовать технологическим и финансовым возможностям компании-заказчика. Не стоит моделировать процесс, учитывающий внедрение самых современ- ных технологий, если у заказчика нет денег или недостаточно компетенций для их применения. Бывает так, что карты процессов «как есть» и «как должно быть» отличаются всего лишь одной функцией. Например, в первом случае функция выполняется вручную, во втором – при помощи информационной системы. С точки зрения карты различия минимальны. Но, реализованные на практике, такие изменения могут сэкономить множество финансовых и трудовых ресурсов. При этом не стоит забывать, что автоматизация даже одной функции порою становится нетривиальной технической задачей. В этом случае не обойтись без системных аналитиков, ИТ-архитекторов и разработчиков. Некоторые заказчики стремятся сразу же перейти к описанию процесса «как должно быть». Они говорят: «Я и так прекрасно знаю, что меня не устраивает! Давайте обсудим идеальный процесс!» Можно ли приступать к работе над идеалом без рассмотрения текущей ситуации? Можно, но нежелательно. Дело в том, что карта «как есть» позволяет избежать узкого, субъективного взгляда на текущую деятельность. Вероятность выявить существенные детали при описании процесса «как есть» намного выше. Это касается взаимодействия разных подразделений, логических развилок, зон ответственности и т. д. Если же сразу начинать с процесса «как должно быть», можно упустить важные детали. Более того, существует риск, что при обсуждении це- левого процесса подразделение-заказчик забудет об интересах других. Каждый руководитель в первую очередь исходит из нужд своего собственного подразделения. Возможна ситуация, при которой вы, как аналитик, потратите время и усилия на создание карты процесса «как должно быть», а потом окажется, что она не учитывает особенности работы других подразделений, поскольку заказчик в ходе работы подумал только о себе. В этом случае карты процессов придется переделывать. Подробнее о том, с чего начинать описание бизнес-процессов, мы поговорим в следующих разделах. ФОРМУЛИРОВАНИЕ ТРЕБОВАНИЙ К ИТ-РЕШЕНИЮ Конечная цель ИТ-проекта – создание ИТ-решения, которое принесет пользу заказчику. ИТ-решение – это совокупность программных и аппаратных средств, выполняющих определенную бизнес-задачу. Для того, чтобы решение учитывало все нюансы деятельности заказчика, и нужен бизнес-анализ. Результатом анализа в этом случае станут различного рода требования: процессные, пользовательские, функциональные и т. д. В основе процессных требований лежат карты процессов «как есть» и «как должно быть». Эти требования описывают текущее и целевое состояние бизнес-процесса, зоны ответ- ственности, используемые в работе программные продукты и т. д. Также в процессных требованиях могут фиксироваться как фактические, так и целевые измеримые показатели процесса. Например, в них может указываться, что внедрение ИТ-решения должно увеличить среднюю скорость выполнения процесса на X минут или Y процентов. Особое внимание в процессных требованиях уделяется различиям между текущим процессом и целевым. Так, в них отражаются все изменения, связанные с последовательностью выполнения функций, форматом их выполнения, ответственными исполнителями и т. д. Пользовательские требования посвящены тем задачам, которые непосредственный пользователь стремится выполнить при помощи ИТ-решения. Иными словами, в подобных требованиях описываются сценарии действий, которые пользователь предпринимает в системе для решения конкретной задачи. В функциональных требованиях, в свою очередь, описываются конкретные функции будущего решения, которые должны реализовать разработчики. Созданию требований к ИТ-решениям посвящен специальный раздел данной книги. МОДЕЛИРОВАНИЕ ЭКРАННЫХ ФОРМ БУДУЩЕГО ИТ-РЕШЕНИЯ Один из важнейших критериев качества любого ИТ-решения – удобство использования. Даже самую технически совершенную систему можно испортить неудобным, неочевидным интерфейсом. Удобство – понятие субъективное. Недаром мы выделили UX/UI-аналитику в отдельное направление. Однако бывает и так, что на вашем проекте нет соответствующего специалиста или у информационной системы, на базе которой вы планируете создать ИТ-решение, ограничены возможности по изменению экранных форм и элементов управления. В этом случае бизнес-аналитик может предложить заказчику совместно набросать на листе бумаги интерфейс будущего ИТ-решения, где будут обозначены поля для ввода информации, кнопки, информационные окна и т. д. Процесс это творческий и довольно увлекательный. Как правило, заказчики с удовольствием принимают в нем участие. Интерфейс системы очень зависит от процесса работы с ней: на определенных этапах нужны одни экранные элементы, на других – другие. Таким образом, при разработке экранных форм нужно учитывать два обстоятельства. 1. Уместность тех или иных экранных элементов на каждом конкретном этапе работы с системой. 2. Технические ограничения информационной системы с точки зрения модификации интерфейса. Иными словами, аналитик должен следить за тем, чтобы заказчик не предложил такой интерфейс, который нельзя реализовать средствами системы. Завершив наброски, аналитик создает макеты экранных форм при помощи векторного графического редактора типа Microsoft Visio. Рукописные заметки превращаются в аккуратные иллюстрации интерфейса. Эти иллюстрации становятся частью требований к ИТ-решению. Макеты экранных форм упрощают разработчикам реализацию интерфейса, близкого к ожиданиям заказчика. К тому же становится понятнее сценарий взаимодействия пользователя с будущим ИТ-решением. СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОЙ ДОКУМЕНТАЦИИ Бизнес-аналитик – это специалист, который способен взглянуть на ИТ-решение глазами конечного пользователя. Иными словами, он знает, как данное решение помогает пользователю выполнять стоящие перед ним задачи. Именно поэтому бизнес-аналитик часто отвечает за создание пользовательской документации. Он пишет инструкции, в которых понятным языком и с обилием иллюстраций рассказывает- ся, как выполнять то или иное действие в информационной системе. В инструкциях учитываются все нюансы процессов заказчика, а также технические ограничения информационной системы. Инструкции пользователя часто входят в комплект обязательной документации, передающейся заказчику по завершении проекта. ВЕДЕНИЕ БАЗЫ ЗНАНИЙ Дейл Карнеги в своих книгах вывел одно из главных правил по борьбе со стрессом. Звучит оно так: ПОРЯДОК – ПЕРВЫЙ ДЕЯТЕЛЬНОСТИ. ЗАКОН ДЕЛОВОЙ И действительно, во время работы ничто не создает большего стресса, чем суета и неразбериха. Если вы хотя бы раз не могли найти свои записи к срочной встрече, то знаете, о чем речь. Значительную роль в поддержании порядка в ИТпроекте играет бизнес-аналитик. Одна из главных задач бизнес-аналитика – поддержание в проектной команде единого информационного поля. Главный инструмент для этого – ведение базы знаний. Для начала разберемся с понятием «знание». Воспользуемся примером из книги Карла Андерсона «Аналитическая культура»17. Представьте себе: вы подходите к термометру и видите, что он показывает «6 градусов выше нуля». Это данные. Сам по себе факт того, что термометр показывает шесть градусов, мало о чем говорит. Но давайте добавим контекста. В какой ситуации мы смотрим на термометр? Допустим, мы находимся в Москве, на календаре 8 июня, время – 15:00. Это информация. О чем нам говорит данная информация? Мы знаем, что +6 в июне в середине дня – аномально прохладная погода для Москвы. Отсюда мы делаем вывод о том, что при выходе из дома надо надеть теплую куртку. А вот это уже знание. В приведенном выше примере данные – показания термометра. Информация – данные, сгруппированные и обобщенные по определенному признаку: мы соотнесли показания термометра с датой, временем и местом их получения. А знания – практически применимая информация, которая отвечает на вопрос «какие действия необходимо предпринять?». В данном случае знание – это вывод: «Если на улице аномальное похолодание, надо одеваться теплее». База, в которой аналитик фиксирует всю ценную и практически применимую информацию по проекту, называется базой знаний. В ней может храниться всё что угодно: карты бизнес-процессов, сравнительные таблицы, нормативные документы и т. д. Команда проекта использует всё это в ра17 См.: Андерсон К. Аналитическая культура… боте. База знаний позволяет аккумулировать информацию о проекте в одном месте и обеспечивает одновременный доступ к ней всем членам проектной команды. Кроме того, наличие базы знаний значительно облегчает погружение в проект новых специалистов. Более опытные товарищи, отвечая на тот или иной вопрос коллеги, могут просто поделиться ссылкой на статью в базе, где содержатся нужные ответы. Это сильно экономит время и силы, которых всегда не хватает участникам ИТ-проекта. Стандартом программного обеспечения для базы знаний является Confluence. Confluence – тиражируемая вики-система, которую организации используют для создания общей базы знаний. Разрабатывается австралийской компанией Atlassian, наряду с системой отслеживания ошибок Jira. Пользователи Confluence самостоятельно наполняют систему информацией и изменяют ее при помощи встроенных инструментов. В этом смысле Confluence идеологически близка к «Википедии». Если в вашем проекте есть возможность вести базу знаний в Confluence – настоятельно рекомендую ею воспользоваться. С точки зрения ответа на вопрос «что делать?» особенно важно занесение в базу знаний протоколов совещаний. Совещание… Сколько времени и потраченных усилий в этом слове! Но без них не обойтись ни в одном проекте. Для чего же проводят совещания в ИТ-проектах? Основ- ные причины следующие. 1. Совещания позволяют поддерживать единый информационный фон. Благодаря им все будут в курсе того, кто чем занимается и за что отвечает в настоящее время. Это позволяет избежать недоразумений и рассогласованности в действиях. Иными словами, хаоса и работы в духе «кто в лес, кто по дрова». 2. На совещаниях обсуждаются текущие задачи, а также проблемы, связанные с их выполнением. Если у кого-то из членов проектной команды возникли проблемы с той или иной задачей, команда должна оперативно узнать об этом. Такой подход позволит вовремя вмешаться в ситуацию, помочь коллеге и не допустить того, чтобы небольшая сложность привела к печальным последствиям вроде смещения сроков проекта. 3. На совещаниях распределяются зоны ответственности. Это касается как представителей заказчика, так и представителей исполнителя. Участники совещания определяют, кто и за что отвечает, какую работу и в какие сроки проводит. 4. На совещаниях с представителями заказчика уточняются детали бизнес-процессов, проясняются технические и законодательные моменты. В большинстве случаев именно на совещаниях аналитик получает информацию, необходимую для формирования карт бизнес-процессов. 5. На совещаниях обсуждаются и фиксируются риски проекта. Риски – это вероятность наступления неблагоприятных для проекта событий вследствие неопределенности. Например, у разработчиков внезапно вышли из строя компьютеры или перестала работать сеть. Или правительство внезапно приняло новый закон, а проектируемое ИТ-решение не учитывает его требований. С чем бы ни был связан риск, его необходимо зафиксировать как можно раньше. После этого команда должна предложить варианты его устранения. Некоторые риски могут быть настолько существенными, что приводят к смещению сроков или увеличению бюджета проекта. 6. Ретроспективный анализ. Если процесс создания ИТрешения поделен на итерации, команде очень полезно периодически собираться для проведения так называемого ретро. Ретро – это совещание, на котором команда обсуждает результаты работы за определенный промежуток времени. Основные вопросы, которые обсуждаются на этом собрании: • Что было сделано хорошо за прошедший период? Что больше всего понравилось, вызвало воодушевление у членов команды? • Какие приемы, примененные в прошедшем периоде, можно в дальнейшем использовать постоянно? Какие прак- тики стоит зафиксировать? • Что за прошедший период было сделано плохо? Что больше всего не понравилось, с какими сложностями пришлось столкнуться? • Что стоит предпринять для того, чтобы минимизировать вероятность аналогичных негативных ситуаций в будущем? Ретро – мощный инструмент развития проектной команды, поскольку коллектив учится критическому взгляду на свою работу, стремится улучшить ее и исключить негативные моменты. 7. На совещании принимаются решения о дальнейших действиях. Опираясь на базу знаний и собственные соображения, участники проектной команды принимают решение о том, что делать дальше: какие вопросы требуют дополнительного изучения, кому и с кем нужно связаться, что выяснить и т. д. Совещание, результаты которого не были зафиксированы, – впустую потраченное время. Допустим, вы провели ретро с командой. Обсуждение прошло в «теплой дружеской обстановке», все поделились своим мнением о том, что было хорошо, а что плохо, что стоит применять в дальнейшем, а что лучше исключить. И, ничего не записав, вы расстались, весьма довольные друг другом. Можете быть уверены: через 15 минут после встречи участники ретро забудут половину того, о чем шла речь. Но если вы зафиксиру- ете результаты обсуждения и занесете их в базу знаний, время собрания не будет потрачено впустую и каждый участник команды при необходимости сможет в будущем обратиться к результатам встречи. Кроме того, значительная часть договоренностей о том, кто и что делает, закрепляется именно на совещаниях. Как правило, членам проектной команды лень фиксировать результаты встречи. Вы, как аналитик, должны помнить: любые договоренности, не закрепленные протоколом совещания, по сути, не существуют. На практике вы можете столкнуться с тем, что на следующем собрании будут обсуждаться те же самые вопросы, что и неделю назад. Если сотруднику назначена задача, но при этом она нигде не подтверждена или ему не поступают регулярные напоминания, высока вероятность, что о задаче просто забудут. Дисциплинированные специалисты, выполняющие устные договоренности, никак не закрепленные официально, встречаются очень редко. Итак, мы поняли, что протоколы совещаний – один из важнейших источников для пополнения базы знаний проекта. Что же такое протокол совещания? Протокол – документ, фиксирующий результаты совещания, принятые решения и обязательства сторон по выполнению задач. Он может существовать в самых разных форматах: текстовый файл, таблица Excel, письмо по электронной почте, сообщение в Telegram-чате команды или статья в Confluence. В каком формате вести запись во время совещания? В любом удобном для вас. Желательно, чтобы этот конспект был структурирован и понятен вам спустя какое-то время. Один из возможных вариантов шаблона для записей приведен ниже. Таблица 1. Шаблон для записи результатов совещания Какую важную информацию мы фиксируем, ведя записи подобным образом? 1. Дата совещания. Обеспечивает нам привязку к вре- меннóй шкале и позволяет вспомнить условия, в которых проводилось совещание. 2. Тема совещания. Отражает суть встречи, основной вопрос, ради обсуждения которого все собрались. 3. Вопросы. Ключевые моменты, затронутые в процессе обсуждения главного вопроса. 4. Участники. В данное поле вписывают всех присутствующих на совещании. Это бывает очень полезно, когда спустя некоторое время кто-то начинает убеждать вас в том, что его не было на этой встрече и он впервые слышит о чем-то. 5. Результаты обсуждения и принятые решения. Здесь фиксируется всё, что вы посчитали нужным записать. Нумерация заметок позволяет быстро отнести полученную информацию к определенной теме. Если тезис или полезные сведения относились к первой теме, то у записи будет номер 1.*, если ко второй – 2.* и так далее. Метка [Р] означает конкретное решение, принятое на встрече. Записи с подобной меткой в дальнейшем превращаются в конкретные задачи со сроками исполнения и ответственными лицами. О фиксации решений, принятых на совещании, поговорим далее. Ведение записей подобным образом позволит вам сохранить всю ценную, принципиально важную информацию по итогам встречи. Наиболее ценная часть в протоколе совещания – достигнутые договоренности, то есть те самые записи с помет- кой [Р]. Грамотно зафиксированная договоренность отвечает на три вопроса: 1. Кто делает? 2. Что делает? 3. В какие сроки? Если договоренность не отвечает хотя бы на один из этих вопросов – решение не является решением. Исключением могут быть лишь декларативные заявления: «Стороны высказали заинтересованность в дальнейшем сотрудничестве». Но такие решения в протоколах бизнес-аналитиков редкость, поскольку в них нет практической пользы. Рассмотрим пример. Две организации, «Рубин» и «Сапфир», совместно запускают ИТ-проект по совершенствованию ИТ-решения – системы CRM. «Рубин» выступает заказчиком проекта, «Сапфир» – исполнителем. Для погружения в специфику работы заказчика аналитикам «Сапфира» нужна документация на текущую версию системы. Такая документация – ценный источник информации, дающий более полное представление о бизнес-процессах в организации. На совещании представители обеих компаний договорились о передаче документов аналитикам «Сапфира» на изучение. Как правильно зафиксировать договоренность в протоколе? И к кому обращаться, если договоренность нарушена? Пункт протокола может звучать следующим образом: В срок до 18.04.2020 ООО «Рубин» обязуется предоставить ООО «Сапфир» техническую документацию по системе CRM. Ответственный: Иванов А. Б. Обратите внимание, что эта запись отвечает на все ключевые вопросы: 1. Кто делает? ООО «Рубин» в лице Иванова А. Б. 2. Что делает? Предоставляет ООО «Сапфир» техническую документацию по системе CRM. 3. В какие сроки? До 18.04.2020. Что делать, если в указанные сроки документация не поступает, тоже понятно: сначала обратиться к Иванову А. Б., а если обращение не принесло результатов – к его руководству. Если помните, в самом начале мы говорили о «знании» как о практически применимой информации, отвечающей на вопрос «что делать?». В данном случае короткая запись в протоколе является знанием в чистом виде. Ведь из нее ясно, что делать представителям и ООО «Рубин» и ООО «Сапфир», причем в разных вариантах развития ситуации. Вот почему важно хранить в базе знаний протоколы совещаний. Конечно, кроме договоренностей в протоколе можно за- фиксировать и иную полезную информацию. Например, в разговоре вам назовут имя специалиста по конкретной системе или предметной области, к которому можно обратиться за консультацией. Это имя важно записать: возможно, консультация понадобится раньше, чем вы думаете. А переспрашивать по нескольку раз: «Так к кому, вы говорили, можно обратиться за уточнениями?» – дурной тон. Протоколы совещаний – ценнейший источник информации для участников проектной команды. Помимо договоренностей в протокол могут заноситься: • технические нюансы; • особенности бизнес-процессов; • законодательные ограничения; • интересные факты; • хронология развития ИТ-решения или компании; • полезные контакты. Начинающие аналитики могут решить, что ведение протокола совещания – низкоквалифицированная канцелярская работа. Конечно же, это совершенно не так. Чтобы в бурном обсуждении вычленить суть, нужно обладать большим опытом, вниманием и умением не позволять сбить себя с толку. Кроме того, важность протокола становится понятной, если учесть следующее. 1. Люди любят четко поставленные задачи и всегда ждут того, кто скажет им, что нужно сделать. 2. Чтобы это стало возможным, нужны совещания, порой достаточно долгие. В ходе обсуждения выясняются позиции сторон и определяются зоны ответственности. 3. Для того чтобы договоренности, достигнутые на совещании, имели шанс воплотиться в жизнь, их нужно фиксировать. Иначе никак. В противном случае вам скажут, что такие решения не принимались, имелось в виду совсем другое или даже что встречи вообще не было. Да-да, не удивляйтесь. У сверхзанятых людей память бывает избирательной. 4. Соответственно, задачи исполнителям чаще всего ставятся именно на основании протокола. Что будет, если не вести протоколы совещаний? 1. Руководитель может вовремя не поставить задачи исполнителям. Как следствие – нарушение сроков проекта. 2. Если руководитель проекта и поставил задачи, то их формулировка и сроки могут отличаться от тех, о которых говорилось на встрече. Как следствие – потеря время на уточнение деталей задач. 3. Девяносто процентов существенной информации, выяснившейся в ходе обсуждения, будут забыты в течение ближайших двух дней. Помните: цель протокола – не в самом протоколе. Его задача – обеспечить фиксацию и последующее выполнение договоренностей и тем самым реализацию проекта. Протокол совещания – важнейший источник информации для аналитика и, зачастую, двигатель всего ИТ-проекта. Не ленитесь вести записи – они выручат вас не один раз. ГЛОССАРИЙ ПРОЕКТА Теперь несколько слов о глоссарии проекта. Одна из главных проблем в ИТ-команде – недопонимание. Каждый человек – личность с уникальным жизненным и профессиональным опытом. На любой вопрос люди смотрят сквозь призму этого опыта и воспринимают одинаковые вещи по-разному. Бизнесмен, юрист или специалист по информационной безопасности, не говоря уже об ИТ-инженерах или, допустим, бухгалтерах, смотрят на один и тот же процесс с разных точек зрения. Поэтому чрезвычайно важно, чтобы все участники проектной команды понимали происходящее в ИТ-проекте одинаково и вкладывали в используемые термины единый смысл. На практике бывают случаи, когда люди в команде долгое время используют какой-либо термин, понимая его совершенно по-разному! И это длится месяцами, пока идет разработка ИТ-решения. Но вот наступает день тестовой эксплуатации, и внезапно выясняется, что заказчик имел в виду од- но, а исполнитель понял совершенно другое. За этим следует немая сцена и осознание того, сколь многое придется переделывать. Допустим, команда проекта работает над новым ИТ-решением для обработки заявок на кредит. Кредитный процесс в целом – один из самых сложных в банковской сфере. Заявка проходит множество стадий жизненного цикла и обрабатывается в нескольких информационных системах подряд. Если у команды проблемы с коммуникацией, то с трактовкой термина «заявка на кредит» могут возникнуть сложности. Например, заказчик понимает под нею сущность, которая обрабатывается в нескольких системах, а ИТ-инженер воспринимает ее только в границах одной конкретной системы. Чем позже обнаружится недоразумение, тем печальнее будут последствия. Бизнес-аналитик и отвечает за то, чтобы такого недопонимания не возникало. Он поддерживает в команде единое информационное поле и одинаковое понимание используемых терминов. А помогают ему в этом база знаний и один из ее разделов под названием «Глоссарий проекта». Глоссарий проекта представляет собой словарь, где расшифровываются все наиболее часто встречающиеся в проекте термины и аббревиатуры. Фактически это таблица из двух столбцов – «Термин или аббревиатура» и «Значение или расшифровка». Аналитик формирует глоссарий на самых ранних стадиях ИТ-проекта и поддерживает его в акту- альном состоянии в течение всей работы. Первоначальный глоссарий создается на одной из встреч с представителями заказчика. Формируя его, бизнес-аналитик не должен стесняться и спрашивать обо всех непонятных терминах. Тогда глоссарий проекта сослужит хорошую службу всем участникам команды. Уточняйте, переспрашивайте, добирайтесь до сути. Как шутят бизнес-аналитики, «речь человека на 80 процентов состоит из воды». А значит, если вы чего-то не поняли – так и говорите, не нужно оставлять какие-то моменты нераскрытыми. Если вы, как аналитик, не поняли того или иного термина, есть вероятность, что его не поймут и другие. Не стоит подходить к формированию глоссария формально. Конечно, можно просто скопировать трактовку некоторых заумных терминов из нормативной документации заказчика. Но ваша главная цель в том, чтобы из глоссария была понятна суть, практический смысл, который вкладывает заказчик в тот или иной термин. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ Изменения в ИТ-проекте происходят постоянно: выясняются новые обстоятельства, вступают в силу новые нормативные документы, заказчик по ходу проекта хочет добавить в ИТ-решение новый функционал или изменить существующий и т. д. Если изменениями не управлять, то они очень быстро приводят к неопределенности и неразберихе в ИТпроекте. Всё это грозит смещением сроков, выяснением отношений и дополнительными временныб ми и финансовыми затратами. Вот почему очень важно фиксировать все запросы на изменение и грамотно ими управлять. Управлять изменениями руководителю проекта очень сильно помогает бизнес-аналитик. Как правило, все запросы проходят именно через него. Это логично, ведь он много общается с заказчиком и имеет представление о его предметной области. В то же время бизнес-аналитик понимает процесс создания и (или) настройки ИТ-решения и способен предварительно оценить, насколько существенно тот или иной запрос заказчика повлияет на реализацию текущего проекта. Следует понимать, что в случае масштабного проекта заказчик – это не один руководитель, отвечающий за проект в целом. Здесь заказчиками могут выступать руководители множества подразделений, каждое со своими интересами и амбициями. Очень редко бывает так, чтобы внутри своей организации заказчик сам сформулировал единую, согласованную точку зрения и затем представил ее исполнителю для реализации. Чаще всего формировать такую единую позицию приходится бизнес-аналитику. От заказчика вы можете получать прямо противоречащие друг другу запросы. Одно подразделение считает нужным убрать кнопку с экранной формы, другое – непремен- но оставить. И не стоит ждать, что они разберутся между собой самостоятельно. Скорее всего, вам придется организовать совещание, продемонстрировать всем сторонам очевидное противоречие и добиться принятия окончательного решения: убираем или оставляем. И здесь мы снова вспоминаем о важности протоколирования встреч. Ведь спустя неделю заказчик может сказать, что ни о чем с вами не договаривался. Бывает, что различаются и каналы поступления запросов на изменения. Даже если вы договорились с заказчиком, что он направляет их все официально, по электронной почте, на практике это правило соблюдается не всегда. Официальная переписка часто отпугивает заказчика, поскольку он не всегда горит желанием брать на себя ответственность за тот или иной запрос. Будьте готовы к тому, что вас либо устно, либо сообщением в мессенджере попросят внести изменения в документацию по проекту. Конечно, в идеале такой формат взаимодействия следует пресекать во избежание спорных ситуаций в будущем. Но если заказчик очень важен для вашей компании – ничего не поделаешь, придется искать компромисс. Как видите, работа с изменениями – это попытка контролировать хаос. Тем не менее инструменты для контроля хаоса есть, и они достаточно простые. В английской терминологии используется термин Matrix of change requests – «матрица запросов на изменение». Русскую версию такой матри- цы иногда называют ЛУК – «лист учета комментариев». В листе учета комментариев скрупулезно регистрируются любые запросы заказчика на изменение документации либо функционала ИТ-решения. По каждому запросу фиксируются: 1. Уникальный номер. Простейший способ идентифицировать запросы – их порядковая нумерация. 2. Суть запроса. 3. Дата поступления. 4. Автор запроса. 5. Канал поступления: email, сообщение в мессенджере, телефонный звонок и пр. 6. Статус запроса: учтен ли он в новой версии документации либо ИТ-решения, или нет. 7. Где учтен запрос: номер измененного пункта документации или название соответствующего раздела в ИТ-решении. 8. Дополнительная информация, комментарии, вопросы для обсуждения. В представленной ниже таблице перечень полей не исчерпывающий. Вы можете добавлять любые столбцы, которые помогут вам при взаимодействии с заказчиком. Например, «Приоритет», позволяющий отфильтровывать в таблице все запросы с высоким или низким приоритетом. Если вы распо- лагаете подробно описанными бизнес-процессами, то в ЛУК можно добавить столбец «Функция», где фиксируют функции процессов, которые затрагиваются при исполнении запроса на изменение. Структура ЛУКа ограничивается лишь вашей фантазией и здравым смыслом. Таблица 2. Пример заполненного листа учета комментариев Запрос может касаться чего угодно: появления новой функции в системе, изменения формулировок в документации и даже устранения опечаток (да, среди заказчиков встречаются очень внимательные и дотошные люди). Всё это важно фиксировать, вплоть до мелочей. ЛУК должен стать вашим главным инструментом при общении с заказчиком. Очень полезно устраивать вместе с ним регулярные обсуждения ЛУКа. Плюсы подобной практики: 1. Увидев ЛУК, заказчик оценит, насколько внимательно вы относитесь к его запросам. 2. Можно акцентировать внимание заказчика на запросах, которые прямо противоречат друг другу и требуют от него принятия окончательного решения. Иногда такое решение принимается прямо в процессе обсуждения – и внезапно оказывается, что изменение уже не требуется. 3. И у вас, и у заказчика всегда будет актуальная картина работы с изменениями: какие из них учтены, какие отклонены, какие требуют срочного обсуждения и т. д. Это значительно снижает градус неопределенности и уровень стресса в проекте. В самом деле, к чему волноваться, если есть документ, из которого всегда можно узнать текущее положение дел и определить ближайшие планы? 4. Из ЛУКа становится понятен объем проделанной вами работы. Для заказчика не всегда очевидно, сколько сил и времени уходит на то, чтобы проанализировать его запросы, оценить стоимость реализации и определить приоритет. Количество запросов иногда измеряется сотнями, поэтому заказчику бывает полезно увидеть полную картину и понять, когда некоторые его представители слишком усердствуют с запросами. Да, ведение ЛУКа может показаться занудным занятием, особенно если заказчик накидал вам с десяток сообщений в WhatsApp, каждое из которых нужно превратить в отдельный запрос. Но время, потраченное на его ведение, всегда окупается: работа с изменениями становится прозрачной и последовательной. Наличие ЛУКа дисциплинирует и вас и заказчика. Кроме того, в разы снижается количество спорных ситуаций типа «Почему вы сделали одно и не сделали другое?». ЛУК всегда придет на помощь: «Потому что такое решение в ответ на наш вопрос принял Иван Иванович, директор департамента N». И вопрошающий либо идет разбираться с Иваном Ивановичем, либо просто отвечает: «А, ну тогда ладно». Так или иначе, вы не становитесь участником подобных разбирательств. А это стоит того, чтобы вести ЛУК. ОБРАБОТКА ИНФОРМАЦИИ И СРАВНИТЕЛЬНЫЙ АНАЛИЗ Все аналитики, и бизнес-аналитики в том числе, регулярно работают с таблицами. Таблица – самый простой и действенный инструмент для систематизации больших объемов разрозненных данных. Вариантов, когда аналитику может пригодиться табличное представление информации, великое множество. Рассмотрим некоторые из них. Иногда бизнес-аналитика просят подготовить краткий отчет для высшего руководства. Например, может понадобиться статистический отчет о работе с изменениями: сколько запросов поступило, сколько из них учтено, сколько отклонено и так далее. При этом его могут запрашивать регулярно и только за определенный период. Если вы дисциплинированно вели ЛУК, собрать такой отчет для вас дело пары ми- нут: вы просто включаете в Excel фильтры по нужным столбцам – и вся необходимая информация перед вами. Остается лишь красиво оформить ее в графиках и диаграммах. При подготовке аналитических материалов для руководства бизнес-аналитики часто используют сравнительные таблицы. Это простой, но мощный и интуитивно понятный инструмент для преподнесения информации. Создавая сравнительную таблицу, вы предлагаете аудитории некую систему координат, помогающую оценить различные варианты. Например, руководству необходимо принять решение о том, какую информационную систему выбрать для реализации проекта. Для этого им необходимо сравнить несколько программных продуктов – и сделать это, по возможности, объективно. Здесь на помощь и приходят сравнительные таблицы с набором критериев, одинаковым для всех. Критерии могут быть самыми разными: стоимость ИТ-решения, наличие технической поддержки, опыт компании-разработчика, используемые технологии и т. д. Иногда грамотный набор критериев сравнения делает выбор очевидным, поэтому аналитик своими материалами может влиять на процесс принятия решения. Подробнее об использовании таблиц для проведения сравнительного анализа см. раздел 2.12. Еще один вариант, когда табличное представление может пригодиться аналитику, – это выявление закономерностей или пересечений в данных. Для иллюстрации этого аспекта работы с таблицами воспользуемся задачкой из универси- тетского учебника. Пятеро друзей из байкерского клуба решили организовать выезд на природу. Мотоцикл Ивана – красного цвета. Мотоцикл Петра не черный, не синий и не фиолетовый. У Михаила – черный и синий мотоциклы. У Бориса – белый и синий. У Александра есть мотоциклы всех перечисленных цветов. Вопрос: у кого был какой цвет, если все они приехали на мотоциклах разного цвета? Казалось бы, чтобы найти правильную комбинацию цветов и решить эту задачу, нужно много времени. Но если представить всю имеющуюся информацию в виде таблицы, то на решение уходит всего пара минут (см. табл. 3). Таблица 3. Решение задачи с мотоциклами Остается лишь найти комбинацию, при которой у каждого байкера будет мотоцикл своего цвета. Иван возьмет красный мотоцикл, Петр – белый, Борис – синий, Михаил – черный, а Александр – фиолетовый. Если вам нужно найти некую закономерность в данных или сопоставить данные друг с другом, первым делом стоит попытаться привести их в табличный вид. Так вы получите мощный инструмент фильтрации и обработки информации и взглянете на нее под другим углом. ПОДГОТОВКА ПРЕЗЕНТАЦИОННЫХ МАТЕРИАЛОВ В самом начале мы с вами говорили о том, что аналитика помогает руководителям компаний принимать взвешенные и обоснованные решения для достижения бизнес-результатов. Если итоги аналитической работы не используются при принятии решений – аналитика теряет всякий смысл. Поэтому бизнес-аналитику важно уметь грамотно преподнести руководству результаты своей работы. Чаще всего управленческие решения принимаются на совещаниях с участием руководителей ключевых направлений компании. Основной инструмент для преподнесения информации на таких совещаниях – презентация в Microsoft Power Point. Презентация должна простым, доступным язы- ком рассказывать о проделанной работе и полученных выводах. В презентационных материалах стоит избегать заумных терминов и сложных умозаключений. Помните: задача презентации не в том, чтобы показать, какой вы умный. Главное, чтобы вас услышали и правильно поняли. При оформлении презентации стоит избегать и так называемых слайдоментов. «Слайдомент» – нечто среднее между слайдом и документом. Видели когда-нибудь слайд, заполненный мелким текстом, как на странице в книге? Это и есть слайдомент. Слайдоментов стоит избегать в любой презентации, поскольку они сложны для восприятия и нагоняют на аудиторию тоску. Единственный случай, когда слайдомент допустим, это если руководство прямым текстом просит вас оформить презентацию именно в таком стиле. Такой подход встречается в крупных компаниях с высоким уровнем бюрократии. В этом случае исповедуется принцип «Мы всегда оформляли материалы для руководства в таком виде, будьте добры соответствовать». Готовясь к презентации, стремитесь к максимальной наглядности. Если презентация посвящена итогам анализа процессов, можно вывести на слайд фрагмент карты и выделить на нем наиболее проблемные функции. Если ваш доклад посвящен созданию новой информационной системы – покажите руководителям прототипы интерфейсов. Это привлечет куда большее внимание к вашей работе и позволит добиться принятия нужного управленческого решения. 2.3. В чем бизнес-аналитик участвует? Помимо выполнения непосредственных задач, бизнес-аналитик участвует и в работе своих коллег по проектной команде. Чаще всего речь идет о содействии им в решении пяти видов задач (см. рис. 4). Рисунок 4. Дополнительные задачи бизнес-аналитика НАСТРОЙКА ПРОТОТИПОВ На этапе создания прототипа ИТ-решения главная ценность бизнес-аналитика – в его умении посмотреть на будущий программный продукт глазами пользователя. К моменту создания прототипа бизнес-аналитик уже ознакомился с бизнес-процессами заказчика, сформировал целевое вáидение процессов и обсудил со всеми заинтересованными лицами прототипы экранных форм. Благодаря этому у него появляется понимание того, какие задачи стремится решить заказчик при помощи информационной системы, с какими сложностями можно столкнуться во время работы и на какие детали следует обратить особое внимание. Собственно, на этапе создания и настройки прототипа бизнес-аналитик – главный консультант команды разработки. ФОРМУЛИРОВАНИЕ ТЕХНИЧЕСКОГО ЗАДАНИЯ Техническое задание – сложный, многоуровневый документ, описывающий все ключевые аспекты будущего ИТ-решения, начиная с функциональных возможностей и заканчивая требованиями к оборудованию, на котором данное ИТ-решение будет работать. В формулировании технического задания участвует множество сотрудников: ИТ-архитектор, специалисты по аппаратному обеспечению, системный аналитик и т. д. Вносит свою лепту в общий документ и бизнес-аналитик. Так в техническом задании появляются разделы с функциональными требованиями к будущему решению, описание бизнес-процессов и прототипы экранных форм. СОЗДАНИЕ ТЕСТОВЫХ СЦЕНАРИЕВ Как я уже упоминал ранее, на этапе разработки бизнес-аналитик – основной специалист, который может взглянуть на функционал ИТ-решения глазами заказчика. Это значит, что бизнес-аналитик понимает ключевые пользовательские сценарии – наборы действий, которые предпринимают пользователи системы для решения своих задач. Такое знание очень полезно на стадии тестирования нового программного продукта. В процессе разработки появляются баги, мешающие пользователю выполнять свои задачи. Может нарушаться логика процесса. Например, документ в системе принимает статусы не в строго определенной последовательности, а какие угодно. Такие ошибки необходимо выявлять и устранять. Этим занимаются инженеры по тестированию, используя тестовые сценарии. Тестовые сценарии должны предусматривать как стандартное поведение пользователя, так и попытки нарушить логику процесса. Поскольку аналитик способен посмотреть на работу с системой глазами заказчика, его помощь может очень пригодиться инженеру по тестированию при создании тестовых сценариев. Благодаря этому тестирование становится более полным, всеобъемлющим, а вероятность пропуска критических ошибок снижается. Участие бизнес-аналитика в тестировании ПО подробнее описано в разделе 2.11. РАЗБОР ДОПУЩЕННЫХ ОШИБОК (РЕТРО) Как и вся проектная команда, бизнес-аналитик участвует в ретроспективном анализе работы и фиксирует его результаты. Подробнее о ретро мы говорили ранее, в разделе, посвященном проведению совещаний и формированию базы знаний. ФОРМИРОВАНИЕ КАЛЬКУЛЯЦИЙ ПО ПРОЕКТУ Запуская ИТ-проект, руководитель проекта формирует так называемую калькуляцию – таблицу, где оцениваются стоимость и трудоемкость его реализации. Один из первых этапов в любом ИТ-проекте – этап исследования, в котором бизнес-аналитик принимает самое активное участие. Соответственно, при формировании калькуляции задача аналитика – предварительно оценить длительность и сложность этапа исследования. Как правило, такая оценка проводится по итогам краткого предварительного исследования, дающего общее представление о масштабе работ. Оценка бизнес-аналитика позволяет рассчитать стоимость соответствующего этапа для заказчика. Кроме того, на основе результа- тов предварительного исследования свои оценки дают и другие участники команды: разработчики, тестировщики, инженеры. Таблица 4. Этапы проекта и работа бизнес-аналитика на каждом из них 2.4. Роль бизнесаналитика в ИТ-проекте В классическом ИТ-проекте пять стадий: 1. Сбор и анализ требований. 2. Разработка и (или) конфигурирование. 3. Тестирование. 4. Подготовка и ввод в промышленную эксплуатацию. 5. Сопровождение. В таблице выше рассмотрены задачи бизнес-аналитика на каждом этапе и результаты его работы. Ранее мы говорили о том, что важнейшая функция бизнес-аналитика – поддержание единого информационного поля для всех участников проекта. Наряду с руководителем проекта, он общается со всеми без исключения участниками команды – как со стороны исполнителя, так и со стороны заказчика. Если заказчик в некоторых проектах может ни разу не встретиться с разработчиком ИТ-решения, то аналитик, напротив, держит связь со всеми. Это видно и из таблицы выше. На этапе сбора и анализа требований аналитик активно взаимодействует со всеми представителями заказчика: описывает процессы, изучает предметную область, старает- ся учесть интересы всех участвующих в процессе подразделений. На этапе разработки и конфигурирования аналитик бок о бок работает с разработчиком ИТ-решения: дает пояснения по предметной области заказчика и оценивает прототипы с точки зрения будущих пользователей. На этом же этапе он продолжает взаимодействовать с заказчиком. Бизнес-аналитик регистрирует все поступающие запросы на изменение и организует их обсуждение с командой. Здесь главный инструмент аналитика – матрица запросов на изменения (она же ЛУК). На этапе тестирования бизнес-аналитик помогает инженеру-тестировщику составлять тестовые сценарии: поясняет задачи, которые стремится решить пользователь при помощи будущего ИТ-решения, и обращает внимание на нюансы процессов. На этапе подготовки и ввода ИТ-решения в промышленную эксплуатацию бизнес-аналитик вновь плотно работает с заказчиком. Он пишет инструкции для конечных пользователей ИТ-решения, проводит обучающие семинары, фиксирует все возникающие вопросы и готовит на них ответы. И наконец, на этапе сопровождения бизнес-аналитик становится для заказчика главным контактным лицом по вопросам дальнейшего совершенствования ИТ-решения. Здесь снова возникает необходимость в матрице запросов на изменение и ее обсуждении с участниками проектной команды. Как видим, бизнес-аналитик на каждой стадии ИТ-проекта погружается в гущу событий и помогает участникам проектной команды. Он также постоянно взаимодействует с заказчиком, а потому от его профессионализма существенно зависит общее впечатление о работе команды исполнителя. Рисунок 5. Схема взаимодействия бизнес-аналитика с участниками ИТ-проекта 2.5. Моделирование бизнес-процессов как ключевой инструмент аналитика 2.5.1. О ВАЖНОСТИ БМП В своей работе бизнес-аналитик регулярно использует БМП. Нет, речь не о боевой машине пехоты! БМП – это блок-схемы, макеты, примеры. Данные инструменты помогают бизнес-аналитику добиться единого толкования того или иного процесса разными людьми. Блок-схемы описывают бизнес-процессы; макеты формируют представление о внешнем виде ИТ-решения, а примеры иллюстрируют предмет обсуждения. Для большинства людей справедлива поговорка о том, что лучше один раз увидеть, чем сто раз услышать. Наглядная блок-схема бизнес-процесса понятнее длинного текстового описания. Иллюстрация интерфейса будущего программного продукта предпочтительнее обстоятельного рассказа о будущем ИТ-решении. Что касается примеров, то здесь бизнес-аналитик стремится задействовать образное мышление коллег. Возьмем пример с бутылочным горлышком из предыдущей главы. Данная метафора очень удачно описывает функцию процес- са с низкой пропускной способностью. Достаточно показать коллегам картинку с бутылкой, заполненной доверху конфетками M&M’s. Если бутылку перевернуть, то из нее в лучшем случае выпадет несколько драже. Все остальные конфеты просто застрянут. Аналогичная ситуация и с бизнес-процессами, в которых общая эффективность зависит от производительности отдельной функции. Применяя в работе яркие образы и метафоры, аналитик способствует быстрому погружению в контекст всех участников команды. Яркие, необычные примеры – мощный инструмент работы в проектной команде, не стоит его недооценивать. Наглядность материалов – важный момент работы бизнес-аналитика, ведь его конечная цель – добиться взаимопонимания между всеми участниками проекта. 2.5.2. ЧТО ТАКОЕ БИЗНЕС-ПРОЦЕССЫ? Эдварду Демингу, выдающемуся американскому экономисту и консультанту в области управления организацией, приписывают такую фразу: Если вы не представляете деятельность своей организации в виде процесса, вы не знаете, чем занимаетесь на самом деле. Это действительно так. Любую деятельность можно пред- ставить в виде процесса: от приготовления каши на завтрак до открытия счета в банке. Что же такое «бизнес-процесс»? Существует несколько десятков определений данного термина, но мы воспользуемся лишь одним из них. БИЗНЕС-ПРОЦЕСС – ЧЕТКАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ ВЗАИМОСВЯЗАННЫХ ДЕЙСТВИЙ, ПРЕОБРАЗУЮЩИХ ВХОДНЫЕ РЕСУРСЫ В ИТОГОВЫЙ РЕЗУЛЬТАТ, ЦЕННЫЙ ДЛЯ КОНЕЧНОГО ПОТРЕБИТЕЛЯ. Бизнес-процессы бывают разные. Классическая иерархия состоит из пяти уровней. Рассмотрим их на примере процессов кредитования в крупном банке. Таблица 5. Иерархия бизнес-процессов 18 18 * Класс процессов – наиболее крупная форма деления процессов на группы. Общепринятых классов процессов три: основные, обеспечивающие, процессы управления.** Направление – условное деление выбранного класса процесса в соответствии с неким принципом. В данном случае таким принципом выступает клиент и направлений всего два: «Обслуживание ФЛ» и «Обслуживание ЮЛ». Ключевое понятие при моделировании бизнес-процессов – сквозной бизнес-процесс. Описать его в ходе изучения предметной области – это как сформировать оглавление при написании книги. Карта сквозного процесса показывает, из каких этапов состоит полный жизненный цикл продукта или услуги. Например, сквозной процесс на промышленном предприятии может описывать производственный цикл от закупки сырья до продажи готовой продукции. Таким образом, в карте сквозного процесса перечисляются подпроцессы, входящие в общий процесс, и указывается их взаимосвязь: очередность выполнения и условия перехода от одного этапа к другому. Например, в сквозном процессе кредитования всё начинается с первоначального консультирования клиента и приема заявки на кредит, а заканчивается погашением кредита и его закрытием в банковской системе. Между этими двумя подпроцессами существует еще множество других подпроцессов: проверка заявки, начисление денежных средств, контроль погашения кредита и т. д. Все эти работы выполняются разными подразделениями, за них отвечают разные руководители. И каждому подпроцессу посвящается отдельная карта этапа сквозного процесса. Преимущество сквозного процесса – восприятие определенного направления деятельности заказчика как единого целого. Вы не просто рассматриваете узкий участок работы, но и видите общую картину, в том числе взаимосвязи с другими подразделениями. Поэтому при описании предметной области заказчика полезно обрисовать сквозной бизнес-процесс, а не одни лишь отдельные подпроцессы. Это позволяет учесть интересы всех вовлеченных сторон и лучше понять специфику деятельности заказчика. Рисунок 6. Упрощенный пример карты сквозного процесса Теперь поговорим об описании подпроцессов, входящих в сквозной бизнес-процесс. Привычные всем карты бизнес-процессов с «дорожками», на которых указывается исполнитель той или иной функции, – это карты этапов сквозного процесса. Это так называемый уровень функций, где описываются элементарные действия участников: оформление заявок, отправка писем и телефонные звонки, проведение операций в системе и т. д. Отметим, что в карте сквозного процесса подобные элементарные действия не описываются. Любая функция представляет собой, по сути, некое действие по преобразованию. Допустим, вам подали на вход функции некий документ. Для примера возьмем ту же кредитную заявку. Вы совершили над входным документом некое действие. Например, проверили заявку на корректность оформления и передали дальше по процессу. В ходе выполнения функции заявка изменилась: статус «На проверке» сменился в системе статусом «Проверена». Любой бизнес-процесс на уровне функций можно пред- ставить как совокупность следующих элементов. 1. Функция. Действия, которые совершает исполнитель в рамках процесса. 2. Событие. События – это условия выполнения либо результат выполнения функций. Например, для функции проверки кредитной заявки инициирующим событием будет: «Сотруднику Отдела андеррайтинга поступила на проверку новая кредитная заявка». А результатом выполнения функции станет: «Кредитной заявке присвоен статус „Проверена“». В зависимости от нотации бизнес-моделирования 19 события могут указываться до и после каждой функции либо только в начале и в конце процесса. 3. Исполнитель. Тот, кто выполняет функцию в процессе. 4. Документ. Электронный, бумажный, информация в любом виде. В процессе выполнения функции над документом совершаются некие действия. 5. Информационная система. Программное обеспечение, которое использует исполнитель в ходе выполнения функции. Это может быть и специализированная банковская система, и привычные Word или Excel. 19 Нотации бизнес-моделирования – графические модели, которые используются для описания процессов, их последующего анализа и оптимизации. Фактически любая нотация представляет собой набор условных обозначений и логических операторов, в соответствии с которым описывается та или иная деятельность. Взяв на себя обязательства по описанию бизнес-процессов, всегда помните об их иерархии, приведенной выше. Ведь это тот случай, когда единица может равняться десяти. Если задача состоит в построении карты сквозного процесса – это одно. Но если нужно описать не только сквозной процесс, но и все входящие в него подпроцессы, – это совершенно другой уровень трудозатрат. Вернемся к нашему примеру. И в случае с описанием сквозного процесса, и при детальном описании подпроцессов задача может звучать одинаково: «Описание процесса кредитования». По сути, это корректно. Формируя общую карту и описывая детали каждого подпроцесса, вы описываете сам процесс кредитования. Но трудоемкость в первом и втором случаях может существенно различаться. Поэтому всегда уточняйте детальность описания. В чем состоит задача? Нужно ли вам лишь сформировать карту сквозного процесса – или детально, до уровня элементарных функций, описать каждый подпроцесс? Это может существенно повлиять на вашу оценку длительности работ. Рисунок 7. Упрощенный пример карты процесса «Консультация клиента» на уровне функций Как у самого сквозного процесса, так и у его этапов есть свои владельцы, и это не обязательно одно и то же лицо. Например, за процесс кредитования в целом отвечает директор Департамента кредитования физических лиц, а за этап консультирования клиента в рамках процесса кредитования – начальник Отдела клиентского обслуживания. При этом Отдел клиентского обслуживания может даже не входить в состав Департамента кредитования, а быть самостоятельным подразделением. Таким образом, владелец процесса определяется исходя из уровня иерархии процесса и сути проводимых в процессе работ. Таблица 6. Владельцы процессов О важности роли владельца процесса мы поговорим в последующих разделах. 2.5.3. ЗАЧЕМ ОПИСЫВАТЬ БИЗНЕС-ПРОЦЕССЫ? Из раздела о ключевых задачах бизнес-аналитика вы узнали, что карты бизнес-процессов очень полезны на этапе анализа предметной области заказчика. Информация из карт процессов становится основой требований к будущему ИТрешению. Изучив эти карты, технические специалисты лучше понимают суть той работы, которую предстоит автоматизировать. Однако, помимо использования карт при разработке ИТрешений, существует еще множество причин для описания бизнес-процессов. Например, автор книги «Бизнес-процессы. Моделирование, внедрение, управление» 20 Владимир Репин выделяет целых 15 причин. На мой взгляд, девять из них наиболее актуальны. Их и рассмотрим подробнее. Причина 1. Четкое определение зон ответственности руководителей и подразделений В деловой среде распространена поговорка: «Если за задачу отвечают двое – за нее не отвечает никто». Действительно, отсутствие четких границ и зон ответственности у подразделений приводит к недопониманию, ошибкам, временным и материальным потерям. Кроме того, отсутствие однозначного разделения полномочий губительно для корпоративной культуры: вместо решения рабочих вопросов сотрудники пытаются «спихнуть» ответственность на коллегу и поскорее найти виноватого. В данном случае карта процесса – наглядный инструмент, фиксирующий периметр работы каждого подразделения. 20 Репин В. Бизнес-процессы. Моделирование, внедрение, управление. – М.: Манн, Иванов и Фербер, 2012. Причина 2. Оптимизация взаимодействия разных структурных подразделений Определив функционал и зоны ответственности каждого участника, намного проще состыковать процессы смежных подразделений. Когда вы выстраиваете карту процесса, то начинаете лучше понимать условия, при которых результат одного процесса передается для дальнейшей обработки в другое подразделение. Таким образом, постепенно выстраивается сквозной бизнес-процесс, в котором несколько подразделений совместно работают для достижения итогового результата. Например, при согласовании нормативного документа определяется условие: подразделение «А» принимает документ в работу, только получив резолюции от экспертов из подразделений «Б» и «В». Причина 3. Автоматическая выгрузка прикладных регламентирующих документов Современные системы бизнес-моделирования (СБМ) позволяют пользователям не только формировать карты процессов, но и выгружать на их основе прикладные регламентирующие документы: паспорта процессов, регламенты, инструкции и т. п. Выгружая регламент, система преобразует каждый функциональный блок на карте процесса в отдельный подраздел в документе. В итоге аналитик получает структурированный документ, оформленный в соответствии с корпоративными стандартами. Остается лишь немного дополнить его справочной информацией и отправить на согласование. Конечно, это намного быстрее, чем каждый раз создавать нормативный документ с нуля. Причина 4. Анализ возможных изменений в компании и их последствий Карты бизнес-процессов используются и при управлении изменениями в организации, в так называемом change management. Чтобы оценить возможные последствия, которые может повлечь изменение процесса, необходимо представлять себе его текущую структуру, технологическую основу, связь с другими процессами. Данная информация содержится в картах бизнес-процессов, а потому незаменима для руководства организации при принятии управленческих решений. Причина 5. Распространение в компании стандартов деятельности Случается, что в крупных организациях разные подразделения выполняют одну и ту же работу с разной скоростью. Например, в одинаковых условиях одно подразделение справляется с задачей за десять минут, а другое – только за пятьдесят. Очевидно, что в первом подразделении есть некие «лучшие практики», позволяющие достигать столь существенного преимущества. Информацию о подобных практиках систематизируют и описывают в виде карты процесса. Благодаря сформулированным материалам новые стандарты распространяются по всей организации и тем самым экономят материальные и трудовые ресурсы. Причина 6. Проведение внутреннего аудита Карты процессов полезны и для проведения внутреннего аудита в организации. У аудитора появляется базовый документ, на основе которого проводится анализ текущей деятельности того или иного подразделения. Изучив карту процесса, внутренний аудитор выявляет несоответствия между плановым и текущим положением дел, а также определяет наличие в процессе контрольных процедур, задача которых – минимизировать риски. Причина 7. Обучение сотрудников компании Благодаря своей краткости и наглядности карты процессов применяются и для обучения сотрудников. Приходя на новое место, любой работник сталкивается с обширной нормативной документацией: должностные инструкции, положения, регламенты, политики и т. д. и т. п. Карты процессов отлично подходят для плавного погружения в рабочую среду: они дают общее представление о ра- боте подразделения, ключевых исполнителях, используемых документах и информационных системах. Изучив карту процесса, сотрудник быстрее включается в работу и лучше ориентируется в остальной нормативной документации. Причина 8. Анализ и совершенствование деятельности компании Карты процессов используются и при поиске возможностей оптимизации. Чтобы понимать потенциал совершенствования процесса, необходимо знать, что он собой представляет. Карты процессов используются для анализа проблем в бизнес-процессах организации, в том числе и для выявления и устранения «бутылочных горлышек», о которых говорилось ранее. Причина 9. Внедрение культуры процессного управления Описание процессов – первый шаг к созданию в организации культуры процессного управления. В этом случае организация воспринимается как совокупность взаимосвязанных бизнес-процессов, направленных на достижение конкретных результатов. В ходе развития культуры процессного управления: • повышается технологическая зрелость организации – процессы становятся конкретными, измеримыми и управляемыми; • повышается ответственность каждого сотрудника за свой участок работы; • постепенно исчезает «культура героев», когда направления деятельности полностью зависят от конкретных исполнителей; • процессы обретают стабильность и предсказуемость; • организация становится более гибкой и быстрее адаптируется к изменениям внешней среды. Как видите, моделирование бизнес-процессов – мощный инструмент для анализа и оптимизации деятельности организации, а потому навык такого моделирования обязателен для любого бизнес-аналитика. 2.5.4. О НОТАЦИЯХ БИЗНЕСМОДЕЛИРОВАНИЯ В этой книге я намеренно не останавливаюсь на конкретных нотациях бизнес-моделирования. Выбор нотации во многом зависит от ваших личных предпочтений, а также от принципов описания процессов, принятых в компании. Тем не менее об одной нотации я хотел бы сказать особо. EPC-диаграмма, она же event-driven process chain, или «событийная цепочка процессов». На мой взгляд, нотация EPC полезна как начинающим, так и опытным аналитикам в качестве инструмента для анализа процессов на уровне функций. Дело в том, что нотация EPC довольно требовательна к деталям. Рассмотрим простейший пример (см. рис. 8). Рисунок 8. Пример блок-схемы в нотации EPC Эта блок-схема описывает ежедневную информационную рассылку, которую делает по электронной почте сотрудник Отдела по работе с персоналом. Возьмем любую функцию из процесса. Например, «Сбор данных для формирования информационной рассылки». Какую информацию о функции мы можем почерпнуть из блок-схемы? Давайте посмотрим. 1. Суть выполняемого действия: сбор данных для формирования информационной рассылки. 2. Исполнитель функции: сотрудник Отдела по работе с персоналом. 3. Инициирующее событие для выполнения функции, а также ее периодичность: рассылку необходимо выполнять ежедневно. 4. Программное обеспечение, используемое для выполнения функции: браузер Microsoft Edge. 5. Объект, с которым работает исполнитель при выполнении функции: пока это абстрактная «информация». 6. Результат выполнения функции: «Информация для ежедневной рассылки собрана». Неплохо, правда? Всего лишь маленький прямоугольник в окружении овалов и многоугольников, а сколько информа- ции! Вы можете взять любую другую функцию из этой карты, и она ответит вам на те же вопросы. Однако это не значит, что все процессы уровня функций нужно описывать в нотации EPC. Вовсе нет! Для каких-то случаев данная нотация уместна, но если количество функций в вашем процессе приближается к десяти – EPC-схема становится слишком громоздкой и с трудом умещается на листе А4. Для описания таких объемов существуют куда более компактные нотации. Но воспринимать процессы в нотации EPC очень полезно. Если мысленно пропускать рассказ заказчика о своей работе через требования нотации EPC, это позволит вам увидеть пробелы в его изложении и задать наводящие вопросы. Например, заказчик может забыть упомянуть название программы, при помощи которой выполняется то или иное действие, или не назвать условие старта работ. Отсюда совет начинающим бизнес-аналитикам: изучите нотацию EPC и сформируйте привычку воспринимать процессы сквозь призму этой нотации. 2.5.5. САМАЯ ВАЖНАЯ РОЛЬ, ИЛИ О ВЛАДЕЛЬЦЕ ПРОЦЕССА Ранее мы говорили о том, что одна из задач бизнес-аналитика – выявление всех заинтересованных сторон и грамотное взаимодействие с ними. Среди последних особого вни- мания аналитика требует роль владельца процесса. Студентам ряда технических специальностей преподают дисциплину «Системный анализ». В системном анализе любая организация рассматривается как совокупность связанных между собой процессов, нацеленных на достижение единой цели – например, экономической эффективности компании. По сути, цель – не что иное, как желаемое состояние организации в качестве системы процессов. В этом смысле системный анализ и процессное управление рассматривают понятие «организация» одинаково. Поскольку организация – совокупность процессов, становится понятно: построение четкой и однозначной системы управления – задача для всех подразделений без исключения. Почему так важно участие каждого? Ответ прост: синергия. Это именно тот самый случай, когда 1 + 1 = 3. Судите сами: 1. Организация – сложная система процессов. В основе каждого процесса – люди. 2. При взаимодействии людей возникают синергетические эффекты, необходимые для достижения целей организации. Если люди и подразделения не станут взаимодействовать, результата (нормативного документа, сделки, новой информационной системы) не будет. 3. Если эффективность взаимодействия подразделений низкая – синергетические эффекты исчезают, что приводит к деградации и разрушению системы. Получается, внедрение процессного подхода полностью зависит от слаженной командной работы различных подразделений. Но даже самой профессиональной команде нужен лидер. Вспомним голливудский фильм «Мстители». Его ключевые персонажи – супергерои, все до единого. Команда «Мстителей» работала на единую цель – защиту Земли от инопланетного вторжения. Но даже в такой команде оказался супергерой, который в итоге спас всех, – Тони Старк, «Железный человек». В случае такой сложной задачи, как построение процессного управления, без супергероев-лидеров не обойтись. «Железными людьми» в организации должны стать владельцы процессов. Кто же такой владелец процесса? Это должностное лицо, которое: • отвечает за результат процесса; • обладает полномочиями для построения и эффективного выполнения процесса. Очевидно, что оба условия обязательны. Нельзя быть владельцем процесса, если вы не отвечаете за итоговый результат. Но в то же время невозможно представить себе и руководителя, которому не хватает полномочий менять процесс. Как правило, владельцами процессов становятся руково- дители среднего и высшего звена. В классических стандартах процессного управления владелец процесса: • определяет процесс, обеспечивает его успешное внедрение и совершенствование; • планирует и документально оформляет все необходимые нормативные документы; • определяет и отслеживает показатели по процессу; • оценивает работу участников процесса и вносит в нее улучшения; • следит за тем, чтобы каждый участник четко понимал свою роль в процессе; • определяет, какие изменения вносить и в каком порядке. Немало, правда? В голову приходит аналогия с собственником небольшого бизнеса. На маленьком предприятии все эти задачи ложатся на плечи собственника. Если он не будет выполнять функции владельца процесса, бизнес закроется быстрее, чем вы успеете сказать «Эйяфьятлайокуддль». Теперь представим себе большую организацию. Например, банк. Количество процессов в нем измеряется сотнями, а порой и тысячами. Невозможно сконцентрировать все задачи в руках одного человека, а потому на помощь топ-менеджменту спешит супергерой – владелец процесса. Процесс для владельца процесса – это его маленький бизнес, который должен исправно и стабильно работать и непрерывно улучшаться. Десятки таких владельцев обеспечива- ют жизнеспособность организации. Процессное управление не построить в одиночку. Но владельцам процессов в решении этой задачи отведена особая роль. 2.6. Формулирование требований к программному обеспечению С точки зрения ИТ-проекта обстоятельные требования к ИТ-решению – главный результат работы бизнес-аналитика. Фактически в требованиях к ИТ-решению фиксируется вся ценная для разработчиков информация, которую аналитик собрал на этапе исследования предметной области заказчика. Исследование предметной области заказчика состоит из четырех этапов (см. рис. 9). Мы с вами сосредоточимся на этапе «Проведение исследования», поскольку именно здесь бизнес-аналитик формирует документацию по проекту, в том числе и требования к ИТ-решению. Итак, после того как вся нужная информация собрана, процессы описаны и потребности заказчика ясны, наступает время сформулировать требования к ИТ-решению. Условно их можно разделить на две крупные категории: функциональные и нефункциональные (см. рис. 10). В своей работе бизнес-аналитик сосредотачивается на функциональных требованиях. Иными словами, он описывает контекст применения будущего ИТ-решения и те задачи, которые планируют решать конечные пользователи. Нефункциональные требования бизнес-аналитик, как пра- вило, формулирует совместно с техническими специалистами: разработчиками, системными аналитиками и ИТ-архитекторами. Рисунок 9. Четыре этапа исследования предметной области заказчика Рисунок 10. Категории требований к ИТ-проекту 2.6.1. ХАРАКТЕРИСТИКИ ТРЕБОВАНИЙ Важно помнить, что сформулированные требования должны обладать следующими ключевыми характеристиками21. Ясность, недвусмысленность Требование определено без обращения к техническому жаргону, акронимам и другим скрытым формулировкам. Оно выражает объективные факты, а не субъективные мнения. Возможна одна и только одна интерпретация. Определение не содержит нечетких фраз. Использование отрицательных и составных утверждений запрещено. Завершенность Требование полностью определено в одном пункте, вся необходимая разработчикам информация присутствует. Проверяемость Реализация требования может быть однозначно проверена с помощью одного из четырех возможных методов: осмотр, демонстрация, тест или анализ. 21 См.: https://qaevolution.ru/testirovanie-po/vidy-testirovaniya-po/testirovanietrebovanij/ Необходимость Требование представляет собой определенную заинтересованным лицом характеристику, отсутствие которой приведет к неполноценности решения. Требование предполагает некую пользу от его реализации. Необязательное требование – противоречие самому понятию требования. Осуществимость Требование может быть реализовано в пределах проекта. Ценность требования сопоставима с затратами на его реализацию. Отслеживаемость Требование соответствует деловым нуждам заинтересованных лиц, документировано, имеет идентификатор и связи с другими артефактами проекта. Корректность, согласованность Требование не противоречит другим требованиям и полностью соответствует внешней документации. Актуальность Требование не устарело с течением времени. Атомарность Требование атомарно, то есть оно не может быть разбито на ряд более детальных требований без потери завершенности. Возможно, ваше внимание привлек комментарий, что словосочетание «необязательное требование», по сути, оксюморон вроде «горячего мороженого» или «громкой тишины». С обязательностью требований связана одна любопытная история. ИСТОРИЯ ПРО ОБЯЗАТЕЛЬНОСТЬ ТРЕБОВАНИЙ Однажды руководство крупной финансовой корпорации начало получать от сотрудников жалобы на очень медленный лифт. Офис компании находился в старом небоскребе в центре Нью-Йорка, и замена лифта обошлась бы в сотни тысяч долларов. Прежде чем идти на такие траты, руководство решило пригласить внешних консультантов для изучения ситуации и поиска вариантов решения проблемы. Консультанты провели несколько дней, внимательно наблюдая за тем, как сотрудники компании использовали лифт, и проводя замеры времени. Затем они пришли к руководству с неожиданным решением: установить перед лифтами в холле огромные зеркала. Как выяснили консультанты, лифт вполне соответствовал современным требованиям к скорости перемещения, а жалобы на медленную работу были вызваны простым обстоятельством: в ожидании лифта сотрудникам нечем было заняться. Здесь стоит отметить, что подобная ситуация возникла в те времена, когда смартфоны и быстрый мобильный интернет еще не захватили мир. Итак, консультанты выяснили, что требование о смене лифта было вовсе не обязательным и оказалось связано с субъективным восприятием времени ожидания. Руководство компании прислушалось к рекомендациям и установило в холлах большие зеркала. Теперь женщины, ожидая лифт, рассматривали себя в зеркалах и поправляли прически, а мужчины… смотрели на женщин. Количество жалоб на лифт резко сократилось, и руководство компании сэкономило большие деньги. 2.7. Десять этапов создания требований к ИТ-решению В этом разделе мы рассмотрим, как поэтапно, шаг за шагом сформулировать требования к ИТ-решению. Особенность предлагаемого подхода – в четкой последовательности шагов и применяемых инструментов, помогающих выявить требования к будущему программному продукту. По сути, каждый следующий этап использует и дополняет результаты предыдущего. Благодаря различным инструментам вы смотрите на будущее ИТ-решение под разными углами: с точки зрения бизнес-процессов, используемых в системе сущностей, ролей пользователей и т. д. Представьте себе, будто каждый этап формулирования требований – это своеобразный фильтр, сквозь который проходит поток информации о предметной области заказчика. Поскольку все фильтры разные, каждый из них улавливает уникальные крупицы полезной информации, которые, после того как их соберут воедино, становятся всесторонними требованиями к ИТ-решению. Для удобства мы рассмотрим все этапы создания требований в едином контексте. Для этого разберем пример постановки требований к системе обработки заявок на предоставление доступа к информационным системам. Представим себе крупный банк, в котором работают ты- сячи сотрудников. В этом банке сотни информационных систем, отвечающих за разные направления деятельности – от обслуживания клиента до проведения финансовых операций. Доступ каждого сотрудника к системе строго зависит от его должностных обязанностей. В рамках текущего процесса доступы к системам предоставляют администраторы информационной безопасности. Заявки они принимают по электронной почте. Естественно, это очень неудобно – в день им поступают сотни писем. Заявки теряются, пользователи нервничают, возникает неразбериха с тем, какие заявки выполнены, а какие нет. Кроме того, для разных типов заявок число согласующих лиц тоже различно. Это значит, что у каждой заявки свой уникальный маршрут согласования, и обеспечить ее прохождение по корректному маршруту при помощи электронной почты очень сложно. Для того чтобы оптимизировать процесс предоставления доступа к системам, руководство компании решило внедрить специализированный программный продукт – Jira. Jira автоматически определяет нужный маршрут согласования, рассылает уведомления и напоминания ответственным лицам, позволяет настроить систему статусов по обработке заявок и т. д. Но чтобы в полной мере воспользоваться преимуществами данного программного продукта, нужно подготовить исчерпывающие требования по его настройке. Этим и занимается бизнес-аналитик. Автоматизация предоставления доступа к информацион- ным ресурсам – распространенная задача в крупных компаниях. Связано это с большим количеством информационных систем, а также необходимостью ограничения доступа в зависимости от должности сотрудника и его принадлежности к тому или иному подразделению. Здесь я не стану приводить полноценного технического задания на автоматизацию процесса. Задача раздела – дать читателю понимание того, из каких этапов состоит постановка требований к ИТ-решению. ЭТАП 1. ОПИСАНИЕ БИЗНЕСПРОЦЕССОВ «КАК ЕСТЬ» О важности описания бизнес-процессов «как есть» и «как должно быть» мы подробно поговорили в разделе о ключевых задачах бизнес-аналитика. Поэтому сразу к делу. На первом этапе создания требований к ИТ-решению аналитик описывает бизнес-процесс или группу процессов заказчика, которые планируется изменить за счет внедрения ИТ-решения. По итогам изучения карт процессов у разработчиков и ИТ-инженеров складывается целостное понимание текущей деятельности заказчика. Ключевой вопрос этапа: Как устроена текущая деятельность заказчика, которую планируется изменить? Описание бизнес-процесса должно быть последовательным и давать стороннему специалисту представление о текущей организации работы. Предпочтительные способы описания процессов: • блок-схема; • текстовый способ. Рисунок 11. Фрагмент блок-схемы бизнес-процесса в формате «как есть» Любой бизнес-процесс состоит из последовательности функций, приводящих в совокупности к заданному результату. В случае выбора текстового способа предпочтительнее описывать процесс: 1. В хронологическом порядке по пунктам. 2. Руководствуясь принципом «одна функция – один исполнитель – один пункт». Каждый пункт должен отвечать на следующие вопросы. 1. Что служит инициирующим событием для выполнения функции? 2. Кто выполняет действие? 3. В чем состоит действие? 4. При помощи какого программного обеспечения выполняется действие (если применимо)? 5. Какие электронные или бумажные документы используются/меняются при выполнении функции (если применимо)? 6. К какому пункту процесса мы переходим после выполнения функции? ПРИМЕР ТЕКСТОВОГО ОПИСАНИЯ ФРАГМЕНТА БИЗНЕС-ПРОЦЕССА 1. Принятому на работу сотруднику требуется предоставление доступов к информационным системам (1). Руководитель нового сотрудника (2) формирует и отправляет заявку на предоставление доступа (3)(5) по электронной почте (4). Далее п. 2 (6). 2. Получив уведомление о новом сообщении в почтовом ящике (1) сотрудник Отдела информационной безопасности (2) открывает письмо в почтовом клиенте (4) и проверяет заявку на корректность оформления (3)(5). Далее п. 3 (6). 3. … ЭТАП 2. ОПИСАНИЕ ПРОЦЕССА «КАК ДОЛЖНО БЫТЬ» На втором этапе описывается вáидение заказчиком будущего бизнес-процесса или группы бизнес-процессов с учетом внедрения ИТ-решения. По итогам изучения карт процессов у разработчиков и ИТ-инженеров складывается целостное понимание пожеланий заказчика к будущему процессу. Ключевой вопрос этапа: Каким заказчик видит бизнес-процесс, оптимизированный при помощи ИТ-решения? Описание бизнес-процесса должно быть последовательным и давать стороннему специалисту представление о будущей организации работ. Предпочтительные способы описания процессов: • блок-схема; • текстовый способ. Любой бизнес-процесс состоит из последовательности функций, приводящих в совокупности к заданному результату. В случае выбора текстового способа предпочтительнее описывать процесс по пунктам по принципу «одна функция – один исполнитель – один пункт». Каждый пункт должен отвечать на следующие вопросы. 1. Что служит инициирующим событием для выполнения функции? 2. Кто выполняет действие? 3. В чем состоит действие? 4. При помощи какого программного обеспечения выполняется действие (если применимо)? 5. Какие электронные или бумажные документы используются/меняются при выполнении функции (если применимо)? 6. К какому пункту процесса мы переходим после выпол- нения функции? ПРИМЕР ТЕКСТОВОГО ОПИСАНИЯ ФРАГМЕНТА БИЗНЕС-ПРОЦЕССА 1. Принятому на работу сотруднику требуется предоставление доступа к информационным системам (1). Руководитель нового сотрудника (2) формирует и отправляет заявку на предоставление доступа (3)(5) в системе Jira (4). Далее п. 2 (6). 2. После отправки заявки (1) система Jira (2) (4) автоматически определяет маршрут согласования заявки и рассылает уведомления (5) ответственным сотрудникам (3). Далее п. 3 (6). 3. Получив уведомление о новой заявке на предоставление доступа (1), сотрудник Отдела информационной безопасности (2) проверяет заявку на корректность оформления и указывает свою резолюцию (3)(5) в системе Jira (4). Далее п. 4 (6). 4. … Обратите внимание, что на данном этапе мы используем результат работы предыдущего этапа: для построения карты процесса «как должно быть» нам потребовалась карта процесса «как есть». Рисунок 12. Фрагмент блок-схемы бизнес-процесса в формате «как должно быть» ЭТАП 3. ФОРМИРОВАНИЕ КАРТОЧКИ ПРОЕКТА В карточке проекта описываются текущая ситуация по той деятельности, которую надо изменить, и концепция целевого решения. Эта карточка представляет собой своеобразное «личное дело» проекта с указанием его ключевых характеристик. По итогам изучения карточки проекта у разработчиков и ИТ-инженеров формируется целостное понимание следующих аспектов. 1. Какие преимущества бизнес-заказчик ожидает получить от внедрения ИТ-решения. 2. Какие проблемы стоят перед заказчиком. 3. Какие риски несет заказчик при текущей организации процесса. 4. Какие ключевые функции («фичи») должны быть у будущего ИТ-решения. Ключевой вопрос этапа: Каковы основные проблемы текущего бизнес- процесса заказчика и за счет чего их можно устранить? Для заполнения карточки проекта используется информация, полученная в ходе построения карт процессов «как есть» и «как должно быть». Таблица 7. Пример карточки проекта ЭТАП 4. КОНТЕКСТ ИСПОЛЬЗОВАНИЯ СИСТЕМЫ Ни одна информационная система не существует в вакууме. Так или иначе, любое ИТ-решение предполагает взаимодействие с пользователями и (или) другими системами, а также двусторонний информационный обмен. С точки зрения постановки требований огромную роль играет контекст – среда, в которой существует ИТ-решение, и субъекты, взаимодействующие с ним. Чтобы понять важность контекста, рассмотрим пример с двуручной пилой. Раньше ею в основном пользовались ле- сорубы, чтобы валить деревья и распиливать бревна. Однако в конце XIX века пиле нашли необычное применение – ее превратили в музыкальный инструмент. Таким образом, восприятие объекта требований может существенно отличаться в зависимости от того, кто с ним взаимодействует и с какой целью. Лесоруб спилит пилой дерево, а музыкант сыграет на ней мелодию. Всё зависит от контекста. Описанию контекста посвящен четвертый этап формулирования требований. Мы фиксируем ключевые субъекты, которые будут работать с будущим ИТ-решением: пользователей и смежные информационные системы. В данном разделе технического задания указывается, какие данные пользователь или смежная система вводят в нашу ИТ-систему, а какие из нее получают. Ключевые вопросы этапа: Кто будет взаимодействовать с ИТ-решением? Какую информацию субъекты будут вводить в систему и какую получать из нее? Схему взаимодействия с системой можно представить в виде контекстной диаграммы. На рисунке 13 представлен упрощенный пример контекстной диаграммы. В реальном проекте на ней будет больше субъектов, а также информационных потоков между ними. Для определения перечня субъектов и потоков данных, изображенных на контекстной диаграмме, используется кар- точка проекта из предыдущего этапа, а точнее, ее поля «Количество типов пользователей (ролей)» и «Смежные системы (интеграции)». Кроме того, при построении диаграммы пригодятся и карты бизнес-процессов. Рисунок 13. Упрощенный пример контекстной диаграммы Таблица 8. Взаимодействие пользователя с системой ЭТАП 5. ФОРМУЛИРОВАНИЕ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ Важнейший этап, в ходе которого аналитик описывает ключевые возможности будущего ИТ-решения. Допускается группировка требований по пользователям с указанием, какие функции доступны пользователю каждого типа. Как же сформулировать требование к ИТ-решению? Рассмотрим классическую схему. «[Предмет] должен позволять [Роль] [Глагол] [Объект] [Условие]» Требование к ИТ-решению состоит из пяти элементов: 1. Предмет требования. 2. Роль. 3. Глагол (действие). 4. Объект. 5. Условие. ПРИМЕР ТРЕБОВАНИЯ Система (1) должна позволять пользователю с ролью «Зарегистрированный пользователь» (2) просматривать (3) список заявок (4) закрепленных за ним (5). Объектами требований могут быть заявка, задача, карточка документа и т. п. Предметом требований, как правило, выступает внедряемая информационная система. Ключевые вопросы этапа: Что должно позволять делать ИТ-решение? Какими функциональными возможностями ИТрешение должно обладать? Результаты данного этапа можно условно разнести по двум подразделам: 1. Пользовательские роли. Здесь описываются задачи, которые выполняет сотрудник с указанной ролью в ИТ-решении. Для заполнения данного подраздела можно исполь- зовать карточку проекта и контекстную диаграмму. 2. Функциональные требования. В этом подразделе описываются требования к ИТ-решению в контексте каждой пользовательской роли. Таблица 9. Пример заполнения подраздела «Пользовательские роли» Таблица 10. Пример заполнения подраздела «Функциональные требования» Аналогичные таблицы заполняются для каждой выделенной роли. При оформлении этого раздела помните о ключевых характеристиках требований: они не должны повторяться, противоречить друг другу, должны быть выполнимыми и т. д. Под требования, актуальные для всех без исключения типов ролей, лучше создать отдельную макророль «Зарегистрированный пользователь». Узкопрофильным пользовательским ролям необходимо указывать требования, имеющие отношения только к этим ролям. Формулируя функциональные требования, не забывайте обращаться к результатам предыдущих этапов: картам процессов, карточке проекта, контекстной диаграмме. Эти материалы подскажут вам идеи для новых требований. ЭТАП 6. ФОРМИРОВАНИЕ МОДЕЛИ ДАННЫХ Модель данных описывает ключевые сущности, с которыми работает система, и демонстрирует их взаимосвязь. Например: заявка, пользователь, маршрут согласования, отчет, уведомление. Таким образом, эта модель очерчивает «внутренний мир» ИТ-решения. Упрощенно построение модели данных можно сравнить с созданием анатомического атласа. Человеческое тело – то- же система со своими элементами: мозг, сердце, легкие и т. д. И все эти элементы находятся в определенной взаимосвязи: одни органы напрямую зависят от других, остальные – косвенно. Рисунок 14. Модель данных Задача данного этапа – определиться с ключевыми элементами нашего ИТ-решения и взаимосвязями между ними. Ключевой вопрос при построении модели данных: Связан ли объект А с объектом Б? Смысл построения модели данных – выявление требований, которые могли быть упущены на предыдущем этапе. Например, связь сущности «Заявка» с сущностью «Шаблон заявки» может натолкнуть вас на мысль сформулировать требование создать для администратора системы инструменты настройки шаблонов заявок. ЭТАП 7. СЛОВАРЬ ДАННЫХ Словарь данных определяет перечень объектов требований, их атрибутный состав и формат каждого атрибута. Этот раздел можно дополнить прототипами экранных форм будущего ИТ-решения. Задача раздела – описать структуру каждой сущности, выделенной в модели данных. Обратите внимание на оформление следующей таблицы. Объект (Заявка, Запрашиваемый ресурс, Запись о согласовании) представляет собой совокупность атрибутов разного типа. Затем для каждого атрибута, входящего в состав объекта, прописывается тип, ограничения или перечень возможных значений. Таблица 11. Пример заполнения подраздела ЭТАП 8. ФОРМИРОВАНИЕ ДИАГРАММЫ СОСТОЯНИЙ Диаграмму состояний можно сравнить с краткой биографией человека. С помощью нее описывают жизненный цикл объекта требований с момента его возникновения в системе и вплоть до достижения финального статуса. Однако, в отличие от биографии, в диаграмме состояний отражаются все возможные варианты развития событий. Описать подобным образом жизненный путь человека, конечно же, невозможно. Диаграмму состояний аналитики используют для определения логической и хронологической последовательности присвоения статусов объектам в информационной системе. Рисунок 15. Пример диаграммы состояний Ключевые вопросы этапа: Каков жизненный цикл объекта в информационной системе? Какие статусы может принимать объект и в каком порядке? Диаграмма состояний формируется для всех объектов, у которых предполагается изменение статуса в ходе работы ИТ-решения. ЭТАП 9. ФОРМИРОВАНИЕ USE CASE DIAGRAM Рассмотрим понятие use case, или пользовательских сценариев, на примере бытовой техники. Взаимодействие потребителя с любым бытовым прибором, начиная с чайника и заканчивая микроволновой печью, предполагает выполнение определенных действий. Эти действия направлены на решение задачи пользователя: вскипятить воду, разогреть еду и т. д. При этом разработчикам важно понимать, как бытовой прибор должен реагировать на то или иное действие своего хозяина. Описание поведения прибора или системы при взаимодействии с внешней средой (пользователем или другой системой) и называется use case. Use case diagram схематично отображает ключевые сценарии работы пользователей и смежных систем с ИТ-решением: регистрация, согласование, выгрузка отчетов, настройка прав доступа и т. д. Рисунок 16. Пример use case diagram Как и в случае с моделью данных, use case diagram служит для выявления требований, которые аналитик мог упустить на предыдущих этапах. Задача этой диаграммы – наглядно продемонстрировать сценарии, которые предстоит детализировать на следующем этапе. ЭТАП 10. ПОЛЬЗОВАТЕЛЬСКИЕ СЦЕНАРИИ На последнем, десятом этапе аналитик детально описывает пользовательские сценарии: что делает пользователь, как на это реагирует система, при каких условиях реализуется сценарий, какой результат получается в итоге и т. д. Обратите внимание на структуру use case. В разделе «Предусловия» описываются все условия, которые должны быть соблюдены к моменту старта пользовательского сценария. Если хотя бы одного из них не будет – выполнение сценария окажется невозможным. Основной («положительный») сценарий приведен в разделе «Основной поток». Отметим, что в «Основном потоке» описываются не только действия пользователя в системе, но и поведение самой информационной системы. В блоке «Расширения» описаны отклонения от стандартного сценария. Посмотрите, сколь многое может пойти не так при работе пользователя с ИТ-решением. Все негативные сценарии тоже необходимо учитывать. Таблица 12. Пример пользовательского сценария «Подать заявку» На данном этапе описываются все пользовательские сценарии, отображенные в use case diagram. Подчеркнем важность блока «Расширения», обратившись всё к тому же примеру с бытовой техникой. Допустим, пользователь решил вскипятить воду в электрическом чайнике. Описание подобного use case должно предусматривать случаи, когда в сети нет электричества или пользователь забыл налить в чайник воду. Если при проектировании бытового прибора инженеры не учтут все возможные негативные сценарии, вплоть до самых фантастических, это может привести к печальным последствиям. Очевидно, что при отсутствии воды электрический чайник должен тут же выключиться. Однако, если такого расширения use case не предусмотреть, чайник может стать причиной пожара. Лучший способ написать use case – поставить себя на место конечного пользователя и не спеша, шаг за шагом описать все действия, необходимые ему для решения конкретной задачи. Неоценимую помощь в создании use case могут оказать специалисты со стороны заказчика, которым предстоит работать с ИТ-решением. Что же в итоге? Пройдя путь из десяти этапов, аналитик получает десять артефактов, среди которых карты процессов, таблицы, схемы и пользовательские сценарии. Каждый артефакт описывает определенный аспект работы будущего ИТ-решения. После того как работа над артефактами будет завершена, останется лишь оформить итоговые требования. Итоговые требования представляют собой структурированный документ, созданный на основе получившихся артефактов. Затем этот документ отправляется на согласование к заказчику, а после его одобрения передается команде разработки. Прочитав данный раздел, вы теперь понимаете, насколько глубоко бизнес-аналитик погружается в исследование предметной области заказчика. Именно в процессе формирования артефактов для требований у бизнес-аналитика появляется экспертиза, которой могут воспользоваться другие участники проектной команды: руководитель проекта, разработчики и инженеры-тестировщики. 2.7.1. О СТАНДАРТАХ ОФОРМЛЕНИЯ ТРЕБОВАНИЙ Данный раздел – лишь пример того, какие техники можно использовать для выявления и формулирования требований. Подобных техник великое множество. Каждая из них позволяет посмотреть на будущее ИТ-решение под другим углом и сформулировать новые наводящие вопросы. Чем больше инструментов вы освоите – тем проще будет работать. Какие инструменты выбирать, в какой последовательности их использовать и как распорядиться итоговым результатом – решать вам. Выбор зависит от разных факторов: ваших личных предпочтений, пожеланий заказчика, специфики проекта и тому подобного. Не стоит опасаться, что какие-то техники со временем устареют. Да, мода на отдельные типы диаграмм и форматы описания требований порой проходит. Но это не значит, что подобные инструменты становятся хуже. Вы всё равно можете использовать их, чтобы фильтровать информацию, которую получаете от заказчика. К примеру, в предъявляемых заказчиком стандартах оформления требований может отсутствовать контекстная диаграмма. Однако это не значит, что вы не можете ею воспользоваться, – наоборот, подобная диаграмма позволит вам выявить скрытые, не лежащие на поверхности требования. В дальнейшем, ориентируясь на предложенные заказчиком стандарты, вы оформите полученную информацию в нужном виде. Со временем у вас сформируется собственный «арсенал» техник, понятных и удобных именно вам. По мере накопления опыта вы сформулируете собственное понимание того, «как должно быть хорошо», и будете выбирать соответствующие инструменты. Как и в случае с нотациями бизнес-моделирования, я намеренно не останавливаюсь на стандартах оформления требований к ИТ-решениям, вроде ГОСТ 34 и ГОСТ 19. Конечный вид требований полностью зависит от подхода к их оформлению, принятого в вашей организации, а также от пожеланий заказчика. И в финальных требованиях вовсе не обязательно найдется место для артефактов, описанных в этой главе. Моя задача – лишь рассказать вам о некоторых инструментах, помогающих вычленить требования к ИТ-решению из огромного массива информации о предметной области заказчика. Главное – добраться до сути, а за оформлением дело не станет. 2.8. Особенности коммуникации в бизнес-анализе, или При чем здесь телешоу из девяностых «Пойми меня» Упрощенный жизненный цикл разработки программного обеспечения состоит из пяти этапов: 1. Обследование. 2. Разработка. 3. Тестирование. 4. Опытная эксплуатация и внедрение. 5. Сопровождение. На каждом этапе предполагается работа различных ИТспециалистов: руководителя проекта, аналитиков, разработчиков и тестировщиков. Это значит, что каждый этап стоит бизнес-заказчику определенных денег. Естественно, заказчик заинтересован в том, чтобы работа шла строго по плану, выполнялась без ошибок, а в идеале – и с опережением сроков. Увы, людям свойственно ошибаться, и ИТ-проект, реализованный без единой ошибки, – нечто из области фантастики. Тем не менее цена ошибок, допущенных в рамках ИТпроектов, может сильно различаться. В данном разделе мы поговорим о том, почему ошибки аналитиков могут обходиться заказчику особенно дорого и что с этим делать. Итак, по итогам этапа обследования аналитик готовит структурированный документ, в котором формулирует требования к будущему ИТ-решению. Требования эти нацелены на то, чтобы максимально удовлетворить потребности заказчика для решения стоящей перед ним проблемы. Как правило, такая проблема связана с бизнес-процессами: длительностью выполнения отдельных работ, высокими затратами, техническими и законодательными рисками и т. д. Получив сформулированные требования, разработчик приступает к созданию ИТ-решения, призванного либо частично, либо полностью устранить имеющиеся у заказчика проблемы. Требования для разработчика – ключевой документ с точки зрения понимания потребностей заказчика. Допустим, по ходу разработки программист неверно реализовал в системе логику расчета финансовых показателей. В идеале такую ошибку должен выявить инженер по тестированию, тестовые сценарии для которого подготавливаются на основе тех же требований аналитика. Если в ходе тестирования инженер выявит расхождение между написанным в требованиях и тем, что реализовано на практике, то разработчик исправит баг и продолжит работу над системой. Да, на устранение ошибки понадобятся дополнительные время и деньги, но ее влияние на сроки и бюджет проекта будет не столь велико. Совсем другое дело, если требования изначально были сформулированы неверно из-за недопонимания, возникшего между заказчиком и аналитиком. Очевидно, что такие ошибки выявляются гораздо позже, чем на стадии разработки и тестирования. В самом деле: и разработчик, и тестировщик реализовали функциональную возможность в ИТрешении, строго следуя представленным аналитиком требованиям. Какие к ним могут быть претензии? За корректность требований отвечает аналитик. Ошибку в требованиях могут обнаружить лишь на этапе опытной эксплуатации, в которой примут участие представители заказчика. Вот тут-то и может выясниться, что «это совсем не то, чего мы хотели». Чем же это грозит с точки зрения жизненного цикла разработки? В подобной ситуации все этапы придется проходить с самого начала: проводить дополнительное обследование, вносить изменения в требования, переделывать код и повторно его тестировать. А мы помним, что каждый этап – это время и деньги. Вот почему ошибки бизнес-аналитика имеют куда более серьезные последствия, чем любые другие. Важно понимать, почему подобные ошибки возникают в принципе и что с ними делать. Начнем с причин их возникновения на этапе обследования. Ключевая причина – сложности в коммуникации между аналитиком и заказчиком. Авторы «Настольной книги аналитика» Сергей и Вале- рий Ковалевы отмечают, что при прохождении более чем через два звена устная информация искажается более чем на 50 %. Данный принцип наглядно продемонстрировало телешоу «Пойми меня», выходившее в начале 1990-х годов. По сути, это была телеверсия популярной игры «Испорченный телефон», в ходе которой информация непроизвольно искажалась, проходя через большое количество людей. Действительно, поставьте себя на место заказчика: у вас есть собственное представление о текущей проблеме в вашем процессе и о вариантах ее решения. Не обязательно, что это мнение правильное. Но поскольку заказчик – вы, именно ваше понимание ситуации станет определяющим для команды разработки. По тем или иным причинам вы можете сообщить аналитику далеко не всё, что думаете о проблеме. Это бывает связано с корпоративной культурой компании, политическими нюансами, конфиденциальностью отдельных видов работ и тому подобным. В конце концов, вы можете изначально быть настроены против проекта и участвовать в нем исключительно под давлением руководства. В этом случае вы вряд ли примете аналитика с распростертыми объятиями. Итак, допустим, вам всё-таки необходимо поделиться с бизнес-аналитиком некоторой информацией о своей предметной области. Хорошо, если ваш рассказ последователен, структурирован, учитывает детали и особенности предметной области. А если нет? Человеку свойственно думать, что другие знают о его работе почти столько же, сколько и он сам. Профильный специалист часто не останавливается в своем рассказе на очевидных ему моментах. Вот только людям с другим жизненным и профессиональным опытом эти моменты могут показаться совершенно неочевидными. Теперь взглянем на процесс коммуникации с точки зрения аналитика. Это тоже человек со своим жизненным и профессиональным опытом. У аналитиков своя «профессиональная деформация» – они мыслят схемами бизнес-процессов и структурированными документами вроде технических заданий. Ваш рассказ аналитик неизбежно начнет воспринимать в рамках документации: схем, требований, таблиц и т. д. Хорошо, если он достаточно опытен и не поддается соблазну додумать или подогнать рассказ заказчика под желаемый формат. Важно, чтобы аналитик подмечал детали и цеплялся за логические нестыковки и «белые пятна» в рассказе заказчика, а не стремился как можно скорее упаковать полученную информацию в документ. Тем не менее все мы люди, и бизнес-аналитик может бессознательно додумать ответ на незаданный вопрос, а потом отразить его в требованиях. В реальности же ответ заказчика бывает совершенно иным. Увы, подобное недопонимание часто обнаруживается лишь на этапе опытной эксплуатации. Кроме того, нельзя сбрасывать со счетов и разницу компетенций заказчика и аналитика в рамках предметной обла- сти. Очевидно, что заказчик намного глубже погружен в детали конкретного процесса, нежели аналитик, – поэтому его рассказ может изобиловать десятками специфических терминов и аббревиатур. Аналитику может показаться, что он всё понял, хотя в действительности это не так. Видите, сколь многое в ходе коммуникации может пойти неправильно? А если один из представителей заказчика настроен против проекта? В таком случае вероятность возникновения дорогостоящих ошибок в требованиях крайне велика. В англоязычном ИТ-сообществе распространена аббревиатура CYA. Расшифровка слегка неблагозвучная, но в целом правильная: Cover Your Ass (прикрывай свой зад). Для аналитика это означает, что до передачи в разработку все материалы обследования должны быть официально согласованы с заказчиком. Как минимум в виде ответных писем в электронной почте. Участникам проекта важно постоянно «сверять часы». Цель согласования документов в том, чтобы сказать заказчику: «Я понял ваш рассказ так. Предполагаю, что он приведет к появлению следующих требований… Правильно ли я вас понял? Этого ли вы хотите от будущего ИТ-решения?» Иногда заказчик может уклоняться от прямых ответов или вовсе игнорировать процесс согласования. Проявите настойчивость. При необходимости эскалируйте вопрос на руководителя проекта. Начало работ с несогласованными требованиями на руках может дорого обойтись обеим сторонам проекта. Если же на этапе опытной эксплуатации заказчик начнет говорить, что «всё не так и всё не то», но при этом у вас будут согласованные им же требования, – это станет серьезным аргументом в вашу пользу. Наличие согласованных требований позволит вам урегулировать спорную ситуацию. Если заказчик согласовал требования не читая – это проблема. Но проблема общая, а не только ваша. И в таком случае обвинить аналитика в срыве сроков и выходе за рамки бюджета проекта не получится. В конце концов, документация как раз для того и нужна – до начала работ убедиться, что стороны понимают друг друга, изучают одну и ту же проблему и согласовали подходы к ее решению. По той же причине официальная переписка в электронной почте предпочтительнее телефонных звонков и мессенджеров. Это дисциплинирует участников проекта и стимулирует их нести ответственность за принятые решения. 2.9. Электронная нервная система В 1999 году вышло первое издание книги основателя Microsoft Билла Гейтса – «Бизнес со скоростью мысли». Ключевым понятием, которое автор использовал в своей книге, стала электронная нервная система (ЭНС). Несмотря на то что прошло уже более 20 лет, многие тезисы из этой книги не теряют своей актуальности, а потому в данном разделе мы обсудим, каким образом они связаны с бизнес-анализом. Согласно Гейтсу, электронная нервная система – это компьютерные процессы, используемые работниками умственного труда для принятия оптимальных решений. В свою очередь, умственный труд – это обработка данных человеческим интеллектом для решения поставленных задач. Таким образом, под работниками умственного труда понимаются не только ИТ-специалисты, но и все сотрудники, чья работа так или иначе связана с обработкой информации: экономисты, юристы, менеджеры по продажам и т. д. Современную организацию сложно представить без работников умственного труда, чем и объясняется насущная потребность в электронной нервной системе. Билл Гейтс отмечает, что извлечение данных из рабочих процессов и их использование для решения практических задач – одна из самых трудноразрешимых проблем биз- неса. Следовательно, ЭНС нужна сотрудникам организации для того, чтобы анализировать информацию, реагировать на изменения и адаптироваться к ним. Бизнес-аналитик, как посредник между бизнесом и ИТ, принимает непосредственное участие в построении подобной системы. Важно понимать, что электронную нервную систему невозможно выстроить на базе одного-двух программных продуктов. ЭНС представляет собой сложную совокупность взаимосвязанных ИТ-решений и бизнес-процессов. С каждым годом тенденция к усложнению лишь усиливается, а значит, растет и потребность в бизнес-аналитиках. Согласно древней мифологии, земля покоилась на трех слонах, а у электронной нервной системы таких слонов – четыре. 1. Система электронного документооборота (СЭД). СЭД обеспечивает обмен информацией между структурными подразделениями и позволяет документировать деятельность организации в целом. Она используется для официальной переписки внутри компании, а также согласования и подписания различных документов: договоров, приказов, положений и регламентов. 2. Customer Relationship Management (CRM) – система управления взаимоотношениями с клиентами. Эта система обеспечивает поддержку процесса продаж и хранит всю необходимую информацию о клиентах и формате взаимодействия с ними. Данные о ключевых параметрах сделок, хронологии продаж и ответственных исполнителях также можно найти в CRM. 3. Системы управления разработкой, в том числе системы отслеживания ошибок и вики-системы. В этих системах хранится информация о ходе работ над созданием новых цифровых продуктов: данные о затраченном на разработку времени, аналитические материалы, результаты тестирования и т. д. Иными словами, это «сердце» производственных процессов. 4. Системы автоматизации экономической деятельности, так называемые учетные системы. Это системы, в которых хранится информация о бухгалтерском и управленческом учете, кадровой структуре организации, данные по финансовым потокам и т. д. На мой взгляд, все элементы ЭНС равнозначны между собой, поскольку каждый из них способствует ИТ-поддержке критически важного направления работ. Тем не менее Билл Гейтс особое внимание уделяет анализу данных, поступающих непосредственно от клиентов: • сведениям об объемах продаж; • отзывам покупателей; • тенденциям развития бизнеса в регионах; • востребованности тех или иных продуктов и услуг компании и т. д. Согласно Гейтсу, эти данные обеспечивают наилучшее понимание конкурентной среды, позволяют быстрее адаптироваться к изменениям и заранее выявлять негативные тренды. Таким образом, с точки зрения бизнеса ключевым элементом ЭНС является CRM-система. В определении электронной нервной системы говорится о «принятии оптимальных решений». Здесь важно отметить, что пользователями системы выступают все сотрудники компании, а не только высшее руководство. ЭНС должна не только формировать отчеты для принятия сложных стратегических решений, но и предоставлять необходимую информацию сотрудникам на местах. В своей книге Билл Гейтс приводит пример нарушения подобного принципа. Крупная сталелитейная компания начала внедрять управленческую информационную систему, доступ к которой был исключительно у высшего руководства. По мере того как топ-менеджеры анализировали данные из системы, у них возникало всё больше конкретных вопросов к своим сотрудникам. Парадокс заключался в том, что эти сотрудники не обладали всеми необходимыми данными для ответов на подобные вопросы: ведь доступа к системе у них не было. Иными словами, информационная поддержка высшего руководства оказалась значительно лучше, чем у рядовых сотрудников. Это еще один довод в пользу проведения бизнес-анализа в ИТ-проекте для реализации концепции ЭНС: участие бизнес-аналитика позволяет сократить вероятность того, что при создании системы будут упущены те или иные потребности заинтересованных подразделений. Заниматься внедрением и совершенствованием ЭНС можно бесконечно. Появляются новые технологии, процессы, рынки сбыта, – всё это приводит к необходимости чтото менять в информационных системах компании. Вот почему ЭНС нельзя назвать ИТ-проектом в классическом понимании этого слова: ведь любой проект предполагает определенные временные и бюджетные рамки. Здесь же речь идет о непрерывном совершенствовании ИТ-поддержки ключевых бизнес-процессов компании. Электронная нервная система не только помогает решать практические задачи, но имеет и другие положительные стороны. Так, процесс внедрения и совершенствования ЭНС приводит к развитию технологической и процессной культуры внутри организации. Бизнес-подразделения начинают лучше понимать специфику работы над ИТ-системами и ограничения, с которыми приходится сталкиваться разработчикам. Кроме того, подразделения привыкают мыслить категориями бизнес-процессов: учитывать зоны ответствен- ности, а также следить за логическими и хронологическими аспектами своей работы. В электронную нервную систему входит множество взаимосвязанных информационных систем и бизнес-процессов. С учетом этого становится понятно, что в подобном проекте работы у бизнес-аналитика – непочатый край. Чтобы правильно выстроить ЭНС, необходимо описать процессы «как есть» и «как должно быть», выявить заинтересованные стороны, сформировать требования к функционалу ее будущих элементов и т. д. На мой взгляд, внедрение электронной нервной системы – одно из самых интересных направлений работы в бизнес-анализе. ЭНС затрагивает различные аспекты деятельности компании и строится на разных программных продуктах, а значит, участие в подобном проекте поможет вам значительно расширить свой профессиональный кругозор. 2.10. Принцип ближайшей атомарной задачи, или Как обеспечить поступательный прогресс в параллельных проектах Если вы работаете в сфере ИТ, то знаете, что рано или поздно аналитик может оказаться занят на нескольких проектах одновременно. Под «проектом» в данном разделе будет подразумеваться не только проект в его классическом понимании, но и любая задача, реализация которой предполагается в течение длительного периода времени. Мы поговорим о том, что любую масштабную задачу или проект можно декомпозировать до уровня элементарных действий. Деятельность бизнес-аналитика по своей природе связана с обработкой больших объемов информации и взаимодействием с разными людьми. При параллельном участии в нескольких проектах объем поступающей ему информации и количество его взаимодействий увеличивается в разы. Как же быть, если аналитику необходимо контролировать не только свои задачи, но и задачи подчиненных? Очевидно, что держать в голове десятки договоренностей, имена ответственных лиц, детали прошедших встреч и тому подобные сведения – нереально. На помощь аналитику приходят разнообразные приложения для проектной работы: виртуальные канбан-доски, чек-листы и органайзеры. Во время параллельной работы на нескольких проектах у аналитика регулярно возникает потребность быстро переключаться между разными предметными областями. На примере онлайн-сервиса Trello мы посмотрим, какие приемы помогают упростить подобное переключение между задачами. Методов контроля выполнения работ великое множество. На эту тему написан не один десяток книг как у нас, так и за рубежом. Каждый выбирает тот метод, который больше подходит к конкретной ситуации и соответствует индивидуальным предпочтениям специалиста. Метод ближайшей атомарной задачи сформировался у меня в ходе работы над проектом «Банк идей». В рамках этого проекта сотрудники одного крупного банка публиковали в специальной системе свои идеи по совершенствованию процессов, продуктов и услуг. Я отвечал за своевременную обработку этих предложений. Суть проекта была в том, чтобы ни одно предложение сотрудников не осталось без ответа. Это было особенно важно на первых порах, поскольку отсутствие внятной обратной связи неизбежно демотивировало бы авторов идей и поток предложений быстро бы иссяк. Целью же проекта было прямо противоположное. Каждая идея проходила по четкому жизненному циклу: первичный анализ, подробное изучение профильным экспертом и последующее внедрение или аргументированный отказ. Реализация подобного жизненного цикла означала необходимость одновременно контролировать рассмотрение десятков, а то и сотен поступающих предложений. По сути, каждая идея представляла собой «микропроект», и моя задача как администратора системы состояла в том, чтобы доводить предложения сотрудников до логического завершения. Ежедневно администратору системы приходилось отвечать на десятки однотипных вопросов: • Какие идеи необходимо взять в работу? • Какие идеи стоит направить на экспертизу? • Кому из экспертов следует напомнить об истечении сроков предоставления обратной связи по тому или иному предложению? • По каким идеям требуется оформить обоснованный отказ? • По каким идеям требуется организовать совещание экспертной группы? И так далее и тому подобное. Важно понимать, что ход рассмотрения каждой идеи был уникален. Отличались предметные области, уровень исполнительской дисциплины экспертов, сложность реализации и установленные сроки. Всё это необходимо было как-то учитывать. В этом смысле деятельность администратора системы была схожа с работой проектного менеджера, одновременно курирующего несколько проектов. Как же в таких условиях было обеспечить контроль и поступательное движение вперед сотни параллельных, не связанных между собой задач? Требовался некий подход для ведения записей и контроля сроков. Так и появился принцип ближайшей атомарной задачи, который удалось реализовать при помощи Trello. Ранее уже говорилось, что в ситуации параллельной работы над несколькими проектами важно уметь быстро переключаться между задачами. Подобное переключение можно обеспечить, ответив себе на два вопроса: • Где мы сейчас? Иными словами, какая работа проделана к настоящему моменту и, условно, на чьей стороне «мяч»? • Что мы делаем дальше? Какие действия необходимо совершить, чтобы обеспечить дальнейший ход работ по проекту? Чтобы ответить на эти вопросы, аналитики и руководители проектов много времени уделяют ведению базы знаний. У базы знаний две ключевые функции: • хранение основных артефактов по проекту; • фиксация хронологии работ и контроль задач. С хранением артефактов по проекту всё более или менее понятно. Для начала создается некая иерархическая структура: начиная с простого каталога папок на сетевом ресурсе и заканчивая деревом вложенных страниц в Confluence. В этой структуре и размещаются протоколы совещаний, требования к ПО, нормативная документация и полезные ссылки. Но как вести базу знаний так, чтобы она стала полезным прикладным инструментом, а не превратилась в забитый документами «склад»? Один из вариантов – работать в базе по принципу ближайшей атомарной задачи. Этот принцип основывается на следующих трех постулатах. 1. «Личное досье» на каждый проект. 2. Краткая, но емкая фиксация хронологии работы над задачей. 3. Контроль сроков исполнения ближайшей атомарной задачи. Рассмотрим их подробнее. 1. «Личное досье» на каждый проект. В случае с Trello – на доске создается отдельная карточка проекта (см. рис. 17). Рисунок 17. Пример отдельной карточки проекта в Trello 2. Краткая, но емкая фиксация хронологии работы над задачей. Обязательно с именами действующих лиц и датами событий. Рассмотрим пример. Допустим, мы работаем над проектом по созданию информационной системы для Отдела кадров. Для этого мы заводим отдельную карточку, в которую будем заносить всю необходимую информацию. По итогам очередного совещания с бизнес-заказчиком в карточке проекта должна появиться запись: «10.03.2021. Провели совещание с представителями От- дела кадров: Олегом Ивановым и Марией Семёновой. По итогам встречи получена информация для формирования функциональных требований. Аналитик Ольга Филатова приступила к написанию документа. Протокол совещания: ссылка на протокол» (см. рис. 18). Рисунок 18. Пример записи в карточке проекта Цель подобных записей – обеспечить максимально быстрое погружение в контекст, ответив на вопросы: • Где вы сейчас находитесь? • Что уже сделано? • Кто и что вам пообещал? • На чьей стороне «мяч»? • Какие обязательства вы взяли на себя? • Каким было последнее событие по задаче? Фиксация хронологии работы – это шпаргалка, которая не даст сбить вас с толку и не позволит забыть существенные детали. Да, этот принцип требует определенной дисциплины, но поверьте: вы еще не раз скажете себе спасибо за подобные подсказки. В Trello запись хронологии работ удобнее всего вести в ленте комментариев к карточке проекта. ВАЖНО! Не стоит писать объемные и пространные комментарии вроде мини-версии «Войны и мира». Чем короче, тем лучше: «Кто? Что? Когда? Полезная ссылка». 3. Контроль сроков исполнения ближайшей атомарной задачи. Если вдуматься, любой успешный проект – это совокупность тысяч элементарных действий, выполненных в правильном порядке. Какие же это действия? • Телефонный звонок коллеге. • Организация встречи. • Отправка письма по почте или сообщения в мессенджере. • Обсуждение обратной связи по документу или письму. • Написание программного кода или документа, создание схемы. И так далее. Нам важно понимать, что прогресс по проекту обеспечивается выполнением подобных действий в соответствии с контекстом ситуации, – а значит, для реализации данного принципа необходимо: • зафиксировать ближайшее атомарное действие – звонок, сообщение, напоминание, формирование документа; • зафиксировать дату выполнения атомарного действия; • либо приступить к выполнению действия в указанный срок, если за него отвечаете вы; • либо убедиться, что сотрудник, ответственный за выполнение действия, в курсе дел, и отправить ему уведомление о задаче – желательно по электронной почте. Вернемся к нашему примеру. Допустим, у вас состоялась встреча с подразделением-заказчиком в лице Отдела кадров. По итогам встречи была получена нужная информация, и аналитик Ольга Филатова взяла неделю на формирование функциональных требований. Это значит, что помимо записи о состоявшейся встрече (см. выше) в карточке проекта должна появиться запись с контрольным сроком: «19.03.2021. Уточнить ход формирования функциональных требований у аналитика Ольги Филатовой» (см. рис. 19). Рисунок 19. Карточка проекта. Добавляем запись в чеклист Или, если вы и есть аналитик, запись типа: «19.03.2021. Сформировать функциональные требования и отправить бизнес-заказчику». В Trello ведение записей о ближайшей атомарной задаче обеспечивается: • во-первых, присвоением срока карточке проекта («в пятницу, в 16:45»); • во-вторых, указанием сути атомарной задачи в чек-листе карточки проекта. Когда в следующий раз вы зайдете в карточку проекта, у вас будет понятная картина, отражающая текущую ситуацию: • Хронология проекта напомнит, что состоялась встреча, на которой получена нужная информация. При необходимости можно будет ознакомиться с протоколом встречи. • Запись о ближайшей атомарной задаче напомнит о том, что нужно сделать и когда. Допустим, Ольга Филатова сформировала функциональные требования и отправила их заказчику. Это означает, что теперь нужно: • Внести новую короткую запись в хронологию проекта. Например: «19.03.2021. Функциональные требования сформированы и отправлены на рассмотрение в Отдел кадров: Олегу Иванову и Марии Семёновой». • Изменить ближайшее атомарное действие. Например: «22.03.2021. Запрос обратной связи по итогам изучения требований специалистами Отдела кадров. Ответственный: О. Филатова» (см. рис. 20). Рисунок 20. Карточка проекта. Обновляем записи в карточке Подобным образом записи ведутся до тех пор, пока проект не будет доведен до конца. К примеру, до того момента, когда описанный в требованиях функционал не будет реализован и принят бизнес-заказчиком. Фиксированный срок, указанный в карточке проекта, служит для вас определенным фильтром. Благодаря ему вы мо- жете сортировать задачи: «Просроченные», «Срок истекает на этой неделе», «Срок истекает сегодня» и т. д. Кроме того, с помощью установки срока можно настроить отправку напоминаний исполнителям в интервале от «За 5 минут до окончания срока» до «За 2 дня до окончания срока». Если вы работаете в команде, не лишним будет указывать владельца каждой карточки. Кроме того, любым карточкам в Trello можно присваивать цветовые метки: например, для обозначения приоритета или классификации проектов по предметным областям. Это позволит вам использовать комбинации фильтров. Допустим, можно будет вывести только те карточки, владельцем которых является Ольга Филатова, с приоритетом «Срочно» и сроком исполнения «Завтра». Метки и фильтры – гибкий и удобный инструмент для работы с параллельными проектами. Каждый рабочий день аналитик или руководитель проекта может начинать с включения фильтров и вывода карточек со сроком исполнения «Просрочено» и «Сегодня». Пара кликов – и план работы на день готов. Если карточка проекта попала в список просроченных, для вас это сигнал о том, что ближайшей атомарной задаче по проекту нужно уделить особое внимание. Указанный принцип можно использовать не только в Trello, но и в Confluence и даже в Excel, заведя для каждого проекта отдельный лист и сформировав сводную таблицу со статусами работ при помощи формулы ДВССЫЛ. 2.11. Бизнес-аналитик и тестирование программного обеспечения Из предыдущих разделов мы узнали, что бизнес-аналитик может принимать участие в процессе тестирования ПО. Как правило, его участие заключается в содействии при подготовке сценариев тестирования. Это логично: бизнес-аналитик больше других участников проектной команды общается с бизнес-заказчиком и способен посмотреть на программный продукт глазами конечного пользователя. Именно так бизнес-аналитик помогает тестировщикам выявлять наиболее вероятные действия пользователя в системе, а также оценивать риски возникновения ошибок. Кроме того, понимая специфику работы заказчика, аналитик может выдвигать свои предложения относительно дизайна пользовательского интерфейса и изменения бизнес-логики системы. Но что делать, если в команде нет отдельного инженера по тестированию? Более того, как быть, если вся команда проекта состоит из разработчика, аналитика и руководителя проекта? В этом случае аналитику и разработчику придется поделить функцию тестирования между собой. На проект могут не назначить инженера по тестированию, если речь идет не о разработке «с нуля», а о настройке и (или) доработке стороннего коммерческого продукта, так на- зываемого коробочного решения, или «коробки». Сторонняя компания-разработчик уделяет много времени тестированию своего коробочного продукта, прежде чем выпустить его на рынок и предложить другим организациям. Кроме того, разработчики «коробки» ограничивают возможности других программистов в части ее настройки и доработки. Исходный код таких продуктов зачастую закрыт. Поэтому вероятность критических ошибок, спрятавшихся в глубине программного кода, у коммерческих продуктов ниже, чем у проектов, которые пишутся «с нуля». Тем не менее, даже при настройке процессов штатными средствами системы, без тестирования не обойтись. Типичный пример «коробки» – система электронного документооборота. Без преувеличения СЭД можно назвать кровеносной системой современной компании. Вместо кислорода и питательных веществ она разносит информацию, обеспечивающую жизнедеятельность организации: служебные записки, приказы, договоры и всевозможные заявки на получение внутренних сервисов. В качестве условного примера рассмотрим, как в СЭД реализован процесс оформления командировок. Ключевых действующих лиц в этом процессе трое: 1. Инициатор. Сотрудник, собирающийся в командировку. 2. Руководитель инициатора. Начальник группы или отдела, который должен «дать добро» на отъезд своего сотрудника. 3. Офис-менеджер. Специалист, обеспечивающий оформление командировки. Вкратце суть процесса такова. Инициатор заходит в систему и создает заявку на командировку. Заполненную заявку он направляет на согласование руководителю. Если всё в порядке – руководитель ставит положительную резолюцию в системе, и заявка отправляется офис-менеджеру. Офис-менеджер проверяет и исполняет ее: оформляет приказ на командировку, на основе которого начислят командировочные; покупает билеты, бронирует гостиницу и т. д. После отправки инициатору всех необходимых документов офис-менеджер закрывает заявку как исполненную. Конечно, и руководитель инициатора, и офис-менеджер, каждый на своем этапе, имеют право вернуть инициатору заявку на доработку. Кроме того, в организации могут быть сотрудники, для которых командировка – стандартная часть рабочего процесса. В этом случае постоянно согласовывать командировки с руководителем не требуется. Таким сотрудникам присваиваются особые права в системе: их заявки сразу же поступают на исполнение офис-менеджеру. В нашем условном примере мы исходим из того, что на этапе обследования бизнес-аналитик подготовил ряд ар- тефактов: карту бизнес-процесса, атрибутный состав заявки, описание пользовательских сценариев и диаграмму состояний (статусов). На основе этих документов разработчик и создал прототип, который нам необходимо протестировать. Особый интерес для нас представляет диаграмма состояний, она же диаграмма статусов. Данная диаграмма описывает жизненный цикл заявки в системе. Иными словами: какие статусы принимает заявка, в каком порядке и при каких условиях (см. рис. 21). В прямоугольниках указаны статусы, которые может принимать заявка. Стрелки обозначают последовательность присвоения статусов и условия, при которых происходит смена статуса. В построении диаграммы состояний бизнес-аналитику очень помогает карта бизнес-процесса. Рисунок 21. Условный пример диаграммы состояний По сути, работа пользователей в системе сводится к тому, чтобы провести заявку по статусам в определенной последовательности и выполнить соответствующие этим статусам действия. Бизнес-аналитик не обладает глубокими техническими познаниями и не заглядывает вглубь системы. Он не работает с кодом и редко соприкасается с базами данных и архитектурными вопросами. Поэтому участие бизнес-аналитика в тестировании сводится к тому, чтобы поработать с прототипом в роли конечного пользователя и оценить, сможет ли заказчик решить свою бизнес-задачу при помощи системы. Диаграмма состояний – очень полезный инструмент для того, чтобы сделать подобное пользовательское тестирование более упорядоченным и осмысленным. Ведь нам предстоит совершать действия, обеспечивающие переход из одного статуса в другой. Базовые тестовые сценарии можно отмечать непосредственно на диаграмме или фиксировать в отдельной таблице (см. рис. 22, 23, 24). Рисунок 22. Сценарий 1. Инициатор создал заявку, но закрыл ее без сохранения Рисунок 23. Сценарий 2. Руководитель согласовал заявку, а офис-менеджер не согласовал Рисунок 24. Сценарий 3. Привилегированный сотрудник отправил заявку напрямую офис-менеджеру Важно охватить все возможные варианты, потому что ошибки порой возникают в самых неожиданных местах. Например, при особой комбинации статусов: в одной последовательности шагов всё будет в порядке, а в другой возникнет критический баг. Глядя на диаграмму состояний, выявлять ключевые сценарии и цепочки статусов проще: меньше вероятность пропустить тот или иной статус и комбинацию действий. Конечно, для такого тестирования бизнес-аналитику понадобятся четыре учетные записи в системе: 1. Инициатор стандартный. Учетная запись для выполнения основных действий пользователя. 2. Инициатор привилегированный. Учетная запись для проверки сценариев с отсутствием обязательного согласования заявки руководителем. 3. Руководитель инициатора. Для согласования заявок или отправки их на доработку. 4. Офис-менеджер. Для исполнения заявок или их отправки на доработку. Можно еще немного углубиться и протестировать не только законченные сценарии из 3–5 статусов, доводящих заявку до некоего логического завершения, но и все возможные пары статусов. Таким образом мы проверяем исключительно корректность перехода из статуса «Новая» в статус «Согласование руководителем» или из статуса «На исполнении» в статус «На доработку». В этом формате мы можем перейти на следующий уровень тестирования. Допустим, вы выделили все возможные пары статусов и убедились, что переход по ним осуществляется корректно. Значит ли это, что за качество продукта можно быть спокойным? А вот и нет! Самое время задаться вопросом: позволяет ли система совершить действия, которые не предусмотрены основными сценариями? Например, у нас не предполагается переход из статуса «Новая» в статус «На исполнении» для инициатора со стандартными правами. А вдруг система позволяет так сделать? Если да – это баг! Все допустимые пары статусов определяются на основании той же диаграммы состояний. Для этого нужно найти все стрелки, которые выходят из интересующего вас статуса, и записать, куда они ведут. Кстати, таким образом вы можете обнаружить, что в системе нет какой-либо пары статусов, которая нужна заказчику (см. рис. 25). Рисунок 25. Пример чек-листа для всех допустимых пар статусов в Excel Помимо описанных выше способов проверки системы, бизнес-аналитик может провести простейшее тестирование пользовательского интерфейса. Например, попытаться заполнить поле «Телефон» буквами или спецсимволами. Или оставить обязательные поля незаполненными и попробовать отправить заявку на согласование и т. п. Если чтото подобное удалось – это баг. В общем, на этапе простейшего тестирования интерфейса бизнес-аналитик примеряет на себя роль неадекватного пользователя и старается устроить в системе хаос и разрушения! Итак, подведем промежуточный итог. Основные формы тестирования для бизнес-аналитика таковы: 1. Тестирование ключевых пользовательских сценариев, в том числе с разными комбинациями заполнения полей. Например, в одном случае оформляется заявка с просьбой приобрести авиабилеты, а в другом активи- руется атрибут, подтверждающий, что билеты инициатор купит сам. Ориентиром для бизнес-аналитика на этом этапе служит диаграмма состояний, а кроме того, ему могут сильно пригодиться пользовательские сценарии (use cases), которые он написал на этапе обследования. 2. Тестирование всех возможных пар статусов. Для определения всех возможных пар статусов также используется диаграмма состояний. 3. Попытки выйти за пределы изначально установленной бизнес-логики системы. Например, перевести заявку из статуса «Оформлена» в статус «На доработку». Как видно по диаграмме состояний, такой возможности быть не должно. 4. Режим «неадекватного пользователя». В этом режиме мы пишем буквы в полях для цифр, не заполняем обязательные атрибуты и всячески нарушаем правила. Важно понимать, что пользовательское тестирование со стороны бизнес-аналитика не обеспечивает того же уровня качества продукта, который возможен при участии профессионального тестировщика. Бизнес-аналитик может выявить баг, но вряд ли укажет на его причину. Если проблема в методе обращения к базе данных, то в нашем примере это способен определить только разработчик. Тем не менее тестирование на стороне бизнес-аналитика – это своеобразный гигиенический минимум. Без такого те- стирования нет никакого смысла демонстрировать заказчику прототип: кого интересуют системы, которые не отрабатывают даже базовые сценарии? Описанный выше подход к базовому пользовательскому тестированию можно применять к любой системе, предполагающей обработку заявок и имеющей статусную модель: BPM22, ECM23, CRM и т. д. Помимо шлифовки бизнес-логики системы, пользовательское тестирование на стороне бизнес-аналитика поможет: • выявить недостатки в оформлении интерфейсов; • получить пользовательский опыт и оценить, насколько удобно пользоваться системой; • ответить на вопрос, решает ли система задачи бизнес-заказчика. Результатом тестирования на стороне бизнес-аналитика могут быть в том числе и пожелания по размещению и оформлению элементов интерфейса. В завершение раздела – пара слов о тест-кейсах. Если предполагается, что бизнес-аналитик будет проводить несколько итераций пользовательского тестирования, все основные сценарии лучше записать. Это позволит лишний раз не придумывать и не вспоминать сценарии тестиро22 23 Business Process Management – управление бизнес-процессами. Enterprise Content Management – управление корпоративным контентом. вания. Также аналитику необходимо быть готовым к тому, чтобы четко и последовательно расписать разработчику порядок действий, приводящих к ошибке. По этой теме рекомендую прочитать книгу Романа Савина «Тестирование dot com». В ней описаны основы основ тестирования ПО, в том числе оформление тест-кейсов и баг-репортов. 2.12. Принятие решений в бизнес-анализе В начале книги мы поговорили о том, что одна из задач бизнес-анализа – содействие в принятии обоснованных управленческих решений. Какое же решение можно считать обоснованным? Осмысленное, то есть подкрепленное фактами, логическими доводами и экспертными оценками. Для принятия такого решения важно учитывать потребности заинтересованных сторон и смотреть на вопрос с разных точек зрения. Участие бизнес-аналитика особенно полезно тогда, когда компания встает перед выбором из нескольких альтернативных вариантов. В подобной ситуации аналитик собирает и анализирует всю информацию, имеющую отношение к вопросу, и предлагает способы ее обстоятельной оценки. Удобный инструмент для решения подобных задач – матрица принятия решений (не путать с таблицей принятия решений – методом тест-дизайна). Этот инструмент также называют «матрицей оценки проектов». Она очень удобна, когда требуется систематизировать информацию о нескольких альтернативных вариантах и дать им оценку. Рассмотрим использование данного инструмента на примере. Представим себе крупную организацию – банк, промыш- ленное предприятие или ИТ-компанию. В организации запущен проект, цель которого – оптимизация и автоматизация определенного направления деятельности. Для этого руководство компании намерено приобрести готовый коробочный продукт – информационную систему, заточенную под решение конкретных задач. Это может быть что угодно: платформа для электронного документооборота, CRMсистема или корпоративный портал для сотрудников. Вне зависимости от типа системы принцип работы с матрицей решений одинаков. Команда проекта (руководитель проекта, бизнес-аналитик, представитель заказчика и др.) изучает вопрос и приходит к выводу, что на рынке есть несколько конкурирующих ИТ-решений. Как же выбрать наиболее подходящее компании? В рамках проекта бизнес-аналитик общается с заинтересованными сторонами и формулирует требования к будущей информационной системе: каким должен быть предполагаемый бизнес-процесс, кто и с какой информацией будет работать в системе и какие задачи решать. Подготовленные бизнес-аналитиком требования становятся основой для формирования списка критериев, при помощи которых будут оцениваться альтернативные варианты. В формировании перечня критериев принимают участие как представители бизнес-заказчика, так и специалисты из технических подразделений. Это важно, поскольку каж- дую сторону интересуют разные аспекты работы программного продукта. Итоговый список критериев может быть кратким, а может состоять из десятков пунктов. В нашем примере мы для краткости ограничимся только шестью. При необходимости каждый критерий можно декомпозировать на более мелкие составляющие. ПОМНИТЕ, ЧТО КОНЕЧНЫЙ СПИСОК КРИТЕРИЕВ ЗАВИСИТ ОТ СПЕЦИФИКИ ПРОЕКТА, ПОЗИЦИИ ЗАИНТЕРЕСОВАННЫХ СТОРОН И ВАШЕГО СОБСТВЕННОГО ПОНИМАНИЯ СИТУАЦИИ. Итак, нашими критериями будут: 1. Информация о компании – разработчике программного продукта. Как давно она на рынке? Какая у нее репутация? Какие проекты реализованы и для каких заказчиков? Каковы результаты? И т. д. 2. Подход к внедрению. Как организованы работы со стороны компании-разработчика? Какие мероприятия необходимо провести для успешного внедрения системы? Насколько четко компания-разработчик представляет себе план работ и необходимые условия для его выполнения? 3. Функциональные требования. Насколько функциональные возможности информационной системы, заявленные разработчиком, соответствуют потребностям бизнес-заказчика? Позволит ли внедрение этой системы решить задачи конечных пользователей без существенных доработок? 4. Нефункциональные требования. Условия функционирования информационной системы: производительность, надежность, масштабируемость, технические ограничения. В значительной степени оценки по данному критерию выставляют технические специалисты. 5. Информационная безопасность. Всё, что касается обеспечения целостности, конфиденциальности и доступности информации, обрабатываемой системой. К оценке по данному критерию привлекаются инженеры по информационной безопасности. 6. Стоимость владения. Финансовая сторона вопроса. Весьма важный пункт, который порою перевешивает все остальные. В соответствии с этим критерием оценивается стоимость лицензий на программное обеспечение и технической поддержки со стороны компании-разработчика, необходимость приобретения дополнительных серверных мощностей, а также найма новых сотрудников и т. д. и т. п. Информацию для выставления оценок по данным критериям бизнес-аналитик собирает из открытых источников в интернете, взаимодействуя с заинтересованными сторонами внутри компании, а также в ходе переговоров с представителями компании-разработчика. Каждый критерий обладает такой характеристикой, как важность, или вес. Обычно не все критерии равнознач- ны. Для одного проекта важнее будет стоимость владения, для другого – информационная безопасность и т. д. Поэтому каждому критерию необходимо присвоить вес, указывающий на его значимость относительно других. Вес можно представить в виде десятичной дроби. Сумма всех весов должна равняться 1, или, иными словами, 100 %. Расставим веса так, как считаем нужным, и построим таблицу следующего вида. Таблица 13. Критерии оценки и их вес Теперь расставим оценки. Для начала определимся со шкалой измерения. Для примера возьмем 100-балльную шкалу, где 100 – максимальная оценка по критерию, а 0 – минимальная. Выставим оценки на основе имеющейся у нас информации. Таблица 14. Расстановка оценок Обратите внимание: чем больше система соответствует критерию, тем выше у нее балл. Так, высокая оценка «Системы 2» по критерию «стоимость владения» означает, что она дешевле конкурентов. После того как оценки расставлены, приходит время подвести итоги. Добавим в нашу таблицу строку «Итого» и вы- числим необходимые значения. Для этого умножим оценку по каждому критерию на соответствующий вес и просуммируем получившиеся произведения. Это и будет наша итоговая оценка по каждой системе. На примере «Системы 1»: Оценка «Системы 1» = = 90×0,05 + 98×0,1 + 85×0,3 + 84×0,2 + 75×0,1 + 80×0,25 = = 84,1 балла. Таблица 15. Подведение итогов оценки Завершив расчеты, мы увидим, что оптимальным решением для нашего проекта будет выбор «Системы 2». Если по тем или иным причинам «Система 2» будет исключена из числа возможных вариантов, то приоритетным становится выбор «Системы 3». Конечно, итоговая оценка, на которую мы опираемся при выборе решения, полностью зависит от указанных критериев, их весов и оценок по каждому из них. Так, стоит лишь немного изменить вес критериев – и расклад сил между конкурирующими решениями изменится. Тем не менее использование матрицы – более системный и вдумчивый подход, нежели интуитивное принятие решений. При этом даже матрица не застрахует вас от влияния эмоций при выставлении оценок. Всегда есть субъективная составляющая в виде личных симпатий и антипатий, которая может сказаться на итоговых баллах. Следовательно, каждый, кто участвует в заполнении матрицы решений, должен быть готов ответить на вопросы вроде: 1. Почему были выбраны именно эти критерии? 2. Почему критериям были присвоены такие веса? Чем руководствовалась команда проекта, присвоив, допустим, требованиям по информационной безопасности меньший вес, чем функциональным требованиям? 3. Почему подход к внедрению от компании – разработчика «Системы 2» оценили выше, чем подход компании – разработчика «Системы 1»? И так далее. Понимание того, что впоследствии руководство может задать вам подобные вопросы, заставляет подходить к выставлению оценок более вдумчиво, взвешенно и без лишних эмоций. Полагаю, никому из команды проекта не хотелось бы в будущем получить обвинения в предвзятости. Оценки могут выставлять разные специалисты: представители заказчика, аналитики, инженеры технической поддержки и т. д. В этом случае аналитик собирает таблицы, заполненные всеми участниками, а затем вычисляет среднюю оценку по каждому критерию. Особое внимание следует обратить на разброс оценок. Если один специалист оценил систему по определенному критерию на 92 балла, а другой – на 87, это нормально. Но вот если один поставил 90 баллов, а другой лишь 72, – это однозначно повод для обсуждения. Необходимо понять причины столь существенного расхождения. Вполне возможно, либо первый специалист, либо второй не обладает какой-то важной информацией о системе и потому завысил или занизил свою оценку. При определении необходимого количества критериев для матрицы решений рекомендую руководствоваться принципом разумной достаточности. Их количество должно зависеть от степени критичности вопроса, а также времени, которым располагает команда проекта. Важно понимать, что каждый дополнительный критерий увеличивает трудозатраты на заполнение матрицы и последующую обработку данных. То же самое касается и участников оценки. Привлекайте к работе с матрицей только тех специалистов, которые максимально «в теме». Иными словами, тех, кто: • напрямую заинтересован в реализации проекта; • участвовал во встречах с компаниями-разработчиками; • принимал участие в подготовке и согласовании аналитических материалов; • обладает критически важными компетенциями для оценки ИТ-решения и проекта в целом. От оценки людей, поверхностно знакомых с вопросом, пользы немного. В заключение отмечу, что матрица решений подходит не только для работы. Раздумываете ли вы о переезде в другой город, крупной покупке или ином важном вопросе – матрица и здесь пригодится. Она поможет понять, какие аспекты того или иного вопроса для вас важны: что критично, а что не очень. Постарайтесь расставлять оценки честно и объективно: тогда матрица решений покажет, чего вы хотите на самом деле. И если полученный результат вам не понравится – это тоже ответ. Скорее всего, вы просто были не до конца откровенны с самим собой. Да, принимая важное решение, невозможно предусмотреть всё. Существует множество обстоятельств вне зоны вашего контроля. Тем не менее матрица решений, как и другие аналитические инструменты, будет вашим проводником. Она задаст наводящие вопросы, заставит задуматься и взглянуть на ситуацию с разных точек зрения. И как бы в дальнейшем ни сложилась ситуация, вы всегда сможете ответить себе и другим на вопрос «Чем я руководствовался, принимая такое решение?». А это уже немало. Глава 3 Начинающим бизнес-аналитикам 3.1. Где учиться на бизнес-аналитика? Если говорить о высшем образовании, наилучшую теоретическую базу для работы бизнес-аналитиком дает специальность «Бизнес-информатика». Бизнес-информатика изначально задумана для подготовки специалистов, которые ориентируются как в сфере бизнеса, так и в сфере информационных технологий. Такие предметы, как «Основы программирования» и «Проектирование информационных систем», дадут вам хорошее представление о специфике деятельности разработчика или системного аналитика. В то же время дисциплины вроде «Экономической оценки инвестиций» и «Анализа финансово-хозяйственной деятельности предприятия» помогут в будущем при работе с бизнес-подразделениями. Бизнес-информатику как специальность преподают и на экономических факультетах, и на факультетах ИТ. Может случиться так, что в вузах вашего города не преподают бизнес-информатику. В таком случае маркером для поиска подходящей специальности будет наличие в учебной программе предмета «Моделирование и анализ бизнес-процессов». Как мы обсудили ранее, навык моделирования бизнес-процессов – важнейший для бизнес-аналитика, хотя и не единственный. Так или иначе, при выборе чисто экономической специальности вам предстоит самостоятельное погружение в ИТ. И наоборот: если вы выберете ИТ-специальность, вам будет крайне полезно познакомиться с экономическими дисциплинами – хотя бы на базовом, теоретическом уровне. Сотни курсов и книг по экономике и ИТ к вашим услугам. Конечно, как и в любом деле, в бизнес-анализе главное – практика. Я встречал специалистов с образованием, далеким от бизнес-анализа: бухгалтерским, юридическим и даже аграрным. Это не мешало им грамотно описывать процессы и формулировать требования к программному обеспечению. Стоит отметить, что в отдельных случаях непрофильное образование бывает очень кстати. Например, мой первый руководитель прекрасно ориентировался в вопросах налогового учета. Ему не составляло никакого труда найти общий язык с соответствующими подразделениями и разобраться в специфике их работы. В моей практике люди с непрофильным образованием приходили в бизнес-анализ уже опытными, сложившимися специалистами. Им было проще адаптироваться. Если же вы только думаете о карьере в бизнес-аналитике, профильное образование будет для вас большим плюсом. 3.2. Десять советов начинающим бизнес-аналитикам СОВЕТ 1. НЕ СТЕСНЯЙТЕСЬ! Хороший аналитик любит задавать вопросы. Причем и себе, и другим. Его любимый вопрос – «А что если?». Начинающий аналитик часто стесняется о чем-то спрашивать, особенно вышестоящих руководителей. Ему кажется, что он может сморозить глупость и потерять авторитет в глазах коллег. Важно помнить, что правильно заданный вопрос экономит часы, а иногда и недели работы. Задача аналитика – докопаться до сути, разложить предметную область на «атомы», элементарные составные части. Поэтому задавать вопросы во время аналитической работы нужно обязательно. Некоторые вопросы придется задавать не по одному разу. К своему удивлению, вы обнаружите, что при этом получаете разные ответы. А значит, вы не зря спрашиваете повторно. И помните: даже самый глупый вопрос можно задать так, что он покажется понятным и обоснованным. Нужно лишь пояснить собеседнику, почему вы об этом спрашиваете: какая логическая нестыковка вас смущает или какой информации не хватает. Кроме того, почаще просите объяснить что- то на конкретном примере – так всегда понятнее. СОВЕТ 2. ЗАПИСЫВАЙТЕ! Крайне важно всё записывать во время деловых встреч и совещаний. Работа аналитика связана с разными предметными областями и большими объемами данных. Если информацию не фиксировать и не структурировать, со временем она смешается в голове или забудется. Без вариантов. Как ни странно, начинающий аналитик может стесняться вести записи. Ему кажется, что при этом он выглядит вчерашним студентом-«ботаником», старательно записывающим лекцию преподавателя. Если вас тоже гложут подобные опасения – отбросьте их. Поверьте: прилежно ведя записи, вы окажетесь в числе тех немногих, кто четко фиксирует тему обсуждения и достигнутые договоренности. И станете одним из редких людей, полностью ориентирующихся в истории вопроса и текущем статусе работ. Ваши коллеги это оценят. СОВЕТ 3. УТОЧНЯЙТЕ, ИЛИ «ЧТО ТАКОЕ НИИ ЧАВО?» НИИ ЧАВО – Научно-исследовательский институт чародейства и волшебства из повести братьев Стругацких «Поне- дельник начинается в субботу». НИИ ЧАВО – хороший пример непонятной аббревиатуры, которыми изобилует язык профессионалов в любой отрасли. Начав работу в организации, вы столкнетесь с десятками непонятных аббревиатур, терминов, а также со специфическим сленгом. Возвращаясь к совету 1: не стесняйтесь спрашивать, что означает тот или иной термин или аббревиатура. Если же вам всё-таки неловко спросить об этом на встрече, сделайте себе текстовую пометку, а потом погуглите. Или спросите у коллеги с глазу на глаз. Привычка уточнять непонятные моменты сэкономит вам в дальнейшем много времени и сил: вы быстрее вольетесь в работу. СОВЕТ 4. СИСТЕМАТИЗИРУЙТЕ ЭТО! Часто работа аналитика связана с нормативной и технической документацией: инструкциями, регламентами, техническими заданиями. Подобные документы приходится согласовывать со множеством разных подразделений, каждое из которых смотрит на вопрос по-своему. Если документ большой, в нем могут содержаться десятки замечаний. Чтобы не запутаться в них, ведите лист учета комментариев (ЛУК). Ведение ЛУКа требует терпения и последовательности, но оно того стоит. У вас перед глазами всегда будет общая картина работы над нормативным документом: что учтено, что требует внимания, что можно проигнорировать и т. д. Ну и, конечно, приятно ставить галочки в списке напротив устраненных замечаний. СОВЕТ 5. ДЕКОМПОЗИРУЙТЕ ЭТО! Винсент Ван Гог писал своему брату Тео: «…великое не создается порывом, а представляет собой цепь постепенно слагающихся малых дел». Новый проект может вызвать стресс и у опытного специалиста: таким огромным и неподъемным он кажется вначале. Настоящий слон! Лучшее, что можно сделать в подобной ситуации, – разделить его на множество элементарных действий, вплоть до телефонного звонка, встречи или сообщения по электронной почте. После того как список действий определен, остается только последовательно выполнять их – одно за другим. Иными словами, фокусироваться надо на небольших задачах, а не на глобальной цели. Со временем «слон» начнет уменьшаться в размерах и станет маленьким и симпатичным. СОВЕТ 6. ИСПОЛЬЗУЙТЕ ВИРТУАЛЬНУЮ КАНБАН-ДОСКУ ИЛИ ТАСК-МЕНЕДЖЕР Поскольку работа аналитика связана с разными предметными областями и большими объемами информации, удержать всё это в голове нереально. Сервисы типа Trello и Microsoft To Do помогут не нарушать сроки и всегда быть в курсе хода работ и достигнутых договоренностей. СОВЕТ 7. ПИШИ, СОКРАЩАЙ Работа аналитика напрямую связана с текстом: нормативная и техническая документация, протоколы встреч, деловая переписка и общение в мессенджерах. Поэтому умение хорошо писать – однозначный must have. Оно позволяет: • писать краткие и информативные тексты, помня об уважении к читателю; • использовать разные стили текста для разных случаев; • последовательно, структурированно излагать в переписке свои мысли или просьбу. По данной теме очень рекомендую книги Максима Ильяхова и Людмилы Сарычевой «Пиши, сокращай» и «Новые правила деловой переписки» 24. Это книги не только о работе с текстом, но об отношении к работе как таковой. СОВЕТ 8. ИЗУЧАЙТЕ СМЕЖНЫЕ ОБЛАСТИ Аналитику приходится находить общий язык со всеми: бизнес-подразделениями, ИТ-специалистами, дизайнерами и т. д. Единственный способ говорить с ними на одном языке – расширять кругозор. Чем он шире, тем проще работать. Не нужно становиться гуру во всех указанных областях. Но специфику разных направлений понимать важно. Поэтому бизнес-литература и специализированные сайты придутся как нельзя кстати. СОВЕТ 9. МЕНТАЛЬНЫЙ ИММУНИТЕТ В книге «Чему учил Будда»25 Рахула Валпола отмечал важность понятия «осознанность» в восточной философии и буддизме. Концепция осознанности нашла отклик в бизнес-сообществе в начале XXI века. Практиковать осознанность означает: • умение находиться исключительно в настоящем момен24 См.: Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст. – М.: Альпина Паблишер, 2020; Ильяхов М., Сарычева Л. Новые правила деловой переписки. – М.: Альпина Паблишер, 2018. 25 Валпола Р. Чему учил Будда. – М.: Махасангха, 1999. те; • умение контролировать свои мысли, эмоции и поступки; • умение замечать всё, что происходит вокруг; • умение полностью отдаваться текущему занятию, не отвлекаясь на посторонние мысли и заботы. Иными словами, достигать состояния глубокого сосредоточения, как у художника при работе над картиной. Китайцы говорят: «Моешь чашку – думай о чашке». Практика осознанности развивает способность разума к концентрации и анализу. Умение сосредоточиться, контролировать мысли и эмоции даже в самой стрессовой ситуации – незаменимо в любой работе. По этой теме рекомендую «Книгу радости»: запись беседы двух лауреатов Нобелевской премии мира – Далай-ламы XIV и архиепископа Десмонда Туту. Совместно с писателем Дугласом Абрамсом они обсудили вопросы психологической устойчивости с точки зрения религии, философии и современной науки26. СОВЕТ 10. ТРЕНИРУЙТЕ ВОСПРИЯТИЕ НА СЛУХ Значительную часть информации, с которой приходится 26 Далай-лама XIV, Десмонд Туту, Дуглас Абрамс. Книга радости. Как быть счастливым в меняющемся мире. – М.: Манн, Иванов и Фербер, 2018. работать бизнес-аналитику, ему сообщают в устном виде. Такую информацию еще предстоит зафиксировать и разложить по полочкам, прежде чем приступать к анализу. Вот почему для аналитика очень важен навык восприятия на слух. Необходимо уметь слушать и слышать собеседника, направлять его рассказ в нужной вам логической и хронологической последовательности, вовремя задавать уточняющие вопросы. Развивать слуховое восприятие поможет прослушивание подкастов, аудиокниг и передач на разговорных радиостанциях. Оно научит вас не терять нить повествования, фиксировать важную информацию и отбрасывать ненужное. БОНУСНЫЙ СОВЕТ. ПРЕДЛАГАЙТЕ ВАРИАНТЫ Главная обязанность бизнес-заказчика в ИТ-проекте – принимать решения. Их ему приходится принимать множество: по бизнес-процессам, функциональным требованиям, дизайну, разграничению прав доступа и т. д. Конечно, это очень непросто. И задача аналитика – по возможности помочь заказчику в принятии решений. Для этого аналитик может предложить несколько вариантов, обозначить преимущества и недостатки каждого из них и описать возможные последствия. Поверьте, заказчик будет вам очень благодарен за сбор и структурирование информации по какому-либо сложному вопросу. Возможно, он не выберет ни один из предложенных вами вариантов, а предложит свой. И это тоже хороший результат для аналитика: ведь благодаря изучению различных альтернатив заказчик всё-таки смог сформулировать свою потребность. Может случиться и так, что предложенный вами вариант не приходил в голову ни одному из представителей заказчика. Возможно, они даже не смели и мечтать о функции, которая на самом деле вполне осуществима. Не ждите, когда перед заказчиком встанет сложная задача и он задаст вам вопрос о вариантах ее решения и возможных последствиях. Готовьтесь к этому заранее, до очередной точки контакта с заказчиком. Подобный вопрос, требующий оценки всех «за» и «против», обязательно возникнет. 3.3. Гибкие навыки бизнес-аналитика В этой книге я не раз говорил о разнообразии направлений аналитической работы. В зависимости от предмета анализа различаются цели, инструменты, а также необходимые навыки. Однако помимо профильных профессиональных навыков существуют и так называемые soft skills. Данным словосочетанием обозначают неспециализированные навыки, необходимые для продуктивной работы, но не связанные с конкретной предметной областью. В этом разделе мы поговорим о том, какие soft skills необходимы аналитику вне зависимости от профиля его работы. СИСТЕМНОЕ МЫШЛЕНИЕ И ЛОГИКА В аналитической работе большое внимание уделяется причинно-следственному контексту при работе с информацией. Одни и те же данные в зависимости от контекста могут приводить к совершенно противоположным выводам. Аналитику важно владеть базовыми логическими приемами, такими как анализ и синтез, сравнение и обобщение, абстрагирование. Ему важно понимать, из каких предпосылок он исходит в своих суждениях, и проверять их корректность. Изучите основы логики как науки о правильном мыш- лении. Возможно, ничего нового вы для себя не откроете. Но целостное понимание приемов логического мышления и причинно-следственных связей пригодится в любой работе. Рекомендую любой учебник по логике для вузов 27 или, например, «Логику» Виноградова и Кузьмина. Их легко найти в интернете в электронном виде и даже в аудиоварианте. ГРАМОТНАЯ УСТНАЯ И ПИСЬМЕННАЯ РЕЧЬ Профессия аналитика связана с постоянной коммуникацией и работой с текстом. Поэтому он обязательно должен уметь грамотно и четко формулировать свои мысли. Это справедливо как для устной коммуникации, так и для письменной: в переписке, при оформлении технической документации и т. п. ВНИМАНИЕ К ДЕТАЛЯМ И МЕТОДИЧНОСТЬ Как вы уже узнали, аналитику приходится работать с большими объемами информации. Кроме того, результатом аналитической работы становятся рекомендации для руковод27 См., например: Хоменко И. В. Логика. Теория и практика аргументации. Учебник и практикум. – М.: Юрайт, 2019. ства компании или заказчика относительно того, какое решение им принять. А потому важно, чтобы результаты анализа были проверенными и обоснованными. Возьмите за правило поговорку саперов: «Профессионал не терпит суеты». Суета – худший враг не только сапера, но и аналитика. У ошибки, допущенной по невнимательности, порой могут быть далеко идущие последствия. Не торопитесь – и между «быстро» и «качественно» всегда выбирайте второе. Какой смысл от быстро сделанной работы, если она привела к неверным выводам? Единственный способ избежать непредвиденных ошибок – работать методично и последовательно. ИСТОРИЯ О ВНИМАТЕЛЬНОСТИ К ДЕТАЛЯМ Пятидесятые годы XX века, США. Президентские выборы. Газеты печатаются долго. Чтобы первыми сообщить о том, кто стал новым президентом, сотрудники одного издания обзвонили тысячи граждан с единственным вопросом: за кого они проголосовали. По результатам опроса подготовили и на первой полосе напечатали статью «Победил кандидат X!» до объявления итогов выборов. Когда же стали известны официальные результаты, журналисты испытали шок: победил кандидат Y! Почему же так вышло? Всё дело в нерепрезентативной выборке. Несмотря на то что при звонках учитывались пол, возраст, штат и множество других параметров, один существенный фактор оказался упущен: газетчики звонили своим респондентам. Иными словами, в выборку попали только те избиратели, у которых был домашний телефон. Для 1950-х годов это довольно существенное отклонение. Вывод один: внимание к деталям превыше всего. НАВЫКИ ОБЩЕНИЯ И ПОВЕСТВОВАНИЯ. ВЕЖЛИВОСТЬ Аналитику важно уметь находить общий язык со специалистами разных направлений: от бизнеса до ИТ, от бухгалтерии до службы безопасности. Но если они, в свою очередь, не принимают во внимание результатов аналитики и не используют их в работе – любой анализ теряет всякий смысл. Поэтому умение рассказать интересную и связную историю будет весьма кстати. И, конечно, в любом взаимодействии важно сохранять конструктивный и вежливый настрой и не поддаваться на провокации. ДИСЦИПЛИНА И ТАЙМ-МЕНЕДЖМЕНТ Постепенно проектов и задач, требующих вашего участия, будет становиться всё больше. Держать в голове десят- ки задач и хронологию работы над ними – нереально. Поэтому важно аккуратно вести дела: методично фиксировать информацию и договоренности, своевременно выполнять задачи и заранее информировать коллег, если возникает необходимость переноса сроков. ЗДОРОВЫЙ СКЕПТИЦИЗМ Как я уже упоминал ранее, аналитику полезно проявлять здоровый скептицизм: перепроверять результаты своей работы, не стесняться уточнять непонятные детали, не принимать на веру даже самое авторитетное мнение. Иногда один вовремя заданный вопрос может существенно повлиять на дальнейший ход работ. УВЕРЕННОСТЬ В СЕБЕ Мало провести анализ – нужно еще и аргументированно защитить итоговые выводы перед руководством. Для особо важных презентаций не помешает предварительная репетиция с участием коллег. Их взгляд со стороны придется очень кстати. Попросите во время репетиции задавать вам каверзные вопросы и уточнять все непонятные моменты. К моменту выступления вы будете чувствовать себя увереннее и сможете четко ответить на поставленные вопро- сы. МЕНТАЛЬНЫЙ ИММУНИТЕТ И ОСОЗНАННОСТЬ Аналитик много общается с людьми и обрабатывает большие объемы данных. Поэтому умение сосредоточиться, контролировать мысли и эмоции, оценить последствия каждого действия даже в самой стрессовой ситуации пригодится любому аналитику. ТЕРПЕНИЕ Иной раз для достижения итогового результата придется проявить недюжинное терпение. Поступают новые вводные, и вот вам необходимо начинать анализ заново: пересчитывать показатели, уточнять детали процессов, запрашивать дополнительные сведения. Подобные обстоятельства часто находятся вне вашего контроля, поэтому без терпения в таких случаях не обойтись. Глубокий вдох – и начинаем сначала. ПРАГМАТИЗМ И ДЕЛОВОЙ ПОДХОД Помните, что цель анализа – принять на основе данных благоприятное для бизнеса решение. В конечном счете цель любого бизнеса состоит в получении прибыли. Поэтому, проводя анализ, важно концентрироваться на тех вопросах, которые позволят улучшить показатели работы компании: увеличить доходы, сократить затраты, оптимизировать процессы. СТРЕМЛЕНИЕ УЧИТЬСЯ Хороший аналитик любит учиться и узнавать новое. Это помогает ему найти общий язык с представителями разных профессий и легче ориентироваться в новой предметной области. Для пополнения знаний годится всё – курсы, книги, статьи, подкасты, обучающие ролики на YouTube, общение с интересными людьми. Выдающийся авиаконструктор Андрей Николаевич Туполев говорил: «Информация – мать интуиции». Действительно, профессиональная интуиция – это прежде всего сплав знаний и опыта, а не врожденная способность человека. Чем более обширными, глубокими и систематизированными знаниями вы обладаете, тем проще вашему мозгу искать решение, а также выявлять скрытые взаимосвязи и закономерности в процессах заказчика. Со временем ваш опыт и багаж знаний неизбежно будут расти. Но темпы этого роста во многом зависят от вас. 3.4. Психологический настрой бизнес-аналитика Бизнес-аналитик очень много коммуницирует. Это логично, ведь он выступает посредником между заказчиком и ИТразработкой. Проекты по внедрению ИТ-решений или оптимизации процессов начинаются со сбора информации о предметной области заказчика, а потому на ранних стадиях проекта аналитик взаимодействует с ним больше, чем кто бы то ни было. Во многом от качества работы аналитика зависит общее впечатление о компании-подрядчике и отношение заказчика к продолжению сотрудничества. Именно поэтому при взаимодействии с заказчиком важен определенный психологический настрой, состоящий из ряда установок. О них и пойдет речь в настоящей главе. УСТАНОВКА 1. СТРЕМЛЕНИЕ ПОМОЧЬ, ИЛИ ДЕЛОВОЕ СОЧУВСТВИЕ Если вдуматься, сакральный смысл любой работы – борьба с несовершенством мира. В качестве примера такого несовершенства можно привести любой процесс заказчика, требующий оптимизации. Для него подобный процесс – источник стресса и дополнительных трудозатрат. Поэтому при выстраивании коммуникаций с заказчиком ключевой психологической установкой аналитика должно быть искреннее стремление помочь. Сочувствие – ключевой навык межличностных отношений. «Деловое сочувствие» – это уважение к времени заказчика, поиск вариантов решения задачи и организованный подход к работе. Как правило, оптимизации требуют сложные, трудоемкие направления. В основе делового сочувствия лежит желание помочь заказчику разобраться со сложным, неэффективным процессом. К тому же работы по оптимизации часто связаны для него с дополнительной нагрузкой. Ведь никто на время проекта не отменяет основные обязанности участников процесса. Всё то время, пока реализуется проект, сотрудники должны будут по старинке выполнять свою работу. Это потребует от них значительных усилий, а тут еще вы со своими вопросами о том, как устроена их работа. Очень важно с самого начала донести до заказчика мысль о том, что сбор информации о предметной области необходим вам не для проформы, а для того, чтобы разобраться с проблемой. Деловое сочувствие вовсе не означает, что надо гладить заказчика по голове, приговаривая: «Бедненький, как же ты намучился». Сочувствие должно быть деятельным. В зарубежной бизнес-литературе вместо слова «сочувствие» чаще используют «сострадание» и приводят следую- щий пример. Вы идете по горной дороге и видите человека, которого придавила каменная глыба. Проявить сочувствие – значит пожалеть человека, попавшего в сложную ситуацию. Сострадание же состоит в том, чтобы попытаться убрать камень. Такой подход к работе оправдан и для вас лично. Когда вам удается помочь другому решить сложную проблему, вы испытываете самое приятное и мотивирующее чувство, какое только можно получить от работы. Иногда заказчик воспринимает общение с аналитиком как своеобразный экзамен на знание собственной предметной области. Естественно, в таком случае он напрягается, что отнюдь не способствует продуктивному общению. Деловое сочувствие позволяет заказчику перейти из режима «экзамен» или «переговоры с оппонентом» в режим «мы на одной стороне». Он расслабляется, если видит ваше искреннее желание помочь ему решить задачу. Благодаря этому отношение к вашей работе может измениться у него с «вы кто такие, я вас не звал» на «вы же не оставите нас разбираться с этим в одиночку?». УСТАНОВКА 2. УСЕРДИЕ И СТРЕМЛЕНИЕ РАЗОБРАТЬСЯ Главная задача аналитика – разобраться в том, как устроены процессы в организации. Конечно, становиться гуру в сфере деятельности заказчика совсем не обязательно, но понимание базовых принципов, логики и причин, по которым выполняется то или иное действие, очень важно. Даже если вы искренне стремитесь помочь, отдельные представители заказчика не всегда будут с вами заодно. Самая распространенная причина – вашу работу воспринимают как угрозу собственному положению. Нельзя, однако, сказать, что во всех случаях подобные опасения беспочвенны. Да, внедряемая вами система может существенно упростить работу множеству людей. Но по итогам внедрения руководство компании-заказчика может решить, что на данном направлении теперь не требуется такого количества сотрудников. Обычно работодатель стремится сохранить кадры и перераспределяет сотрудников по другим направлениям, менее подверженным автоматизации и требующим более творческого подхода. Увы, бывает и так, что работников просто сокращают, а потому отдельные представители заказчика могут быть заранее настроены против вас. Вообще, выявление заинтересованных сторон и работа с ними – обширный раздел дисциплины «Бизнес-анализ». Аналитику нужно четко понимать, как все участники относятся к проекту: кто «за», а кто «против»; кто в явной оппозиции, а кто – в скрытой; кто на словах «за всё хорошее», а по факту либо ничего не делает, либо вставляет палки в колеса. У кого мотивация – достижение бизнес-результата, а у кого – получение «звездочки на погон». Все эти нюансы и сопутствующие риски аналитик должен учитывать в своей работе. Большинство людей, с которыми вам предстоит общаться, либо очень заняты, либо стремятся создать впечатление таковых. Это значит, что они не уделят вам много времени. Кроме того, по тем или иным причинам представители заказчика могут и не захотеть делиться с вами информацией. Готовьтесь к встречам заблаговременно и заранее определяйте круг интересующих вас вопросов. Предварительная подготовка всегда себя оправдывает. Помимо помощи в структурировании встречи, она продемонстрирует заказчику: вы знаете, что делаете и чего хотите. Подобная собранность вызывает уважение. Во время встречи важно быть организованным и вести записи. Если представитель заказчика настроен против вас – не давайте сбить себя с толку. Вам могут давать туманные ответы или пытаться перевести разговор на другую тему. Возможно, в ответ на свои вопросы вы услышите фразу типа «Мы ведь вам всё уже рассказали». Под этим представитель заказчика может понимать какую-то обтекаемую формулировку, в которой для вас нет решительно никакого смысла. Если вы понимаете, что вопрос не закрыт, и записи это подтверждают, – настаивайте на подробном обсуждении деталей до тех пор, пока процесс не станет понятен или вы не получите прямой отказ отвечать на вопрос. С таким отказом можно разобраться позднее, на более высоком уровне. УСТАНОВКА 3. СПОКОЙСТВИЕ, КОРРЕКТНОСТЬ, САМОУВАЖЕНИЕ Иногда у представителей заказчика бывают довольно своеобразные представления об этике общения. Не имеет никакого смысла закрывать глаза на некорректное обращение, пассивную агрессию и иные признаки токсичного поведения. В конце концов, границы адекватного для большинства людей одинаковы, да и правила делового этикета никто не отменял. А потому, если заказчик переходит эти границы, нужно вежливо возвращать его обратно. Копировать же в таком случае его манеру общения – плохая идея. Токсичное поведение заказчика может касаться как вас лично, так и вашей работы. И если вы считаете его упреки несправедливыми – не нужно молчать. Когда вы сами не уважаете себя и результаты своего труда – не стоит ждать хорошего отношения и от заказчика. Если же замечания справедливы и высказаны в корректной форме – имейте мужество признать их и устранить. Достаточно фразы «Принимается, исправим». Такой подход вызывает уважение. И это лучше, чем изворачиваться и придумывать оправдания. Подводя итоги, отмечу: самая большая похвала, которую аналитик может услышать от заказчика, – «с вами приятно иметь дело». 3.5. От чего зависит успех бизнес-анализа Существует семь ключевых факторов, от которых зависит успех бизнес-анализа. ФАКТОР 1. ОПЫТ АНАЛИТИКА Самый очевидный фактор. Как и в любом деле, вероятность успешного выполнения задачи выше, если ее решает опытный специалист. По мере накопления практического опыта аналитические задачи будут отнимать у вас всё меньше времени, а общее качество работы вырастет. Главное здесь – усердие, внимательность и отсутствие суеты. В этом случае рост неизбежен. ФАКТОР 2. УРОВЕНЬ ЗНАНИЙ В ПРЕДМЕТНОЙ ОБЛАСТИ, АНАЛИЗ КОТОРОЙ ПРОВОДИТСЯ Часто в бизнес-анализ приходят люди из других отраслей: банковской, промышленной, ИТ и т. д. Так или иначе, проекты, для которых проводится бизнес-анализ, не существуют в вакууме – они неизбежно соприкасаются с той или иной сферой деятельности. И если у бизнес-аналитика есть опыт работы в нужной области – это существенный плюс. Например, внедряется новый программный продукт кредитования физических лиц. Если бизнес-аналитик раньше работал в банке, то найти общий язык с заказчиком и продемонстрировать ему свое понимание специфики будет намного проще. Почему бизнес-аналитику столь важен опыт работы в других сферах деятельности? Всё потому, что со знаниями о предметной области аналитику проще выстроить коммуникацию и выявить скрытые, глубинные требования к ИТ-решению. В чем же заключаются такие знания? 1. Знание особенностей ведения бизнеса или производства. Имея за плечами опыт работы в крупном банке, промышленной компании или на заводе, вы лучше осознаёте специфику конкретной предметной области. Вам не требуется много времени, чтобы понять, как в аналогичной компании выстроены процессы, в чем суть и ценность проводимых работ, какие проблемы возникают чаще всего. 2. Знание организационной структуры. Названия подразделений в разных компаниях могут раз- личаться, но суть выполняемых ими задач будет для отрасли плюс-минус стандартной. Это значит, что, поработав в том или ином бизнес-подразделении, вы с высокой долей вероятности начнете понимать, с кем подразделение взаимодействует, какие задачи перед собой ставит, какие интересы преследует. Это справедливо и для «политических» нюансов. С опытом работы в бизнесе или на производстве легче понять «внутреннюю кухню» заказчика: кто и каким влиянием обладает, кто с кем дружит и против кого, и т. д. Всё это может иметь существенное значение для проекта, который вы реализуете. 3. Знание используемых программных продуктов. Допустим, вы на практике работали с конкретным ИТ-решением: бухгалтерской программой или системой подготовки отчетности. В этом случае найти общий язык со специалистом, которого чем-то не устраивает текущее решение, для вас не составит никакого труда. С высокой долей вероятности вы и сами уже сталкивались с проблемами, которые возникли у заказчика. 4. Знание используемых технологий, стандартов и методологий. Если вы работали в банковской сфере, то знаете, насколько она зарегулирована. Центральный Банк Российской Федерации ежегодно выпускает и актуализирует сотни доку- ментов, в соответствии с которыми обязаны работать банки по всей стране. Нарушение требований ЦБ РФ грозит им серьезными штрафами, вплоть до отзыва лицензии и прекращения существования. Поэтому умение читать нормативную документацию, ориентироваться в ней и правильно трактовать будет весьма ценным в банковском ИТ-проекте. Это же справедливо и для любой другой сферы деятельности: стандарты, нормативы, технологии есть везде, и их важно учитывать, чтобы бизнес заказчика не нажил себе проблем. Приведу литературный пример. У американского писателя О. Генри есть замечательный рассказ «Родственные души». В начале 1960-х в экранизации этого рассказа снялись Юрий Никулин и Ростислав Плятт. Фабула его такова. В особняк состоятельного гражданина проникает вор. Оценив обстановку, он поднимается на второй этаж, где находит хозяина дома спящим в постели. Тот просыпается, и вор, угрожая револьвером, требует поднять руки. Однако хозяин поднимает только одну руку – вторую из-за прихватившего плечо ревматизма он поднять не в состоянии. Тут прихватывает и самого вора – выясняется, что ревматизм у обоих. Позабыв о том, что один из них – жертва, а другой – преступник, случайные собратья по несчастью начинают увлеченно обсуждать в разной степени не помогающие обоим средства от ревматизма. В конце концов оба соглашаются, что наиболее действенное средство – это спиртное. Чувствуя в хозяине особняка родственную душу, жулик приглашает его в паб пропустить стаканчик-другой. Одевшись с помощью вора, хозяин у выхода вспоминает, что выложил все свои деньги на туалетный столик. «Бросьте это, – отвечает несостоявшийся вор. – Я вас приглашаю. На выпивку хватит. А вы никогда не пробовали „Чудодейственный орех“ и мазь из сосновых иголок?» Конечно, аналитик – не жулик, а заказчик – не жертва ограбления. Но объединивший их ревматизм – прекрасная метафора для проблемы, которая лежит в основе любого ИТпроекта. Из этого примера видно, насколько сильным может быть эмоциональный контакт между людьми со схожим жизненным опытом. Какой уровень доверия и взаимопонимания возникает между ними! Данный эффект проявляется в десятках ситуаций: люди – земляки и жили в одном городе, служили в одной воинской части, работали в одной организации и т. д. Поиск общего – важная часть психологии отношений. Аналитику, для которого коммуникации с людьми – основная часть работы, не стоит недооценивать силу подобного эффекта. Практический опыт в той или иной сфере бизнеса позволит вам не только быстрее разобраться в особенностях работы заказчика. Этот опыт поможет наладить с ним деловые и доверительные взаимоотношения, которые благоприятно скажутся на реализации всего ИТ-проекта. ФАКТОР 3. УРОВЕНЬ ПОНИМАНИЯ СВОИХ ПОТРЕБНОСТЕЙ ЗАИНТЕРЕСОВАННЫМИ ЛИЦАМИ На практике бизнес-заказчики бывают совершенно разными. Одни очень слабо представляют себе, каким образом процесс переходит из текущего состояния в целевое. Другие представляют себе этот путь отчетливо и ясно, вплоть до того, какие поля и кнопки необходимы в будущем ИТрешении и как должна работать система в целом. Понятно, что чем туманнее заказчик представляет себе переход из текущего состояния в целевое, тем большее участие требуется от бизнес-аналитика, чтобы сформировать это представление. Чем лучше заказчик понимает свои собственные потребности и пути их удовлетворения, тем быстрее и качественнее проходит этап бизнес-анализа. ФАКТОР 4. ОТНОШЕНИЕ ЗАИНТЕРЕСОВАННЫХ ЛИЦ К БИЗНЕСАНАЛИЗУ И ПРОЕКТУ В ЦЕЛОМ Работа с заинтересованными сторонами – одна из самых сложных и творческих сторон бизнес-анализа. Всё дело в том, что у каждого руководителя, вовлеченного в ИТ-про- ект, могут быть свои интересы. Один горит желанием немедленно преобразовать давно устаревшие процессы. Другой стремится за счет ИТ-проекта повысить значимость своего подразделения и отличиться перед руководством. Третий и вовсе внутренне сопротивляется, поскольку опасается, что его подразделение станет ненужным после внедрения ИТрешения, но при этом не может пойти против воли высшего руководства. Бизнес-аналитику приходится учитывать интересы каждой заинтересованной стороны. Наличие их исчерпывающего списка сильно помогает в работе, позволяя заручиться поддержкой одних, отработать возражения других, учесть интересы третьих и т. д. Особое значение в перечне заинтересованных лиц стоит уделить их иерархии, зонам ответственности и полномочиям. Благодаря этому руководитель проекта получит четкое понимание перспектив работы с заказчиком, что важно при выявлении и устранении рисков проекта. Как видите, бизнес-аналитик должен быть еще и неплохим психологом. ФАКТОР 5. КОЛИЧЕСТВО ВРЕМЕНИ, ВЫДЕЛЕННОЕ ЗАИНТЕРЕСОВАННЫМИ ЛИЦАМИ НА БИЗНЕС-АНАЛИЗ Фактор, который отчасти, но не всегда, зависит от личного отношения заинтересованного лица к ИТ-проекту. Начнем с того, что бизнес-анализ не проводится в вакууме. Анали- тику для работы всегда нужны источники информации: эксперты в предметной области, нормативная и техническая документация и т. д. Львиную долю необходимой информации аналитик обычно получает в процессе интервью. Оно редко длится менее часа – всегда необходимо обсудить общую структуру процессов, задать уточняющие вопросы, зафиксировать ответы. Для многих руководителей выделить целый час рабочего времени – настоящая роскошь. Конечно, если проект важен для руководителя, то он найдет в своем плотном графике время на общение с вами. Или, как минимум, сведет с нужными людьми, которые ответят на интересующие вас вопросы. Если же руководитель внутренне настроен против вас и проекта в целом – будьте готовы к максимально формальному подходу. Скорее всего, вас попросят оформить официальное письмо-запрос с перечнем интересующих документов и вопросов, а потом будут долго на них отвечать. Кроме того, из-за причин политического характера руководитель может быть против того, чтобы бизнес-аналитик напрямую общался с непосредственными исполнителями. Понятно, что для сбора необходимой информации такой формат коммуникации гораздо менее эффективен. Бывают и такие ситуации, когда нужный вам руководитель обеими руками за проект, но из-за слишком сильной занятости ему не удается уделить вам ни минуты. При этом он также не может поручить общение с вами и своему подчиненному, поскольку только сам владеет критическими знаниями о процессе. В этом случае вам не остается ничего другого, как ждать «окна» в расписании руководителя. Это также негативно сказывается на скорости и качестве бизнес-анализа. СОВЕТ Старайтесь назначать встречи для сбора информации о предметной области бизнес-заказчика на первую половину дня. Участникам подобных совещаний предстоит обсуждать множество разных вопросов, поэтому крайне желательно, чтобы никто не приходил утомленным текущими задачами. Встреча в первой половине дня повышает вероятность того, что обсуждение пройдет спокойно и конструктивно, и вам будет легче получить нужные сведения. Вторая причина назначать встречи до обеда состоит в том, что после нее вы можете «по горячим следам» набросать карту бизнес-процесса или оформить протокол совещания. Если же делать это спустя какое-то время, то даже при наличии заметок могут позабыться интересные или важные детали. ФАКТОР 6. ПРИМЕНЯЕМЫЕ В КОМПАНИИ ЗАКАЗЧИКА МЕТОДОЛОГИЯ БИЗНЕСАНАЛИЗА, ИНСТРУМЕНТЫ И НОРМЫ У крупных компаний бывают жесткие стандарты, по которым должен проводиться бизнес-анализ. Эти стандарты могут касаться, например, нотаций бизнес-моделирования или регулировать структуру и содержание проектной и технической документации. Кроме того, особые требования могут предъявляться к программному обеспечению, которое использует бизнес-аналитик. Если к проведению бизнес-анализа подобных требований со стороны заказчика нет, это позволяет вам сэкономить время и работать так, как привычно и удобно вам. При наличии у заказчика жестких требований необходимо закладывать время на приведение результатов вашей работы к принятым в компании стандартам. ФАКТОР 7. КОРПОРАТИВНАЯ КУЛЬТУРА ОРГАНИЗАЦИИ Корпоративная культура – это совокупность официальных и негласных моделей поведения сотрудников в рабочих процессах. Упрощенно все организации можно разбить на две категории. 1. В одних компаниях всё строго и официально: есть дресс-код, жесткий режим работы, регламенты на все случаи жизни. У них жесткая иерархия, близкая к военизированным подразделениям. Для получения доступа к необходимой информации необходимо писать официальные запросы и обоснования. 2. В других компаниях обстановка мягче: нет дресс-кода, плавающий режим дня, плоская структура, небольшое количество руководителей. Многие вопросы решаются по звонку или сообщением в мессенджере. Если вы работаете с организацией первого типа, будьте готовы к большему количеству циклов согласования результатов вашей работы. В жестко регламентированных компаниях не принято брать на себя единоличную ответственность, поэтому в согласовании карт процессов и документов могут принимать участие несколько подразделений. Сами согласования будут длиться до тех пор, пока всем участникам не станет ясно, что в случае положительной резолюции риски для них минимальны. В организациях второго типа количество циклов согласования меньше, поскольку выше вероятность встретить руководителя, отвечающего за проект целиком – «от и до». 3.6. Инструментарий бизнес-аналитика МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ Для создания карт бизнес-процессов существует множество программных продуктов с разным набором возможностей и в различных ценовых категориях. Приведем краткую характеристику некоторых из них. Microsoft Visio Самая распространенная программа для моделирования бизнес-процессов. Microsoft Visio представляет собой векторный графический редактор. На сегодня MS Visio – стандарт на рынке программных продуктов для создания всевозможных схем. В MS Visio вы можете создавать карты бизнес-процессов, схемы компьютерных сетей, планы помещений, прототипы экранных форм и т. д. MS Visio поддерживает все распространенные нотации бизнес-моделирования: классические блок-схемы, EPC, IDEF, BPMN. Не забыты и любимые системными аналитиками UML и ER-модели. Важное преимущество MS Visio перед другими графиче- скими редакторами – возможность превратить любой элемент схемы в ссылку, которая приведет на другую карту процесса в этом же документе или на сетевой ресурс. Важно, что ссылки будут работать, даже если вы конвертируете карту в PDF. Это серьезный плюс, когда у других участников проекта нет возможности просматривать файлы в формате Microsoft Visio (*.vsdx). MS Visio – лучший вариант для начинающих аналитиков. Кроме того, программа отличается очень удобным интерфейсом: видно, что над ним серьезно поработали. Удобство работы – важнейший критерий, особенно если вам предстоит сформировать большое количество схем за короткое время. Business Studio Это система бизнес-моделирования от российской компании «СТУ-Софт». Можно сказать, что Business Studio – «золотая середина» для организации, которая решила серьезно заняться моделированием и анализом бизнес-процессов, но не готова платить сотни тысяч долларов за программный продукт. Business Studio использует в качестве графической оболочки Microsoft Visio – без установки этой программы Business Studio просто не будет работать. Но это, скорее, преимущество. Во-первых, сохраняется удобный инструментарий для работы со схемами из MS Visio. Во-вторых, если аналитик ранее работал в MS Visio, то перейти на Business Studio ему будет проще. Ключевые отличия Business Studio от Microsoft Visio следующие. 1. Business Studio обеспечивает одновременную работу нескольких аналитиков в едином информационном пространстве. Это позволяет создать общий для всей организации перечень бизнес-процессов и параллельно работать над ним неограниченному количеству аналитиков. Если в вашей организации есть отдел аналитики, возможность параллельной работы специалистов в одной системе – существенное преимущество. 2. Business Studio имеет собственную базу данных, в которой хранятся результаты работы всех аналитиков, имеющих доступ к системе. Наличие единой базы данных позволяет легче выстраивать взаимосвязи между бизнес-процессами и поддерживать ссылочную целостность. В случае с MS Visio карты процессов хранятся у каждого аналитика на личном компьютере или, в лучшем случае, на общем сетевом диске. Файлы имеют свойство теряться, дублироваться или повреждаться. Если есть единая база данных, все карты хранятся в одном месте. Как следствие – аналитикам легче принять единый стандарт именования карт и их размещения в дереве процессов. 3. Business Studio позволяет выгружать регламенты бизнес-процессов, созданные на основе карт процессов. Это, на мой взгляд, одна из главных ее возможностей. Если вы построили карту процесса в соответствии с определенными правилами и корректно настроили шаблон документа, то система автоматически сформирует структурированный документ на основе карты процесса. Каждая функция превратится в отдельный пункт документа, где будут указаны исполнители функции, используемые документы, информационные системы, условия выполнения и ограничения. Если в организации существуют жесткие требования закреплять зоны ответственности текстовыми нормативными документами, работа в Business Studio может существенно сократить время на их подготовку. 4. Business Studio позволяет проводить функционально-стоимостный анализ процессов. Построив карту процесса и указав длительность выполнения каждой функции и вероятность перехода к тем или иным веткам бизнес-процесса, можно запустить так называемую имитацию. В ходе «имитации» система рассчитывает нагрузку сотрудников, задействованных в бизнес-процессе на заданном промежутке времени. Иными словами, можно оценить оптимальную численность сотрудников для выполнения определенного объема работ при текущей организации процесса. Это далеко не все функциональные возможности Business Studio. Я остановился лишь на тех возможностях, которые, на мой взгляд, наиболее применимы практически и отличают эту систему от классического графического редактора. Draw.IO и Bizagi Modeler Draw.IO и Bizagi Modeler – это свободно распространяемые программные продукты для моделирования бизнес-процессов. Если в вашем распоряжении нет Microsoft Visio или Business Studio, эти программы придутся очень кстати. При выборе программного продукта обратите внимание на то, что Bizagi Modeler ориентирован на моделирование процессов исключительно в нотации BPMN и обладает расширенным набором возможностей именно для нее. Draw.IO – инструмент более универсальный, по своим возможностям близкий к Microsoft Visio. ОФОРМЛЕНИЕ ДОКУМЕНТАЦИИ И ПРЕЗЕНТАЦИОННЫХ МАТЕРИАЛОВ Microsoft Word В текстовом редакторе MS Word бизнес-аналитик создает документацию по ИТ-проекту: формулирует требования к ИТ-решению, ведет аналитические записки, пишет инструкции для пользователей и т. д. Аналитику важно уметь создавать в Word структурированные документы с понятным именованием и нумерацией разделов, удобным оглавлением и ссылками. Документация должна быть аккуратно оформлена, поэтому уделите внимание: 1) выделению заголовков; 2) нумерации страниц; 3) подписям к иллюстрациям; 4) используемым шрифтам; 5) выравниванию текста. Ваша задача – сформировать документ, с которым будет удобно и приятно работать. Microsoft Excel MS Excel – основной инструмент аналитика для работы с таблицами и массивами данных. В Excel ведется матрица запросов на изменение, известная как «лист учета комментариев» (ЛУК). Также Excel используется для создания сравнительных таблиц и поиска закономерностей в данных. Основное его преимущество в том, что он содержит мощный инструментарий для фильтрации и обработки данных. СОВЕТ Не работайте с таблицами в Word, если только речь не идет о финальном оформлении документа. Во всех остальных случаях возьмите за правило: если нужно поработать с таблицами – используйте Excel. Microsoft Power Point MS Power Point – стандарт на рынке программных продуктов для подготовки презентаций. В главе о ключевых задачах аналитика мы говорили о том, насколько важно уметь грамотно представить результаты аналитической работы лицам, принимающим бизнес-решения. Поэтому умение работать с Power Point вам не раз пригодится. Особое внимание при оформлении презентаций уделите иллюстрациям. Удачно подобранная иконка или картинка могут сильно повлиять на впечатление от слайда и презентации в целом. Для поиска иконок и картинок подойдут бесплатные интернет-ресурсы типа FreePik и FlatIcon. УПРАВЛЕНИЕ ЗАДАЧАМИ И РАБОЧИМ ВРЕМЕНЕМ Trello Если вы параллельно работаете над множеством задач, вам пригодится инструмент, который поможет держать дела в порядке и получать общее представление о происходящем в проекте. Таким инструментом для вас может стать онлайн-сервис Trello. По сути, Trello представляет собой виртуальную версию канбан-доски. Канбан – метод управления задачами, придуманный инженерами компании Toyota. Главный принцип – выполнение задач точно в срок благодаря равномерному распределению нагрузки между работниками. Канбан-доска представляет собой инструмент для визуализации рабочего процесса. Самая простая доска состоит из трех колонок (слева направо): 1. Нужно сделать (to do). 2. В работе (in progress). 3. Сделано (done). В классической версии канбан-доски каждая задача – это стикер. При старте крупного проекта все задачи размещаются в колонке to do. Затем члены команды выбирают себе по одной и приступают к работе. По мере выполнения какой-либо задачи стикер переклеивается из одной колонки в другую. Периодически команда проекта собирается у доски и обсуждает прогресс – выполнение имеющихся задач и постановку новых. Если команда видит, что какая-то задача не выполняется слишком долго, ее члены обсуждают ва- рианты исправления ситуации. Главное преимущество метода канбан – визуализация рабочего процесса. Взглянув на доску, легко получить представление о ходе всего проекта и понять, какие задачи выполнены в срок, а какие выбились из графика. Благодаря этому руководитель проекта может принять своевременные меры. Принципы канбан-доски: • визуализация рабочего процесса; • ограничение количества задач, которые находятся в процессе выполнения; • перемещение задач от колонки к колонке; • мониторинг задач, оптимизация нагрузки на сотрудников. Trello позволяет заменить реальные доски и стикеры на виртуальные. Это означает, что вы и ваши коллеги в любой момент можете получить доступ к своей доске. При наличии интернета, конечно. В Trello удобный инструментарий для поиска и фильтрации задач, установки и контроля сроков, ведения чек-листов. Сервис удобен как для самостоятельной, так и для командной работы. Microsoft To Do Приложение для ведения списков дел. Реализованы эти списки максимально просто – в виде чек-листов. Одна задача – одна строка. Сделав дело, вы нажимаете галочку, и оно исчезает из списка. Для каждой задачи можно установить сроки и контролировать их, добавлять заметки и составлять списки подзадач. To Do незаменима для мелких рабочих дел. Например, для напоминания о небольших задачах, до которых у вас никак не доходят руки из-за основного проекта. Бизнес-аналитик постоянно общается со всеми членами проектной команды. Часто к нему обращаются с разными мелкими просьбами. Например, руководитель проекта, столкнувшись с аналитиком в коридоре, просит прислать последнюю версию документации. В повседневной суете легко забыть о такой просьбе. Через минуту вас кто-то чем-то отвлек – и всё, вы уже и думать забыли о предыдущем разговоре. Для того чтобы не упускать из виду подобных мелких задач, лучше записывать их в To Do сразу, как только они появились. Тогда, вернувшись к работе, вы просто откроете список дел и начнете последовательно их выполнять. Подобная привычка поможет вам всегда соблюдать достигнутые договоренности, а это очень важно для поддержания здоровой деловой атмосферы в команде проекта. 3.7. Собеседование Как правило, ваше трудоустройство в компанию на должность бизнес-аналитика зависит от двух людей: HR-менеджера и руководителя подразделения бизнес-анализа – группы, отдела или департамента. Задача HR-менеджера – отобрать для руководителя подразделения наиболее подходящих кандидатов. С этой целью он изучает резюме соискателей и проводит с ними очные либо онлайн-встречи. Собеседования с HR обычно носят общий характер и не затрагивают ваших компетенций в области бизнес-анализа. Кадровик оценивает ваши коммуникативные навыки, опыт предыдущей работы и желание работать в компании. Примеры общих вопросов от HR-менеджера: • Почему вы выбрали свою специальность в университете? Что вас в ней привлекает? • Как вы представляете себе работу бизнес-аналитика? • Что вас мотивирует? Чем хотелось бы заниматься на работе, а чем нет? • Что вы считаете своими достоинствами? А что недостатками? • Расскажите о допущенной вами ошибке. Как вы ее исправили? • Приходилось ли вам выступать перед большой аудито- рией? • Сталкивались ли вы с конфликтными ситуациями? Как вы из них выходили? С кем вам было бы трудно выстроить деловые отношения? • Как вы повышаете свой профессиональный уровень? И так далее. Если вы претендуете на рядовую позицию junior, он же «джун» (не путать со «ждуном»), – очевидно, что профессионального опыта в области бизнес-анализа у вас немного или нет совсем. Поэтому важно продемонстрировать HR-менеджеру ваше стремление к профессиональному развитию. Например, будьте готовы к вопросу о том, какой была последняя прочитанная вами деловая книга и какие выводы вы из нее сделали. Большим плюсом для HR-менеджера будет наличие в вашем резюме пункта о прохождении профильных курсов, тренингов или семинаров. Потратьте время и пройдите пару онлайн-курсов по бизнес-анализу и смежным областям: банковской, ИТ или любой другой, в зависимости от профиля компании, в которую вы стремитесь попасть. Важно понимать, что HR-менеджера больше интересует не то, что вы узнали из того или иного курса, а то, что вы в принципе «горите» профессией и стремитесь развиваться как специалист. Один из лучших онлайн-курсов по бизнес-анализу, который мне встречался, – это «RPA Business Analysis Fundamentals»28 от компании UiPath. Курс посвящен задачам бизнес-аналитика в сфере роботизации процессов. Отличная новость в том, что компания перевела его на русский язык. В свое время я изучал материалы, вооружившись онлайн-переводчиком. За прохождение курса выдается сертификат, что может прибавить вам уверенности при общении с потенциальным работодателем. Кроме того, на собеседовании важно продемонстрировать свои знания о компании, в которую вы устраиваетесь. Изучите ее официальный сайт и почитайте последние новости. Если вы четко ответите, почему выбрали именно эту компанию, а не какую-то другую, это станет плюсом. Вариант ответа «я ищу всё, что есть» не годится. Руководителя подразделения и вашего потенциального начальника будут уже интересовать ваши профессиональные знания и навыки. Будьте готовы к вопросам о том, с какими нотациями бизнес-моделирования и программными продуктами вы знакомы. Если вы откликаетесь на вакансию, размещенную на сайте компании или в специализированном сервисе по поиску работы, то с вероятностью 99 % требования к кандидату писал сам руководитель подразделения. Поэтому текст вакансии даст вам хорошее представление о том, что хотел бы видеть в потенциальном сотруднике непосредственный руководитель бизнес-аналитиков. 28 См.: RPA Business academy.uipath.com/). Analysis Fundamentals от UiPath (https:// Если у вас нет практического опыта по тому или иному пункту вакансии, говорите об этом прямо, не забывая добавить, что очень хотели бы научиться новому. Смысла казаться опытнее, чем вы есть на самом деле, немного – это сразу заметят и сделают невыгодные для вас выводы. Общаясь с кандидатами на позицию junior, большинство руководителей с пониманием относятся к отсутствию опыта. Потенциальный начальник смотрит на вашу адекватность, образ мышления, умение конструктивно и доброжелательно общаться с людьми. Бизнес-аналитику приходится много коммуницировать, и у кандидата, с трудом формулирующего мысли, шансов совсем немного. Иногда кандидаты уводят разговор в сторону, чтобы отвлечь внимание от недостатка опыта и выставить себя в лучшем свете. – Вы когда-нибудь описывали бизнес-процессы? – Нет, но в университете / на прошлом месте работы я… И далее следует пространный рассказ об опыте, не имеющем к бизнес-анализу никакого отношения. Так делать не надо. Подобным поведением вы вызовете только раздражение, ведь бизнес-анализ стремится к ясности и однозначности. Если вам задают четкий вопрос, то и ответ ожидают услышать такой же четкий. Кроме того, отвечая не по теме, вы тратите чужое время – отнеситесь к нему с уважением. Крайне желательно знать стадии типового ИТ-проекта (мы рассматривали их выше), а также виды требований и разницу между ними. Типичный вопрос на собеседовании: «Чем отличаются функциональные требования от нефункциональных?» Хотя бы в общих чертах вы должны представлять ключевые роли в проектной команде: чем занимаются руководитель проекта, бизнес-аналитик, разработчик, тестировщик, ИТ-архитектор и т. д. Для этого рекомендую изучить описание ИТ-профессий на сайте «БудуГуру» или посмотреть несколько выпусков на YouTube-канале «IT-борода». Несколько слов о тестовых заданиях. Если вам предлагают тестовое задание – соглашайтесь. Аналитика не та сфера деятельности, в которой работодатель решает свои рабочие задачи, подсовывая их кандидатам под видом тестовых. Опытному аналитику проще выполнить задачу самому, чем разбираться с плодами трудов кандидатов на вакансию. Наиболее вероятными заданиями будут моделирование бизнес-процессов на основе текстового фрагмента либо формулирование требований к абстрактному ИТ-решению вроде системы учета заказов в швейной мастерской. Если в задании не указаны конкретные требования к оформлению, вы можете уточнить предпочтительную нотацию бизнес-моделирования или стандарт оформления требований. Это продемонстрирует работодателю ваш сознательный подход к решению задачи. Не забывайте, что собеседование – процесс обоюдный. Задавайте вопросы о том, в каких нотациях моделируют про- цессы в компании, какие программы используются, как организован рабочий процесс. Этим вы продемонстрируете потенциальному работодателю понимание специфики работы и свою заинтересованность в ней. Не лишним будет и поинтересоваться условиями труда: режимом работы, расположением офиса, форматом рабочего пространства – кабинет это или openspace, а также наличием командировок и т. д. По итогам встречи вы должны понять, в каких условиях предстоит работать в случае положительного ответа. Не расстраивайтесь, если вас не взяли на работу после первого же собеседования. Это нормально: решение о приеме нового сотрудника зависит от множества обстоятельств, и не на все из них вы способны повлиять. Продолжайте поиск и свое профессиональное развитие. Всё получится. Фиксируйте все вопросы, которые вызывали у вас затруднение на собеседованиях, и находите на них ответы. Получив отказ, не стесняйтесь спросить о том, какие знания и навыки вам следует подтянуть, – так вы лучше поймете потребности работодателя и наметите направления развития. С каждым собеседованием вы будете чувствовать себя всё увереннее – и шансы получить работу будут расти. Не воспринимайте собеседование как экзамен, поскольку его главная цель – понять, что вы за человек, можно ли с вами работать и ориентируетесь ли вы в профессии. В свою очередь, ваша задача – понять, хотели бы вы работать в этой компании и с этими людьми. Практические же навыки – де- ло наживное, это вам скажет любой опытный специалист. Как создавалась эта книга. Вместо заключения Материалы я собирал около двух лет. Изначально цели написать книгу о бизнес-анализе, собственно, и не было. Я просто писал статьи о разных аспектах аналитической работы и публиковал их в личном блоге. Количество статей постепенно росло. Посещая курсы и лекции опытных аналитиков, я получал полезную информацию и пищу для размышлений. Позже преподаватели Казанского федерального университета пригласили меня прочитать студентам лекцию о профессии бизнес-аналитика. Готовясь к ней, я начал упорядочивать свои знания о бизнес-анализе. Хотелось дать студентам максимум полезной информации за ограниченное время. Это был первый шаг. Следующим шагом к написанию книги стало предложение руководителей компании, в которой я работал, создать и возглавить группу бизнес-анализа. Возник вопрос о поиске кандидатов. Со временем мы поняли, что быстро найти опытных бизнес-аналитиков на рынке труда непросто: слишком велик спрос. Альтернативным вариантом было приглашение на работу специалистов из смежных отраслей или вчерашних студентов, в которых можно вырастить нужные компетенции. Так мы в итоге и поступили. Новых сотрудников требовалось обучить: рассказать им о задачах группы, зонах ответственности и используемых инструментах. Так появился внутренний учебный курс, который и лег в основу данной книги. Целью курса было постепенное погружение новичков в работу. Мы были очень заинтересованы в том, чтобы ребята освоились быстро, без лишнего стресса, и приступили к решению рабочих задач. Наконец стало ясно, что материалов курса и статей в блоге достаточно для создания книги. Несколько месяцев упорной работы над текстом – и вот она перед вами. Прочитав книгу, вы спросите – а что же дальше? А дальше вас ждет практика бизнес-анализа: интервью, совещания, описание бизнес-процессов и постановка требований. На овладение ключевыми навыками профессии потребуется несколько лет. Двух одинаковых компаний не бывает, поэтому ваш опыт бизнес-аналитика в любом случае будет уникальным. Запаситесь терпением на этом пути. Не всегда работа будет идти гладко, а результат окажется востребованным. Это нормально. В конце концов, множество факторов, влияющих на успех проекта, находится вне зоны вашего контроля, а значит, ваша задача – сделать всё от вас зависящее для достижения итогового результата и посмотреть, что же из этого получится. Работая бизнес-аналитиком, вы серьезно расширите свой кругозор, познакомитесь с интересными людьми и всегда бу- дете в центре событий. Всё потому, что бизнес-аналитик – один из главных проводников изменений в любой компании. И конечная цель таких изменений – сделать мир лучше. А ради этого стоит постараться. Удачи! Приложение Материалы для изучения: книги, подкасты, YouTube-каналы Книги 1. Андерсон К. Аналитическая культура. – М.: Манн, Иванов и Фербер, 2017. 2. Вигерс К., Битти Д. Разработка требований к программному обеспечению. – СПб.: БХВ, 2021. 3. Гейтс Б. Бизнес со скоростью мысли. – М.: Эксмо, 2007. 4. Далай-лама XIV, Десмонд Туту, Дуглас Абрамс. Книга радости. Как быть счастливым в меняющемся мире. – М.: Манн, Иванов и Фербер, 2018. 5. Зараменских Е. П. Основы бизнес-информатики: монография. Новосибирск: Издательство ЦРНС, 2014. 6. Ильяхов М., Сарычева Л. Новые правила деловой переписки. – М.: Альпина Паблишер, 2018. 7. Ильяхов М., Сарычева Л. Пиши, сокращай. Как создавать сильный текст. – М.: Альпина Паблишер, 2020. 8. Ковалёв С., Ковалёв В. Настольная книга аналитика. Практическое руководство по проектированию бизнес-про- цессов и организационной структуры. – М.: 1С-Паблишинг, 2021. 9. Репин В. Бизнес-процессы. Моделирование, внедрение, управление. – М.: Манн, Иванов и Фербер, 2012. 10. Роулинг С. Я хочу больше идей. Более 100 практик и упражнений для развития творческого мышления. – М.: Манн, Иванов и Фербер, 2018. 11. Савин Р. Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах. – М.: Дело, 2007. 12. Хоменко И. В. Логика. Теория и практика аргументации. Учебник и практикум. – М.: Юрайт, 2019. Подкасты и YouTube-каналы 1. Войти в IT. 2. Запуск завтра. 3. IT-борода. 4. АйТи-Самурай. Стандарты 1. Профессиональный стандарт «Бизнес-аналитик» Министерства труда и социальной защиты Российской Федерации 08.036. 2. Профессиональный стандарт «Системный аналитик» Министерства труда и социальной защиты Российской Федерации 06.022. 3. ГОСТ 34: комплект стандартов на автоматизированные системы. 4. ГОСТ 19: единая система программной документации. 5. Business analysis body of knowledge (BABOK – Руководство к своду знаний по бизнес-анализу). Благодарности Я хотел бы поблагодарить всех, кто сделал свой вклад в мое профессиональное становление: преподавателей, коллег, родственников и друзей. Без ваших знаний, опыта и поддержки этой книги бы не было. Спасибо! Особую благодарность выражаю: Денису Горюнкову Айдару Гузаирову Ирине Урысовой Булату Гузаирову Азату Садриеву Тимуру Кушареву Максуду Маруфи Ксении Халиловой Анастасии Андриановой Владиславу Исмагилову Ольге Пинягиной Денису Бескову Ренарду Фатхутдинову Алине Мироновой Ольге Гарифуллиной Неле Ярахановой
