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

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

Николай Кузнецов, заместитель директора центра решений RedSys: «Работа с требованиями – очень важный этап. Именно здесь ошибки стоят очень дорого, и во многом именно от него зависит успех проекта»

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

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

Оптимизация взаимодействия

Дмитрий Мелешкин, главный аналитик центра отраслевых и бизнес-решений RedSys: «Имея дело с крупными проектами, мы пришли к выводу, что необходима единая рабочая среда, что должно быть понимание, какие требования откуда приходят и как потом реализуются»

«Мы реализуем крупные ИТ-проекты с участием многих сторон, их структура весьма сложна, а эффективность взаимодействия в нашей стране традиционно невелика. Мы беремся за проекты, даже если видим в них определенные риски, и помогаем нашим заказчикам строить эффективный бизнес», – рассказывает Дмитрий Мелешкин, главный аналитик центра отраслевых и бизнес-решений RedSys. Активных участников проекта, работающих в разных компаниях, может быть несколько сотен. Как эффективно организовать их взаимодействие?

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

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

Чтобы перевести разработку продуктов и оказание услуг на другой уровень, в RedSys была внедрена новая методология на платформе IBM Rational DOORS Next Generation, охватывающая весь цикл работы с требованиями.

Работа по-новому

«Мы уже давно пришли к необходимости использования подобного решения и пытались его выстроить с помощью других инструментов, объединяющих возможности электронного документооборота и файлового хранилища. До сих пор это не очень получалось – видимо, требовались более серьезные платформы. Увидев возможности DOORS, мы поняли, что она включает в себя все необходимые функции и может решать стоящие перед нами задачи. По реализованной концепции эта система просто несопоставима с другими продуктами», – рассказывает Мелешкин.

IBM Rational DOORS Next Generation – специализированная система для работы с требованиями. Ее основной объект – артефакт, который может описывать какие угодно требования: бизнес-требования, функциональные требования, пользовательские требования, замечания, предложения. Он имеет свои атрибуты и жизненный цикл.

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

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

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

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

«На этапе подготовки к работе у нас высвободилось 30% времени. Мы перестали искать информацию в почте, а раньше это занимало примерно треть рабочего дня», – констатирует Мелешкин.

Сейчас эта система используется на шести проектах RedSys. Более того, на одном из них удалось полностью отказаться от традиционных документов. И эксперты интегратора, и специалисты заказчика работают в едином информационном пространстве. Сбор требований, техническое задание, проектные решения – все это ведется в рамках DOORS. А документация, необходимая по ГОСТ 34, выгружается из системы в виде обычных отчетов. Это позволяет избежать временных и информационных разрывов и обеспечить интерактивное взаимодействие.

Функциональные требования к ИТ-системе с привязкой к исходным требованиям Заказчика в DOORS

Отражение зависимости разных видов требований в графическом виде

Добиться вовлеченности

«Работа с требованиями – очень важный этап. Именно здесь ошибки стоят очень дорого, и во многом именно от него зависит успех проекта», – говорит Кузнецов.

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

Действительно, главная проблема исполнителя – нехватка времени у заказчика. Использование решения DOORS позволяет в несколько раз сократить риски, вовлечение всех заинтересованных лиц серьезно возрастает.

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

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

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

От планов к действиям

Результатом использования системы является документация – сформулированные и согласованные требования к продукту, которые могут служить базой для начала работ. Дальше идет планирование работ и требования конвертируются в конкретные действия. Например, в случае разработки ПО используется система управления изменениями IBM Rational Team Concert. Затем начинается выполнение отдельных задач в рамках пунктов плана.

Пример ведения плана работ по этапу проекта с углубленным планированием отдельных итераций в IBM Rational Team Concert

ИТ-проекты можно разделить на две группы: заказная разработка систем с нуля и внедрение тиражируемых решений. В первом случае используется средство управления исходным кодом, входящее в Team Concert, и все работы привязываются к конкретным требованиям. Однако чаще внедряются готовые решения, где этого не требуется, и тогда используется система управления проектированием IBM Rational Design Manager, где отмечаются все изменения конфигураций системы. Это решение показывает, как каждое изменение влияет на остальные настройки и состояние целевой системы.

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

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

«Конечно, занимаясь крупными проектами, большинство компаний предпочитают классические подходы. Мы соглашаемся с желаниями заказчиков, но планируем и выпускаем релизы все равно итерационно, применяя свой внутренний, невидимый извне Agile», – говорит Мелешкин.

Актуально для многих

«К идее развивать продукт и выводить его на рынок привели потребности наших заказчиков-девелоперов, перед которыми встала проблема согласования договоров с подрядчиками. Когда подрядчика попытались заставить доделать работы, тот предъявил договор. Как выяснилось, не все требования были в нем учтены, и возникла очень неприятная ситуация», – говорит Кузнецов. ИТ-компаниям в этом отношении проще: даже если придется потратить на это много времени, работы можно переделать. А вот в строительстве, например, ошибки могут быть непоправимыми. Как выяснилось, девелоперы тоже мучаются с большим количеством разрозненных требований, и они выступают в роли заказчиков, у которых нет права на ошибку, а изменения в проекте являются катастрофическими.

«Мы внедрили инструмент для управления требованиями, успешно его используем и можем поделиться своим опытом», – отмечает Кузнецов. Это особенно важно: ведь в большинстве случаев интегратор, несмотря на весь свой проектный опыт, не является пользователем внедряемых систем. Когда он приходит к заказчику и начинает его учить реализации проектов, тот, естественно, воспринимает это скептически. Но продукт IBM Rational DOORS используется внутри RedSys, и ее специалисты сами ощущают все преимущества нового решения.

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

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

«Многие заказчики даже не подозревают, что так можно работать. Мы как интегратор можем показывать свои компетенции, демонстрируя новые стандарты работы», – резюмирует Кузнецов.

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