Комментарии 14
А не могли бы Вы поделиться опытом в части взаимоотношений с иностранными заказчиками? Например, основные существенные различия при работе, в зонах ответственности, в приемке работ?
Вы имеете в виду особенности работы с иностранными заказчиками в сравнении с работой с заказчиком на территории Родины?
В ближайшее время я завершу экскурс по гарантиям — там много еще интересного, а затем расскажу подробнее о интересующих Вас вопросах. Если Вы сталкивались с какими-либо конкретными проблемами — смело описывайте ситуцию, а я постараюсь дать ответы в комментариях или постах.
После гарантий предлагаю перейти к приемке работ.
В ближайшее время я завершу экскурс по гарантиям — там много еще интересного, а затем расскажу подробнее о интересующих Вас вопросах. Если Вы сталкивались с какими-либо конкретными проблемами — смело описывайте ситуцию, а я постараюсь дать ответы в комментариях или постах.
После гарантий предлагаю перейти к приемке работ.
Интересно будет. Вернее, уже интересно. Так что пожалуйста продолжайте :)
Спасибо за интересные моменты.
Вы должны быть на вес золота в своей компании. Юристов, разбирающихся в IT еще и в рамках международного права, в СНГ совсем не достаточно.
Вы должны быть на вес золота в своей компании. Юристов, разбирающихся в IT еще и в рамках международного права, в СНГ совсем не достаточно.
Лично мне кажется не очень удачной формулировка «after installation» во втором варианте. Использование «delivery» гораздо лучше отрадает смысл гарантии. «Delivery» не обязательно включает «installation» — могут придраться.
Согласен, «installation» — это скорее более специфичный вариант, но он тоже имеет право на существование. Сложно привести пример идельных формулировок. «Delivery» использовался в первом примере, а во втором — это тот вариант, с которым можно встретиться на практике либо самому использовать.
Но если говорить в общем, то Вы правы: «delivery» — это более безопасный и точный вариант. Спасибо за комментарий.
Но если говорить в общем, то Вы правы: «delivery» — это более безопасный и точный вариант. Спасибо за комментарий.
С подобным подходом и EULA пишут. Жаль, что читают их единицы, особенно в России.
Дмитрий, а где вы обучались переводу? Имею в виду, на основном образовании или 2-м высшем? У нас в СамГТУ, например, только второй способ был возможен, которым я и воспользовался. Или, может, на личном опыте постигали?
Дмитрий, а где вы обучались переводу? Имею в виду, на основном образовании или 2-м высшем? У нас в СамГТУ, например, только второй способ был возможен, которым я и воспользовался. Или, может, на личном опыте постигали?
Высшее образование, к сожалению, дало мне только основные принципы юридической техники в английском языке. Специфике переводов нас не обучали, но и на этом спасибо. Приходится постигать на личном опыте либо вычитывать в специализированной литературе.
Пока специализированной литературы по ИТ-праву на русском языке мало, но я уверен, что не за горами время, когда у нас на руках появится качественная отечественная литература.
Пока специализированной литературы по ИТ-праву на русском языке мало, но я уверен, что не за горами время, когда у нас на руках появится качественная отечественная литература.
У нас специальность на 2-м образовании называлась «Переводчик в сфере профессиональной коммуникации», так по каким только текстам нас не гоняли: и по органической химии, и по экономике, и по политике, и по электротехнике. Уроки деловой переписки были, пожалуй, самыми полезными — и по сей день навыки пригождаются почти ежедневно.
По юридическим вопросам тоже было дело. На примере контрактов (стороны, именуемые так-то, заключают договор о нижеследующем; обязательства сторон; гарантии; форс-мажор и т.п.).
Преподаватели говорили: «Не важно, о чём речь в тексте, какова его тематика. Поймите принципы, подходы к переводу, и тогда применить общие принципы к своей профессиональной области сможете всегда». И я с ними согласен: дело наживное, через пару лет «варения в профессиональном котле» и постоянной практики всё придёт.
По юридическим вопросам тоже было дело. На примере контрактов (стороны, именуемые так-то, заключают договор о нижеследующем; обязательства сторон; гарантии; форс-мажор и т.п.).
Преподаватели говорили: «Не важно, о чём речь в тексте, какова его тематика. Поймите принципы, подходы к переводу, и тогда применить общие принципы к своей профессиональной области сможете всегда». И я с ними согласен: дело наживное, через пару лет «варения в профессиональном котле» и постоянной практики всё придёт.
«Warranties as to Viruses and Disabling Code» — похоже, это шире, чем «гарантия отсутствия вирусов». Дословно — «гарантия отсутствия вирусов и блокирующего кода», а в техническом русском — что-то вроде «отсутствия вредоносных программ и недокументированных возможностей» (то есть, ПО не должно вирусов и всяких там «черных ходов» содержать).
Спасибо за статью. Тоже немного поделюсь опытом. Мы работаем в основном по Штатам. Все похоже, но есть небольшие отличия.
Наш адвокат говорит, что если вы включили пункт в контракт, значит:
1) вы либо готовы (=знаете как) по нему судиться,
2) либо готовы (=знаете как) по нему защищаться,
3) и при этом стоимость вопроса более $15K (потому что ровно столько будет стоить податься)
Если это не так, то либо соответствующего provision-а в договоре быть не должно, либо вообще браться за работу не стоит… К примеру, в «удачных примерах» — как сторонам договориться о том, что есть существенное требование? Если в приложении они по номерам не перечислены, у доски будут субъективные бодания (=утраченное преимущество, ущерб,...)…
Видимо из-за этого у нас есть два специфических момента:
Все общие положения (=разговоры про то, как должно быть) включаются в PSA (Professonal Services Agreement, от 15 до 50 страниц у разных организаций) — регулирующий документ, описывающй наши взаимоотношения безотносительно контрактов и выполняемых работ, и собственно контракт (SOW, Statement of Work, 1-2 страницы), в котором стоит ссылка на PSA и формулируются сроки, деньги, объемы работ и у кого остается IP. Если есть спецтребования — все идет туда же, по параграфу на требование. PSA подписывают экзеки, а SOW меньше определенной суммы (напр. $250K) могут подмахнуть и координаторы или даже менеджеры.
За любые отсылы к документации в контракте или PSA у меня заворачивают предложение. Причина в том, что из-за этого ТЗ становится частью контракта (Exhibit) и следовательно адвокатам надо вычитывать и этот птичий язык, и в случае чего доказывать его непротиворечивость PSA и законодательству. В случае реального разбирательства это влетит в копеечку. Поэтому если есть на столько существенные требования, что при невыполнении их мы готовы судиться, то они должны быть перечислены в явном виде.
Про ограничение по времени — абсолютно верно. Все что имеет начало должно иметь конец. Прошу прощения за длинный пост, надеюсь получилось по делу.
Наш адвокат говорит, что если вы включили пункт в контракт, значит:
1) вы либо готовы (=знаете как) по нему судиться,
2) либо готовы (=знаете как) по нему защищаться,
3) и при этом стоимость вопроса более $15K (потому что ровно столько будет стоить податься)
Если это не так, то либо соответствующего provision-а в договоре быть не должно, либо вообще браться за работу не стоит… К примеру, в «удачных примерах» — как сторонам договориться о том, что есть существенное требование? Если в приложении они по номерам не перечислены, у доски будут субъективные бодания (=утраченное преимущество, ущерб,...)…
Видимо из-за этого у нас есть два специфических момента:
Все общие положения (=разговоры про то, как должно быть) включаются в PSA (Professonal Services Agreement, от 15 до 50 страниц у разных организаций) — регулирующий документ, описывающй наши взаимоотношения безотносительно контрактов и выполняемых работ, и собственно контракт (SOW, Statement of Work, 1-2 страницы), в котором стоит ссылка на PSA и формулируются сроки, деньги, объемы работ и у кого остается IP. Если есть спецтребования — все идет туда же, по параграфу на требование. PSA подписывают экзеки, а SOW меньше определенной суммы (напр. $250K) могут подмахнуть и координаторы или даже менеджеры.
За любые отсылы к документации в контракте или PSA у меня заворачивают предложение. Причина в том, что из-за этого ТЗ становится частью контракта (Exhibit) и следовательно адвокатам надо вычитывать и этот птичий язык, и в случае чего доказывать его непротиворечивость PSA и законодательству. В случае реального разбирательства это влетит в копеечку. Поэтому если есть на столько существенные требования, что при невыполнении их мы готовы судиться, то они должны быть перечислены в явном виде.
Про ограничение по времени — абсолютно верно. Все что имеет начало должно иметь конец. Прошу прощения за длинный пост, надеюсь получилось по делу.
Спасибо за комментарий. Все по делу.
Если мы хотим дать такую гарантию, нам придется включить этот пункт. Когда мы говорим о работоспособности ПО, сложно себе представить описание этой рабособности в теле контракта. Описывают работоспособность иные проектные документы. Поэтому отсылка к этим документам неизбежна.
Категория «существенность» в этих примерах появилась в целях того, чтобы обезопасить разработчика от необоснованных претензий недобросовестных заказчиков.
Гарантия работоспособности напрямую связана с Acceptance criteria, который у нас, например, уточняется в SoW и, в свою очередь, тесно связан со спецификацией. Правил Acceptance criteria диктуют критерии приемки работы, определяя что существенно. (Косметические дефекты: пунктуационные ошибки, грамматические ошибки, проблемы с каким-нибудь цветом — не существенно).
При правильном подходе, мы можем описать «существенность» в SoW или спецификации. Все начинается и заканчивается с грамотной спеки
Если мы хотим дать такую гарантию, нам придется включить этот пункт. Когда мы говорим о работоспособности ПО, сложно себе представить описание этой рабособности в теле контракта. Описывают работоспособность иные проектные документы. Поэтому отсылка к этим документам неизбежна.
Категория «существенность» в этих примерах появилась в целях того, чтобы обезопасить разработчика от необоснованных претензий недобросовестных заказчиков.
Гарантия работоспособности напрямую связана с Acceptance criteria, который у нас, например, уточняется в SoW и, в свою очередь, тесно связан со спецификацией. Правил Acceptance criteria диктуют критерии приемки работы, определяя что существенно. (Косметические дефекты: пунктуационные ошибки, грамматические ошибки, проблемы с каким-нибудь цветом — не существенно).
При правильном подходе, мы можем описать «существенность» в SoW или спецификации. Все начинается и заканчивается с грамотной спеки
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Гарантия работоспособности ПО в англоязычном контракте (Часть 1)