Текст книги "Профессия «бизнес-аналитик». Краткое пособие для начинающих"

1.4. Еще раз о размытости границ

Разобраться во всех хитросплетениях профессии аналитика непросто. Анализировать можно всё что угодно, отсюда и многообразие видов аналитики. Кроме того, каждый по-своему называет специалистов-аналитиков, исходя из собственного понимания стоящих перед ними задач.

Вот и получается, что специалист на должности бизнес-аналитика в разных организациях может заниматься совершенно разными задачами. Один – настройкой информационной системы заказчика. Другой – анализом финансовых показателей, планов развития компании и ключевых показателей эффективности деятельности. Третий – моделированием и анализом бизнес-процессов, а также разработкой требований. И у всех в трудовой книжке будет написано «бизнес-аналитик».

На бизнес-анализ можно смотреть с двух наиболее распространенных точек зрения – информационно-технологической и финансовой.

С точки зрения ИТ бизнес-аналитик занимается изучением предметной области заказчика, описывает бизнес-процессы и формирует требования к ИТ-решениям. Данной позиции я и придерживаюсь. Подробнее эти вопросы раскрыты в главе 2.

С финансовой точки зрения бизнес-аналитик занимается оценкой состояния бизнеса и его способностью исполнять обязательства. Помимо этого, аналитик определяет факторы, сильнее всего влияющие на финансовый результат. На мой взгляд, решение таких задач корректнее называть финансовым анализом.

Кроме того, зоны ответственности специалистов по аналитике сильно зависят от принятых в организации подходов к работе. Бывает, что системный аналитик берет на себя часть функций бизнес-аналитика, а бизнес-аналитик активно участвует в разработке интерфейсов информационных систем.

Я хотел бы, чтобы моя книга помогла закрепить в сознании читателя роль бизнес-аналитика как посредника между миром бизнеса и миром информационных технологий. Бизнес-аналитик для меня – переводчик с языка бизнеса на язык ИТ и обратно. За счет этого он и выполняет главную задачу бизнес-анализа – способствует переходу организации из текущего состояния в целевое при помощи ИТ-решения.

Глава 2
Практика бизнес-анализа. От описания процессов до постановки требований

2.1. Роль бизнес-анализа в современной организации

В данной главе мы поговорим о том, что представляет собой профессия «бизнес-аналитик». Вы узнаете, какие задачи решают эти специалисты и в чем ценность их участия в ИТ-проектах. Но начнем мы с обсуждения роли бизнес-анализа в работе современной организации.

Условно деятельность любой организации можно разбить на три блока: «Финансы», «Развитие» и «Клиенты». Каждому блоку соответствуют свои ключевые задачи, а также виды аналитики, помогающие в их решении.

Как видно из рисунка 2, бизнес-анализ относится к блоку «Развитие». Это логично, ведь его ключевая задача – обеспечить переход организации из текущего состояния в целевое.

Рисунок 2. Блоки и задачи разных видов аналитики

Обратите внимание, что бизнес-анализ используется при решении двух классов задач: «Оптимизация процессов» и «Внедрение новых технологий». Здесь важно отметить, что с течением времени понимание роли бизнес-аналитика в организации существенно расширилось. Раньше его воспринимали исключительно как специалиста по моделированию и анализу бизнес-процессов. Иными словами, задача бизнес-анализа заключалась по большей части в описании текущего и определении структуры целевого, «идеального» бизнес-процесса. Еще 10–15 лет назад трансформация бизнес-процессов могла не иметь никакого отношения к технологиям: просто изменялись зоны ответственности, порядок выполнения действий, вводились контрольные процедуры и т. д. При этом технологическая платформа бизнес-процессов практически не менялась.

Однако с течением времени развитие технологий привело к тому, что любой проект по совершенствованию работы организации стал включать в себя ИТ-составляющую. Для решения поставленных задач бизнес-аналитикам приходилось всё больше работать бок о бок с техническими специалистами: системными аналитиками, разработчиками, инженерами по тестированию, что потребовало от бизнес-аналитиков расширения компетенций в области информационных технологий. В связи с этим бизнес-аналитика начали воспринимать как посредника между миром бизнеса и миром ИТ. С тех пор как любой проект по оптимизации процессов стал связан с ИТ, организациям срочно потребовались специалисты, способные найти общий язык со всеми заинтересованными сторонами.

