«Клиент может сказать, что он это не согласовывал»: инструменты и советы, как бизнес-аналитику облегчить себе жизнь

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

Я расскажу об основных подходах и инструментах утверждения требований. И поделюсь практическими кейсами и советами по моему опыту.

Утверждение требований — один из главных шагов в анализе цикла разработки

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

В этой статье я ограничусь общими понятиями, самое главное, что вам нужно знать для работы. Более подробно об утверждении требований вы можете прочитать в книге — A Guide to the Business Analysis Body of Knowledge (см. «Управление жизненным циклом требований»). В общем, буду опираться на материалы из этой книги.

Полезно утвердить требования на старте, ведь это поможет:

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

Существует два пути утверждения требований

Адаптивный подход

Утверждаете требования только тогда, когда можно приступить к реализации решения.

То есть готовите требования, подтверждаете и проверяете их с командой и только потом со стейкхолдерами.

Здесь хочу напомнить разницу между Validate и Verify. В первом случае вы подтверждаете, что требования отвечают намерениям заинтересованной стороны. Во втором — проверяете, могут ли требования соответствовать предполагаемой цели. Получаете письменное утверждение и беритесь за разработку. Этот подход хорошо коррелирует с Agile-методологией.

Прогнозируемый подход

Утверждение требований происходит в конце фазы или во время митингов. Здесь по классике, как в Waterfall.

Какой путь лучше выбрать, решайте на этапе планирования проекта.

Переходим к практике

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

Переходим к общению с заказчиком. Здесь ваши основные шаги следующие.

1 Определить роли стейкхолдеров

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

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

2 Разрешать конфликты во время обсуждения

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

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

3 Достичь общего согласия

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

4 Следить за утверждением требований

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

Инструменты утверждения требований

Стратегия перемен

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

Объем решений

Утвержденные требования не должны выходить за определенные рамки решения.

Подход к управлению

Этот инструмент определяет заинтересованные стороны, их полномочия и ответственность. Вы можете скорректировать процесс утверждения относительно, скажем, политики компании вашего клиента.

Юридическая/нормативная информация

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

Инструменты управления требованиями

О них подробнее я расскажу чуть позже.

Техники утверждения требований

Что касается техник утверждения требований, то ВАВОК выделяет следующие:

• Критерии принятия и оценки позволяют определить критерии утверждения, что очень популярно в Agile.
• Анализ решений — благодаря нему сможете решить вопрос и достичь общего согласия.
• Отслеживание проблем — например, технически невозможно реализовать определенные требования или есть ограничения на продукты. Эта техника поможет в нужный момент вернуться к обсуждению проблемы и требования, требующей изменений.
• Отзывы позволяют оценить требования и сигнализировать, что их можно передавать на утверждение.
• Воркшопы — практические семинары, тренинги облегчают восприятие требований. Особенно полезно для разрешения конфликтных вопросов между разными стейкхолдерами.

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

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

Кто может утверждать требования к проекту?

• Заказчик — он главный, он все рассматривает и утверждает. Его слово — последнее.
• Эксперты — специалисты по профильным вопросам могут привлекаться к пересмотру и утверждению требований.
• Пользователи — конечные пользователи, конечно, не утверждают требования, но прямо или косвенно проверяют и определяют приоритеты требований.
• Операционная поддержка — саппорт отвечает за то, чтобы требования и дизайн поддерживались в пределах ограничений, наложенных, например, технологическими стандартами или планами организационных возможностей. Иногда эта команда рассматривает и утверждает требования.
• Проектный менеджер — управляет всем планом реализации проекта. Его работа касается и пересмотра и утверждения требований.
• Регуляторы — внешняя или внутренняя сторона, которая дает выводы, например, о связи между нормативными актами и требованиями к проекту.
• Спонсоры — эта сторона пересматривает утверждение, оценивает бизнес-обоснование решения, иногда даже дает согласие на объем продукта.
• Тестировщики просматривают требования и отслеживают, что они выполнимы.

Далее я расскажу об инструментах, которыми пользуюсь сама, а также из практики моих коллег.

Инструменты для управления требованиями

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

Отдельно следует упомянуть и различные ПО для управления проектом: Trello, ClickUp, Asana и т.д. Здесь я рассмотрю несколько наиболее удобных инструментов и способов утверждения требований.

Confluence

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

У этого подхода есть несколько преимуществ:

• Наглядность. Клиент непосредственно на странице конкретного требования пишет, что этот пункт утвержден.
• Экономия времени. Вам не нужно создавать отдельное место для отслеживания утверждений.
• Простая коммуникация. Можно обсуждать все вопросы на странице фичи, здесь очень удобны инлайн-комментарии.
• Использование макросов. Так пользователям легче сориентироваться в системе. Например, есть удобный макрос «Подпись для подтверждения». В одном проекте наша команда использовала макросы Status и Page Properties. Мы создали отдельную страницу, куда выводили название фичи (или страницы) и статус готовности к разработке.

Однако учитывайте и недостатки Confluence:

• Сложности контроля. Много внимания придется уделять мониторингу утвержденных требований. Хотя с этим могут помочь, например, вышеупомянутые макросы Status и Page Properties.
• Риски неоднозначности. В Confluence нет шаблонов ответов. Клиент может писать комментарии как ему вздумается: «Вроде ОК», «Похоже на то» и т.д. Поэтому нужно предварительно обсудить с ним это, продумать единую систему формулировок для утверждения.
• Отсутствие истории удаленных комментариев. Если клиент недоброжелателен, забывчив или невнимателен к процессам, это может стать проблемой.

Google Таблицы

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

Аргументы «за» Google Sheets:

