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

1. В чём суть договора с
заказчиком для
глобального рынка ИТ?
Подготовила: Наталия Перестюк (доклад 11.09.2016)
Управляющий партнёр Network Partners
Адвокат, МВА

2. ИТ-договор с заказчиком
НЕ затрагиваются в докладе:
ни вопросы налогообложения (в т.ч. сотрудник/СПД)
ни таможенные правила (в т.ч. пересечение границы)
ни взаимодействие с локальными регуляторами (КСЗИ)
ни использование доменов (в т.ч. для целей e-commerce)
ни роли, ни способ, ни процесс заключения договора
Каких условий
в нём
будет
больше?

3. Насколько ИТ-рынок широк?

4. Аутсорсинг разработки ПО

5. Что не всегда очевидно юристу?
(подводные камни разработки ПО)
1: «софта без ошибок не бывает в принципе»
2: «требования не замораживаются на 100%»
3: «доступность сервиса не может быть 100%»
4: «расширяемость команды всегда ограничена»
5: и т.п. «само собой разумеющееся»…

6. Подряд и Услуга в Праве
Подряд:
передаётся готовый результат
поставка против требований
ошибки (дефекты) – помеха для приёмки
Услуга:
конечную ценность несёт уже сам процесс
критерии качества – мерка приемлемости
приёмки как таковой нет (подтверждение предоставления)
НО: СМЕШАННАЯ ПРИРОДА УСЛУГ РАЗРАБОТКИ ПО
не всегда позволяет разделить одно и другое

7. «Регламент» vs. «полёт мысли»
Вопросы к самому себе на берегу»:
Как измерять результат «творческого труда»?
Что значит «сиё творение» достаточно хорошо?
Как защитить «согласованные ожидания» без
ущерба маневренности во имя общего блага?
В чём вклад договора с субподрядчиком в
управление проектом разработки ПО
какими рисками мы благодаря этому управляем?
стандартизированы ли процессы (CMM(I), ISO,…)?
делегированы ли полномочия (как минимум, до
уровня руководителя конкретного проекта)?

8. Разработка ПО &
Строительство
2 бизнес-индустрии, в которых
практики управления проектами
наиболее востребованы

9. Что такое «Риск Предупредить»?
(Risk Mitigation)
Предупреждение/снижение риска – это:
уменьшение вероятности наступления и/или последствий
воздействия риска/угрозы до приемлемого уровня
Примеры:
- внедрение менее сложных процессов,
- выбор более надежного поставщика
Если невозможно повлиять на вероятность наступления угроз,
мероприятия по смягчению должны быть направлены на
последствия его воздействия
Пример:
- проектирование избыточности в системе может уменьшить ощутимость
Руководство PMBOK 4, © 2008 Project Management Institute

10. Что такое «Риск Принять»?
(Risk Accept)
Принятие (риска) важно для тех угроз, которые не удается устранить
Такая стратегия указывает на то, что проектная команда:
- решила не изменять план управления проектом для борьбы с риском или
- не способна определить иную подходящую стратегию реагирования
Принятие риска может быть как активное, так и пассивное
Активное принятие риска – это:
установление резерва на возможные потери,
включая определенные величины времени, денег или ресурсов,
необходимых для устранения рисков.
Руководство PMBOK 4, © 2008 Project Management Institute

11. Мировые Тренды в Индустрии ПО
Когда безлимитная ответственность по контракту -
«нечто само собой разумеющееся»?
за нарушение прав интеллектуальной собственности
(в т.ч. не обеспечение «их чистоты» третьими лицами)
за разглашение конфиденциальной информации
(в т.ч. не обеспечение другими должной сохранности)
за вред от умышленного нарушения условий договора

12. Сюрпризы из «Общего Права»
Agreement in general: “no consideration – no contract”
Lack of intention to be bound: “subject to contract”
Copyright: “moral rights transfer” & indemnity as to:
no author's name indication (anywhere the SW is in use)
derivative works (authorisation without any limits)
Warranties & Conditions – contract discharge cause
Representations vs. Contract Terms (express & implied):
common law or equitable remedies may apply?
Exemptions for breach – way to agree & wording matters
Anticipatory breach: accept + damages vs. performance

13. Алгоритм Заключения Договора

14. Права Автора: Личностный Аспект
КОНФЛИКТЫ ОЖИДАНИЙ иностранных заказчиков
с корнями в области авторских прав ©:
личные неимущественные права (moral rights)
в Украине: нельзя просто забрать у «первичного носителя»
transformative works vs. derivative works
в Украине: нет разницы среди «производных произведений»
НО: “первичный носитель” (возмездно!) может сам
определить способ реализации такого права, как:
 разрешить переработку на усмотрение заказчика,