Так бизнес-аналитик стал своеобразным «универсальным солдатом», который в своей работе общается со всеми – начиная с ИТ-инженеров и бизнес-заказчиков и заканчивая высшим руководством компании. На мой взгляд, это один из ключевых плюсов данной профессии. С течением времени специалист по бизнес-анализу становится экспертом с широким кругозором, развитыми коммуникативными навыками и экспертизой по самым разным вопросам. Конечно, глубина этой экспертизы не сравнится с компетенциями узкопрофильных специалистов. Но это обстоятельство компенсируется широтой взглядов. У опытного бизнес-аналитика множество вариантов продолжения карьеры в зависимости от личных предпочтений. Проработав в компании несколько лет, он начинает понимать внутреннюю кухню ИТ-разработки, тестирования, управления проектами и процесса продаж. Обладая подобными знаниями, а также налаженными связями, бизнес-аналитик с большей легкостью, чем специалисты извне, развивается в смежных областях.

Что же такое ИТ-проект? Классический ИТ-проект – это комплекс взаимосвязанных мероприятий по разработке и (или) внедрению информационной системы для бизнес-заказчика. Напомню: цель ИТ-проекта – обеспечить переход компании из текущего состояния в целевое путем автоматизации и оптимизации процессов. Инструментом для автоматизации и оптимизации в данном случае выступает информационная система. Как и у любого другого, у ИТ-проекта есть план мероприятий с ограниченными сроками, бюджетом и трудовыми ресурсами.

Приведу пример. Практически в любом крупном банке найдутся десятки бизнес-процессов, которые можно улучшить: сделать прозрачными, эффективными, уменьшить количество ручных операций. Даже в крупных банках встречаются отделы, большая часть рабочего времени которых уходит на перенос данных вручную из одной системы в другую. Причина этого в отсутствии информационного обмена между разными банковскими системами. Конечно, процесс процессу рознь – некоторые из них имеют десятки нюансов или слишком дороги для автоматизации. В этом случае банку проще содержать целый отдел для выполнения рутинных работ, нежели внедрять ИТ-решение. Однако возможна частичная автоматизация таких процессов, которая если и не заменит человека полностью, то сильно облегчит его работу. Кроме того, в любой крупной организации существуют процессы, обладающие всеми признаками, говорящими о том, что их можно полностью автоматизировать, а именно:

● работа выполняется вручную;

● работа повторяется изо дня в день;

● выполняемые процессы линейные: работа выполняется шаг за шагом, нет сложной, разветвленной логики принятия решения;

● наборы полей, откуда нужно брать данные и куда переносить, – известны.

Так или иначе, любой ИТ-проект, в котором участвует бизнес-аналитик, посвящен автоматизации, систематизации и оптимизации какой-либо деятельности. Цель бизнес-аналитика – понять, в чем проблема текущих процессов и каковы варианты их усовершенствования.

Теперь важно сказать несколько слов о понятии «заказчик» или «бизнес-заказчик».

При реализации любого ИТ-проекта возникает система взаимоотношений «заказчик – исполнитель».

Зона ответственности заказчика:

1. Доступным языком рассказать о своей предметной области и бизнес-процессах: чем занимается подразделение, какие задачи решает, какие цели перед собой ставит, кто и за какие участки работ отвечает.

2. Объяснить аналитику, каковы ключевые сложности, с которыми сталкивается заказчик в текущих бизнес-процессах.

Исполнитель же, в свою очередь, отвечает за создание ИТ-решения, призванного устранить проблемы в бизнес-процессах заказчика. Главное, о чем стоит помнить при делении специалистов на «заказчиков» и «исполнителей»: заказчик говорит на языке бизнеса, исполнитель – на языке ИТ.

Бизнес-аналитик может быть как представителем заказчика, так и представителем исполнителя. Как же такое возможно? Рассмотрим варианты взаимоотношений заказчика и исполнителя в ИТ-проекте.

