7 вызовов для бизнес-аналитика при выявлении требований

Статья написана в соавторстве с Мэри Ротарь, Co-Founder IAMPM.

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

У меня экономическое образование. Когда стоял выбор между финансами и экономической кибернетикой, я выбрала кибернетику. После института мне предложили поработать аналитиком-консультантом по внедрению 1С-систем. Позже работала PM, потом снова вернулась в бизнес-анализ. И вот в DataArt я уже три года.

Семь вызовов, о которых я рассказываю сегодня, — это мой опыт: то, что сама переживала в работе и с чем училась справляться.

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

Первый вызов — выявить истинную бизнес-потребность

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

Например, директор говорит: «Хочу формировать отчет по данному проекту в виде: сотрудник/количество затраченных часов». Бизнес-контекст этого запроса: «На проекте сложности с оплатой от клиента, он хочет понимать, куда тратится время». Соответственно и решение может быть следующим: менеджер проекта сам формирует данный отчет, выгружает в Excel раз в неделю и дальше отправляет клиенту и директору. Сотрудники, логирующие время в задачи, получают напоминания залогировать его на следующий день/по пятницам. Это можно распространить на все проекты.

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

Как выяснить истинную бизнес-потребность заказчика

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

• Для чего этот функционал нужен в системе?
• В чем конкретно решение поможет бизнесу?
• Какой цели хотите достичь?
• Почему нужно автоматизировать данный процесс?

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

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

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

Расскажу показательный кейс о супербыстром решении клиентской проблемы

В самом начале моей карьеры, когда я работала консультантом в компании, внедряющей 1С-продукты, знакомый рекрутер попросил разработать для него систему на базе 1С. Exсel ему не хватало: хотелось перейти на более стандартизированную, сложную и комплексную систему для учета соискателей и заказчиков.

Главный запрос — возможность размещать в системе максимально полную информацию о соискателях и легко находить нужные данные. Он звучал абсолютно логично, поэтому мы начали обсуждать детали решения, и в какой-то момент (каюсь, что не сразу) я подумала: «А чем же заказчику не подходит Excel, ведь это довольно мощный инструмент?».

Дальше у нас состоялся примерно такой диалог:

Я: А что конкретно не устраивает в Excel, почему решили перейти на 1С?

Рекрутер: В Excel удобно работать со списком соискателей, но когда нужно открыть отдельное резюме, то файл приходится искать по всем папкам. Такой поиск неудобный, занимает много времени, а в 1С процесс будет проще.

Я: В Excel же есть функция гиперссылки: в отдельной колонке можно сделать ссылки на месторасположение конкретных файлов. И тогда при нажатии на ссылку сразу открывается необходимое резюме.

Знакомый заинтересовался, сказал, что не знал о такой функции и хочет попробовать. А чуть позже — перезвонил и восторженно сообщил, что я решила все его проблемы.

Чтобы задавать правильные вопросы, бизнес-аналитику понадобится качественная предварительная подготовка. Это следующий вызов: заранее изучить предметную область бизнеса заказчика.

Второй вызов — знать бизнес-домен

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

Может показаться, что углубляться в домен необязательно, ведь БА — человек от разработки: он должен звучать уверенно, когда речь идет об автоматизации и функциональном наполнении систем. Однако суть в том, что без знания домена бизнес-аналитик не сможет точно понять и даже правильно сформулировать вопрос. Поэтому задача БА — заранее изучить предметную область продукта, насколько это возможно. А затем, начав с базовых знаний об отрасли, дальше углубляться в домен уже в процессе обсуждения требований с клиентом.

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

Реально ли хорошо знать бизнес-домен до начала работы на проекте

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

• Знакомиться с первичными документами и оригинальными формулировками от заказчика. Кстати, здесь помогут тикеты и заявки на доработку в техподдержку.
• Если возможно использовать наблюдение (BABОK даже выделяет это как отдельную технику по выявлению требований), то посмотреть на сам процесс работы бизнес-подразделений полезно для бизнес-аналитика.
• Подписаться на периодические издания по теме бизнеса.
• Проходить внутренние курсы компании: часто для бизнес-подразделений проводят курсы для новичков или для повышения квалификации. IT-шники также могут включиться.

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

Третий вызов — строить доверительные отношения

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

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

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

Как завоевать доверие клиента

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

Настраиваться на одну волну с заказчиком мне помогает образ из «психологического айкидо», о котором говорит Ирина Хакамада:

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

Смысл в том, чтобы сначала понять приоритеты, интересы клиента и уже потом перевести разговор в нужное русло.

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

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

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

Ну и конечно, пройдя этап погружения в проект, БА начинает хорошо ориентироваться в бизнес-процессах, часто являясь knowledge holder’ом — чуть ли не единственным человеком, который с ходу может рассказать, «как это все работает». Когда бизнес-аналитик показывает свое глубокое понимание процессов, хорошо знает разработанный продукт, задает правильные вопросы, он привносит ту самую ценность, что укрепляет отношения между бизнесом и разработкой.

Способность оставаться доброжелательным в любой ситуации помогает БА справляться с еще одним вызовом: фасилитировать достижение соглашения в требованиях между стейкхолдерами.

Четвертый вызов — решать конфликты в требованиях стейкхолдеров

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

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

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

