Как осуществлять управление изменениями в разработке систем с юридической точки зрения

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

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

Почему проекты по разработке систем “изменяются” после завершения?

Разработка системы – совместная работа вендора и пользователя

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

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

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

Что такое документ управления изменениями

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

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

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

• Если были пропущены некоторые вопросы при определении требований или базовом проектировании, и требуется добавить функцию после этого
• Если в процессе разработки происходит пересмотр бизнес-стратегии и требуется изменение спецификаций

Это только некоторые из возможных примеров.

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

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

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

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

（Процедура управления изменениями）
Статья 37. Если сторона А или сторона Б получает предложение об изменении на основании статьи 34 (Изменение спецификаций системы и т.д.), статьи 35 (Утверждение промежуточных материалов пользователем) или статьи 36 (Обработка неопределенных вопросов), она должна в течение ○ дней с даты получения представить другой стороне документ (далее – “документ управления изменениями”), в котором указаны следующие пункты. Стороны А и Б обсуждают вопрос о возможности такого изменения на контактном совещании, предусмотренном статьей 12.
① Название изменения
② Ответственный за предложение
③ Дата
④ Причина изменения
⑤ Подробные сведения об изменении, включая спецификации, связанные с изменением
⑥ Если требуются затраты на изменение, то их сумма
⑦ График работ по изменению, включая период обсуждения
⑧ Прочие влияния изменения на условия настоящего и отдельного контракта (сроки выполнения работ или сроки поставки, комиссионные, условия контракта и т.д.)

Если вы прочитаете текст статьи и проверите рекомендуемые пункты для записи, дальнейшие объяснения не потребуются. Чтобы избежать проблемы “сказал – не сказал” впоследствии, следует записывать ход изменений подробно и конкретно.

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

Что стоит знать о управлении изменениями

Управление изменениями, как правило, должно проводиться вместе с управлением задачами

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

Лучше также установить правила для проведения обсуждений об изменениях

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

Обсуждение изменений и обязательство добросовестности

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

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

Примером может служить следующий текст (приведен пример статьи, взятой из “Базового/индивидуального контрактного образца”, официально созданного Независимым административным агентством по продвижению обработки информации).

Статья 4, пункт 3: В обсуждении изменений обе стороны должны добросовестно обсудить объект изменения, возможность изменения, влияние изменения на стоимость и сроки поставки и т.д.

Положения об изменении метода

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

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

Заключение

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

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