Вариант 1: и заказчик и исполнитель – сотрудники одной организации. Для примера возьмем уже полюбившийся нам крупный банк. В нем существует Департамент розничного бизнеса (ДРБ), отвечающий за работу с физическими лицами. Предположим, ДРБ хочет оптимизировать свои процессы – и для этого ему необходимо ИТ-решение. Если банк крупный и обладает достаточными техническими компетенциями, то ДРБ совершенно не обязательно обращаться к внешней ИТ-компании для разработки необходимого решения. Вместо этого ДРБ обращается в Департамент информационных технологий (ДИТ) в своем же банке, и специалисты ДИТ реализуют необходимую бизнесу доработку в рамках текущей деятельности.

В данном случае ДРБ – заказчик, а ДИТ – исполнитель. Но кто же из них формулирует требования к ИТ-решению, без которых не обойтись в процессе разработки? Бизнес-аналитик, ответственный за разработку требований, может быть как сотрудником ДРБ, так и сотрудником ДИТ. Как правило, в первом случае аналитик больше специализируется на процессах розничного бизнеса, а во втором – на технических моментах. Кроме того, в банке может существовать отдельный Департамент аналитики, не входящий в состав ДРБ и ДИТ. В этом случае заказчик обращается в Департамент аналитики за содействием в реализации ИТ-проекта. Как правило, здесь работают универсальные специалисты, обладающие знаниями в области бизнеса и ИТ, но не специализирующиеся на чем-то конкретном.

Вариант 2: заказчик и исполнитель – представители разных организаций. Если у того же банка недостаточно компетенций или ресурсов для самостоятельной разработки требуемого ИТ-решения, то многие компании на рынке готовы предложить ему свои услуги. В этом случае ДРБ обращается к представителям той или иной ИТ-компании и объясняет, как они хотели бы оптимизировать свои процессы. Банк даже может провести тендер, чтобы выбрать исполнителей, предлагающих наилучшие условия. Но, с тендером или без, заказчику необходимо подготовить четкие требования к будущему ИТ-решению. И здесь, опять же, возможны два варианта работы бизнес-аналитика.

1. Бизнес-аналитик – сотрудник банка из ДРБ, ДИТ или Департамента аналитики. В этом случае он проводит исследование предметной области подразделения-заказчика (возможно, своего собственного) и готовит требования к будущему ИТ-решению. В эти требования включаются карты бизнес-процессов, таблицы, диаграммы – всё, что может пригодиться системным аналитикам и разработчикам при знакомстве с предметной областью заказчика. Требования становятся частью технического задания, которое затем отправляется на оценку в ИТ-компании. На основании их ответов о сроках и стоимости проекта банк выбирает исполнителя. Кроме того, в дальнейшем требования используются при разработке самого ИТ-решения. При таком сценарии анализ предметной области и подготовка требований не создают банку дополнительных затрат, так как выполняются его же сотрудниками, получающими зарплату.

2. Бизнес-аналитик – сотрудник ИТ-компании. В этом случае исследование предметной области заказчика проводится внешним по отношению к банку специалистом. Это исследование может проводиться как до заключения официального договора между заказчиком и исполнителем, так и после старта проекта. Всё зависит от достигнутых договоренностей. Так или иначе, результатом работы аналитика становятся те же требования к ИТ-решению: карты процессов, диаграммы, таблицы и т. д. На основе сформулированных требований ИТ-компания оценивает сроки и стоимость работ, а также организует процесс разработки и (или) настройки ИТ-решения.

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

Переходя к обсуждению ключевых задач бизнес-аналитика, важно помнить: в основе любого ИТ-проекта лежит некая проблема. Не будь проблемы, у заказчика не было бы и повода обращаться к исполнителю для создания или доработки ИТ-решения. Чтобы устранить данную проблему, ее для начала нужно сформулировать. Казалось бы, очевидно: как решать задачу, которой не понимаешь? Парадоксально, но многие команды именно так и поступают, особенно на ранних стадиях работы над проектом. Естественно, это сказывается на итоговых результатах и порой приводит к необходимости переделывать всю работу. Следовательно, одна из ключевых задач аналитика – минимизировать вероятность подобной ситуации за счет скрупулезного фиксирования информации по проекту и стремления не оставить ни одного вопроса без ответа. Подробнее об этом – в следующей главе.