• Отслеживание истории перемен. Вы можете легко понять, кто редактировал документ и когда. Это снимает вопрос, когда кто-то забыл о поставленном Approved или случайно или намеренно изменил требования.
• Избегание неоднозначности. Комментарии стейкхолдеров могут быть очень разными по формулировке. Например, в Confluence заказчики у меня иногда писали фразы вроде «It’s OK», «Looks good» или «I think yes maybe». Но ведь это неоднозначно! Поэтому лучше всего конкретное слово Approved. К тому же вы можете настроить дропдаун, где клиент будет выбирать готовый вариант ответа. Так и бизнес-аналитик, и заказчик будут легко контролировать утвержденные требования.
• Координация команды. Если на проекте есть несколько аналитиков, таблицы Google упрощают совместную работу. Я убедилась в этом на собственном опыте. Мы с коллегой отмечали, кто описывает ту или иную фичу, делили объем работ, отслеживали процесс. При этом мы были не единственными на проекте, кроме нас были бизнес-аналитики из Индии и Израиля. Благодаря этому инструменту мы видели, над какими фичами работает наша команда.

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

Софт для управления проектами

Программы для управления проектами позволяют визуализировать процессы и легко отслеживать статусы утверждения требований. Такого софта очень много. Лично я работала с Trello, ClickUp, Asana и MeisterTask.

Все эти программы объединяют несколько положительных черт:

• Легкий контроль. Достаточно только перемещать карты с названиями требований между разными колонками: Waiting for review, Approved и т.д. Также можно делать карты фич, над которыми вы работаете. Так клиент увидит, на каком этапе описания требований вы находитесь.
• Отслеживание истории изменений карт. Все видят, кто заправил карточку и поставил ей лейбу Approved, кто пересек ее между колонками. Полезно в работе с несколькими стейкхолдерами.
• Удобная коммуникация. Это тоже самое, что и в случае Confluence: команда может обсуждать определенную фичу непосредственно в одноименной карточке. Хотя после этого нужно дополнительно вносить изменения в самом Confluence.

Относительно недостатков:

• Время, чтобы все настроить. Создание доски и карт, распределение доступов, слежка за ними — все это требует усилий и времени.
• Требования к внимательности. Если вы очень торопитесь, то можете случайно переместить карту или поставить ей неправильную лейбу. Эти системы очень сенситивны в использовании и не нуждаются в лишних подтверждениях. Говорю об этом по собственному опыту. У меня не раз случались такие казусы. К примеру, я хотела открыть карточку, но случайно перетащила ее в другую колонку. Будьте внимательны и в случае чего смотрите историю перемен.

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

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

Митинги

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

• Риски отрицания полученного согласия

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

• Сложный контроль соблюдения требований

Если вы утверждаете требования на митинге, продумайте, как в дальнейшем отслеживать апрувы. Здесь пригодятся Google Sheets. В комментариях можете так писать: «Это требование было утверждено во время митинга такого-то числа». И тогда, если вам понадобится email с митинг-минутками, вы будете знать нужную для поиска дату.

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

Как выбрать лучший инструмент?

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

• Адаптация к предпочтениям клиента. Некоторые опытные заказчики уже выбрали для себя удобный инструмент, например Trello. Конечно, лично вам он может оказаться некомфортным. Поинтересуйтесь, почему клиент выбрал именно эту платформу. Может, он просто не знает возможности других лучших систем? Тогда вы можете показать преимущества разных инструментов и выбрать удобный для вас обоих.
• Определение личности клиента. Все заказчики разные. Кто сразу реагирует на ваши обращения, а кто редко. У меня был проект, где клиент очень редко проверял накапливавшиеся десятками требования. Тогда я решила создать таблицу в Google Sheets, где отслеживала забытые требования и напоминала клиенту о них. У него также был доступ к этому документу и видел, какие требования ему нужно проверить. В конце концов, процесс быстрее.
• Оценка объема проекта. Никогда не усложняйте жизнь себе, команде, заказчику. Для маленького проекта имеет смысл брать обычный инструмент. Не стоит тратить на тулзу больше времени, чем продолжается сам проект.

Советы напоследок

• Определите требования по приоритету. Это отлично работает с Google Sheets и софтом для проджект-менеджмента. Объясните заказчику: «Обратите внимание, что в списке требования в порядке приоритетности!». Тогда клиент не будет выбирать сам, что проверять. Ведь некоторые проверяют требования, начиная с кратчайшего, что не всегда ОК для команды.
• Старайтесь получить точный ответ. Конкретное слово Approved, а не «Выглядит хорошо» или «Что-то вроде того». Точность важна не только учитывая проблемы честности. Это прежде всего нужно для понимания между вами и клиентом. Он может подумать, что вы сбросили только половину, поэтому и написал OK, а на самом деле ожидал еще чего-нибудь. Обычно я пишу прямо: «Посмотрите на это и, если вы согласны, напишите Approved». Так человек ясно понимает, что я от него ожидаю, и меньше тратит времени на размышления, как оформить ответ.
• Отслеживайте утвержденные и неутвержденные страницы. Когда страниц много, вы сами можете забыть, что среди них самое важное. Благодаря системе контроля вы убережетесь от ошибок и сэкономите время — свое и заказчика.
• Используйте историю перемен. Я не раз описывала этот функционал, но повторю: обращайтесь к нему! История изменений, например, в Trello или Asana — ваша защита на случай преднамеренных или случайных изменений.
• Не утверждайте требования в мессенджерах. Не имеет значения то Telegram, или Slack. Утверждение требований должно фиксироваться в отдельных системах или переписке на почте. Вам все равно придется отслеживать процессы аплева. Поэтому после каждой встречи в мессенджере вы будете отправлять на email митинг-минутки и собирать письменные утверждения.

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