Актуальные проблемы управления требованиями

http://www.reqs.ru/OracleForum2008.htm

Доклад на эту тему был сделан на пятом ежегодном форуме Oracle для компаний-разработчиков из стран СНГ 21 мая 2008 г., Москва - тезисы на сайте форума Oracle- оригинальная версия слайдов презентацииЗдесь публикуется несколько расширенная статья, посвященная этой теме.

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

Примерно так начал свой доклад Карл Вигерс (Karl Wiegers) “Космические истины о требованиях для ПО” (Cosmic Truths about Software Requirements) на заключительной сессии конференции Better Software 30 сентября 2004 г. San Jose, CA USA. Далее он продолжил: «Если вы не можете собрать правильные требования, то становится совершенно неважным то, насколько хорош ваш процесс разработки». Так было раньше, так есть сейчас, и вряд ли это измениться когда-то. Если вы не можете собрать хорошие требования, вы очень сильно рискуете разработать очень хороший продукт, очень качественный, и вместе с тем никому ненужный…

Область проблем и область решений

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

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

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

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

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

При сборе и анализе требований часто не происходит разделения между двумя различными областями: областью проблем и областью решений.

Проблема: Преждевременный переход в область решений

Недостаточное понимание проблем приводит к тому, что:

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

• Трудно управлять рамками проекта, ибо не существует объективных (документально подтвержденных) критериев включения той, или иной функциональности в систему.

• Заказчик и разработчики по-разному понимают назначение системы, это, в частности, приводит к тому, что разработчики и заказчик включают в системы ненужные возможности и несуществующие на практике ограничения.

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

Рекомендации:начинать проект с понимания проблем стоящих перед заказчиком, по возможности разрабатывать формальный документ «требования заинтересованных сторон», анализировать и моделировать бизнес процессы заказчика.

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

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

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

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

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

Проблема: Упущенные заинтересованные стороны

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

Заинтересованные стороны это: Государства, организации, отдельные люди или группы людей, а так же системы, которые могут прямо или косвенно быть заинтересованы в результатах проекта, или если результаты проекта или ход его выполнения прямо или косвенно влияет на них (как положительно, так и отрицательно).

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

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

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

Проблема: Поставщик оставляет заказчика на долгое время без внимания

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

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

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

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