Регламент изменений для проекта развития: как согласовывать доработки без очередного мини-водопада
После запуска системы работа над ней обычно не заканчивается. Наоборот, через некоторое время появляется постоянный поток изменений: одному подразделению нужен новый отчет, другому не хватает варианта согласования, кто-то просит добавить реквизит, а параллельно возникают более крупные задачи, которые затрагивают сразу несколько процессов или систем. Если для каждого такого запроса использовать тот же порядок, что и на большом внедрении, проект развития довольно быстро превращается в череду маленьких водопадов, где несколько часов разработки предваряют недели согласований.
Полностью отказываться от порядка тоже нельзя, потому что тогда задачи начинают приходить в чатах и письмах, срочность определяется громкостью инициатора, а сроки обещаются еще до того, как команда поняла объем работ. Поэтому смысл регламента изменений не в том, чтобы добавить очередные согласования, а в том, чтобы заранее договориться, какие задачи можно проводить быстро, а какие требуют более серьезной проработки.
Первое, от чего стоит отказаться - один маршрут для всех задач
Исправление подписи на форме, новый отчет по уже имеющимся данным и интеграция с внешней системой отличаются не только трудоемкостью. У них разная цена ошибки, разное количество участников и разный объем информации, который требуется собрать до начала разработки. Если все три задачи должны пройти одинаковое обследование, одинаковую оценку, один и тот же список согласующих и одинаковую приемку, простые изменения начинают двигаться медленнее, чем выполняться.
Поэтому в регламенте полезно сразу разделить изменения хотя бы на несколько групп. Например, небольшая доработка может затрагивать один объект, не менять интеграции и укладываться в согласованный лимит часов; обычное изменение уже требует работы аналитика и отдельной оценки; крупное затрагивает несколько подразделений, перенос данных, права или смежные системы. Отдельно стоит выделить срочные изменения, потому что для них важен не размер задачи, а причина, по которой нельзя ждать обычной очереди.
Бизнесу достаточно описать проблему и желаемый результат
На входе не нужно требовать от пользователя готовое ТЗ. Если для регистрации идеи сотрудник должен самостоятельно описать алгоритмы, права, исключения и структуру данных, аналитическая работа просто перекладывается на инициатора, который чаще всего и не должен уметь это делать.
Для первоначального запроса достаточно понять, что происходит сейчас, что пользователь хочет изменить, какой результат ему нужен и почему задача вообще появилась. Хорошо работают простые вопросы: «Что сейчас не устраивает?», «Как должно работать после изменения?», «Кто будет этим пользоваться?» и «Есть ли дата, к которой результат действительно нужен?». Если инициатор знает конкретный документ, отчет или форму, это тоже стоит указать, но превращать заявку в спецификацию требований на этом этапе нет смысла.
Не каждый зарегистрированный запрос должен сразу попадать к аналитику
Перед подробной проработкой полезен короткий первичный разбор, потому что часть запросов вообще не требует разработки. Пользователь мог не знать о существующей настройке, похожая задача уже может находиться в очереди, а иногда проблема решается изменением прав или консультацией.
На этом же этапе становится понятно, относится ли запрос к текущему проекту развития и кто должен принимать решение о его дальнейшем движении. Подробно описывать все поступившие идеи заранее невыгодно: аналитик может потратить несколько дней на задачу, которую бизнес через неделю снимет с приоритета.
После первичного разбора запрос либо закрывается без разработки, либо объединяется с существующей задачей, либо попадает в общую очередь изменений. Уже там принимается решение, насколько подробно его нужно прорабатывать.
Глубина аналитики должна зависеть от самой задачи
Одна из причин появления мини-водопада - правило, по которому любая доработка сначала должна превратиться в полноценное ТЗ. Для большой задачи это нормально, но если разработчику нужно добавить один отбор в существующий отчет, подготовка нескольких страниц требований вряд ли улучшит результат.
Для небольшой доработки иногда хватает описания текущего и желаемого поведения, примера и критериев приемки. Если меняется большой бизнес-процесс, появляется новая интеграция или затрагиваются несколько ролей, потребуется уже нормальное обследование, описание сценариев и зависимостей.
Здесь полезнее ориентироваться не на размер документа, а на количество неопределенности. Если после прочтения задачи разработчик понимает, что нужно получить, и ему не приходится самостоятельно придумывать бизнес-правила, информации достаточно. Если же один нерешенный вопрос способен изменить решение и оценку в несколько раз, задача пока сырая независимо от того, сколько страниц уже написал аналитик.
Оценка тоже не всегда должна быть окончательной
Иногда владельцу продукта достаточно понять порядок трудоемкости, чтобы решить, стоит ли вообще двигать запрос дальше. В такой ситуации нет необходимости сначала полностью описывать задачу, а затем получать оценку с точностью до часа. Можно дать диапазон и явно указать условия, на которых он основан.
Например, новый отчет предварительно оценивается при условии, что все данные уже находятся в текущей базе. Если позже выясняется, что половину показателей нужно получать из ERP, первоначальная оценка перестает быть актуальной не потому, что кто-то ошибся, а потому, что изменился известный объем работ.
Когда задача уже включается в конкретный релиз и на ее основании подтверждается бюджет, уровень проработки должен быть выше, а оценка - учитывать основные сценарии, интеграции, права, миграцию и другие зависимости, которые способны заметно повлиять на трудоемкость.
Допущения лучше хранить рядом с часами
Это простое правило снимает много последующих споров. Если оценка дана без переноса истории, без изменения смежной системы и при использовании типового маршрута, эти условия нужно зафиксировать там же, где указаны часы. Через месяц заказчик наверняка вспомнит цифру, но вполне может забыть, что она относилась к другой конфигурации задачи.
Когда вводные меняются, достаточно показать, какое из первоначальных условий больше не выполняется, после чего необходимость переоценки выглядит вполне понятной.
Очередь должна быть общей, а приоритет - понятным
Если один запрос живет в Jira, второй в письме РП, третий в личном списке аналитика, а четвертый обсуждается только в чате с заказчиком, управлять развитием системы практически невозможно. Нужен один список, в котором хотя бы на верхнем уровне видны содержание изменения, инициатор, статус, приоритет, оценка и зависимости.
При этом техническая команда не должна самостоятельно определять бизнес-приоритет только потому, что лучше понимает трудоемкость. Аналитик или разработчик может объяснить риски, стоимость и зависимости, но решить, что компании важнее сейчас - новый отчет или изменение процесса согласования, - должен человек, который видит общую бизнес-картину.
Комитет по изменениям нужен не для каждой кнопки
На крупных проектах регулярная встреча по изменениям бывает полезной, особенно когда несколько подразделений конкурируют за один бюджет или одна доработка влияет сразу на несколько систем. Но если туда нужно выносить каждую небольшую настройку, комитет быстро становится еще одной очередью, которая собирается раз в неделю и тормозит задачи, по которым никто на самом деле не спорит.
Полномочия лучше разделить заранее. Например, небольшие изменения внутри согласованного бюджета подтверждает владелец продукта или РП, тогда как на общий уровень выносятся задачи, которые заметно меняют стоимость, сроки, архитектуру или затрагивают несколько владельцев процесса. Тогда время руководителей тратится именно на управленческие решения.
Срочные задачи все равно появятся, поэтому для них нужен понятный порядок
На любом проекте рано или поздно приходит запрос «нужно сегодня», и если правила срочности заранее не определены, почти каждый инициатор начинает считать свою задачу исключением. Критическая ошибка, которая блокирует работу пользователей, изменение законодательства с близким сроком или отказ важной интеграции действительно могут требовать отдельного маршрута, тогда как желание успеть изменить отчет к завтрашнему совещанию само по себе еще не делает задачу аварийной.
При срочном изменении часть обычных шагов можно сократить, однако совсем отказываться от фиксации опасно. Должно остаться хотя бы понимание причины срочности, ожидаемого результата, человека, который подтвердил внеочередной порядок, и минимального набора проверок перед выпуском.
Если из-за срочности требования описали только частично, к ним нужно вернуться после стабилизации решения, иначе через несколько месяцев никто уже не вспомнит, почему система работает именно так.
Перед разработкой должен существовать понятный рубеж
Независимо от выбранного маршрута нужно определить момент, после которого задача действительно готова к работе. Для обычной доработки достаточно, чтобы были понятны цель, границы, основной сценарий, существенные зависимости, критерии приемки и актуальная оценка, а приоритет был подтвержден человеком, который имеет право его определять.
Набор может меняться в зависимости от задачи. Для интеграции нужно понимать, что происходит в смежной системе, для миграции - какие данные и за какой период переносятся, а для небольшой типовой настройки часть вопросов вообще не возникает. Смысл не в том, чтобы ставить галочки в обязательном чек-листе, а в том, чтобы разработка не начиналась с выяснения основных бизнес-правил.
После уточнения требования не нужно автоматически запускать весь круг заново
В проекте развития требования меняются постоянно, поэтому регламент должен позволять отличить обычное уточнение от реального изменения объема. Если аналитик только конкретизировал уже согласованный сценарий и трудоемкость не изменилась, достаточно обновить описание задачи.
Если же во время обсуждения появилась еще одна роль, новый вариант процесса, дополнительная интеграция или перенос данных, оценку нужно пересмотреть. После этого на согласование возвращается именно изменившаяся часть, а не весь комплект материалов только потому, что в тексте требований появилась новая версия.
С приемкой действует тот же принцип
Небольшую настройку, результат которой понятен заранее, может проверить инициатор или один назначенный бизнес-пользователь, поэтому собирать для нее отдельную комиссию и готовить большой протокол необязательно. Крупное изменение, которое затрагивает несколько подразделений или важный процесс, уже требует более формальной приемки, поскольку последствия ошибки заметно выше.
Если процедура завершения одинакова для любых задач, мини-водопад просто возвращается в конце маршрута, поэтому уровень приемочного контроля тоже лучше связать с масштабом и риском изменения.
Что действительно стоит записать в регламент
Сам документ может быть довольно коротким, если после его чтения понятно, куда попадает новый запрос и кто принимает решения на каждом этапе. В нем стоит определить:
- где находится единая очередь изменений и кто может регистрировать запросы;
- какую минимальную информацию предоставляет инициатор;
- кто проводит первичный разбор и что проверяет на этом этапе;
- на какие классы делятся изменения и по каким признакам;
- для каких задач достаточно короткого описания, а когда требуется полноценная аналитика;
- когда используется предварительная оценка, а когда нужна уточненная;
- кто определяет бизнес-приоритет и кто подтверждает бюджет;
- какие изменения можно согласовать по короткому маршруту;
- что считается срочной задачей и кто может подтвердить срочность;
- что должно быть известно до передачи задачи разработчику;
- когда изменение требований требует переоценки и повторного согласования;
- кто принимает результат для разных классов задач.
Хороший регламент должен убирать лишние решения, а не создавать новые
После появления правил участникам должно стать проще работать: бизнес понимает, куда отправить идею, аналитик знает, насколько подробно ее нужно разбирать, разработчик получает достаточно информации, а РП видит реальную очередь и зависимости. Если вместо этого любая небольшая доработка начала несколько недель путешествовать между обследованием, ТЗ, оценкой, комитетом и приемкой, регламент просто узаконил новый мини-водопад.
Проверка здесь довольно простая: чем меньше риск и масштаб изменения, тем короче должен быть путь до разработки, тогда как крупные и спорные задачи получают дополнительную проверку именно там, где она действительно нужна. В результате контроль не исчезает, но перестает быть одинаковым для задачи на два часа и изменения, которое затрагивает половину системы.