2.2. Ключевые задачи бизнес-аналитика

Итак, какие же основные задачи решает бизнес-аналитик? Всего их девять (см. рис. 3).

Рисунок 3. Ключевые задачи бизнес-аналитика

Рассмотрим подробнее каждую из них.

МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ AS IS И TO BE

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

Создание карт бизнес-процессов – удобный и наглядный инструмент для описания текущей работы заказчика и его представлений о целевом процессе.

С точки зрения моделирования бизнес-процессов бизнес-аналитик всегда находится в двух плоскостях: «as is» («как есть») и «to be» («как должно быть»).

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

«Бутылочное горлышко» – это узкое место в процессе: функция или набор функций с низкой пропускной способностью. Русская пословица гласит: «Где тонко, там и рвется». В случае же с бизнес-процессами можно сказать: «Где узко – там потеря времени и денег».

Рассмотрим «бутылочное горлышко» на примере. Представим себе банк с разветвленной филиальной сетью из десятков офисов. В каждом офисе менеджеры обслуживают клиентов и принимают заявки на выдачу кредитов. Каждую заявку менеджер заводит в информационную систему и отправляет на проверку в центральный офис, где их обрабатывает кредитный аналитик. Допустим, у аналитика нет удобных инструментов для выяснения всех деталей заявки: кредитной истории клиента, оценки рисков и т. д. Из-за этого он тратит уйму времени на проверку. Представьте себе, что в день ему поступают десятки кредитных заявок, но скорость предоставления клиенту ответа о выдаче кредита полностью зависит от скорости работы кредитного аналитика. При этом удобных инструментов для работы у него нет. Неважно, насколько быстро и качественно клиента обслужили в офисе, – это практически не влияет на скорость получения ответа. В данном случае все ждут кредитного аналитика.

Таким образом, функция кредитного анализа становится в процессе тем самым «бутылочным горлышком», из-за которого резко снижается уровень клиентского обслуживания. Если у аналитика имеется на руках карта бизнес-процесса «как есть», ему гораздо проще выявлять подобные проблемы. Их можно выделять на карте процесса и обсуждать на встречах с заказчиком.

Вторая плоскость описания процессов – «как должно быть». При создании карт процессов этого типа бизнес-аналитик предлагает заказчику представить идеальный в его понимании целевой процесс. Карта этого процесса должна отвечать на вопрос о том, как будет организована деятельность заказчика с учетом необходимых изменений, в том числе с учетом внедрения новой информационной системы.

Например, если карта «как есть» описывает сложный, бюрократизированный бизнес-процесс с обилием ручных операций, то карта «как должно быть» отражает светлое будущее, где уже внедрена информационная система, а недостатки работы устранены.

Конечно, «идеальный» процесс должен подчиняться здравому смыслу и соответствовать технологическим и финансовым возможностям компании-заказчика. Не стоит моделировать процесс, учитывающий внедрение самых современных технологий, если у заказчика нет денег или недостаточно компетенций для их применения.

Бывает так, что карты процессов «как есть» и «как должно быть» отличаются всего лишь одной функцией. Например, в первом случае функция выполняется вручную, во втором – при помощи информационной системы. С точки зрения карты различия минимальны. Но, реализованные на практике, такие изменения могут сэкономить множество финансовых и трудовых ресурсов. При этом не стоит забывать, что автоматизация даже одной функции порою становится нетривиальной технической задачей. В этом случае не обойтись без системных аналитиков, ИТ-архитекторов и разработчиков.

