Сбор требований для чайников и технарей

Вступление


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

Как собирать требования


Я хочу поделиться своим опытом сбора требований в области внедрения CRM систем, но думаю принципы, которые будут здесь описаны, подойдут и для других продуктов. Итак, с чего же начинается сбор требований. Естественно, с общения с заказчиком. Тут у нас есть два пути: непосредственное общение и анкетирование. Разберем оба варианта, с их плюсами и минусами.

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

Плюсы:

• Экономия времени
• Все ответы строго зафиксированы на бумаге
• Возможность собрать запросы с большого количества сотрудников

Минусы:

• На самом деле минус здесь глобальный один, но он нивелирует все плюсы. При заполнении анкеты, без установления личного контакта, без наводящих вопросов, без возможности посмотреть где и как работают сотрудники мы в 90% случаев не сможем определить все проблемы заказчика. Соответственно не сможем предложить наиболее подходящее решение. И как итог получим негатив на выходе, будем требования пересобирать, заново анализировать и т.д. (опыт есть)

Непосредственное общение.

Плюсы:

• Максимально полный разбор (при умении) проблем заказчика
• Возможность побеседовать со всеми сотрудниками и посмотреть за их работой

Минусы:

• Большие затраты по времени (опишу ниже)
• Существует вероятность что-то упустить или банально забыть записать (в последнее время использую диктофон)
• И, наконец, то ради чего собственно и пишется эта статья – необходимость говорить с людьми, которые могут или не полностью понимать, что вы предлагаете или не понимать совсем

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

Первое общение


На самом деле с заказчиком уже скорее всего общались и менеджер по продажам и менеджер проекта, но вот настало наше время. Тут опять же есть два пути: общение посредством средств связи (Skype, What`s Up, мобильная связь и т.д.) или же личная встреча. Не буду разбирать здесь плюсы и минусы, мне кажется они очевидны. Однако, если вы не хотите, чтобы во время разбора проходило следующее: «Мне… ы… лось чт…… ы… о.к…», «Вас не слышно» — «А СЕЙЧАС!!?», то я бы настоял на личной встрече. Опять же ситуации бывают разные, заказчик может быть из другого города, в таком случае выбора у нас нет. Но сейчас нас интересует

Личная встреча


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

Время и место разбора назначены, заказчик ждет вас, как же подготовиться ко встрече? Сейчас я скажу довольно банальные вещи, однако, многие не знают о них, а многие игнорируют, чего делать не стоит. Во-первых, выспитесь перед встречей и поешьте, если вы будете зевать, заказчик ответит вам тем же, поешьте, урчание вашего желудка может и вызовет жалость, но не поспособствует качественному разбору (про одежду и дезодорант писать не буду, думаю и так поня… Хотя нет! Люди, пользуйтесь дезодорантом!!!). Во-вторых, возьмите с собой набор чистых листов, пару ручек, ноутбук с материалами, если есть возможность, или, как минимум, пару распечаток того, как выглядит продукт, потому что часто заказчик не представляет себе интерфейса, а ваших художественных возможностей может не хватить. В-третьих, и это самое нарушаемое правило, не опаздывайте, вообще, никогда. Приходите за 15 минут до встречи, чаще всего вам придется проходить через некие проходные, что занимает время, плюс вы успеете сходить в туалет и ваши мысли во время разбора не будут заняты этим.

Все, мы выспались, сытые, пришли вовремя, встреча началась. Наступает еще один важный момент

Установление контакта с заказчиком


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

• Принимает решения и заинтересован (скорее всего это сам заказчик)
• Принимает решения и не заинтересован (это руководители отделов, которые считают, что все и так хорошо, нам предстоит их переубедить)
• Не принимает решения и заинтересован (интересная категория – их необходимо опросить, но все их запросы нужно будет потом согласовывать)
• Не принимает решения и не заинтересован (данная категория нам не интересна, просто надо знать, что она есть).

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

Сбор требований


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

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

• Основные направления деятельности (чем занимаетесь)
• Структура компании (отделы, подразделения, департаменты)
• Сотрудники (количество, качество)
• Можете ли назвать показатели, по которым можно понять успешна ваша деятельность или нет? Измеряете ли вы их?
• Кто ваши клиенты?

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

Блок 2. Нефункциональные требования

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

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

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

Блок 3. Функциональные требования

Это максимально специализированный блок. То есть конкретно под ваш продукт. Как он будет выглядеть в итоге, какие будут функции и т.д. (грубо говоря какого цвета и размера будет кнопка «Решить проблему заказчика»). Если вы технический специалист, то здесь начинается ваша любимая часть.

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

Подведение итогов


Еще раз, вкратце, ВКРАТЦЕ, потому что все устали и вы в том числе, пройдитесь по всем пунктам. Добейтесь согласия от заказчика по каждому из них, потом будет проще. Убедитесь, что ничего не забыли. Далее, если требуется, согласуйте дату следующей встречи, обговорите все дальнейшие действия и запишите их себе. Обменяйтесь с заказчиком контактными данными. Можете вставать и уходить.

Еще немного общей информации. Не делайте встречи более 4-4,5 часов, с учетом перерывов. После четвертого часа вы уже тяжело воспринимает информацию и можете упустить что-то важное или понять неправильно. И все предыдущие 4 часа пойду насмарку. Ничего страшного, если придется провести 2, 3, 4 и т.д. встречи, это лучше, чем месяц согласовывать сдачу проекта.

Вместо заключения


Не бойтесь заказчиков, они боятся вас больше, чем вы их.

В следующий раз немного углубимся в разбор CRM.
Метки:
сбор требований, общение с заказчиком, общение с клиентом, системная аналитика, ТЗ, разбор задач, запуск проекта

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