Запускать нельзя дорабатывать: как управлять требованиями к ИТ-системе в проекте внедрения

Михаил Дьяконов -

При внедрении ИТ-продукта нередко возникают требования, которые выходят за рамки первоначального технического задания. Почему возникают такие задачи? Ведь на старте проектные команды оговаривают сроки, заключают договор, согласовывают план. В статье разбираем, как работать с таким потоком требований и не превратить проект в бесконечность.

Взгляд на цели проекта

Цель любой задачи, будь то исправление ошибки в ИТ-продукте или внедрение ITSM-системы, получить результат. При реализации проекта заказчику важно оценить, что он планирует получить на выходе. Это может быть увеличение прибыли за счет оптимизации бизнес-процессов, повышение скорости обработки заявок либо качества предоставляемых услуг пользователям. Оптимально, если задачи формулируются по методу SMART. Так они связываются с конкретными результатами всего проекта. Правильно сформулированная задача — это фактически половина решения.

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

С чего начинается проект

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

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

Источники требований к ITSM-системе и их риски

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

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

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

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

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

Все дополнительные требования несут много рисков. Выделим ключевые:

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

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

Сбор требований в бэклог

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

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

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

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

Не каждое требование попадает в бэклог. Существуют разные критерии оценки, что в него включать. Приведем некоторые из них:

  • Насколько «громко» говорят о важности новой функции пользователи? Как это отразится в деньгах, если ее не будет? Каков негативный эффект, если выполнить позже, а не раньше?
  • Как влияет на общий поток задач? Задерживает ли реализацию чего-то еще? Нужно ли это выпустить к определенной дате? Есть ли риск того, что отказ в реализации сведет к нулю всю проделанную работу?
  • Снижает ли новое требование какие-то риски? Будет ли позитивно влиять на качество в других областях? Будет ли эффект сиюминутным или долгосрочным?

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

Как найти баланс между критичностью доработок и запуском ITSM-системы

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

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

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

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

Другая ситуация, когда в ходе тестирования выявлены дефекты, которые критично сказываются на производительности системы. Такие дефекты необходимо устранять сразу, но стараться «не вылезать» из плана проекта. При этом дату старта придется корректировать. Не стоит делать все и сразу. Это риски. Перед тем, как записывать задачу в бэклог и планировать реализацию, следует выполнить следующие шаги:

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

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

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

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

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

6. Провести демонстрацию функционала.
Когда разработка завершена, лучше отдельно показать заказчику итоги реализации.

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

Подведем итог

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

Каждый руководитель проекта вспомнит свои трудности, с которыми он сталкивался, и как происходила работа с требованиями: какие из них дали вау-эффект, а какие получились совсем не востребованными. А как вам удалось изменить набор требований по ходу проекта и что было вынесено в развитие? Делитесь своим опытом в комментариях.