Некоторые заказчики стремятся сразу же перейти к описанию процесса «как должно быть». Они говорят: «Я и так прекрасно знаю, что меня не устраивает! Давайте обсудим идеальный процесс!» Можно ли приступать к работе над идеалом без рассмотрения текущей ситуации? Можно, но нежелательно. Дело в том, что карта «как есть» позволяет избежать узкого, субъективного взгляда на текущую деятельность. Вероятность выявить существенные детали при описании процесса «как есть» намного выше. Это касается взаимодействия разных подразделений, логических развилок, зон ответственности и т. д. Если же сразу начинать с процесса «как должно быть», можно упустить важные детали. Более того, существует риск, что при обсуждении целевого процесса подразделение-заказчик забудет об интересах других. Каждый руководитель в первую очередь исходит из нужд своего собственного подразделения. Возможна ситуация, при которой вы, как аналитик, потратите время и усилия на создание карты процесса «как должно быть», а потом окажется, что она не учитывает особенности работы других подразделений, поскольку заказчик в ходе работы подумал только о себе. В этом случае карты процессов придется переделывать.

Подробнее о том, с чего начинать описание бизнес-процессов, мы поговорим в следующих разделах.

ФОРМУЛИРОВАНИЕ ПРОЦЕССНЫХ И ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К ИТ-РЕШЕНИЮ

Конечная цель ИТ-проекта – создание ИТ-решения, которое принесет пользу заказчику. ИТ-решение – совокупность программных и аппаратных средств, выполняющая определенную бизнес-задачу. Для того, чтобы это решение учитывало все нюансы деятельности заказчика, и нужен бизнес-анализ. Результатом анализа в этом случае станут процессные и функциональные требования.

В основе процессных требований лежат карты процессов «как есть» и «как должно быть». Эти требования описывают текущее и целевое состояние бизнес-процесса, зоны ответственности, используемые в работе программные продукты и т. д. Также в процессных требованиях могут фиксироваться как фактические, так и целевые измеримые показатели процесса. Например, в них может указываться, что внедрение ИТ-решения должно увеличить среднюю скорость выполнения процесса на X минут или Y процентов. Особое внимание в процессных требованиях уделяется различиям между текущим процессом и целевым. Так, в них отражаются все изменения, связанные с последовательностью выполнения функций, форматом их выполнения, ответственными исполнителями и т. д.

Функциональные требования описывают то, какие задачи планируется выполнять при помощи ИТ-решения. Иными словами, в этом документе говорится о возможностях информационной системы, а также о том, кто и с какой целью этими возможностями будет пользоваться. Разработке функциональных требований посвящен специальный раздел данной книги.

МОДЕЛИРОВАНИЕ ЭКРАННЫХ ФОРМ БУДУЩЕГО ИТ-РЕШЕНИЯ

Один из важнейших критериев качества любого ИТ-решения – удобство использования. Даже самую технически совершенную систему можно испортить неудобным, неочевидным интерфейсом.

Удобство – понятие субъективное. Недаром мы выделили UX/UI-аналитику в отдельное направление. Однако бывает и так, что на вашем проекте нет соответствующего специалиста или у информационной системы, на базе которой вы планируете создать ИТ-решение, ограничены возможности по изменению экранных форм и элементов управления.

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

Интерфейс системы очень зависит от процесса работы с ней: на определенных этапах нужны одни экранные элементы, на других – другие. Таким образом, при разработке экранных форм нужно учитывать два обстоятельства.

1. Уместность тех или иных экранных элементов на каждом конкретном этапе работы с системой.

2. Технические ограничения информационной системы с точки зрения модификации интерфейса. Иными словами, аналитик должен следить за тем, чтобы заказчик не предложил такой интерфейс, который нельзя реализовать средствами системы.

Завершив наброски, аналитик создает макеты экранных форм при помощи векторного графического редактора типа Microsoft Visio. Рукописные заметки превращаются в аккуратные иллюстрации интерфейса. Эти иллюстрации становятся частью функциональных требований к ИТ-решению. Макеты экранных форм упрощают разработчикам реализацию интерфейса, близкого к ожиданиям заказчика. К тому же становится понятнее сценарий взаимодействия пользователя с будущим ИТ-решением.

СОЗДАНИЕ ПОЛЬЗОВАТЕЛЬСКОЙ ДОКУМЕНТАЦИИ

