Найти правильный путь в лабиринте требований

Исходная статья: Finding the right path through the Requirements’ labyrinth
Перевод опубликован с разрешения PA Consulting Group 

By Simon Duke and Peter Durant, PA business analysts and technologists
Перевод: Мадорская Ю.М.

Simon Duke и Peter Durant из компании PA Consulting Group – опытные бизнес-аналитики. Учитывая свой коллективный опыт разработки продуктов, определения бизнес-стратегий и поддержки  сложной деятельности по закупке, они разработали набор лучших практик, которые должны применяться в ходе всего жизненного цикла проектных требований.

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

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

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

Постоянно взаимодействуйте со всеми заинтересованными сторонами

Работая над определением требований в вашем проекте вы можете ожидать столкновение с вопросами, начиная с «Почему мы это делаем» до «Почему вы не спросили меня раньше».

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

  • Установите ожидания насчет того, в каком объеме люди должны будут участвовать в разработке требований. Как много времени понадобится для интервью? Кто будет рецензировать разработанные требования? Планируйте заранее и убедитесь, что люди следуют согласованным датам.
  • Вы можете не знать всех заинтересованных лиц в начале проектa. Обратитесь к людям, которые не вовлечены напрямую и и не участвуют  в создании требований . Это обеспечит новые представления и точки зрения, а также  поможет разработать требования, которые будут лучше приняты всей организацией.  Слушайте внимательно мнение людей и понимайте их позицию, поскольку это обычно рассеивает потенциальное напряжение, а также любые существующие опасения.Обеспечьте регулярные сессии по обмену информацией, в том числе о прогрессe проекта.. Без этого, требования могут быть чем-то мистическим для большинства людей и ценность того, что обычно представляет собой огромный пласт работы, может быть непонятна им. Это, в свою очередь, может привести к вопросам о необходимости этой работы, а также их вовлечения.

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

Установите правильный источник данных

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

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

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

Используйте правильные инструменты и формат работы

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

Формат действительно имеет значение: технические специалисты или бизнес рецензенты могут предпочитать совершенно разный формат презентации и это может привести к проблемам, если не будет согласовано заранее. Переделка формата весьма неприятна и отнимает много времени, a  поддерживание требований в различных форматах  вручную — просто непрактично.. Мы рекомендуем:

  • Выберите инструмент, который вы будете использовать для получения и  презентации ваших требований, a также определитесь как он будет помогать вам управлять прослеживаемостью и связями между требованиями, учитывая ростобъема исходных данных. Это может быть специализированный инструмент, такой как Cradle, Doors, Artisan или Jama или это может быть что-то совсем простое, например изготовленная на заказ электронная таблица.
  • Будьте педантичны, используя согласованную  терминологии и сделайте требования однозначными, конкретными, измеряемыми и соответствующими целям заказчика. Примите то, что требования будут изменяться и скурпулезно управляйте их версиями.
  • Упорядочьте требования так, чтобы они рассказывали историю или проводили читателя через некоторый логичный путь. Это поможет поставщикам понять потребности заказчика и предоставить им наиболее благоприятную позицию для наиболее эффективных ответов.
  • Не используйте требования для того, чтобы определить цели системы и как она должна быть реализована. Избегайте спецификации конкретных решений пока вы пишите требования.
  • Делайте каждое требование дискретным и тестируемым – не объединяйте несколько требований в одно большое. Это позволит вам разработать требования так, чтобы они поддерживали верификацию и валидацию позднее (например, если используется подход системной инженерии).

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

Воплощайте требования в жизнь в течении всего проекта

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

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

  • Испытывайте ваш подход и тестируйте его принятие. Стоит опробовать подход, который у вас сложился в голове, например, в небольшой области функциональности. Это возможно сделать, применяя различные потенциальные инструменты для того чтобы уточнить требования перед тем как согласиться на весь объем работы,Организуя работу таким образом, вы получите драгоценные отзывы от всех заинтересованных сторон, а также обеспечите их постоянную вовлеченность.
  • Рассмотрите возможность повторения испытаний если есть изменения в границах проекта, влиятельных заинтересованных лиц или доступных инструментах.
  • Поскольку проект идет дальше, некоторые источники требований могут измениться и это может повлиять на ваши требования. Таким образом, у вас должен быть способ отслеживать такие изменения и гарантировать, что ваши требования пересматриваются и обновляются в соответствии с этими изменениями. Это может отнимать весьма много времени если вы полагаетесь на несколько источников, поэтому учтите заранее – когда вы впервые будете использовать источник – как вы сможете это делать далее.
  • Стремитесь поставлять применимый набор требований. Лучше начать с небольшой области и приоритезировать расширение на другие, чем пытаться сделать сразу все.

Выгода ‘живых требований’ часто хорошо чувствуется в ходе на протяжении всего проекта: меньше переделок, более быстрая поставка и более легкий контроль за изменениями. Вы извлечете значительную выгоду из усилий, которые Вы приложите к воплощению требований в жизнь.

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

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

Опубликовано в: