ИТ-аутсорсинг: сервис с ответственностью за процесс работы команды (team leasing) или за поставленные наработки (deliverables) с успешным приёмочным тестированием
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
www.cmcons.com. Практика и технология внедрения процесса конфигурационного управления и управления изменениями с применением IBM Rational ClearCase и ClearQuest
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Это доклад на онлайн-конференции, посвящённой управлению качеством в проектах. Рассматриваются различия подходов к управлению качеством в "гибких" и "водопадных" методологиях и подход "stage-gate" как разумный компромисс между ними.
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Оплата за процесс или за результат, в чём отличие заказа на строительство/разработку от услуги на доступ к экспертизе/ресурсу, аутсорсинг и аутстаффинг, разработчики софта и системные интеграторы, передача прав интеллектуальной собственности или лицензия, само собой разумеющееся глазами юриста и программиста, какими сюрпризами чрезаты договоренности по "общему праву", уязвимые места ожиданий американских заказчиков в части авторства и доработок и как их учесть не в ущерб интересам друг друга
Модуль 14. Лекция 55-56. Управление релизами и развертыванием продуктаYana Brodetski
Управление релизами и развертыванием
продукта (Release and Deployment)
● Планирование управлением поставками
продукта
● Определение артефактов
● Формирование плана конфигурации поставки
продукта
● Определение и формирование плана релиза
продукта
Аналитик и Тестировщик в одном лице – путь к качеству (Максим Цепков, SQA Day...CUSTIS
Выступление Максима Цепкова, нашего главного архитектора дирекции по развитию решений, на конференции Software Quality Assurance Days (2–3 декабря 2011 года, Москва).
Это доклад на онлайн-конференции, посвящённой управлению качеством в проектах. Рассматриваются различия подходов к управлению качеством в "гибких" и "водопадных" методологиях и подход "stage-gate" как разумный компромисс между ними.
User Stories vs. Use Cases
● User Stories
● Определение User Story
● Структура пользовательской истории
● Принципы проверки на качество User Story
● Use Cases
● Определение Use Cases
● Структура Use Cases
● Принципы составления Use Cases
Ромуальд Здебский, Обеспечение качества через интегрированное управление прое...SQADays_2009_Piter
Ромуальд Здебский, Microsoft, Санкт-Петербург, Россия
Обеспечение качества через интегрированное управление проектами разработки ПО - настоящее и будущее
Оплата за процесс или за результат, в чём отличие заказа на строительство/разработку от услуги на доступ к экспертизе/ресурсу, аутсорсинг и аутстаффинг, разработчики софта и системные интеграторы, передача прав интеллектуальной собственности или лицензия, само собой разумеющееся глазами юриста и программиста, какими сюрпризами чрезаты договоренности по "общему праву", уязвимые места ожиданий американских заказчиков в части авторства и доработок и как их учесть не в ущерб интересам друг друга
Жизненный цикл разработки ПО (SDLC)
Этапы жизненного цикла разработки
Этап планирования
Этап разработки
Этап поддержки
Роли в жизненном цикле разработки ПО
Артефакты в жизненном цикле разработки ПО
Терминология
Достоинства и ограничения проектных моделей водопада и гибких подходов: скрам, аджайл (scrum, agile).
Как на основе специфичных характеристик проекта подобрать модели планирования и управления ИТ проектом
Сделать безопасно и сертифицировано — ЗАО «ПМ» на DevCon 2015Maxim Avdyunin
Сертификация приложений по требованиям федеральных и отраслевых регуляторов, требованиям компаний (если они есть) — необходимое условие разработки и поставки коробочного решения. Требования потребителей и пользователей современных технологий по функционалу и удобству развиваются значительно быстрее эволюции ограничений. В результате, исследования практической защищенности, если и рассматриваются, то вне темы сертификации, что порождает двойной объем работ и сложности в управлении проектами.
Презентация, подготовленная сотрудниками компании «Перспективный Мониторинг» для конференции DevCon 2015, содержит информацию о том, какие практики безопасной разработки позволяют удовлетворить как требования сертификации, так и потребности практической безопасности. Рассматриваются тонкие моменты на стыке этих задач, вопросы, в которых можно опереться на мировой опыт, а также планы регуляторов по развитию требований сертификации.
В докладе представлен опыт ЗАО «ПМ» по внедрению безопасной разработки в проекты создания и развития линейки средств защиты информации для сетевого оборудования, мобильных платформ и рабочих станций, подлежащих сертификации по требованиям регуляторов.
Risk of employment relationship recognized by Ukrainian regulator(s) where individual subcontractors engaged by IT company. May Diia City be treated as mitigation strategy?
Module 5 contract requirement to respect "industry standards"Natalia Perestyuk
Неявные условия договора с заказчиком на разработку ПО: соблюдение "передовых стандартов индустрии", выполнение работы "до окончательного удовлетворения закзчика", ссылка на "vision" продукта, “в должном объёме и должным образом”
Recommendations on Ukraine’s Accession to Hague Trust Convention (1985)Natalia Perestyuk
“the first serious attempt in 600 years to bridge the gap of the “English Channel” (known in French as La Manche) in the field of fiduciary law" D.W.M.Waters, 1995
Module 4 On going service consumption vs deliverables expectations
1. Модуль 04
Потребление услуги
(по ходу предоставления)
или ожидания по
результатам
В рамках серии вебинаров Наталии Перестюк
«Контракты с иностранными заказчиками ИТ
услуг (разработка ПО)»
2. ИТ-аутсорсинг: процесс & результат
Expertise to be provided
(extension to customer's team)
«варианты расширения
команды заказчика»
Predefined scope delivery
(SW requirements specified)
«части отдельных задач
в проекте заказчика»
Remote team allocation
(staff leasing + infrastructure)
«подбор и размещение
удалённой команды»
Custom application development
(based on business requirements)
«разработка приложения на
заказ»
Commitment on…
(что было/ будет
продано?)
3. Примеры покупки «процесса»
team extension
dedicated team
engineering at scale
offshore development center
shared competence center
staff leasing
remote team allocation
so on…
4. Примеры покупки «результата»
custom application development
corporate / web portal / mobile app dev
turn-key solution for specific business domain
business application development
product development & support
reverse engineering (legacy system)
requirements finalization
so on…
5. Переход в «юридическую плоскость»
Подряд (ответственность за результат):
передаётся готовый результат
поставка против требований
ошибки (дефекты) – помеха для приёмки
Услуга (ответственность за процесс):
конечную ценность несёт уже сам процесс
критерии качества – мерка приемлемости
приёмки как таковой нет (подтверждение предоставления)
НО: СМЕШАННАЯ ПРИРОДА УСЛУГ РАЗРАБОТКИ ПО
не всегда позволяет разделить одно и другое (напр. Agile)
6. “Idle time” или “bad” Deliverable
Непредоставленное благо оплате не подлежит!
В сервисном контракте (на процесс) нет пользы от фразы
«заказчик оплачивает idle time»
В подрядном контракте (на результат) нет пользы от фразы
«заказчик оплачивает непринятый продукт»
Обе фразы не будут законны (нельзя действовать «в лоб»)
Поможет согласованный регламент взаимодействия
(роли/обязанность утвердить/отказать в некие сроки)
7. Отчёты & контроль изменений
Процедура регулярной отчётности по контракту
как инструмент защиты от «лишних сюрпризов»:
согласованный регламент (график, каналы
коммуникации, форма, правильный адресат)
обратная связь (временные параметры – 3-5 дней на
негативный ответ)
связка обратной связи с легитимным основанием к
пересмотру суммы инвойса
Процедура контроля изменений – залог управляемости
рамками ответственности сервис-провайдера
Отсутствие негативной обратной связи влечёт
невозможность «оспорить» инвойс
8. Если отвечаем за результат:
Регламент (временные параметры):
3-5 дней заказчику на негативный ответ
10-15 на более сложное тестирование
20-30 подрядчику на доработку
(по результатам непройденной приёмки)
Управления рамками ответственности:
критерии приёмки (не всегда есть к старту)
ранжирование «дефектов», блокирующие
ранжирование «блокирующих» по этапам
процедура контроля изменений: сроки, роли
9. Разные модели разработки ПО
Что Продано Заказчику? Какой Договор Предложить?
(1) “Team leasing”, т.е. доступность тех или
иных специалистов/экспертизы
(расширение основной команды
заказчика)
предоставление услуг
(см. «подводные камни» для
критериев качества)
(2) готовность достаточно оперативно
принимать в работу заказы той или иной
направленности (поддержание
актуальности среды разработки)
предоставление услуг
(с элементами подрядных условий в
части критериев качества)
(3) «Custom app dev», в т.ч. полная
разработка приложения «с нуля» (со
сбором требований)
подряд (см. «подводные камни» для
критериев приёмки/требований) или
предоставление услуг
(4) сопровождение приложения в ходе его
жизненного цикла
предоставление услуг
(см. «подводные камни» для
критериев качества)
(5) поддержка разработанных
приложений, гарантии уровня их
доступности («успешность сервиса»)
предоставление услуг (с элементами
«успешности» в критериях качества)
10. Модель (1) «Team Leasing»
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
доступность тех или
иных
специалистов/эксперт
изы (расширение
основной команды
заказчика)
описание квалификации разработчиков/тестировщиков
(не конкретных людей)
контроль отсутствия в отчете о предоставленном сервисе
такой позиции, как «простой команды» (idle time)
согласованность регламента предоставления сервиса (в т.ч.
временные интервалы для обратной связи типа «с
сервисом что-то не так»)
процедура отчётности по завершению периода (отправка
отчёта, сроки/формат ответа на него, степень и сроки
детализации замечаний)
контроль величин «сверхурочных» в отчёте о
предоставленном сервисе
критерии качества услуги должны учитывать то, что люди
могут быть недоступны (в частности, из-за болезни,
отпуска, перехода на другую работу)
11. Разные модели разработки ПО
Что Продано Заказчику? Какой Договор Предложить?
(1) “Team leasing”, т.е. доступность тех или
иных специалистов/экспертизы
(расширение основной команды
заказчика)
предоставление услуг
(см. «подводные камни» для
критериев качества)
(2) готовность достаточно оперативно
принимать в работу заказы той или иной
направленности (поддержание
актуальности среды разработки)
предоставление услуг
(с элементами подрядных условий в
части критериев качества)
(3) «Custom app dev», в т.ч. полная
разработка приложения «с нуля» (со
сбором требований)
подряд (см. «подводные камни» для
критериев приёмки/требований) или
предоставление услуг
(4) сопровождение приложения в ходе его
жизненного цикла
предоставление услуг
(см. «подводные камни» для
критериев качества)
(5) поддержка разработанных
приложений, гарантии уровня их
доступности («успешность сервиса»)
предоставление услуг (с элементами
«успешности» в критериях качества)
12. Модель (3) Custom app dev
Когда заказчик
платит за
Практические «уловки» для договора, отчёта по нему
полную разработку
приложения
«с нуля»
(в т.ч. сбор
первичных
требований)
согласованность критериев приёмки промежуточных/
конечных поставок (например, ранжирование дефектов по
неким признакам, дабы не допустить подхода «ПО должно
быть без дефектов»)
учёт особенностей жизненного цикла (эволюции) самих
требований к ПО (в т.ч. условий устранения помех приёмке)
ранжирование веса для разных источников требований (как
по иерархии/приоритетности проектных документов, так и
по времени согласования)
взаимозависимость этапов сбора/согласования
требований, разработки, тестирования (в т.ч. последствия
для отклонений от плана)
Процедура контроля изменений, как «хранитель
устойчивости согласованных рамок заказа» (изменение не
может подлежать имплементации по-умолчанию)
13. Что не всегда очевидно юристу?
(подводные камни разработки ПО)
1: «софта без ошибок не бывает в принципе»
2: «требования не замораживаются на 100%»
3: «доступность сервиса не может быть 100%»
4: «расширяемость команды всегда ограничена»
5: и т.п. «само собой разумеющееся»…
14. Мировые Тренды в Индустрии ПО
Когда безлимитная ответственность по контракту -
«нечто само собой разумеющееся»?
за нарушение прав интеллектуальной собственности
(в т.ч. не обеспечение «их чистоты» третьими лицами)
за разглашение конфиденциальной информации
(в т.ч. не обеспечение другими должной сохранности)
за вред от умышленного нарушения условий договора
15. Оформление обязательств команды
Как часть мероприятий по управлению персоналом:
для передачи резюме и интервью менеджером клиента
в рамках мероприятий по охране коммерческой тайны
для обеспечения выполнения обязательств компании
«Ретрансляция» условий контракта с заказчиком:
NDA (рамки конфиденциальности + процедура контроля)
non-compete (в т.ч. участие в non-solicit)
передача персональных данных (в т.ч. “background check”)
Смягчение риска “переквалификации” (если с ФОП):
реализуемо не для всех моделей (team leasing)
16. Ряд контрактов в ИТ-аутсорсинге
Возможные участники:
сервис-провайдер – заказчик ИТ-услуг
сервис-провайдер – сотрудники / бизнес-партнёры
заказчик – сотрудники сервис-провайдера
Возможная суть:
предоставнение ИТ-услуги / выполнение разработки
завершение взятой работы / готовность к новым задачам
конфиденциальность / не работа на конкурента
(NDA / non-compete)
17. Благодарю за внимание!
С наилучшими пожеланиями,
Наталия Перестюк, адвокат, MBA
+ 38 067 215 37 37
natalia@perestyuk.com
linkedin.com/in/NataliaPerestyuk