Бизнес-аналитик – это специалист, который способен взглянуть на ИТ-решение глазами конечного пользователя. Иными словами, он знает, как данное решение помогает пользователю выполнять стоящие перед ним задачи. Именно поэтому бизнес-аналитик часто отвечает за создание пользовательской документации. Он пишет инструкции, в которых понятным языком и с обилием иллюстраций рассказывается, как выполнять то или иное действие в информационной системе. В инструкциях учитываются все нюансы процессов заказчика, а также технические ограничения информационной системы.

Инструкции пользователя часто входят в комплект обязательной документации, передающейся заказчику по завершении проекта.

ВЕДЕНИЕ БАЗЫ ЗНАНИЙ

Дейл Карнеги в своих книгах вывел одно из главных правил по борьбе со стрессом. Звучит оно так:

ПОРЯДОК – ПЕРВЫЙ ЗАКОН ДЕЛОВОЙ ДЕЯТЕЛЬНОСТИ.

И действительно, во время работы ничто не создает большего стресса, чем суета и неразбериха. Если вы хотя бы раз не могли найти свои записи к срочной встрече, то знаете, о чем речь. Значительную роль в поддержании порядка в ИТ-проекте играет бизнес-аналитик.

Одна из главных задач бизнес-аналитика – поддержание в проектной команде единого информационного поля. Главный инструмент для этого – ведение базы знаний.

Для начала разберемся с понятием «знание». Воспользуемся примером из книги Карла Андерсона «Аналитическая культура»[6]6
  См.: Андерсон К. Аналитическая культура…


[Закрыть].

Представьте себе: вы подходите к термометру и видите, что он показывает «6 градусов выше нуля». Это данные. Сам по себе факт того, что термометр показывает шесть градусов, мало о чем говорит. Но давайте добавим контекста. В какой ситуации мы смотрим на термометр? Допустим, мы находимся в Москве, на календаре 8 июня, время – 15:00. Это информация. О чем нам говорит данная информация? Мы знаем, что +6 в июне в середине дня – аномально прохладная погода для Москвы. Отсюда мы делаем вывод о том, что при выходе из дома надо надеть теплую куртку. А вот это уже знание.

В приведенном выше примере данные – показания термометра. Информация – данные, сгруппированные и обобщенные по определенному признаку: мы соотнесли показания термометра с датой, временем и местом их получения. А знания – практически применимая информация, которая отвечает на вопрос «что делать с полученной информацией?». В данном случае знание – это вывод: «Если на улице аномальное похолодание, надо одеваться теплее».

База, в которой аналитик фиксирует всю ценную и практически применимую информацию по проекту, называется базой знаний. В ней может храниться всё что угодно: карты бизнес-процессов, сравнительные таблицы, нормативные документы и т. д. Команда проекта использует всё это в работе.

База знаний позволяет аккумулировать информацию о проекте в одном месте и обеспечивает одновременный доступ к ней всем членам проектной команды. Кроме того, наличие базы знаний значительно облегчает погружение в проект новых специалистов. Более опытные товарищи, отвечая на тот или иной вопрос коллеги, могут просто поделиться ссылкой на статью в базе, где содержатся нужные ответы. Это сильно экономит время и силы, которых всегда не хватает участникам ИТ-проекта.

Стандартом программного обеспечения для базы знаний является Confluence. Confluence – тиражируемая вики-система, которую организации используют для создания общей базы знаний. Разрабатывается австралийской компанией Atlassian, наряду с системой отслеживания ошибок Jira. Пользователи Confluence самостоятельно наполняют систему информацией и изменяют ее при помощи встроенных инструментов. В этом смысле Confluence идеологически близка к «Википедии». Если в вашем проекте есть возможность вести базу знаний в Confluence – настоятельно рекомендую ею воспользоваться.

С точки зрения ответа на вопрос «что делать?» особенно важно занесение в базу знаний протоколов совещаний. Совещание… Сколько времени и потраченных усилий в этом слове! Но без них не обойтись ни в одном проекте.

Для чего же проводят совещания в ИТ-проектах? Основные причины следующие.

