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