Методы сбора требований
То, что ты говоришь и пишешь грамотно, не означает, что тебе не надо знать правила русского языка!
Мой учитель
3.7K открытий
Так говорил мой учитель, и я с ним полностью согласен (хоть грамотно писать все равно не научился). Поэтому я решил повторить материал, который когда-то был изучен на тему анализа данных и описания требований, а чтобы труды были как-то оцифрованы — поделиться материалом с тобой!
Ну, а теперь к теме статьи!
Сегодня мы тобой поговорим про методы сбора требований, которые может применять как аналитик, так и менеджер.
Сбор требований — это процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения поставленных целей. Ключевая выгода данного процесса состоит в том, что он предоставляет основу для определения содержания продукта и проекта. Этот процесс выполняется единожды или в предопределенные моменты в проекте.
Существуют разные методы сбора требований, а сегодня мы говорим, как мне кажется, о самых часто используемых:
- анализ данных;
- интервьюирование;
- анкетирование;
- работа в “полях”;
- мозговой штурм;
- бенчмаркинг.
Анализ данных
Анализ данных может в себя включать:
- изучение технической и нормативной информации;
- работа с приложением/продуктом;
- работа с набором данных (например отчет в excel, который необходимо автоматизировать);
- работа с программным кодом.
Анализ данных позволит тебе погрузиться в задачу и начать разговаривать с бизнесом на одном языке.
Твоя важная цель составить требования так, чтобы это не привело к нарушению существующих бизнес-процессов, поэтому важно погрузиться в предметную область, с которой ты сейчас работаешь.
Этот метод считается одним из самых трудоемких, но позволяет сформировать требования, основываясь на фактах работы системы или на основе нормативных документов.
Интервьюирование
Интервьюирование (интервью) – разновидность разговора, беседы между двумя и более людьми, при которой интервьюер задаёт вопросы своим собеседникам и получает от них ответы.
Интервьюирование, как по мне, один из самых эффективных методов сбора требований. Если ты провел интервью качественно, то, скорее всего, ты сможешь составить 80% требований на основе этой информации. Хоть данный метод и является в большей степени устный, не стоит пренебрегать протоколированием и согласованием результатов интервью.
Виды интевьюирования
По стадии исследования:
- предварительное — на данной стадии мы знакомимся с проблемой и ее источником. Уточняем перечень стейкхолдеров, которых необходимо включить в основную стадию и сроки начала основной стадии;
- основное — для начала этой стадии важно начать проработку требований и проблемы, которую обозначил бизнес на предварительной стадии. Это необходимо, чтобы сформировать “правильные” вопросы к основной стадии интервью. Не жди, что с тобой охотно поделятся информацией, ее придется доставать со слезами на глазах;
- контрольное — на этой стадии фиксируем результат, записываем новые хотелки бизнеса и, если они есть, фиксируем отклонения от исходных требований.
По количеству участников:
- индивидуальное — тут без комментариев, обычное общение с глазу на глаз;
- групповое — делите группы по интересам, не надо собирать одновременно отдел бухгалтерии и маркетинга;
- массовое — данный тип позволяет получить мнения большого количества человек. Обычно для этого используется анкетирование.
По степени формализации:
- стандартизованное — данный вид интервью позволяет ограничить рамки ответов, для этого необходимо подготовить варианты ответов на вопросы;
- фокусированное — в данном случае хорошо подойдут открытые и наводящие вопросы, главное не забывай держать фокус и не уходить от темы интервью;
- свободное или ненаправленное — данный тип интервью прекрасно подойдет на предварительной стадии, оно поможет вам понять “боль” бизнеса и запросить всю необходимую информацию, для начала анализа данных.
Анкетирование
Данный метод сбора требований предполагает специально оформленный список вопросов, закрытого и/или открытого типа. Анкетирование полезно для того, чтобы подтвердить или детализировать существующие требования или выбрать наиболее удачный вариант реализации.
Анкетирование может быть:
- общее или выборочное — анкетирование проводиться для всей имеющейся аудитории или для определенной фокус-группы;
- очное или заочное — анкетер может быть в аудитории или проводить анкетирование дистанционно.
Работа в «полях»
Данный метод особенно любят госкомпании и заводы из-за высокой степени загруженности (да-да, у них реально никто не выделяет время на интервью в чистом виде). Оформляешь командировку и бегом к бизнесу в “поля”.
Твоя задача максимально точно считать процессом работы в среде бизнеса. Представь, что менеджер по продажам рассказывает тебе, как создавать клиента, оформляет клиенту карту лояльности или оформляет доставку на заказ. В этот момент он не демонстрирует программные средства, с помощью которых он выполняет эти действия. В результате такого интервью сложно повторить процесс в системе, в которой работает менеджер по продажам и, следовательно, сложно качественно описать требования.
Работа в “полях” имеет большое значение, когда вы не владеете предметной областью, позволяет избежать недопонимания, которое может возникнуть при проведении интервью, которое не предусматривает использование приложения/продукта бизнеса.
Работа в “полях” тесно переплетена с основной и контрольной стадией интервью.
Мозговой штурм
Мозговой штурм целесообразно использовать, когда нужны новые идеи или творческие решения задач.
Любой мозговой штурм состоит из двух этапов:
- генерация идей;
- отбор идей.
Среднее время генерации идей составляет один час.
Правила генерации идей:
- каждая идея фиксируется ведущим мозгового штурма со слов автора;
- идея не обсуждается в процессе генерации идей;
- мозговой штурм продолжается, пока все участники не почувствуют, что достигли логического конца/исчерпали идеи.
- фильтрация идей;
- группировка и уточнение идей;
- расстановка приоритетов.
Бенчмаркинг
Бенчмаркинг (эталонное оценивание) — сопоставительный анализ на основе эталонных показателей как процесс определения, понимания и адаптации имеющихся примеров эффективного функционирования предприятия с целью улучшения собственной работы.
Анализ включает в себя два процесса:
- оценивание;
- сопоставление.
Обычно за образец принимают «лучшую» продукцию или и маркетинговый процесс прямых конкурентов, используемые прямыми конкурентами, работающими в подобных областях, для выявления фирмой возможных способов совершенствования её собственных продуктов и методов работы.
Ну, а если по-простому, то мы берем существующие решения, стандарты, методики и примеряем это на себя. Если после примерки выглядим хорошо и нигде не трет, а результативность наша выросла, то надо брать.
Этот метод позволяет наиболее точно составить требования, т.к. все уже реализовано, а тебе остается только переиспользовать имеющиеся наработки, с учетом собственных бизнес-процессов, нормативных документов и пожеланий бизнеса.
Сбор требований является важным подготовительным этапом в любой деятельности, а особенно в ИТ. Уделите время тому, чтобы сформировать хорошие навыки сбора требований и не забывайте повышать уровень своих скилы.
Сбор требований для чайников и технарей
Одна из основных проблем, с которой сталкивается большинство технических специалистов — это общение с заказчиком. Причем эта проблема стоит настолько остро, что была придумана специальная профессия «Системный аналитик», т.е. по сути человек, который выступает некой прослойкой или переводчиком между обеими сторонами. И все бы было ничего, но большинство системных аналитиков выходят из той же технической среды, потому что им необходимо знать мат часть. Вот для них, по большей части, и написана эта статья.
Как собирать требования
Я хочу поделиться своим опытом сбора требований в области внедрения CRM систем, но думаю принципы, которые будут здесь описаны, подойдут и для других продуктов. Итак, с чего же начинается сбор требований. Естественно, с общения с заказчиком. Тут у нас есть два пути: непосредственное общение и анкетирование. Разберем оба варианта, с их плюсами и минусами.
Анкетирование. Мы высылаем заказчику анкеты для заполнения, с указанием кто из сотрудников должен их заполнить. Затем собираем, анализируем и выдаем некий итог.
• Экономия времени
• Все ответы строго зафиксированы на бумаге
• Возможность собрать запросы с большого количества сотрудников
• На самом деле минус здесь глобальный один, но он нивелирует все плюсы. При заполнении анкеты, без установления личного контакта, без наводящих вопросов, без возможности посмотреть где и как работают сотрудники мы в 90% случаев не сможем определить все проблемы заказчика. Соответственно не сможем предложить наиболее подходящее решение. И как итог получим негатив на выходе, будем требования пересобирать, заново анализировать и т.д. (опыт есть)
• Максимально полный разбор (при умении) проблем заказчика
• Возможность побеседовать со всеми сотрудниками и посмотреть за их работой
• Большие затраты по времени (опишу ниже)
• Существует вероятность что-то упустить или банально забыть записать (в последнее время использую диктофон)
• И, наконец, то ради чего собственно и пишется эта статья – необходимость говорить с людьми, которые могут или не полностью понимать, что вы предлагаете или не понимать совсем
Как, наверное, понятно из текста выше я предпочитаю непосредственное общение с заказчиком. В редких случаях прошу некоторых сотрудников, чье мнение не очень важно, но они будут пользоваться продуктом, заполнить некие формы, чтобы они тоже принимали участие и были более заинтересованы в процессе внедрения. И исходя из этого у нас происходит
Первое общение
На самом деле с заказчиком уже скорее всего общались и менеджер по продажам и менеджер проекта, но вот настало наше время. Тут опять же есть два пути: общение посредством средств связи (Skype, What`s Up, мобильная связь и т.д.) или же личная встреча. Не буду разбирать здесь плюсы и минусы, мне кажется они очевидны. Однако, если вы не хотите, чтобы во время разбора проходило следующее: «Мне… ы… лось чт…… ы… о.к…», «Вас не слышно» — «А СЕЙЧАС. », то я бы настоял на личной встрече. Опять же ситуации бывают разные, заказчик может быть из другого города, в таком случае выбора у нас нет. Но сейчас нас интересует
Личная встреча
Возможно я когда-нибудь напишу статью и про разбор через средства связи, но позже. Итак, вы или менеджер проекта согласуете встречу с заказчиком. Сразу предупредите его, что процесс сбора требований занимает минимум три часа (и это в небольшой компании), при этом его не должны много отвлекать и должна быть возможность привлечь к общению других сотрудников. По моему опыту, встречи лучше проводить в первой половине дня, потому что, если начинать после обеда возможна ситуация, когда сотрудники будут спешить уйти домой и разбор не получится полноценным.
Время и место разбора назначены, заказчик ждет вас, как же подготовиться ко встрече? Сейчас я скажу довольно банальные вещи, однако, многие не знают о них, а многие игнорируют, чего делать не стоит. Во-первых, выспитесь перед встречей и поешьте, если вы будете зевать, заказчик ответит вам тем же, поешьте, урчание вашего желудка может и вызовет жалость, но не поспособствует качественному разбору (про одежду и дезодорант писать не буду, думаю и так поня… Хотя нет! Люди, пользуйтесь дезодорантом. ). Во-вторых, возьмите с собой набор чистых листов, пару ручек, ноутбук с материалами, если есть возможность, или, как минимум, пару распечаток того, как выглядит продукт, потому что часто заказчик не представляет себе интерфейса, а ваших художественных возможностей может не хватить. В-третьих, и это самое нарушаемое правило, не опаздывайте, вообще, никогда. Приходите за 15 минут до встречи, чаще всего вам придется проходить через некие проходные, что занимает время, плюс вы успеете сходить в туалет и ваши мысли во время разбора не будут заняты этим.
Все, мы выспались, сытые, пришли вовремя, встреча началась. Наступает еще один важный момент
Установление контакта с заказчиком
Скорее всего, вам предложат кофе или чай, не отказывайтесь, можете даже не пить. А вот от еды откажитесь, не стоит жевать перед заказчиком, а при попытке ответить — усыпать стол крошками. Когда садитесь за стол – постарайтесь сесть напротив человека, с которым будет происходить общение. Если людей несколько, садитесь так, чтобы не оказаться между ними.
При начале общения, поздоровайтесь и представьтесь, они представятся в ответ – запомните имена, это важно. Опишите, вкратце, как будет происходить разбор. В процессе дальнейшего общения вам необходимо будет выделить для себя несколько категорий людей:
• Принимает решения и заинтересован (скорее всего это сам заказчик)
• Принимает решения и не заинтересован (это руководители отделов, которые считают, что все и так хорошо, нам предстоит их переубедить)
• Не принимает решения и заинтересован (интересная категория – их необходимо опросить, но все их запросы нужно будет потом согласовывать)
• Не принимает решения и не заинтересован (данная категория нам не интересна, просто надо знать, что она есть).
Вам с самого начала нужно понять в каком ключе идет беседа. Если все крайне серьезно (что на самом деле встречается очень редко, даже у крупных заказчиков), то и вы ведите себя соответственно: не шутите, не отходите от темы, старайтесь как можно больше информации фиксировать. Если обстановка более расслабленная, то тут будут уместны и небольшие шутки из разряда «На ноутбуке не могу показать, вот на вас заработаю миллионы и куплю себе», однако перебарщивать не стоит – это удлиняет время разбора и усложняет возврат в рабочее русло. И тут мы переходим непосредственно к…
Сбор требований
На мой взгляд, весь процесс сбора требований, независимо от размера компании состоит из трех больших блоков. Просто если компания маленькая, то мы эти три блока применяем ко всей компании целиком, а если большая, то к каждому отделу.
Блок 1. Общая информация. Многие забывают про это и сразу переходят к функционалу, однако, этот этап один из самых важных, как для аналитики, так и для установления контакта с заказчиком. Как же эта информация собирается? Вы просите заказчика самого рассказать о своей компании, и все, большинство собственников бизнеса с удовольствием рассказывают о себе. Тем не менее нам необходимо иногда подталкивать его рассказ в нужное нам русло. И в случае, если заказчик не очень общителен, мы тоже задаем ему эти наводящие вопросы:
• Основные направления деятельности (чем занимаетесь)
• Структура компании (отделы, подразделения, департаменты)
• Сотрудники (количество, качество)
• Можете ли назвать показатели, по которым можно понять успешна ваша деятельность или нет? Измеряете ли вы их?
• Кто ваши клиенты?
Вопросов может быть много, все зависит от величины заказчика и направления его деятельности. Кстати, важный момент, перед встречей ознакомьтесь с той информацией о заказчике, которую можно найти в свободном доступе. На встрече это покажет вашу заинтересованность и позволит не задавать глупых вопросов.
Блок 2. Нефункциональные требования
Этот блок уже более специфичный и зависит от того, какой продукт вы предлагаете. Однако есть несколько общих вещей, которые необходимо узнать.
• Проблемы, которые знает заказчик: описание, почему она есть, как он решает ее сейчас, как хотел бы решать
• Проблемы, о которых не знает заказчик, но которые есть у большинства, исходя из вашего опыта. Называете проблему, если заказчик согласен, что она есть, описываете решение.
• Проблемы, которые вы увидели при общении с заказчиком. Называете проблему, если заказчик согласен, что она есть, придумываете решение совместно или предлагаете свое.
Обязательно фиксируйте все проблемы у себя. После того как все проблемы описаны, обсудите с заказчиком приоритетность решения данных проблем, а также разбейте их на три категории: делаем обязательно, хорошо бы сделать и хотелось бы, но не принципиально. Пробегитесь еще раз вместе с заказчиком (тут подразумевается то лицо, с которым вы общаетесь или группа лиц) по списку, может всплывет дополнительная информация. Если вы производите опрос с разными отделами, то итоговый список проблем в любом случае надо будет согласовывать с руководителем.
Блок 3. Функциональные требования
Это максимально специализированный блок. То есть конкретно под ваш продукт. Как он будет выглядеть в итоге, какие будут функции и т.д. (грубо говоря какого цвета и размера будет кнопка «Решить проблему заказчика»). Если вы технический специалист, то здесь начинается ваша любимая часть.
Здесь, однако, не стоит ни в коем случае забывать, что заказчик, очень часто, вообще не представляет, о чем идет речь. Поэтому, каждый термин, который вы называете надо уметь объяснить заказчику, а еще лучше привести пример из его сферы деятельности. Тут нам как раз пригодится ноутбук или распечатки с примерами. Не погружайтесь слишком глубоко, опишите общее представление – главное, чтобы оно сошлось у вас с заказчиком. Ему не очень интересно какой и где вы будете дописывать код, главное, чтобы это выглядело и работало так как он хочет. После того как, на ваш взгляд, вы описали все, что нужно, переходите к следующему этапу.
Подведение итогов
Еще раз, вкратце, ВКРАТЦЕ, потому что все устали и вы в том числе, пройдитесь по всем пунктам. Добейтесь согласия от заказчика по каждому из них, потом будет проще. Убедитесь, что ничего не забыли. Далее, если требуется, согласуйте дату следующей встречи, обговорите все дальнейшие действия и запишите их себе. Обменяйтесь с заказчиком контактными данными. Можете вставать и уходить.
Еще немного общей информации. Не делайте встречи более 4-4,5 часов, с учетом перерывов. После четвертого часа вы уже тяжело воспринимает информацию и можете упустить что-то важное или понять неправильно. И все предыдущие 4 часа пойду насмарку. Ничего страшного, если придется провести 2, 3, 4 и т.д. встречи, это лучше, чем месяц согласовывать сдачу проекта.
Вместо заключения
Не бойтесь заказчиков, они боятся вас больше, чем вы их.
В следующий раз немного углубимся в разбор CRM.
Как собирать требования аналитику
Основная задача этой техники – обеспечить структуру в неопределенной ситуации.
Мы еще только приступаем к работе над проектом, и информация о том, что делать, с
кем работать, какой будет результат проекта, еще недостаточно формализована. Для
того, чтобы в этой ситуации не наделать много ненужной работы – то есть не
вовлекать лишних людей, не переделывать, не формировать документы, которые
никому не будут нужны, – необходимо процесс планировать: создать структуру,
которая позволит нам эффективно действовать в условиях неопределенности.
Для того, чтобы спланировать процесс выявления требований, нам нужно, выполнить следующие шаги.
- Первое – определить цели выявления требований: кто является заказчиком этого процесса, кто будет работать с теми требованиями, которые мы соберем, зачем это делается.
- Следующий шаг – проанализировать и определить, какие существуют источники требований: откуда мы можем черпать информацию для того, чтобы эти требования определить.
- Исходя из полученных целей и источников требований, которые нам доступны, мы выбираем шаги и техники, которые мы будем применять для того, чтобы эти требования извлечь и зафиксировать.
- Следующий шаг, обязательный в любой задаче – согласовать с теми, кто будет пользоваться результатами нашей работы, форму результатов. То есть, как мы должны оформить требования.
- Возможно, будет достаточно неформального описания, иногда такое бывает.
- Возможно, кто-то планирует работать над проектом в формате гибких методологий, и, по большому счету, ему нужен некий story board, некая информация для команды, с которой нужно начать, и нет необходимости формальных спецификаций.
- В каких-то ситуациях проект в дальнейшем будет передаваться на аутсорсинг или на исполнение независимым исполнителем, и соответственно, требования должны быть сформулированы максимально детально и точно.
Очень важный факт: абсолютное и календарное время в процессе работы с
требованиями очень часто не соответствует друг другу, потому что для того, чтобы
получить ту или иную информацию от представителя заказчика, необходимо, чтобы
мы смогли с ним встретиться и обсудить соответствующие вопросы. Поэтому, прежде чем предоставить календарный план заказчику, необходимо убедиться, что в
календарном плане присутствует взаимодействие со всеми необходимыми людьми, и эти люди подтвердили возможность взаимодействовать с нами в этот период времени.Для коллег, которые думают, что это слишком большие усилия: если у нас возникает
проблема договориться о том, чтобы аналитик пообщался с заказчиком, представьте
себе, насколько проблематично будет обеспечить свободный доступ разработчиков с целью получить информацию от того же самого представителя заказчика в тот
момент, когда возникнет потребность у разработчика.Поэтому, если у нас возникают проблемы с формированием календарного плана, или мы не знаем, каким образом это обеспечить для сбора требований, такие проблемы, если не гораздо серьезней, гарантированно возникнут у команды разработки, если этого не будет сделано.
И последний этап, связанный с любым планированием – необходимо оценить те
риски, те последствия, которые возникают из-за принятых решений.К примеру, если мы решили не дожидаться выхода из отпуска какого-то из
специалистов заказчика и начать разработку до того, как получим от него
некоторые данные или информацию, мы должны четко сформулировать, в какой
области у нас возникает риск и что с ним нужно сделать.На осуществление планирования процесса выявления требований опытному
специалисту, как правило, требуется около 8 часов. Ответы на необходимые вопросы
о том, как будут использованы результаты работы аналитиков, можно получить от
руководителя проекта или координатора.Источники требований
Источники требований очень сильно зависят от специфики проекта.
Возможные источники требований:- беседы/обсуждения с потенциальными пользователями;
- документы, описывающие существующие или конкурирующие продукты;
- спецификации требований к системам;
- отчеты об ошибках / запросы по совершенствованию / претензии к возможностям работающей системы;
- маркетинговые исследования / опросы пользователей;
- наблюдение за пользователями на рабочих местах;
- анализ сценариев задач пользователей.
Обязательно необходимо встретиться и пообщаться с пользователями продукта,
которые будут использовать нашу систему либо прямо, либо косвенно.Можно найти документы, которые описывают существующую систему, существующий контекст или конкурирующие продукты, которые рассматриваются в качестве альтернативы для нашего решения.
Очень важным моментом, особенно когда одновременно в экосистеме разрабатываются и формируются множество систем, является наличие информации о системах, с которыми мы будем работать. Как правило, наиболее полная информация, связанная с назначением систем находится в требованиях к системам.
Очень интересный источник информации – отчеты об ошибках и запросы по совершенствованию. Служба поддержки, как правило, очень много взаимодействует
непосредственно с пользователями. Если для того, чтобы обеспечить контакт аналитика с пользователем, необходимо достаточно много времени, и аналитик должен встречаться с каждым пользователем, то люди из поддержки, которые в компании уже достаточно длительное время взаимодействуют с этой категорией пользователей, знают все основные болевые точки существующих решений. Поэтому служба поддержки для соответствующей области бизнеса – один из очень интересных и важных источников информации о том, что необходимо разработать и что нужно сделать.Также могут быть использованы маркетинговые исследования. Под маркетинговыми исследованиями подразумеваются либо кабинетные исследования, когда мы собираем информацию из общедоступных источников (социальных сетей, форумов), либо целенаправленно проведенные опросы пользователей, когда мы работаем, например, над разработкой продукта, и нам необходимо встречаться не просто с конкретными представителями заказчика, а собрать значимое количество релевантных требований и потребностей.
Очень важным элементом является даже не столько техника, сколько хорошее
дополнение к интервью или работе с заказчиком – наблюдение за пользователем на
рабочем месте, как он выполняет те задачи, которые предполагается либо
автоматизировать, либо с той системой, которую предлагается заменить.Очень часто в процессе работы выявляется значимое количество информации и
дополнений, которые помогают понять, по какой причине требуется заменить
приложение, или по какой причине у нас могут возникнуть сложности с новыми идеями и концепцией.И мы можем осуществлять анализ различных сценариев, их взаимодействий, как с
точки зрения достижения бизнес-целей, так и с точки зрения взаимодействий и
достижения целей отдельных пользователей.Анализ документации
- сократить время и ресурсы, затрачиваемые заказчиком на передачу знаний и информации;
- получение информации, которой уже или еще не владеют представители заказчика.
- Определить перечень и релевантность имеющейся документации.
- Убедиться в релевантности полученной документации.
- Осуществить анализ и подготовить перечень вопросов для дальнейшего анализа с экспертами.
- является частью работы с большинством других техник.
- 1 час на 2-32 страницы текста документации.
Одна из наиболее простых, самых распространённых и, наверно, самых недооцененных техник извлечения требований – это анализ документации.
Несмотря на то, что в большинстве случаев наиболее актуальной информацией
обладают люди, полной информацией о том, как устроена та или иная система или
каким образом происходит взаимодействие людей не обладает ни один человек. Эта
информация принадлежит или содержится в головах у многих представителей
заказчика.Очень часто для того, чтобы обеспечить те или иные виды работ, происходит работа
над сбором этой информации, ее обработка и согласование.Чтобы сэкономить время, очень желательно найти и ознакомиться с теми результатами документирования и описания существующей системы и ее предметной области, которые уже были сделаны.
Две основных цели анализа документации – 1) сократить время и повысить уважение заказчика к аналитикам или разработчикам, которые с ним работают; 2) получить ту информацию, которой уже, возможно, никто из представителей заказчика не обладает или еще не обладает.
Основные шаги по реализации анализа документации:
- Определить документацию, которая у нас есть, и получить информацию о том, с какой информацией необходимо или желательно работать. Мы приходим к представителю заказчика и выясняем, с какими из найденных нами документов – к примеру, это могут быть какие-то отчеты организации, книжки, статьи — с точки зрения заказчика нам стоит ознакомиться, и какие из этих документов релевантны тому, что сейчас происходит в организации.
- После того, как мы получили эту документацию, нужно убедиться в том, что документы, с которыми мы с вами работаем – это действительно те документы, которые нам нужны. Очень часто в организациях возникает путаница, и по той или иной причине к аналитикам могут попасть документы, которые либо не последней версии, либо не соответствуют действительности. Помимо перечня документов нужно убедиться, что тот документ, который у вас есть, действительно важен.
Я так много внимания уделяю этому вопросу, потому что в моей практике была ситуация, когда для работ по подготовке требований к системе и оценки проекта была передана документация, разработанная (в течение 3 лет) очень уважаемой зарубежной консалтинговой компанией, и там было около 600 содержательных страниц.
Нам повезло – мы осуществили проверку на релевантность информации, которая есть в этом документе, и, как оказалось, компания, для которой осуществлялся этот консалтинговый проект, буквально за пару месяцев до инициации нашего проекта осуществила реструктуризацию, сменила функции и начала реструктуризацию бизнес-процессов таким образом, что большая часть информации, которая содержалась в отчёте этой уважаемой консалтинговой компании, оказалась не релевантной.
Представляете, сколько бы времени заняла проработка и работа с документами !?
Хотелось бы обратить ваше внимание, что очень часто недооценивается не только
важность документации, но и время, которое необходимо на работу с документацией.
В зависимости от сложности содержания, стандарт на проработку либо ревью, либо на ознакомление с документацией составляет от 2 до 32 страниц текста в час. Причем, когда мы говорим о 32 страницах текста, это скорость, с которой человек просто ознакамливается с документацией, а не прорабатывает детально предметную область и формирует модель.Одним из основных результатов работы с документацией является конкретный
артефакт, над которым мы работаем, и/ или перечень вопросов, которые необходимо
уточнить.Техника анализа документации применяется практически при всех остальных техниках. Даже не совсем корректно называть ее техникой, это скорее здравый смысл – сначала ознакомиться с тем, что уже сформулировано, прежде чем создавать свой велосипед.
Интервью
Техника, которая может быть применена и при анализе проблемы, и извлечении потребностей.
- получить понимание реальных проблем и потенциальных решений с точки зрения пользователей, заказчиков и других заинтересованных лиц.
- Определить перечень лиц для интервью.
- Подготовить цели и вопросы.
- Согласовать календарь встреч.
- Провести интервью.
- Осуществлять обработку материалов интервью.
- 3-4 часа для каждого интервьюируемого специалиста (1 час — подготовку, 1 час — интервью, 1-2 часа — обработка).
Один из самых важных процессов, который происходит при сборе, извлечении
требований – это проведение интервью.Одна из основных целей интервью – получить понимание реальных проблем и
потенциальных решений с точки зрения пользователей, заказчиков и других
заинтересованных лиц. При этом, нам необходимо сформировать и обеспечить
возможность для действительно доверительных отношений между заказчиком и
исполнителем.При проведении интервью, как правило, контакт между представителем команды
заказчика и представителем команды исполнителя устанавливается впервые. И
возможность в дальнейшем использовать те или иные средства, скорость коммуникации и взаимодействия, зависит от того, насколько в рамках первой встречи удастся наладить контакт и взаимопонимание и обеспечить основу для дальнейшего сотрудничества.Основные шаги, которые необходимо предпринять для того, чтобы интервью было
эффективным:- Сформировать полный перечень заинтересованных лиц и пользователей, с которыми мы собираемся провести интервью. В каждой группе пользователей, необходимо выделить, как правило, двух специалистов, с которыми будем проводить интервью (один специалист предоставит нам однобокий или, возможно, специфический взгляд на проект).
- Необходимо учитывать, что, скорее всего, в процессе первичных интервью у нас появятся кандидаты на дополнительное интервьюирование. Дополнительный список интервью обычно составляет около 50% от первичного.
- К каждому интервью необходимо подготовить цели (ради чего мы встречаемся с данным конкретным человеком), и вопросы, которые мы собираемся ему задать.
В больших структурах представители заказчика часто уже настолько издерганы и замучены различными компаниями, которые для них что-то реализовывают, что если вы не пришлете им заранее список вопросов, на которые им необходимо будет ответить, и вопросы, которые вы хотите решить, то, возможно, они даже не будут с вами встречаться. - Согласовать календарь встреч. В календаре встреч нужно учесть время, которое вам необходимо для первичного интервью, и заранее оговорить возможность встретиться с этим человеком позднее (учесть возможность повторного интервью).
- Проведение интервью. В отдельном уроке остановимся на этом вопросе и рассмотрим более детально.
- Обработка материалов интервью. Люди очень часто планируют время на осуществление взаимодействия, но не планируют времени на то, чтобы обработать информацию.
Итак, при планировании интервью обязательно учитывайте время на подготовку, на
интервью и на обработку материалов, полученных во время интервьюирования.Совместная сессия работы над требованиями (Requirements
Workshops)- ускорение процесса сбора требований;
- сокращение времени, необходимого на валидацию и согласование собранных требований.
- собирает всех заинтересованных лиц вместе для интенсивного общения;
- ведущий управляет обсуждением (фасилитирует);
- результаты становятся доступны мгновенно;
- обеспечивает контекст для применения других техник.
- 12-40 часов для подготовки и проведения мероприятия (2-8 часов — подготовка, 4-16 часов — сессия, 8-20 часов — обработка).
В ситуации, когда в проекте или создаваемом продукте очень большое количество
заинтересованных сторон и заказчиков, индивидуальное взаимодействие и работа с
каждым заказчиком может оказаться достаточно длительным процессом, который может внести значительные задержки в календарный план.Более того, челночные переговоры в той ситуации, в которой согласование обсуждения вопросов с одним из заказчиков приводит к конфликту информации, которая получена от другого заказчика, в индивидуальном порядке зачастую не решается.
Как мы уже знаем, на интервью отдельного специалиста необходимо планировать
около 3-4 часов. Соответственно, если есть порядка 20 пользователей или заинтересованных сторон, с которыми нужно проработать требования к нашему продукту, получится календарь в 80 часов работ только на осуществление интервьюирования и без возможных проблем с накладками, когда тот или иной специалист будет недоступен.Чтобы избежать «челночных» переговоров, можно применять специальную форму групповой работы, которая называется Requirements Workshops, или совместная сессия работы над требованиями. В рамках работы в группе мы:
- Ускоряем процесс сбора требований. Мы помещаем представителей заинтересованных лиц в одну среду, в которой происходит одновременный обмен мнением и валидация тех или иных предположений.
- Когда мы собираем большое количество заинтересованных сторон в одном месте, одна из важнейших и сложных задач – обеспечить эффективную работу людей всех вместе. Многие знают по собственному опыту, что как только на собрании собирается 5-7 человек, результатов у такого совещания, как правило, бывает немного. Через час-два после начала работы люди переходят в конфликтные позиции, и решить те или иные вопросы зачастую не удается. Для того, чтобы этого избежать, необходимо, чтобы ведущий такого Workshop’а осуществлял фасилитацию, или управление процессом.
Из дополнительных плюсов, которые можно отнести к проведению Workshop’а – результаты становятся доступны мгновенно. Все ключевые заинтересованные лица собраны вместе, и их участие обеспечивает возможность сразу валидировать или согласовать те или иные гипотезы в процессе Workshop.
Среднестатистическое время, необходимое, чтобы провести небольшой Workshop на 3-4 человека — 8 часов.
Если это действительно масштабное мероприятие, то уйдет как минимум один-два рабочих дня на его подготовку и, в зависимости от того, что мы делаем, либо 4-х часовая, либо двухдневная сессия. Двухдневная сессия – это достаточно большая редкость, тем не менее, для больших продуктов с большими направлениями 2 дня бывает в самый раз.
Необходимо запланировать дополнительное время на обработку результатов Workshop’а. Несмотря на то, что результаты стали доступны мгновенно, и все участники Workshop’а знают о решениях, которые были приняты на Workshop’е, необходимо обеспечить долговременную память о достигнутых договоренностях. Иногда это можно сделать, фотографируя материалы, которые были разработаны на самом Workshop’е. Но лучше, если результаты будут зафиксированы в виде документа.
Контекстная диаграмма
- определение и описание контекста проекта / системы для определения границ и полноты требований к системе
- Определить заинтересованные лица и роли, взаимодействующие с системой.
- Выявить системы, с которыми необходимо взаимодействие.
- Определить ограничения, накладываемые на систему.
- Определить характер взаимодействия системы с внешними объектами.
- 4-16 часов, эксперт в предметной области, эксперт в области существующего решения.
Контекстная диаграмма – это один из самых старых и самых системных инструментов в арсенале работы аналитика. Контекстная диаграмма разделяет все пространство решений, информационное пространство на область, которая относится к объекту, для которого строится контекст, и все то, что не относится к системе, но так или иначе обладает влиянием. Объекты в контексте могут может иметь требования или накладывать ограничения на реализацию самой системы.
Существует много различных вариантов контекстной диаграммы – так или иначе смысл воспроизводится во многих техниках. Наибольшее распространение получила так называемая луковая модель заинтересованных лиц, в которой разделяется прямой контекст, непрямой контекст и всё остальное.
Поскольку это – одна из основных техник работы аналитика с пространством решений, мы подробнее остановимся на технике составления контекстной диаграммы дальше, а сейчас поговорим о том, каким образом контекстная диаграмма применяется.
Основная цель техники – обеспечить возможность для эффективного сбора требований и идентификации всех заинтересованных сторон, которые могут иметь интересы или накладывать ограничения на реализацию нашей системы.
Это – основной инструмент определения границ и достижения полноты требований к системе.
Для того, чтобы создать контекстную диаграмму, необходимо вначале определить заинтересованные лица и роли, которые осуществляют взаимодействие с системой. После этого выявить системы, с которыми необходимо осуществлять взаимодействие.
Дальше нужно понять, кто и какие ограничения накладывает на систему, которую мы будем модифицировать или разрабатывать.
И последний шаг – обозначить характер взаимодействия системы со всеми выделенными ранее внешними объектами.
Определив все объекты, которые должны будут взаимодействовать с системой, мы формируем границу, в рамках которой решение должно быть реализовано.
На создание контекстной диаграммы в коммерческом проекте я рекомендую резервировать от 4 до 16 часов, в зависимости от сложности решения.
Для того, чтобы создать контекстную диаграмму, потребуется доступ к экспертам в предметной области, которые расскажут, каким образом с точки зрения бизнес-целей система будет использоваться и, соответственно, какие требования и ограничения могут быть наложены. И доступ к эксперту в области существующего и будущего решения, чтобы определить, с какими системами нам потребуется взаимодействовать и какие особенности у системы будут в процессе замещения одной системы другой.
Бизнес моделирование процессов
- изучение и понимание организации;
- визуализация организации и ее процессов и коммуникация это информации другим участникам разработки;
- выявления и упорядочивания бизнес-требований;
- дальнейшего реинжиниринга бизнес-процессов.
- 4-16 часов на каждый выявленный процесс, эксперт в предметной области, эксперт в области существующего решения.
Моделирование бизнес-процессов и моделирование бизнеса, как такового – это техника, которая позволяет нам структурировать контекст, внешнюю часть системы, которая оказывает наиболее значимое влияние на продукт или систему, которую мы разрабатываем.
Бизнес-моделирование применяют во многих случаях.
Одна из наиболее распространенных ситуаций – когда необходимо улучшить наше понимание и изучить организацию. Когда мы выделяем какой-то процесс или аспект системы и структурируем его в виде модели, модель позволяет нам задавать дополнительные вопросы и понять, где находятся белые пятна в нашем понимании того, как организация функционирует.
Следующая цель моделирования бизнес-процессов – визуализировать организацию и ее процессы так, чтобы можно было эффективно и быстро коммуницировать то, как организация работает, как она устроена, другим участникам процесса разработки.
Еще одно применение – выявить и упорядочить бизнес-требования. Так или иначе, система, которую мы разрабатываем, информационно существует и функционирует в контексте процессов, которыми организация создает ценность для своих клиентов. Чтобы упорядочить и сформулировать все требования, которые возникают с точки зрения достижения целей организации, очень часто бывает полезным сначала сформировать процесс, как будет осуществляться та или иная деятельность, и уже потом под него подложить поддержку информационной системы.
И последнее применение, которое делает работу над бизнес-моделированием отдельной дисциплиной и в котором реализовано большое количество различных подходов и отдельных внутренних техник – реинжиниринг бизнес-процессов. Реинжиниринг бизнес-процессов – это классическая работа по модели: перейти от ситуации, как она есть, к ситуации, как она должна быть (As Is и To Be). Мы можем сформировать модель процессов как есть и определить модель процессов, как это должно быть. Революционное изменение или значимый эффект от внедрения информационных систем, как правило, невозможен без пересмотра того, как осуществляется деятельность организации.
И именно поэтому, для того, чтобы мы смогли сформулировать требования к информационной системе, мы должны вначале определить, как будут меняться бизнес-процессы для того, чтобы та информационная система, которую мы предложим, соответствовала тем требованиям и тем потребностям, которые есть у бизнеса.
Моделирование бизнес-процессов – это исследовательская техника и исследовательский процесс, и поэтому жёсткого регламента на осуществление моделирования предложить нельзя. Однако я бы рекомендовал резервировать от половины до 2-х дней на описание каждого выявленного процесса. 4 часа – это минимальное время, которое необходимо для того, чтобы сделать базовое описание. 2-х дней достаточно для того, чтобы описать достаточно сложный процесс с несколькими ветвлениями, и даже успеть пройти несколько этапов согласования, коммуникации с заказчиком, правильно ли мы все понимаем.
Для того, чтобы это сделать, нам потребуется эксперт в предметной области, который разбирается в бизнес-процессах организации. Чтобы сформировать модель As Is, понадобится эксперт в области существующего решения, а чтобы сформировать модель To Be, – специалист в области технологий, которые мы собираемся применить, и тех возможностей, которые может нам дать информационная технология, и которая потребует изменение бизнес-процессов.
Бизнес-моделирование достаточно редко применяется. В одном из 10 — 15 проектов встречаются те или иные аспекты моделирования бизнес-процессов или бизнес-моделирование.
10 правил для успешного сбора требований
Elicitation (Выявление) — это деятельность по вытягиванию информации из заинтересованных сторон и других источников.
Requirements gathering (Сбор требований) является неотъемлемой частью любого проекта. Понимание того, какую ценность должен поставить проект — критическая составляющая успеха проекта. Сбор требований звучит как здравый смысл, но этой области отводится слишком мало внимания.
10 правил для успешного сбора требований:
— Не предполагайте, что Вы знаете, что хочет клиент — всегда спрашивайте;
— Привлекайте пользователей с самого начала;
— Сформулируйте и согласуйте рамки (объем) проекта;
— Убедитесь что требования удовлетворяют технике SMART — Конкретные, измеримые, согласованные, реалистичные и имеют временные границы;
— Проясняйте любые сомнения (через общение);
— Создайте четкий, краткий и исчерпывающий перечень документов и поделитесь им с заказчиком;
— Подтвердите Ваше понимание требований компании (воспроизведите их);
— Избегайте разговоров о технологиях или решениях до тех пор, пока требования не будут полностью поняты;
— Получите требования, согласованные с заинтересованными сторонами до начала проекта;
— Создайте прототип, если необходимо подтвердить или уточнить требования заказчика.