1. Совещания позволяют поддерживать единый информационный фон. Благодаря им все будут в курсе того, кто чем занимается и за что отвечает в настоящее время. Это позволяет избежать недоразумений и рассогласованности в действиях. Иными словами, хаоса и работы в духе «кто в лес, кто по дрова».

2. На совещаниях обсуждаются текущие задачи, а также проблемы, связанные с их выполнением. Если у кого-то из членов проектной команды возникли проблемы с той или иной задачей, команда должна оперативно узнать об этом. Такой подход позволит вовремя вмешаться в ситуацию, помочь коллеге и не допустить того, чтобы небольшая сложность привела к печальным последствиям вроде смещения сроков проекта.

3. На совещаниях распределяются зоны ответственности. Это касается как представителей заказчика, так и представителей исполнителя. Участники совещания определяют, кто и за что отвечает, какую работу и в какие сроки проводит.

4. На совещаниях с представителями заказчика уточняются детали бизнес-процессов, проясняются технические и законодательные моменты. В большинстве случаев именно на совещаниях аналитик получает информацию, необходимую для формирования карт бизнес-процессов.

5. На совещаниях обсуждаются и фиксируются риски проекта. Риски – это вероятность наступления неблагоприятных для проекта событий вследствие неопределенности. Например, у разработчиков внезапно вышли из строя компьютеры или перестала работать сеть. Или правительство внезапно приняло новый закон, а проектируемое ИТ-решение не учитывает его требований. С чем бы ни был связан риск, его необходимо зафиксировать как можно раньше. После этого команда должна предложить варианты его устранения. Некоторые риски могут быть настолько существенными, что приводят к смещению сроков или увеличению бюджета проекта.

6. Ретроспективный анализ. Если процесс создания ИТ-решения поделен на итерации, команде очень полезно периодически собираться для проведения так называемого ретро. Ретро – это совещание, на котором команда обсуждает результаты работы за определенный промежуток времени. Основные вопросы, которые обсуждаются на этом собрании:

• Что было сделано хорошо за прошедший период? Что больше всего понравилось, вызвало воодушевление у членов команды?

• Какие приемы, примененные в прошедшем периоде, можно в дальнейшем использовать постоянно? Какие практики стоит зафиксировать?

• Что за прошедший период было сделано плохо? Что больше всего не понравилось, с какими сложностями пришлось столкнуться?

• Что стоит предпринять для того, чтобы минимизировать вероятность аналогичных негативных ситуаций в будущем?

Ретро – мощный инструмент развития проектной команды, поскольку коллектив учится критическому взгляду на свою работу, стремится улучшить ее и исключить негативные моменты.

7. На совещании принимаются решения о дальнейших действиях. Опираясь на базу знаний и собственные соображения, участники проектной команды принимают решение о том, что делать дальше: какие вопросы требуют дополнительного изучения, кому и с кем нужно связаться, что выяснить и т. д.

Совещание, результаты которого не были зафиксированы, – впустую потраченное время. Допустим, вы провели ретро с командой. Обсуждение прошло в «теплой дружеской обстановке», все поделились своим мнением о том, что было хорошо, а что плохо, что стоит применять в дальнейшем, а что лучше исключить. И, ничего не записав, вы расстались, весьма довольные друг другом. Можете быть уверены: через 15 минут после встречи участники ретро забудут половину того, о чем шла речь. Но если вы зафиксируете результаты обсуждения и занесете их в базу знаний, время собрания не будет потрачено впустую и каждый участник команды при необходимости сможет в будущем обратиться к результатам встречи.

Кроме того, значительная часть договоренностей о том, кто и что делает, закрепляется именно на совещаниях. Как правило, членам проектной команды лень фиксировать результаты встречи. Вы, как аналитик, должны помнить: любые договоренности, не закрепленные протоколом совещания, по сути, не существуют. На практике вы можете столкнуться с тем, что на следующем собрании будут обсуждаться те же самые вопросы, что и неделю назад. Если сотруднику назначена задача, но при этом она нигде не подтверждена или ему не поступают регулярные напоминания, высока вероятность, что о задаче просто забудут. Дисциплинированные специалисты, выполняющие устные договоренности, никак не закрепленные официально, встречаются очень редко.