Закон, касающийся ухода участников проекта по разработке системы

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

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

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

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

• Физическое недомогание из-за чрезмерного сверхурочного труда или работы в выходные дни
• Психологический стресс из-за конфликтов в отношениях между людьми

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

Важные судебные прецеденты, связанные с уходом членов команды

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

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

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

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

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

Действительно, представитель пользователя признал, что на встрече в ноябре 2003 года (Heisei 15) он говорил в грубой форме: “Ты не хочешь работать?“, “Что это, контракт закончен. Если я выйду из этой комнаты, все закончится.” Однако, несмотря на то, что в основном соглашении было указано, что октябрь 2003 года (Heisei 15) является периодом прототипа, дополнительные функции, которые являются целью разработки этого проекта, не были включены в проектную документацию, и даже после того, как были сделаны комментарии к представленному проекту, не было никакого ответа. Это было вызвано задержкой работы поставщика и его реакцией, и это не может быть описано как чрезмерное поведение.

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

Решение Токийского окружного суда от 4 декабря 2007 года (Heisei 19)

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

Что можно узнать из этого судебного прецедента

Кроме того, можно извлечь следующие важные уроки:

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

Как подготовиться к риску ухода сотрудников

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

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

Создание системы, которая не оставляет сотрудников в одиночестве

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

Стремление к достаточному распределению персонала

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

Пересмотр распределения до ухудшения состояния здоровья

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

Тщательное управление изменениями и документацией проекта

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

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

https://monolith.law/corporate/the-minutes-in-system-development[ja]

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

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

Заключение

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

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

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