Без рубрики · Организация работ

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

Автор статьи: Илья Корнипаев, автор книги «Требования для программного обеспечения: рекомендации по сбору и документированию», которую вы можете найти в разделе Книги по управлению требованиями

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

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

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

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

Начнем с самого начала.

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

Разделим условно пространство проекта на область проблем и область решений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Изменения

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

Проблема: изменения происходят постоянно

Как же мы можем снизить негативное влияние изменений на наш проект?

Рекомендации: Первое и самое простое – подготовиться к изменениям и подготовить к ним заказчика. Для этого надо определить и формально зафиксировать процедуру внесения изменений, которая предусматривает пересмотр оценок по срокам и трудозатратам. Следующее что обычно всегда помогает – это опыт и экспертиза аналитиков, которые занимаются сбором требований.

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

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

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

Плохой заказчик

С чем еще приходиться сталкиваться во взаимоотношениях заказчиков и разработчиков? С плохими заказчиками.

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

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

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

Проблема: мы вынуждены работать с плохими заказчиками

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

Личные качества аналитика

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

Проблема: очень тяжело найти хорошего аналитика

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

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

Требования и модели

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

Проблема: попытка замены требований моделями

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

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

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

Степень детализации требований

Проблема: когда же остановиться?

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

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

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *