Бизнес-анализ от а до я: гид для начинающих

Простой пример применения навыка тайм-менеджмента в личной жизни (многие, я уверен, так делают) – например, каждый день дома я убираю со стола посуду в посудомойку. В среднем это 6 тарелок. Если я отношу каждую тарелку на кухню в посудомойку, то это занимает примерно 6 секунд на каждую и 36 секунд на все тарелки. Если посчитать обед, завтрак и ужин, то это 108 секунд в день. Округлим до 2 минут для простоты. Значит, в месяц это 60 минут или 1 час. В год это 12 часов на уборку тарелок в посудомойку. А если я немного изменю процесс и все тарелки буду ставить на поднос или друг на друга и относить одним разом на кухню, то это займет не 36 секунд, а в три раза меньше времени – допустим, около 12 секунд. Соответственно, при годовом расчёте можем уменьшить первоначальные 12 часов в три раза, то есть до 4 часов, и тогда 8 часов мы сэкономим. Таким образом, у нас есть 8 часов в год, которые я гипотетически могу потратить, как захочу.

В этом примере ключевой момент заключается в том, что время обладает гибкостью и всё зависит от того, как человек планирует своё время. Планирование – это важно. Одна из ключевых частей управления временем – это его планирование. Планирование времени включает в себя распределение времени на задачи – ежедневные, еженедельные, ежемесячные и так далее. Наша жизнь состоит из постоянных задач, и от того, как мы планируем обязательные задачи, зависит, сколько у нас будет свободного времени на необязательные задачи (например, отдых). Естественно, желательно, чтобы времени на отдых было как можно больше.

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

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

