Управление требованиями. Инсайты с доклада Карла Вигерса

Лучшие практики управления требованиями (requirements management) от Карла Вигерса.

Предисловие

Многие бизнес-аналитики читали книгу Карла Вигерса “Software requirements” или хотя бы слышали о ней. Для меня эта книга является первой из книг о бизнес-анализе, она объяснила мне, как справляться с некоторыми задачами аналитика, и подтвердила, что я правильно решаю другие.

А также, что разработка требований, работа с требованиями - это не только “написал-перелинковал-отдал в команду”, а и глубокое понимание контекста изменений, и всех заинтересованных лиц (стейкхолдеров), особенно пользователей.

Поэтому этот доклад для меня был одним из тех, которые я просто не могу пропустить, ведь это Карл, Карл! :)

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

В статье я опишу основные тезисы и их расшифровку.

Ниже - речь от первого лица - докладчика)

Управление требованиями. Лучшие практики.

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

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

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

Давайте определимся с терминологией.

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

Разработка требований делится на выявление требований (не сбор требований, они вовсе не “собираются” (ну разве что немного), а и обнаруживаются, изобретаются).

Менеджмент требований

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

Базовые практики управления требованиями:

Создание бейзлайна требований (requirements baseline)
Управление версиями документов (это не обязательно какой-то официальный документ, может быть любое описание требований в инструменте, конфлюенсе, например)
Принятие и обеспечение соблюдения процесса управления изменениями
Анализ влияния изменений требований (requirements change impact analysis)
Трекинг статуса каждого требования
Трассирование требований
Хранение требований в инструменте по управлению требованиями.

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

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

Рассмотрим практики подробнее.

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

Создание бейзлайна требований (requirements baseline) - это стартовая точка для осуществления изменений. Бейзлайн - это проверенный, принятый, и согласованный список требований к определенному релизу продукта или итерации разработки.

То есть, если владелец продукта (продакт оунер/Product owner) определяет несколько пользовательских историй (юзер стори/user stories), которые будут готовы к следующему релизу - он определяет бейзлайн требований итерации.

Обычно, кто-то должен “подписать” требования - сейчас это не обязательно подписание, но скорей согласие ключевых заинтересованных лиц на то, что они:

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

И это важно, чтобы все участники “подписания” понимали, что это означает, на что именно они соглашаются.

Когда бейзлайн определен, тогда можно:

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

(управление требованиями проекта сложно осуществлять, не имея бейзлайна - прим.)

Управление версиями требований

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

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

требования были актуальными;
участники процесса разработки/выявления требований имели доступ к последней версии требований;
правки в требования вносили только те, кто имеет право это делать.

Храните требования там, где всем заинтересованным лицам будет их легко найти, желательно используя подходящую систему. (Требования на стикерах найти легко, но стикер может отклеиться и потеряться на какое-то время)

Также полезно иметь схему идентификации требований, например:

Версию #1 можно назвать “version 1.0 draft 1”

#2 = “version 1.0 draft 2”

#n (approved) = “version 1.0 approved”

#n+1 (опять черновик) = “version 1.1 draft 1” или “version 2.0 draft 1”.

Эта схема (конвенция наименования) поможет вам различать версии документов.

Управление изменениями требований

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

Поэтому, управление требованиями нужно "усилить", определив формальный процесс управления изменениями требований.

Он может включать в себя такие этапы:

предложение;
проверку;
аппрув;
внедрение.

Также, важно:

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

У меня есть философия, что любой запрос на изменение должен следовать процессу.

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

И помните, что правки могут потребовать изменение коммитментов.

Возможные статусы запроса на изменение (описывают жизненный цикл запроса):

Submitted;
Evaluated (оценка того, что за собой повлечет изменение - какие трудозатраты);
Approved (когда лица, принимающие решение (ЛПР) согласны на необходимые затраты), или, Rejected, если не согласны;
Change made;
Verified;
Closed;
Canceled.

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

Но - не определяйте слишком много статусов.

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

Совет по работе с изменениями (Change Control Board/Configuration Control Board)

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

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

Но это не должно быть так. Это должна быть группа заинтересованных лиц, не больше, чем нужно, чтобы принять бизнес-решение. Иногда это один продакт оунер (владелец продукта/Product Owner), но на больших проектах обычно это несколько людей, которые защищают разные сферы интересов, например:

разработку;
управление проектами;
тестирование;
клиент;
др. (бизнес-анализ, наверняка, входит тоже - прим. BA Girl)

Эти люди должны иметь возможность принимать решения. То есть, это не люди, которые просто могут советовать.

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

Совет по управлению изменениями может:

запросить анализ влияния изменений (impact analysis);
принимать решения по поводу изменения и коммуницировать это решение дальше;
приоритизировать внедрение изменений и выбирать, в какой релиз они попадут.

Анализ влияния изменений требований

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

Несколько моментов, которые нужно оценить, до того, как сказать завести в бэклог юзер-стори и сказать “конечно, мы сделаем”:

Определите, есть ли конфликт с существующими требованиями (которые описывают фичи в любом статусе разработки - те, что уже сделаны, те, что сейчас в разработке, или те, что только планируются);
Определите, какие дизайны, код, тест-кейсы изменятся;
Оцените влияние на юзер интерфейс, БД, репорты, справочную информацию и т.п;
Определите, какие сторонние системы могут быть затронуты;
Какие планы или документы нужно обновить?
Реализуемо ли требование вообще?
Затронет ли изменение быстродействие системы или другие аттрибуты качества?
Перегрузит ли технические ресурсы?
Нужно ли будет избавиться от какой-то части уже выполненной работы?
Нарушают ли изменения бизнес-правила?
Сколько работы нужно сделать, чтобы воплотить изменение в жизнь?

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

Отслеживание (трекинг) статуса проекта

Привет, как там дела с подсистемой?

Хорошо, уже 90% сделано

Так 2 недели назад тоже было 90%?

Да, но теперь это точно 90%

Говорят, все проекты на 90% готовы :)

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

Пример - на слайде ниже.

Возможности инструмента управления требованиями

При выборе инструмента управления требованиями, обратите внимание, может ли инструмент:

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

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

Читайте мои книги:

____________________________________________________

P.S. совет бизнес-аналитикам от Карла Вигерса, который он дал в сессии вопрос-ответ - найдите реальных пользователей и работайте с ними. Требования должны быть ориентированы на использование, а не на фичи. (управлять требованиями для фичей, которые не нужны пользователям - грустно)

P.P.S. Хотите узнать, что такое хорошие требования? Описала характеристики качества требований, и как проверить свои требования здесь - https://www.thebagirl.com/kharaktieristiki-kachiestva-triebovanii/

P.P.P.S. Если вы хотите войти в айти через бизнес-анализ, пытаетесь перейти в бизнес-анализ, или вы сейчас junior бизнес аналитик, но хотите закрепить/упорядочить знания и быстро дорасти до мидла - собрала для вас топ 5 книг для начинающих БА - https://www.thebagirl.com/knighi-dlia-biznies-analitikov/