Инструмент

Что должно перейти из рук в руки при передаче программы?

Сорок один пункт в девяти областях. Отмечайте здесь или распечатайте целиком и идите с этим на встречу.

0 of 49 done

Код и история

Репозиторий — простая часть, и та самая, которую считают законченной, когда она не закончена.

Среды
Инфраструктура и аккаунты

Единственный раздел, после которого можно остаться в проигрыше навсегда, а не просто с задержкой. Установите владение до того, как что-либо отзывать.

Выкатка и релиз
Данные и восстановление
Интеграции и зависимости
Эксплуатация
Понимание

Часть, которая решает, сколько передача продлится, и та, которую почти никогда не прописывают в договоре.

Закрытие передачи

Ticks stay in this browser. Nothing is submitted, no account is needed and no email address is asked for. Print it, or clear it and start again.

  • 41 пункт
  • без аккаунта и почты
  • чисто печатается
  • галочки хранятся в браузере

Короткий ответ

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

#В каком порядке это делать

Список сгруппирован по областям, чтобы по нему было удобно идти. Последовательность другая, и ошибиться в ней дорого.

  1. Сначала владение — по возможности до того, как подано уведомление о расторжении. Это единственная категория, после которой можно остаться неспособным работать, а не просто с задержкой.
  2. Потом техническая картина, потому что её дыры и есть повестка всего дальнейшего.
  3. Потом показ — запустить, выкатить, восстановить, пока знающие люди ещё доступны.
  4. Потом рассуждения: именно сюда должно уйти оставшееся внимание уходящей команды, потому что произвести это больше некому.
  5. Смена доступов — последней, после того как владение подтверждено, а собственные пути входа проверены.

#Что вписывают вместо «документация передана»

Если вписывать в договор одну вещь, впишите эти три — как критерии приёмки:

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

Их дёшево провести, невозможно подделать, и они меняют мотивацию всех участников с первой же недели.

#Чего этот чек-лист не покрывает

Чего это не делает

  • Коммерческие и юридические условия: интеллектуальную собственность, сроки уведомления, ответственность, гарантии. Для этого нужен человек, который посмотрит именно ваш договор.
  • Всё специфичное для регулируемых отраслей — в платежах, медицине и госсекторе передача несёт обязательства, о которых этот список не знает.
  • Ревью качества кода, безопасности и архитектуры. Передача устанавливает, что систему можно эксплуатировать, а не что она хороша.
  • Людей. Способна ли принимающая команда — это не то, что может установить чек-лист.

Вопросы, которые задают на самом деле

Нет. Он прямо на этой странице, он печатается, и никакой формы-шлагбаума нет. Чек-лист за формой сбора почты — это лид-магнит, а не чек-лист.

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

Да, со списками вроде этого так и делают. Если будете — впишите три приёмочные проверки как критерий завершения вместо «документация передана».

Раздел «Понимание» — тот, который занимает недели.

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

Построить карту проекта — бесплатно Сначала проверить готовность