Представьте, что ваша компания только что получила прибыльный и долгосрочный проект. Вам предстоит разработать мобильное приложение для европейского Medtech стартапа для Android и iOS с нуля. Если работа будет эффективной, клиент продолжит сотрудничество и ваша команда будет работать над обновлениями продукта и технической поддержкой. Этот проект важен для вашего бизнеса, так как у него есть потенциал для продолжительного сотрудничества. Чтобы обеспечить комфортную работу и оправдать ожидания, важно заранее заключить MSA договор, который поможет установить правила взаимодействия и предотвратит возможные недопонимания. MSA agreement заранее делает правила более четкими для обеих сторон и устраняет путаницу.
В этой статье наши юристы расскажут про преимущества подписания MSA и опишут важные пункты, которые нужно включить в документ.
Что такое Master Service Agreement?
MSA — это контракт между компанией по разработке программного обеспечения и клиентом, в котором описаны ожидания от проекта, правила взаимодействия, обязанности сторон, ответственность, сроки предоставления услуг и оплаты работы, передача интеллектуальной собственности и другие важные вопросы. MSA подходит для долгосрочных проектов и помогает сделать процесс разработки предсказуемым, несмотря на изменения в команде, объеме работ и видении проекта. MSA — это основа для других документов, таких как технические задания (ТЗ), запросы на изменения и другие.
Как работает MSA?
MSA определяет условия, которые регулируют отношения IT-компании и клиента, чтобы обеспечить взаимопонимание между ними. Если вы окажетесь в непредсказуемой ситуации, вы сможете найти ответ в MSA.
MSA — это руководство для команды компании по разработке программного обеспечения и клиента. Благодаря MSA менеджер проекта (PM) будет знать, как решить проблемы. Например, типичной проблемой, с которой сталкивается PM, будет задержка на стороне клиента. Представьте, что вы работаете на условиях Time & Materials, а клиент не отправляет материалы, которые нужны для продолжения работы, что приводит к простою и потере денег. Чтобы защитить интересы IT-компании, в MSA должно быть правило о том, что простой оплачивается, а дедлайны сдвигаются на время ожидания материалов. Это правило помогает дисциплинировать клиентов. Они будут принимать все возможные меры, чтобы выполнить свои обязанности вовремя, так как никто не хочет платить за команду, которая не работает.
Советы по созданию эффективного MSA
Обычно MSA составляет IT-компания и передает клиенту на утверждение. Задача компании — составить соглашение, которое учитывает риски и интересы обеих сторон. Ниже вы найдете несколько советов от наших юристов по созданию сбалансированного документа, который удовлетворит запросы клиентов и одновременно защитит интересы вашей компании.
Постановка, изменение и расторжение ТЗ
MSA определяет общие правила управления проектом, которых должны придерживаться обе стороны, но конкретные детали каждой новой задачи описываются в отдельном ТЗ. Этот документ – неотъемлемая часть MSA. Правила поставки, изменения и расторжения ТЗ должны быть зафиксированы в MSA.
Мы рекомендуем установить, какая информация должна быть включена в каждое ТЗ: определение услуг и объема работ, члены команды, сроки, процедуры оплаты и выставления счетов, способ передачи результатов работы и правила их приема.
Например, ваша компания предоставляет услуги по UI/UX для криптопроекта. Один из этапов проекта — работа над пакетом брендинга. В этом случае в ТЗ должно быть включено следующее:
- Услуги и объем работ. Например, разработка двух вариантов логотипа. Ваша команда исследует конкурентов, чтобы проверить их tone of voice, основные ценности, сообщения и т. д. Следующий шаг — разработка логотипов и презентация идеи, основных компонентов и примеров реализации. Презентация будет состоять из шаблона Google Slides (9-10 слайдов).
- Команда. Например, бренд-дизайнер и менеджер проекта.
- Сроки. Два месяца с момента подписания ТЗ. При этом, IT-компания своевременно уведомит клиента, если работа займет больше времени, чем планировалось.
- Ставки и оплата. Пакет брендинга будет предоставлен по фиксированной цене в размере $6500. Любые дополнительные функции или материалы должны быть оценены, согласованы и одобрены клиентом до начала работы. Дополнительные материалы будут оплачены отдельно.
- Счета и условия оплаты. Компания выставляет счет клиенту заранее, исходя из отдельных этапов, описанных в ТЗ. Стоимость бренд-айдентики должна быть разделена на два отдельных платежа по $3250 каждый. Счет должен быть оплачен в полном объеме в течение пяти рабочих дней после его выставления и передачи клиенту.
- Коммуникация. Для связи используются электронная почта, WhatsApp, Google Chat, Slack, Discord или аналогичные средства связи.
- Артефакты и материалы. Файлы Figma с доступом через защищенный URL. Презентации Google Slides или PDF с доступом через защищенный URL.
Обратите внимание, что ТЗ для услуг аутстаффинга будет отличаться. В таком ТЗ должны быть, как минимум, список членов команды, фиксированный рейт и роль каждого члена команды.
Следующий важный шаг – согласовать с клиентами условия изменения, приостановки и расторжения ТЗ. Клиент может изменить объем работ, поэтому MSA должен определить точную процедуру на этот случай.
Запрос на изменение означает одно из двух:
- Требование клиента о выполнении дополнительных работ, не предусмотренных в согласованном и утвержденном ТЗ
- Изменение технических спецификаций
Например, следующие ситуации могут считаться изменениями:
- Добавление новой задачи или этапа (функции, модуля, услуги)
- Обновление объема согласованных задач
- Изменение порядка выполнения согласованных задач
- Удаление существующей задачи
- Изменение технологии
Новые услуги, добавленные через запрос на изменение, заново оцениваются компанией и требуют дополнительных затрат, которые понесет клиент.
Мы советуем вам серьезно относиться к оформлению запросов на изменения и их содержанию, так как только правильно составленные документы могут быть использованы в суде, если клиент откажется оплатить работу. Такая ситуация произошла с CIGNEX, глобальной консалтинговой компанией, предлагающей решения, услуги и платформы на базе технологий Open Source, Cloud и Automation. Клиент компании отказался оплатить более $350 000 за услуги, предоставленные в рамках пяти запросов на изменение. Три из них были подписаны сторонами и определяли количество времени, потраченного членами команды CIGNEX на определенные этапы проекта, а также их почасовые ставки. Два других запроса на изменение не были согласованы и оформлены в письменной форме. Поэтому, суд США округа Делавэр постановил, что взыскание долга возможно только по трем правильно оформленным запросам на изменение. Кейс CIGNEX иллюстрирует насколько важно зафиксировать даже минимальные изменения на проекте с помощью запроса на изменение.
Следующий шаг — установить процедуру расторжения. Одна или обе стороны могут расторгнуть любое ТЗ полностью или частично. Чтобы защитить права компании, важно установить срок, в течение которого клиент должен уведомить о расторжении, например, 30 рабочих дней. После получения такого уведомления компания информирует клиента о всех выполненных работах на момент уведомления. Клиент обязуется принять и оплатить работу, выполненную до даты расторжения ТЗ.
Кроме того, компания оставляет за собой право приостановить или прекратить выполнение работ в случае, если клиент не оплатил инвойс вовремя.
Правильно оформленные ТЗ, запрос на изменения и процедура расторжения обеспечивают ясность и прозрачность, помогают избежать споров и снижают финансовые риски.
Простой в работе команды
В MSA нужно включить пункты про простой, чтобы смягчить финансовые риски и эффективно справиться с задержками на проекте. Ниже перечень таких пунктов.
- Определение простоя. В MSA важно написать, что считается простоем. Это время, в течение которого команда проекта не работает из-за задержек со стороны клиента.
- Список ситуаций на стороне клиента, которые будут считаться простоем. Задержки могут включать отказ клиента предоставить необходимые доступы, материалы, несвоевременное одобрение ТЗ и этапов проекта.
- Последствия простоя. Мы предлагаем включить в MSA положение об оплате времени простоя по ставке, указанной в ТЗ.
Дебаг
В первую очередь, включите в MSA определение того, что считается багом. Например, баг – это любое нарушение корректной и стабильной работы программного обеспечения, вызванное ошибками членов команды компании-разработчика. Ошибки можно классифицировать следующим образом:
- Блокирующие ошибки: делают использование программного обеспечения невозможным. Эти ошибки негативно влияют на программное обеспечение и бизнес клиента.
- Существенные ошибки: мешают правильной работе ключевых функций программного обеспечения, такие как значительные отклонения от бизнес-логики или некорректная реализация необходимых функций.
- Несущественные ошибки: не влияют на правильное функционирование программного обеспечения, но ухудшают пользовательский опыт, например, ошибки в дизайне UI/UX.
Далее установите гарантийный срок, в течение которого клиент может обращаться в компанию с просьбой об исправлении ошибок. Например, клиент может отправить запрос компании-разработчику программного обеспечения в течение 45 дней с момента полной оплаты за предоставленные услуги.
Когда клиент отправляет запрос, компании предстоит определить, является ли это ошибкой или запросом на изменение. Компания должна идентифицировать и исправить ошибки бесплатно, если:
- Ошибка не была и не могла быть выявлена на момент принятия работы.
- Баг был вызван технической ошибкой со стороны члена команды, в результате чего программное обеспечение не соответствовало техническим требованиям.
- Третьи стороны не вносили изменения в код программного обеспечения, и компания является единственным разработчиком кода.
В то же время, следующие случаи не должны классифицироваться как баги:
- Ошибки, вызванные дефектами исходных материалов клиента.
- Дополнительные работы, которые не описаны в ТЗ.
Как разработать эффективный MSA?
Чтобы написать эффективный MSA, вам необходимо учитывать ключевые особенности проекта, такие как ваша модель работы (аутсорсинг или аутстаффинг) и модель оплаты (фиксированная цена или почасовая оплата). Эти характеристики создают разные риски, поэтому MSA должен включать положения, учитывающие специфические вызовы вашей компании.
MSA – это не единственный документ, который необходимо подписать с клиентом. Чтобы понять полный объем необходимых документов для защиты вашей компании, ознакомьтесь с нашими статьями об NDA и соглашении о защите данных (DPA).
