Про сбор требований написано очень много, но, наблюдая за коллегами-аналитиками, я вижу, что есть несколько моментов, которые не являются первостепенными, но которые существенно повышают успех встречи.
Подготовка к встрече
Аудитория и ее «боли»
Перед тем, как даже думать о встрече, желательно ответить себе на вопрос: «Кто эти люди, к которым вы идете? Что вы о них знаете? Что они знают о этой встрече, что они ожидают получить?».
Если это первая ваша встреча с этими людьми, скорее всего, уже есть какой-то человек (руководитель проекта, куратор итд) который уже общался с ними ранее, и может рассказать, чего ждать.
Чтобы не получить ответ от руководителя проектов «ребята прикольные, один блондин, другой брюнет и обоих зовут Виталий», нужно правильно задать вопросы о том, кто же ваши Заказчики:
-
Определить состав аудитории на встрече и определить точки интереса этой аудитории. Слушатели не будут вас слушать, пока они не поймут – что они получат, если вас послушают, ответят на ваши вопросы и потратят свои часы.
-
Узнать о процессах и выгодах, которые интересуют аудиторию, хотя бы поверхностно. Так вы покажете, что вы тоже поработали, а не желаете только собрать с них информацию в одностороннем порядке. Лайфхак — ознакомьтесь с терминологией, и употребляйте ее, так покажется, что вы «в теме». Яркий пример — для нефтяников словосочетание «добыча нефти» произносится с ударением на «о».
Цель встречи и повестка
Уверена, что вы были на встрече, где с первой минуты не понятно, зачем вы тут? Вы не единственные. У Заказчика тоже возникает такой вопросы, если до встречи недостаточно внятно договориться, зачем нужна встреча. Для этого есть отличный инструмент — повестка встречи. И да, любой аналитик сейчас посмотрит на меня и закатит глаза, «это же элементарно». Опять же, есть несколько моментов, которые важно знать.
Повестка может формироваться в любом виде (документ, словесно), но я чаще всего сталкивалась именно в виде описания в теле письма-приглашения на встречу. В любом случае, повестка должна содержать:
-
Цель встречи. Явно сформулированная цель позволит выровняться по тому, зачем собирается встреча. Так заказчик сможет пригласить со своей стороны нужных людей, а не всех подряд. Цель встречи — это вообще краеугольный камень подготовки к встречи. Причем цель может отличаться для вас и для заказчика. Держите в голове свои цели. Например, вы пришли прояснить какие-то пункты технического задания, а заказчик хочет «докинуть» фич сверху. Держите в голове всегда свои цели — что именно вам нужно получить от этой встречи. Знание этого позволит вам вернуть заказчика обратно в конструктивное русло. И открою секрет — если цель прописана в приглашении, всегда можно указать на то, что эта встреча собиралась по одному поводу, а вы уже начали обсуждать другое, и попросить вернуться к повестке. Дополнительным плюсом, чтобы уж совсем не расстраивать Заказчика, можно оговориться, что вы готовы обсуждать его пожелания, но на другой встрече.
-
Список вопросов к обсуждению. Также в приглашении ко встрече нужно сформулировать вопросы, на которые вы хотите получить ответ (желательно, формулировать их с руководителем проекта в порядке их приоритетности). Иногда бывает такое, что вся толпа, которую позвали на встречу, отвалится, и придут только те, которых касается вопрос. Я часто видела, что менеджер проекта приглашает как можно больше людей, не понимая, нужны они или нет, и все представители заказчика начинают генерировать идеи (что хорошо), но тот самый функциональный заказчик молчит — и на моменте согласования требований все, то что было нагенерировано, просто летит в корзину — оно не совпадает с целями создания системы.
Много работы до встречи по сбору требований? Да, к сожалению это так. Все это касается по большей части первых встреч, либо встреч с новой аудиторией.
Если вы постоянно собираете требования с одних и тех же людей, то можно пропускать пункт с аудиторией, но помнить про цели встречи и повестку. Хотя выяснение “болей” по тому или иному блоку функционалу позволит вам заранее настроиться на проблематику встречи и сократить сбор “жалоб” с заказчика, перейдя сразу же к решению.
Сама встреча
Итак, вы подготовились, пришли на встречу. Немного «покапитаню», но я много раз видела, что даже миддл и сеньор-аналитики приходили на встречу, волновались и забывали основные правила. Хард-скилы у всех были хорошие, но вот по софт-скиллам для встречи хочется пройтись.
-
Участники встречи. Запишите их имена, потом когда будете писать мемо, вспомните этот совет.
-
Помните про ваши цели встречи, но не добивайтесь ответов на вопросы насильно. Это нормально — возвращать к теме разговора. Но помните, что не нужно притворяться агентом ФРБ из того сериала, что вы смотрели вчера вечером, и сбор требований — не допрос. Не надо светить лампой в лицо и требовать ответов на вопрос. Если вам с одного вопроса не ответили, попробуйте переформулировать, возможно вас не поняли. Если и так не поняли — приведите пример.
-
Жаргон. Умоляю, говорите по-русски с бизнесом, оставьте agile-термины в пределах команды разработки. Если, конечно, бизнес не IT. И даже в таком случае, я бы все равно придерживалась русских терминов, потому что многие называют разными иностранными терминами одно и тоже (я много раз видела, что «спринт» и «релиз» — это одно и тоже, но из-за отличий в процессах вы можете говорить про одно, а заказчик думать про другое).
-
Накал страстей. Важно отслеживать настроение на встрече. Если вы начинаете понимать, что на той стороне злятся на ваши вопросы или ваше “непонимание”, можно попробовать смягчить вопросы, и рассказать о том, что вам важно понять сторону заказчика и проблематику, чтобы улучшить бизнес-процессы. То есть проявите эмоциональный интеллект и помогите представителям заказчика увидеть в вас человека, который искренне хочет помочь решить проблемы. Либо перестаньте перебивать другую сторону — на моем опыте, накал страстей начинает возникать в момент, когда собеседника постоянно перебивают (вы).
-
Дилемма истекающего времени встречи. На встрече есть поворотный момент, когда вы поймете, что стоите перед дилеммой — полностью выяснить все детали одного требования, или поверхностно, но по всем вопросам, с которым вы пришли. Тут придут на помощь ваши цели встречи. Потому что, надеюсь, вы формулировали их совместно с менеджером и там же определили приоритеты.
-
Финализация требований. Лучший способ разойтись довольные друг другом — это тогда, когда обе стороны понимают требования одинаково. Заказчик по умолчанию считает, что вы все поняли, потому что вы покивали головой. И это ваша непосредственная обязанность донести то, до чего договорились, до другой стороны. Попробуйте подвести итоги и рассказать про ожидания, что именно получится после реализации. Желательно, в терминах, которые являются промежуточными между терминами ИТ и терминами заказчика. Потому что если вы начнете употреблять термины только заказчика, не понимая досконально их сути, то может опять случиться непонимание результата. Например, я бы использовала простые слова, понятные всем, кто работает с системами: пользователь заходит в систему, вводя логин и пароль, попадает на главную страницу приложения, видит в пункте меню то-то и по клику открывается страница, где он вводит такие-то данные.
-
Просто хорошие манеры. Поблагодарите за встречу! Расскажите, какую полезную встречу вы все провели и как Заказчик вам помог. Тут важно быть искренним. Если не знаете, что сказать, простого «спасибо за встречу, было очень продуктивно / мы многое узнали итд» хватит.
Ранее я приводила идеальную картину подготовки к встрече, но бывает так, что никто не может вам ответить на вопросы до встречи. Что же делать? Я бы начала встречу с ваших целей, и попросила помощи в совместном погружении в проблематику. Люди склонны помогать — особенно, если они не одни на встрече, так подсознательно среди своих коллег они будут казаться “командными игроками”, и вы получите свои ответы на вопросы. Но тут кроются подводные камни, не нужно принижать себя и извиняться, искать оправдания вашему незнанию. Предложите совместно разобраться, так как мы все делаем все, чтобы система/ функция заработала. Тут главное слово “мы”. Я бы употребляла его почаще. Эмоционально людям проще открыться, когда вы подсознательно напоминаете, что все делаете одно дело.
После встречи
Хорошим тоном считается написанное мемо. Это зафиксированные договоренности между сторонами, со сроками и ответственными.
Я сама не большой фанат мемо — но только в том случае, если заказчик после встречи ждет описанные требования в согласованном формате. То есть заранее известно, например, что после встречи в течении 5 дней вы пришлете схему бизнес-процессов и макеты. В любом другом случае я советую всем писать мемо, особенно молодым аналитикам, только входящим в профессию.
Почему это важно?
-
Вы согласуете требования с менеджером проекта до того, как их отошлете заказчику. Так не будет неприятных сюрпризов, что вы взяли “на борт” реализации что-то, что не входит в границы проекта, а менеджер проекта узнает об этом из вашего письма заказчику.
-
Если что-то осталось непонятным или нелогичным, а вы поняли это только после встречи, разбирая свои заметки, это можно указать в мемо как вопрос к заказчику.
-
Снижается уровень напряженного ожидания после встречи — тревожный заказчик, особенно тот, у которого уже был негативный опыт работ с подрядчиком (или любыми другими разработчиками), будет знать, что вы поняли его правильно, а не потратите энное количество дней, описывая бизнес-процессы по неверно собранным требованиям.
-
В конце-концов, мемо может содержать не только ваши собранные требования, но и договоренности, которые были зафиксированы на встрече. Что-то должен прислать заказчик, что-то он должен уточнить, что-то вы должны прислать или посмотреть в ближайший срок. Это все стоит зафиксировать.
-
Не затягивайте с мемо — спустя неделю оно уже никому не нужно. Даже через три дня оно уже бестолковое. Я бы ставила границы — сутки, т.е. если встреча с утра, то максимум следующим утром до 12 мемо должно быть отправлено, именно тогда оно полезное.
Многие говорят, что мемо — это спустя время найти “правду” в требованиях. Но на моей памяти еще ни один заказчик не посыпал голову пеплом и не сказал: «ребята, вы реализовали как написано в мемо, а не как мы хотели, поэтому мы будем колоться и работать с неудобной системой». Все равно вы переделаете систему под удобство заказчика, как бы это не называлось — agile, опытная эксплуатация и так далее.
Спасибо за чтение, надеюсь мне удалось поделиться своим видением проведения встречи с заказчиком, и это будет хорошей подсказкой, как проводить такие встречи.
ссылка на оригинал статьи https://habr.com/ru/articles/832334/
Добавить комментарий