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

Подготовка к встрече

Аудитория и ее "боли"

Перед тем, как даже думать о встрече, желательно ответить себе на вопрос: "Кто эти люди, к которым вы идете? Что вы о них знаете? Что они знают о этой встрече, что они ожидают получить?".

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

Чтобы не получить ответ от руководителя проектов "ребята прикольные, один блондин, другой брюнет и обоих зовут Виталий", нужно правильно задать вопросы о том, кто же ваши Заказчики:

1. Определить состав аудитории на встрече и определить точки интереса этой аудитории. Слушатели не будут вас слушать, пока они не поймут – что они получат, если вас послушают, ответят на ваши вопросы и потратят свои часы.

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

Цель встречи и повестка

Уверена, что вы были на встрече, где с первой минуты не понятно, зачем вы тут? Вы не единственные. У Заказчика тоже возникает такой вопросы, если до встречи недостаточно внятно договориться, зачем нужна встреча. Для этого есть отличный инструмент - повестка встречи. И да, любой аналитик сейчас посмотрит на меня и закатит глаза, "это же элементарно". Опять же, есть несколько моментов, которые важно знать.

Повестка может формироваться в любом виде (документ, словесно), но я чаще всего сталкивалась именно в виде описания в теле письма-приглашения на встречу. В любом случае, повестка должна содержать:

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

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

Много работы до встречи по сбору требований? Да, к сожалению это так. Все это касается по большей части первых встреч, либо встреч с новой аудиторией.

Если вы постоянно собираете требования с одних и тех же людей, то можно пропускать пункт с аудиторией, но помнить про цели встречи и повестку. Хотя выяснение “болей” по тому или иному блоку функционалу позволит вам заранее настроиться на проблематику встречи и сократить сбор “жалоб” с заказчика, перейдя сразу же к решению.

Сама встреча

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

1. Участники встречи. Запишите их имена, потом когда будете писать мемо, вспомните этот совет.

2. Помните про ваши цели встречи, но не добивайтесь ответов на вопросы насильно. Это нормально - возвращать к теме разговора. Но помните, что не нужно притворяться агентом ФРБ из того сериала, что вы смотрели вчера вечером, и сбор требований - не допрос. Не надо светить лампой в лицо и требовать ответов на вопрос. Если вам с одного вопроса не ответили, попробуйте переформулировать, возможно вас не поняли. Если и так не поняли - приведите пример.

3. Жаргон. Умоляю, говорите по-русски с бизнесом, оставьте agile-термины в пределах команды разработки. Если, конечно, бизнес не IT. И даже в таком случае, я бы все равно придерживалась русских терминов, потому что многие называют разными иностранными терминами одно и тоже (я много раз видела, что "спринт" и "релиз" - это одно и тоже, но из-за отличий в процессах вы можете говорить про одно, а заказчик думать про другое).

4. Накал страстей. Важно отслеживать настроение на встрече. Если вы начинаете понимать, что на той стороне злятся на ваши вопросы или ваше “непонимание”, можно попробовать смягчить вопросы, и рассказать о том, что вам важно понять сторону заказчика и проблематику, чтобы улучшить бизнес-процессы. То есть проявите эмоциональный интеллект и помогите представителям заказчика увидеть в вас человека, который искренне хочет помочь решить проблемы. Либо перестаньте перебивать другую сторону - на моем опыте, накал страстей начинает возникать в момент, когда собеседника постоянно перебивают (вы).

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

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

7. Просто хорошие манеры. Поблагодарите за встречу! Расскажите, какую полезную встречу вы все провели и как Заказчик вам помог. Тут важно быть искренним. Если не знаете, что сказать, простого "спасибо за встречу, было очень продуктивно / мы многое узнали итд" хватит.

Ранее я приводила идеальную картину подготовки к встрече, но бывает так, что никто не может вам ответить на вопросы до встречи. Что же делать? Я бы начала встречу с ваших целей, и попросила помощи в совместном погружении в проблематику. Люди склонны помогать - особенно, если они не одни на встрече, так подсознательно среди своих коллег они будут казаться “командными игроками”, и вы получите свои ответы на вопросы. Но тут кроются подводные камни, не нужно принижать себя и извиняться, искать оправдания вашему незнанию. Предложите совместно разобраться, так как мы все делаем все, чтобы система/ функция заработала. Тут главное слово “мы”. Я бы употребляла его почаще. Эмоционально людям проще открыться, когда вы подсознательно напоминаете, что все делаете одно дело.

После встречи

Хорошим тоном считается написанное мемо. Это зафиксированные договоренности между сторонами, со сроками и ответственными.

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

Почему это важно?

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

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

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

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

5. Не затягивайте с мемо - спустя неделю оно уже никому не нужно. Даже через три дня оно уже бестолковое. Я бы ставила границы - сутки, т.е. если встреча с утра, то максимум следующим утром до 12 мемо должно быть отправлено, именно тогда оно полезное.

Многие говорят, что мемо - это спустя время найти “правду” в требованиях. Но на моей памяти еще ни один заказчик не посыпал голову пеплом и не сказал: "ребята, вы реализовали как написано в мемо, а не как мы хотели, поэтому мы будем колоться и работать с неудобной системой". Все равно вы переделаете систему под удобство заказчика, как бы это не называлось - agile, опытная эксплуатация и так далее.

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