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

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

Что такое инфраструктура в IT-системах

Технические специалисты, занимающиеся разработкой систем, называются системными инженерами (SE). Проекты разработки начинаются с верхних этапов, таких как создание технических заданий и проектной документации, и включают в себя реализацию программ и проведение тестирования. В широком смысле системный инженер (SE) – это технический специалист, который занимается всеми этими задачами. Однако в зависимости от компании или рабочего места, обязанности и область ответственности могут дополнительно разделяться на более узкие категории. Термин “инженер инфраструктуры” обычно относится к техническим специалистам, которые занимаются подготовкой физической среды для работы компьютеров в рамках разработки и эксплуатации IT-систем. IT-системы, используемые в компаниях и на рабочих местах, в некотором смысле являются абстрактными конструкциями, состоящими из комбинаций исходного кода. Однако для того, чтобы эта система могла выполнять свою первоначальную роль, необходимо настроить инфраструктуру, включая серверы и сети. Разработка системы осуществляется на двух колесах: реализация программного кода и подготовка инфраструктуры, поддерживающей рабочую среду. Этот подход считается важным для предотвращения непредвиденных проблем.

Конкретные сценарии, когда проблемы с инфраструктурой могут привести к провалу проекта

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

Как ошибки в размере сервера могут вызвать конфликты

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

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

Суть вопроса – до какой степени вендор должен отвечать за неясные спецификации

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

https://monolith.law/corporate/system-development-specs-function[ja]

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

Меры по предотвращению проблем, вызванных ошибками в размере сервера

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

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

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

Конкретизация требований к разработке и полное управление изменениями

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

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Выбор модели разработки, соответствующей характеру проекта

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

Заключение

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