У меня была такая ситуация: заказчику для интеграции с системой кастомера необходимо было заполнить маппинг мастер-данных — справочников со списками компаний, адресами и прочим. У него этот список был один (коды, имена и так далее), а у его кастомера те же названия были написаны по-другому. Соответственно, надо было хранить маппинги.

Сначала было непонятно, кому поручить маппинг, потому что этим могли заняться два отдела: обработки заказов и контроля мастер-данных. Казалось очевидным, что это работа для отдела контроля. Однако после разговора выяснилось, что они занимаются мастер-данными, глобальными для всех систем корпорации. А вот отдел обработки заказов знает конкретного клиента, его данные, поэтому проще поручить им «замапить» данные системы.

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

Как договориться со стейкхолдерами

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

Можно попробовать альтернативный способ решения конфликта:

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

В результате такой проработки бизнес-аналитик может найти способ действий, что удовлетворит всех стейкхолдеров.

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

Пятый вызов — защитить систему от плохих решений

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

Например, заказчик настаивает, что нужна сложная дополнительная функциональность. Потом выясняется, что она не критична и необходима только небольшой группе пользователей. Вызов для БА — деликатно, но твердо объяснить клиенту, что коверкать всю систему, чтобы одна группа людей пользовалась продуктом так, как она это видит, — это далеко не лучший выход.

Как плохое решение может выглядеть в интерфейсе.

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

Как не пропустить неудачное решение

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

В работе над продуктом клиент описывает идею или бизнес-требование, а задача БА — вовремя отследить, когда речь идет о приемлемых требованиях, а когда — о workaround или исключениях, что не вписываются в систему.

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

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

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

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

В итоге мы не сломали свои процессы и бизнес-потребность клиента также была удовлетворена.

К сожалению, не все кейсы заканчиваются так хорошо. Бывает так, что заказчик принял аргументы БА, работа началась, а потом он отказывается от договоренностей, мотивируя тем, что «мы говорили о другом». Воспоминания о принятых решениях могут отличаться у разных людей, поэтому подтверждать и фиксировать все, что обсуждали с заказчиком, — обязательное условие успешной работы БА.

Шестой вызов — подтвердить договоренности

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

Если БА игнорирует фиксацию и согласование, то возникают кейсы в стиле: «Разве мы это не обсуждали?». Или на долгосрочных проектах уже на этапе разработки появляются фразы: «Не помним результатов, но мы это точно обговаривали и сделали, как показалось правильным». Особенно опасно не подтверждать договоренности в аутсорсинге, потому что любые недопонимания выливаются в дополнительный бюджет или срыв дедлайна и приводят к серьезному разговору с заказчиком.

Воспоминания о договоренностях — вещь субъективная: трудно доказать, о чем шла речь на самом деле, если решения нигде не зафиксированы.

Как фиксировать договоренности

Для меня оптимально сохранять результаты общения с заказчиком в заметках (meeting minutes) и видеозвонках. А для сбора обратной связи и подтверждения требований удобно использовать, например, прототипы.

Заметки и запись видеозвонков

Поиск конкретной темы обсуждения легче всего делать по заметкам: это оптимально как текстовый поиск. Если выяснилось, что конкретную договоренность мы обсуждали, например, полгода назад, — можно поднять запись видеоконференции и послушать, к чему в итоге пришли. Естественно, в аутсорсинге всегда можно сказать: как вы решили, так мы и сделали. Соответственно, изменение оформляется в change request.

Разработка прототипа

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

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

Седьмой вызов — пережить on-site переговоры

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

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

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

Я прилетела чуть раньше и смогла погулять по Мумбаи. Позже при знакомстве индийцы очень тепло восприняли мой интерес к городу и национальной культуре. Помогли также советы сотрудника, который уже был в этом офисе: сначала я настраивалась на жаркую погоду, но благодаря ему узнала, что в офисе кондиционеры морозят по полной и нужно одеваться потеплее.

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

Как почувствовать себя комфортно

На on-site переговорах важно чувствовать себя удобно, уверенно, проявлять дружелюбие. Уверенность и дружелюбный настрой — это составляющие первого впечатления, которое БА производит на людей. Для хорошего самоощущения на переговорах on-site важны три вещи:

• Профессионально настроиться на тему встречи: четко представлять вопросы и цели обсуждения, подготовить все презентации. Это самое важное.
• Если это переговоры с людьми другой культуры, лучше заранее поискать информацию о национальных особенностях или поспрашивать коллег, которые уже ездили в страну.
• Соблюдать дресс-код. Еще один важный момент в переговорах on-site. Самым универсальным для переговоров считается стиль smart casual. При этом задача БA — одеться так, чтобы было удобно. Если вы совсем не привыкли носить пиджак и чувствуете себя некомфортно, это тоже будет влиять на переговоры.

Вместо вывода

Если кратко, то справляться с вызовами при выявлении требований мне помогают несколько вещей:

1. Фокусироваться в первую очередь на проблемах клиента, а только потом — на вариантах решения.
2. Предварительно готовиться, изучать предметную область.
3. Доброжелательно относиться к заказчикам, даже если что-то пошло не по плану.
4. Гибко подходить к решению конфликтов между стейкхолдерами.
5. Оптимизировать бизнес-процессы и приводить их к общему стандарту, прежде чем начнется разработка системы.
6. Фиксировать договоренности с помощью заметок, видеозаписей и прототипов.
7. Учитывать особенности ведения бизнеса в других странах или культурах.

Темы: Business Analysis, оценка, требования