Пока среди аналитиков ведутся обсуждения, как оценить эффект от внедрения Средства Управления Требованиями (СУТ) — мы просто взяли систему и сделали на ней некое подобие пилотного проекта (как и все пионеры внедрения СУТ).
Какие целевые критерии успеха мы для себя определили? На самом деле довольно абстрактные, но позитивные. К сожалению, у нас не было накоплено никаких метрик, а по пилотному проекту их собирать особого смысла не было. В итоге мы будем ограничиваться только нашими ощущениями и голословными высказываниями.
В процессе аналитической работы на наших проектах наблюдаются следующие проблемы:
- Требования с незначительной периодичностью теряются;
- В требованиях тяжело найти нужную версию;
- Влияние новых требований на проект оценивается аналитиком, опираясь исключительно на его опыт и незатуманенную память;
-
Надо делать
Excel-таблицы для выявления степени покрытия требований заказчика постановками; -
Так как людей запрещено приковывать к батареям и/или отбирать у них паспорта, а аналитики относятся к категории людей, то необходимо хранить полную историю изменений требований, их взаимосвязи (особенно, если речь идёт о связанных нескольких проектах) источники. А ещё их надо уметь быстро и правильно находить. Это трудоемкая задача, которую тяжеловато делать исключительно в вышеупомянутом Excel и Word: сразу хочется
как-то автоматизировать поддержание актуальности ссылок, дабы не пребывать в глубочайшей депрессии в момент их актуализации.
Часть из этих бед можно было бы решить при помощи «донастройки» Jira, но потом мы пришли к выводу, что между Jira и некогда любимым всеми нами RequisitePro наблюдается непреодолимая пропасть, многокилометровая заминированная пустыня и ещё неизвестно, что… Вообще, что бы нам хотелось:
- Иметь одно большое ТЗ, не побитое на 100500 маленьких документов, которые потом пришлось бы собирать воедино для отправления заказчику после завершения очередного этапа.
- Работать именно в этом большом ТЗ, а не выгружать его для каждой правки и загружать обратно в Jira.
-
Трассировать отдельные куски этого документа с постановками,
тест-кейсами , задачами на разработку и так далее. -
Автоматизированно отслеживать взаимосвязи между артефактами (включая требования разных типов,
тест-кейсы и т. д. ). - Уметь трассировать куски одного такого документа с кусками другого.
- Не использовать дорогой и древний RequisitePro.
Итого, не имея никаких метрик и осознавая свои потребности, мы выбрали ALM Devprom. Почему?
- Devprom имеет оперативную и качественную поддержку на русском языке (почта, телефон, специальный чат в Skype), проводит бесплатные консультации у нас в офисе. На этом, кстати, мы отсеяли бесплатный Redmine;
- Простотой установки, обновления системы (без привлечения системных администраторов), а также настройкой шаблонов/жизненных циклов/справочников/проектов и всего такого прочего;
-
Devprom учитывает наши пожелания, как одного из лидеров рыночного сегмента заказной разработки, и оперативно (
неделя-месяц ) дорабатывает СУТ (в том числе в рамках поддержки процесса разработки поГОСТ 19 и 34); - Devprom не слишком дорога для покупки: одна лицензия стоит около 7.т.р. (хотя лицензия нужна и для просмотра информации в Devprom, а не только редактирования);
И да, Devprom обеспечивал реализацию наших полумифических ожиданий.
Данное решение было принято примерно 3 месяца назад, а на сегодняшний день мы имеем:
- Установленную новую версию 3.0 (которая пока не доступна широкому кругу, но скриншотом я поделюсь);
- Поползновения в реализации системы по интересующему нас вектору (чего стоит планируемое внедрение baseline, доработка механизма экспорта/импорта в Word/Excel и доработка хранения версий отдельных документов);
- Практически готовый шаблон для создания новых проектов в рамках компании;
- Загруженный пилотный проект;
- Готовность к старту реального проекта.
Ключевым здесь является последний пункт, потому что за отсутствием конкретных метрик мы можем опираться только на ощущения задействованного в проект аналитика. Есть некоторые опасения, что появится много лишней работы, которую аналитик и в предварительную оценку даже не внесет. С другой стороны, есть ожидания, что наибольшая выгода от внедрения СУТ будет заметна на завершающих этапах, при доработках системы, а также при изменениях в команде (замена/добавление аналитиков).
Кроме того, аналитику все равно приходится так или иначе отслеживать покрытие исходных требований детализированными требованиями и
По крайне мере, на этапе пилотного проекта никакого отторжения не возникало, так что перспективы весьма радужные, только сам результат будет отчетливо виден через
Авторы:
Алексей Киселев
(akiselev87.wordpress.com), Аналитик, IBS
Борис Сторонкин
Ведущий аналитик, IBS
Впервые опубликовано на analyst.by.
Автор статьи

Алексей Киселёв
Курсы Вебурситета
Практический анализ ПО с моделированием на UML От 27 000 руб. | |
Введение в профессию аналитика (демо) Бесплатно | |
Введение в профессию аналитика 2 900 руб. | |
Вебинары Сообщества Аналитиков Бесплатно | |
SQL для непрограммистов (СЕРТИФИКАТ) 750 руб. | |
![]() | SQL для непрограммистов Бесплатно |