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

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

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

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

Почему управление документами важно в разработке систем

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

Чтобы избежать споров в будущем

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

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

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

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

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

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

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

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

Что особенно важно в протоколе совещания по разработке системы?

Типы совещаний в разработке систем

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

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

Особое внимание следует уделить стиринг-комитету

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

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

Можно привести такие примеры.

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

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

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

Решение Верховного суда Токио от 26 сентября 2013 года (Heisei 25)

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

Конкретные пункты, которые следует записать в протоколе собрания

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

Пункты, которые следует записать с точки зрения поставщика

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

Учитывая эти обязанности, особенно важно для поставщика записать следующее:

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

Это лишь некоторые примеры.

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

Пункты, которые следует записать с точки зрения пользователя

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

1. История того, что пользователь сообщил поставщику о том, что он хочет, такое как функции, внешний вид экрана и т.д.
2. История различных проблем, возникших в процессе работы поставщика (например, внезапное увольнение члена команды или задержка в графике разработки из-за недостатка исследований со стороны поставщика и его причины)

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

Заключение

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

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