как добавочное благо за добавочную плату
 запретить упоминать о своем авторстве,
заботясь о сохранении своего имиджа (в виду
отсутствия контроля над дальнейшим жизненным
циклом «своего творения в чужих руках»)

15. Разные модели разработки ПО
Что Продано Заказчику? Какой Договор Предложить?
(1) доступность тех или иных
специалистов/экспертизы (расширение
основной команды заказчика)
предоставление услуг
(см. «подводные камни» для
критериев качества)
(2) готовность достаточно оперативно
принимать в работу заказы той или иной
направленности (поддержание
актуальности среды разработки)
предоставление услуг
(с элементами подрядных условий в
части критериев качества)
(3) полная разработка приложения «с
нуля» (в т.ч. сбор первичных требований)
подряд (см. «подводные камни» для
критериев приёмки/требований) или
предоставление услуг
(4) сопровождение приложения в ходе его
жизненного цикла
предоставление услуг
(см. «подводные камни» для
критериев качества)
(5) поддержка разработанных
приложений, гарантии уровня их
доступности («успешность сервиса»)
предоставление услуг (с элементами
«успешности» в критериях качества)

16. Аутсорсинг разработки ПО (1)
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
доступность тех или
иных
специалистов/эксперт
изы (расширение
основной команды
заказчика)
описание квалификации разработчиков/тестировщиков
(не конкретных людей)
контроль отсутствия в отчете о предоставленном
сервисе такой позиции, как «простой команды»
согласованность регламента предоставления сервиса (в
т.ч. временные интервалы для обратной связи типа «с
сервисом что-то не так»)
процедура отчётности по завершению периода (отправка
отчёта, сроки/формат ответа на него, степень и сроки
детализации замечаний)
контроль величин «сверхурочных» в отчёте о
предоставленном сервисе
критерии качества услуги должны учитывать то, что люди
могут быть недоступны (в частности, из-за болезни,
отпуска, перехода на другую работу)

17. Аутсорсинг разработки ПО (2)
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
готовность
достаточно
оперативно
принимать в
работу заказы той
или иной
направленности
(поддержание
актуальности
проектной среды)
процедура изменения требований, как «хранитель
устойчивости согласованных рамок заказа» (изменение не
может подлежать имплементации по-умолчанию)
согласованность критериев качества (например,
ранжирование дефектов по неким признакам, дабы не
допустить подхода «ПО должно быть без дефектов»)
взаимозависимость этапов запроса/уточнения требований,
разработки, тестирования (в т.ч. последствия для
временных сдвигов относительно плана)
ограниченность периода «поддержания готовности»,
правила коммуникации по сдвигам сроков в ожидаемых
запросах

18. Аутсорсинг разработки ПО (3)
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
полную разработку
приложения
«с нуля»
(в т.ч. сбор
первичных
требований)
согласованность критериев приёмки промежуточных/
конечных поставок (например, ранжирование дефектов по
неким признакам, дабы не допустить подхода «ПО должно
быть без дефектов»)
учёт особенностей жизненного цикла (эволюции) самих
требований к ПО (в т.ч. условий устранения помех
приёмке)
ранжирование веса для разных источников требований (как
по иерархии/приоритетности проектных документов, так и
по времени согласования)
взаимозависимость этапов сбора/согласования
требований, разработки, тестирования (в т.ч. последствия
для отклонений от плана)
процедура изменения требований, как «хранитель
устойчивости согласованных рамок заказа» (изменение не
может подлежать имплементации по-умолчанию)

19. Аутсорсинг разработки ПО (4)
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
сопровождение
приложения в ходе
его жизненного цикла
контроль отсутствия в отчете о сервисе такой позиции,
как «отсутствие запросов»
согласованность регламента предоставления сервиса (в
т.ч. временные интервалы для обратной связи типа «с
сервисом что-то не так»)
процедура отчётности по завершению периода (отправка
отчёта, сроки/формат ответа на него, степень и сроки
детализации замечаний)
когда продано
«команду
поддержки»
(см.опцию 1)
критерии качества услуги должны учитывать то, что люди
могут быть недоступны (в частности, из-за болезни,
отпуска, перехода на другую работу)

20. Аутсорсинг разработки ПО (5)
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
поддержку
разработанных
приложений,
гарантии уровня
доступности
(«успешность
сервиса»)
3 или 4 «9-ки» - это стандарт успешности сервиса
промышленных дата-центров
поддержка программного продукта широкого
использования и поддержка заказной разработки –
кардинально разные вещи
…

21. Благодарна за Ваше внимание
Natalia Perestyuk, Attorney at Law, MBA
Managing partner at Network Partners
ua.linkedin.com/in/NataliaPerestyuk
+ 38 067 215 37 37
natalia @ perestyuk . com