Возвращаясь к управлению временем, этот навык важен и сложен одновременно, что делает его особенно значимым. Навык управления временем является сложным, так как работа бизнес-аналитика не подразумевает однообразных и четко определенных процессов – каждый проект и продукт уникален, и БА должен адаптировать свои подходы под каждую задачу. Под каждый проект и продукт нужно соответствующим образом управлять временем. БА должен уметь понимать контекст и эффективно управлять своим временем. Под «важен» я имею в виду высокую ценность и приоритет этого навыка и связанных с ним активностей. Вернусь снова к теме «планирования времени и задач» как к примеру сложности и важности этого процесса. Для меня это до сих пор самая значимая и сложная ежедневная задача. Пока я не запланирую свой день, я не приступаю к выполнению задач. Иногда мне приходится тратить 30, 60, а иногда и 90 минут просто на идентификацию, анализ, подготовку и планирование дневных задач, включая их приоритизацию и декомпозицию. Однако, когда планирование завершено и я точно знаю, что максимально эффективно организовал свое рабочее время, мне становится легко и прозрачно выполнять все запланированные задачи без малейшего сомнения. Детали, рекомендации и подходы мы рассмотрим в следующих главах. Может показаться немного сумбурно, но таковы мои размышления о навыке управления временем. Остается только один важный аспект, без которого описание этого навыка нельзя считать завершенным: описание того, что должен уметь человек, и какими способностями он должен обладать (по моему мнению), и всегда с уточнением «максимально эффективно» относительно активностей/задач/процессов: планировать, приоритизировать, декомпозировать/дробить, распределять/определять время выполнения, оставаться сфокусированным, делегировать, всегда видеть целевую цепочку, принимать решения. Кратко о каждом умении: Планирование – это начало любой активности вообще и включает в себя такие аспекты, как определение самого процесса и подхода к планированию в зависимости от контекста, разработка и документирование артефактов планирования, а также непрерывный мониторинг, проверка и актуализация плана. Непрерывная приоритизация активностей обеспечивает понимание и уверенность в том, что выполнение задач происходит с максимально эффективным использованием времени и приносит максимальную ценность для конечных целей. Приоритеты могут меняться со временем или быть статичными, но должен быть четко определен их порядок и критерии. При наличии прозрачного приоритезированного списка активностей/задач исключаются факторы сомнения о затрачиваемом времени на задачу – это важно как психологически, так и профессионально, поскольку когда я выполняю какую-либо задачу, у меня нет сомнений о её актуальности и полезности. Декомпозиция очень важна, особенно по мере вашего профессионального роста и, соответственно, увеличения сложности проектов/продуктов, в которых вы участвуете. Неправильная или недостаточная декомпозиция может привести к серьезным задержкам в выполнении задач и неэффективному использованию времени. Нельзя удержаться и не привести пример, с которым, я думаю, большинство из вас сталкивалось как в рабочих, так и в личных делах. Вот пример из внерабочих активностей, основанный на реальных событиях: скоро день рождения у моей жены, и у меня есть задача «Поздравить с днем рождения». Для этой активности, естественно, может быть очень простой план без какой-либо декомпозиции, который выглядит как «Поздравить с днем рождения = купить подарок» и всё готово. Или можно подумать и сделать декомпозицию, например, на три пункта: 1. Подготовить поздравление. 2. Подготовить подарок. 3. Определить место для празднования. Эти три пункта, в свою очередь, содержат подпункты. Например, пункт №1 может включать: 1. Придумать сценарий поздравления. 2. Закупить необходимые материалы. 3. Подготовить части поздравления. Каждый из этих пунктов можно далее декомпозировать. Например, пункт №2 разбить на подпункты: 1. Материалы для подготовки видеопоздравления. 2. Материалы для оформления стола. 3. Контекстные материалы. Из этих я еще сделаю разделение, например, для пункта 3 на: надувные шары, фотографии для украшения стен, коробки для подарков, упаковочная бумага и так далее. И вот после всех уровней декомпозиции у меня есть довольно простые задачи, которые я могу запланировать выполнить в уже примерно понятные временные сроки и даты. Да, тут нет ничего сверхъестественного, и всё действительно просто – именно в этой простоте декомпозиции кроется сверхэффективность. Декомпозиция позволяет концентрироваться на конкретной, понятной и выполнимой в краткосрочной перспективе задаче или активности. Следующее умение, связанное с распределением и определением времени, выделяемого на какую-либо задачу, думаю, не требует объяснений, так как в большинстве случаев любая глобальная активность или цель всегда имеет временные рамки. Соответственно, любые ваши действия, чтобы рассматриваться как эффективные с точки зрения времени, должны быть оценены: сколько времени они займут и когда наиболее правильно будет их выполнить. С умением «быть сфокусированным» тоже всё просто и важно. Включая упомянутые выше умения, такие как приоритизация, планирование и декомпозиция, у вас должна быть ясная картина, чем и когда заниматься. Затем важна личная способность а) быть сфокусированным на одной задаче в данный момент времени (никакого мультитаскинга), и б) всегда иметь в фокусе общую картину глобальной цели, когда вы тратите своё время на конкретную активность.Следующая способность, "делегирование", подразумевает, что вы понимаете и распределяете задачи среди коллег, чётко осознавая, какую пользу это принесёт в контексте затрат времени и ценности для конечных целей. Если вы работаете в команде бизнес-аналитиков, то не должно быть сценариев, когда вы пытаетесь взять на себя все важные, сложные или крупные задачи, ведь у вас также есть умение декомпозировать, которое может помочь распределить задачи внутри команды. Также у вас обязательно будут активности, зависящие от внутренних и внешних факторов – у вас должно быть понимание и подход, в каком формате, как, зачем и с какими ожиданиями делегировать задачи другим.

"Видеть целевую цепочку" – это навык, который требует практики и опыта. Я бы описал его как способность быть сфокусированным – в любой момент и при любых обстоятельствах вам должна быть ясна связь от начальной стадии до конечной цели всех задач и проектов. Если я вношу изменения в одно поле на странице веб-сайта, я должен понимать, как это повлияет на один из бизнес-процессов, в рамках которого используется этот веб-сайт, что в свою очередь влияет на результаты работы нашей команды. И последнее умение, которое звучит удивительно просто – умение принимать решения. Да, именно это умение напрямую влияет на эффективное использование времени. Колебания в принятии решений не допустимы. Это особенно просто, если всегда помнить и повторять себе, что откладывание или избегание принятия решения (что ведет к задержкам и, следовательно, к неэффективному использованию времени) можно преодолеть, напоминая себе: «В принятии решения всегда есть опции, из которых надо выбрать. С любой выбранной опцией я продвинусь вперед. Если что-то пойдет не так, я всегда смогу принять следующее решение, и это нормально». Таков подход. Не должно быть ситуации, когда мы говорим: «Я пока не могу принять решение», особенно если все перечисленные выше умения уже применены и использованы. Применение описанного подхода минимизирует любые сомнения. Вот и всё, что я хотел сказать про навык тайм-менеджмента; описать его не так уж и просто, но я постарался.

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

