Управление проектами в картинках

Наглядное пособие изучающим управление проектами

Управление проектами в картинках header image 2

"Собирайте требования правильно!", часть I

August 11th, 2008 · 3 комментарий

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

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

Когда речь заходит об инструментах, которые доступны аналитику в его нелегком труде по извлечению требований из окружающих, в первую очередь говорят об интервью. Обычно не вопросы задают не просто так, а с учетом определенных процедур, таких, как "5 Почему", "SMART" целеполагание, "Случаи использования" (Use cases).

Кейт Матис написал хорошую большую статью, посвященную сбору требований в рамках проекта.  Речь идет об интересной модели проведения интервью, которая называется "воронка интервью".  В двух словах, процесс интервью состоит из следующих этапов (ниже приведена оригинальная схема автора):

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

 

Если же говорить о некой общей процедуре сбора требований, то она может быть изображена следующим образом:

Основные принципы, которые помогут провести интервью с пользой, следующие:

  • Заложите подходящий фундамент. Нужно обязательно объяснить, что к интервью надо отнестись серьезно, подготовиться и составить список вопросов, провести вводную лекцию о формате проведения интервью.
  • Создайте спокойную атмосферу. Вам не нужно сражаться с заказчиком или убеждать его в чем-то. Вам нужно выяснить, чего он хочет.  Если будете слишком жестки, то заказчик больше не захочет с вами встречаться. Найдите золотую середину - не слишком наседайте, но и не забывайте о процедурах проведения интервью.
  • Делайте пометки и записывайте комментарии. Это полезно, чтобы вспомнить затем, о чем именно шла речь. Это убеждает заказчика в серьезности мероприятия и вашего отношения к его ответам. Если у вас бывает много типовых проектов, подготовьте шаблоны интервью. Прислушивайтесь к фразам, которые заказчик повторяет несколько раз - они заслуживают уточнения и детализации.
  •  Помогайте собеседнику. Это означает, что своими комментариями вы должны показать заказчику, что понимаете, куда он клонит. Это и интонации, и мимика, и уточняющие вопросы.
  • Детали, детали, детали. Хорошее интервью - детальное интервью. Не торопитесь, лучше копнуть глубже сейчас, чем быть шокированным в конце проекта. Взгляните на проект глазами заказчика. Помните, что вам придется рассказывать о требованиях вашей команде, подумайте, что они бы спросили.

В следующей части статьи о сборе требований речь пойдет о правильной постановке правильных вопросов. С удовольствием включу в данную запись советы своих читателей.

Тэги: Целеполагание · Управление коммуникациями · Stakeholders · Планирование проекта · Инициация проекта

3 ответов на данный момент ↓

  • 1 krist // Aug 11, 2008 at 11:36 am

    Принципиально, что заказчик не может знать ВСЕХ требований, а если знает не всегда сможет сформулировать.
    Интервью можно, хотя методологически вернее контрольные списки (checklists).
    Управление требованиями на базе стандартов - это на сегодня представляется перспективным.
    Например, стандарт ISO 15288, регламентирует требования к процессам разработки и эксплуатации рукотворных систем и в каждом конкретном случае можно выделить процесс из стандарта с его целями, действиями и результатами.
    Цель, как таковую, нужно отделить, так как ее определяет заказчик до требований к продукту или услуге.

  • 2 Алексей // Aug 12, 2008 at 8:57 am

    В статье есть разделение “открытые” и “закрытые” вопросы. Это какие?

  • 3 Андрей Куликов // Aug 12, 2008 at 9:41 am

    Открытый вопрос - это вопрос, который позволяет собеседнику ответить свободно, например: “Что вы думаете о происхождении жизни на Земле?”
    Закрытый вопрос четко ограничивает ответ, заставляет собеседника ответить “да/нет” или выбрать один из вариантов. Например, “Вы пьете пиво по утрам?” или “Какие носки вам нравятся: белые, серые, черные?”
    Еще вот почитайте: http://en.wikipedia.org/wiki/Open-ended_question

Оставить комментарий