Шаг 2 – отличный БА.

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

Через пару месяцев мой проектный БА оценил развитие моих навыков и способности, и уже стал доверять мне документирование требований и дизайнов целых функций компонента системы. Это было несказанно радостно – ощущение, что ты создаешь что-то целостное от начала до конца, которое я описывал ранее, только усилилось.

Что же такое функция? Возьмем пример из предыдущего этапа: у нас есть компонент системы под названием “система управления информацией о клиентах”. В этом компоненте существуют различные функции, такие как создание профиля клиента, редактирование профиля, просмотр и управление кредитной информацией о клиенте и многие другие. Каждую такую функцию можно далее разделить на множество подфункций или требований. Одно из требований, касающееся кредитной информации, мы уже рассмотрели на предыдущем шаге. Функция представляет собой определённый набор свойств и действий (как пользователя, так и системы), которые позволяют конечному пользователю выполнить полноценное и завершённое действие с определённым ожидаемым результатом. Как я упоминал ранее, например, функция "создать профиль клиента".

С течением времени я начал получать задачи по подготовке функций. Виды задач, активности и ответственность стали разнообразнее, что отражало мой продолжающийся профессиональный рост. Я ощущал, что уровень сложности моих задач повышается: теперь задача заключалась не просто в написании требований и их документировании. Теперь мне требовалось анализировать нужную функцию, декомпозировать её, определять и документировать необходимые требования и дизайн, корректно связывать все требования между собой в матрице требований, управлять статусом готовности и блокерами, а также подготавливать вопросы для заинтересованных сторон (stakeholders) со стороны клиента. Да, это был настоящий взрыв нового опыта! Как следствие, к задачам, связанным с функциями, добавились общие профессиональные задачи в связи с увеличившейся сложностью: проверка и поддержание (а при необходимости изменение) информационной модели/структуры требований и дизайна, поддержание их логичности, понимание работы с моделью данных, разработка спецификаций модели данных, понимание жизненного цикла разработки системы, а также развитие дополнительных и необходимых "мягких" навыков. Столько всего… наверное, я сразу «раскрыл карты» о навыках и активностях, которые буду дальше описывать, но так вот – никаких секретов! Единственное, я упомянул новое слово «стейкхолдер». Поясню: стейкхолдер – это человек, который ожидает и будет иметь какую-то выгоду от ИТ-продукта, который я создаю, или будет его использовать. В проектах компаний-поставщиков сервисов или продуктов, которые нанимают другие компании, основными стейкхолдерами всегда являются люди на стороне клиента, те, кто ожидает готовый продукт. Это может быть всего один человек, взаимодействующий с сервисной компанией, или множество людей на стороне клиента. Это люди разных уровней в организации клиента – от генерального директора до заместителя директора ИТ-департамента, экономического отдела или отдельной проектной команды, курирующей создание продукта. В большинстве случаев именно стейкхолдеры являются источниками входной информации о требованиях к продукту. Именно с ними БА выявляет требования к системе/продукту. Позже мы подробно рассмотрим БА-навык «управление стейкхолдерами».

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

Декомпозиция началась с базовой функциональности по созданию, редактированию, просмотру и удалению адреса. Затем я подумал, что поскольку система предназначена для бизнес-клиентов, они наверняка могут иметь несколько адресов. Поэтому я добавил требования по управлению списком адресов. Очевидно, потребуются требования к работе с полями/параметрами создаваемого адреса: какие поля доступны, каковы их свойства и типы. Например, некоторые поля – это простые текстовые поля, а другие представляют собой список, из которого можно выбрать только одно из предопределённых значений. Также я включил функциональность различения типов адресов – например, физический адрес и адрес для выставления счетов, при этом основные адреса могут отображаться также на главной странице профиля клиента. Плюс такого подхода к декомпозиции, прежде чем начать писать детальные требования и дизайн, заключается в том, что ты уже разделил одну большую задачу на несколько и можешь выбирать, с какой лучше начать. Когда начинаешь работу, ты уверен, что не будет пересечений в разных активностях, которые могут привести к необходимости постоянно переделывать уже готовые артефакты (требования, дизайн и т. д.). Теперь можно было и обсудить всё с моим БА.

На звонке мы определили, какие вопросы БА должен прояснить с клиентами, так как, например, были неясности в бизнес-требованиях, которые по своей природе не должны быть детализированы. Также я получил ценное замечание, о котором совсем не подумал – об интеграции моей функции с существующей в нашем продукте системой управления адресами. Поскольку адреса используются во множестве модулей/компонентов, у нас есть отдельный компонент, предназначенный для этой цели. Мы обсудили необходимость создания карты интеграционных связей между элементами, а также необходимость мне изучить нашу существующую систему управления адресами. Последним пунктом обсуждения стали первые требования из декомпозиции, которые были наиболее понятны и которые можно было начать документировать. В результате звонка появились задачи для каждого из нас, которые нужно выполнить в определённые сроки. БА попросил меня также прислать итоги нашего звонка в письме. Как всегда, любое обсуждение планируемых задач с коллегой оказалось очень полезным – это большой плюс работы в команде, даже если команда маленькая. В течение 30 минут после звонка я отправил митинг-ноутс (Meeting Notes) в письме, где включил информацию о том, что мы обсудили, кто и что должен сделать и когда. Хочу сделать акцент на этом фантастически полезном и ценном артефакте – «митинг-ноутс», который я использую в своей работе в ИТ уже 10 лет и везде, где это возможно. Почему фантастически? Потому что этот артефакт помогает мне структурировать планы мои, команды и клиента; минимизировать риски возможных неясностей во время совещаний; защитить от возникновения любых видов споров как внутри команды, так и с клиентом по поводу договоренностей, указанных в этих записях; определить ответственные стороны и сроки выполнения; и является самым надежным коммуникационным каналом для сохранения информации. Когда у каждого участника совещания есть, по сути, копия документа о договоренностях в его личной электронной почте, то очень сложно изменить эту информацию. Я лично всегда отправляю митинг-ноутс, даже когда меня никто об этом не просит. Это дает мне 100% уверенность, что информация донесена всем, даже если на самом совещании кто-то был не вовлечен по каким-либо причинам; такой человек может потом найти время и прочитать митинг-ноутс позже. И за свою карьеру у меня было множество случаев, когда этот артефакт спасал от масштабных проблем или споров на разных уровнях менеджмента между клиентами и моей компанией. Например, когда речь идет о финансах, и кто-то на стороне клиента упустил важный пункт, который был указан в митинг-ноутс, этот человек может пытаться убеждать на словах, что чего-то не было или что-то было неправильно понято. Однако, пересылка участнику митинг-ноутс письма шестимесячной давности, где он был в числе получателей и согласился со всем предложенным, решает проблему положительно почти всегда. Я приведу небольшой пример митинг-ноутс, который отослал, чтобы показать именно структуру митинг-ноутс письма – простую и очень эффективную.

Письмо, которое я отправил своему БА:

Тема письма: «Митинг нотсы от 10 июля: обсудить функцию управление адресной информацией»

Тело письма: «

Обсудили:

Требования к новой функции

Требования, которые можно брать в работу

Требования, которые нужно прояснить с клиентом (номера требований)

Экшн айтем (action items – пункты действий):

Прояснить бизнес требования с клиентом/// ведущий БА /// до конца недели (список требований прикреплен)

Изучить и включить интеграционный маппинг/// Миша /// следующие две недели.

Подготовить дизайн к требованиям А,Б,С, И так далее/// Миша /// эта неделя.

Дополнение: допиши если я что-то упустил.»

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

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

– «Система должна предоставлять возможность создать адрес для клиента»

– «Система должна предоставлять возможность редактировать адрес для клиента»

– «Система должна содержать следующие данные в адресе: тип адреса, страна, штат, город, улица, номер здания, номер офиса, индекс.»

Атомарность требований позволяет затем значительно упростить решение любых вопросов, например, с клиентом, когда появляются запросы или пожелания к дополнению или изменению требований. Приведу простой пример, с которым я сталкивался: клиент может просмотреть и согласиться с требованиями №2 и №3, но пояснить, что для №1 он хотел бы уточнить, из каких частей приложения можно будет инициировать создание адреса. В этом случае, возможно, потребуется изменение только одного требования, в то время как остальные два уже будут утверждены. Этот пример, конечно, условный и масштабируемый – у меня было 50, 100 и даже 300 таких требований, и их простота и самодостаточность обеспечивали эффективный процесс проверки и утверждения с клиентом. С другой стороны, я мог помечать часть требований как готовых к проверке, а другую часть – как требующих прояснений.

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