Ситуация

Как передать программный проект новой команде?

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

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

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

#Что значит «завершена»

Передача программной системы
Переход способности эксплуатировать систему, менять её и рассуждать о ней от одной команды к другой. Он завершён, когда принимающая команда может выкладывать, восстанавливать и объяснять систему самостоятельно, — а не когда сдан комплект документов.
Если проще Момент, с которого за вашей системой может присматривать кто-то другой, не обращаясь к тем, кто её построил.

Определение здесь не формальность: большинство передач ведут по неверному критерию завершённости. В договоре написано «документация и сессии передачи знаний», обе стороны это делают, все подписывают, а через четыре месяца новая команда всё ещё что-то обнаруживает. Никто ничего не нарушил. Просто в договор записали не то.

#Четыре вещи, которые передаются

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

Из чего на самом деле состоит передача
ЧастьЧто это Если не получитсяКогда это должно произойти
Владение Учётные записи, домены, облако, регистратор, кабинеты провайдеров — на чьё имя каждая Вы теряете контроль над тем, что считали своим До объявления об уходе, а лучше за годы до него
Эксплуатация Запустить локально, выложить, восстановить, увидеть, что происходит Вы не можете выкатываться и узнаёте об этом под давлением Подтверждается показом, а не документом
Понимание Из чего состоит система, что от чего зависит, что неизвестно Месяцы повторного открывания, оплаченные вами дважды Выводится из системы в любой момент
Рассуждения Почему сделано так, что отвергли, с чем быть осторожным Новая команда переделывает то, что существовало не просто так Только пока уходящие готовы отвечать

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

#Порядок, который работает

  1. Разберитесь с владением до любых объявлений

    Пройдите по каждой учётной записи, без которой система не живёт, и запишите, на чью личность она оформлена. Всё, что оформлено на человека, — это передача с процедурой и сроком, а не смена прав.

    Сделайте это до уведомления, если есть хоть какая-то возможность. Когда отношения заканчиваются, «передайте, пожалуйста, домен» превращается из поручения в переговоры.

  2. Выведите техническую картину — независимо

    Прогоните анализ системы и получите карту со ссылками на источники и явным перечнем того, что установить не удалось. Важно сделать это рано: её пробелы задают повестку всему остальному.

    Независимо значит: не документ, написанный уходящей командой о собственной работе. Полезны оба, но проверить можно только один.

  3. Превратите пробелы в список вопросов

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

  4. Докажите эксплуатируемость делом

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

    Это самый ценный день любой передачи. Он превращает каждое «должно работать» в факт.

  5. Заберите рассуждения, пока это возможно

    Записанные встречи, конкретные вопросы, письменные ответы. Что вас беспокоит; что вы пробовали и что не вышло; что здесь из-за ограничения, которого больше нет; что ломается регулярно и что вы с этим делаете.

  6. Прогоните анализ ещё раз в конце

    Второй анализ на закрытии договора, сравнённый с первым, — самый прямой отчёт о том, что за это время действительно изменилось.

  7. Смените все секреты, в правильной последовательности

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

#Как это проверить

Три проверки. Если проходят все три, передача настоящая. Если хотя бы одна не проходит — нет, что бы ни было подписано.

Три проверки

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

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

Для третьей проверки — десять разумных вопросов: из каких компонентов это состоит; от каких внешних сервисов зависит; где лежат данные клиентов; что происходит, когда платёж не прошёл; что запускается по расписанию и что делает; кто может выкладывать; что будет, если встанет очередь; какие части не покрыты тестами; какова процедура восстановления; что последний анализ отметил как неподтверждённое.

#Где передачи разваливаются на самом деле

Считать документацию результатом.

Вместо этого Запишите результатом три проверки выше. Документы — средство; некоторые из них стоит иметь, но ни один не является целью.

Оставлять вопрос владения на конец.

Вместо этого Начните с него, и лучше ещё до того, как отношения заканчиваются. Это единственная часть передачи, которая может оставить вас в необратимо худшем положении.

Тратить время уходящей команды на то, что выведет машина.

Вместо этого Структурную картину выведите из системы. Их часы потратьте на рассуждения и рабочие привычки, которых не восстановит никакой анализ.

Принять экскурсию вместо демонстрации.

Вместо этого Смотреть, как кто-то выкатывается, — не то же самое, что выкатиться. Каждый шаг, который принимающая команда не проделала руками, не передан.

Считать, что репозиторий — это вся система.

Вместо этого Спросите прямо, что работает вне его: задачи по расписанию на сервере, скрипт на чьей-то машине, облачная функция, созданная в консоли, таблица, которую кто-то ведёт руками.

Разрыв между двумя командами.

Вместо этого Наложите их друг на друга. Если уходящая заканчивает в пятницу, а принимающая начинает в понедельник, за выходные не отвечает никто — и за всё, что обнаружится на втором месяце, тоже.

#Где 1ADK помогает, а где нет

Где помогает

  • Независимая техническая картина, без выдачи кому-либо доступа к репозиторию.
  • Явные пробелы — конкретным списком вопросов, а не общим беспокойством.
  • Сравнение «до и после» по всему сроку передачи.
  • Запись, которая останется, когда обе команды уже уйдут.
  • Утверждения, которые принимающая сторона может проверить, а не принять на веру.

Где не помогает

  • Передать учётные записи и домены. Это ваша работа, и последовательность в ней важна.
  • Доказать, что система запускается. Это доказывает только запуск.
  • Восстановить рассуждения или рабочие привычки.
  • Оценить качество кода или найти уязвимости.
  • Вести переговоры с подрядчиком, который не хочет сотрудничать.

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

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

Тогда всё, что является свойством системы, по-прежнему восстановимо, а всё, что является свойством людей, — нет. Расставьте приоритеты соответственно: выведите картину из кода, переведите все учётные записи на компанию и относитесь к их остаточным знаниям как к бонусу, а не как к зависимости.

Немного — и не как основной результат. Документация, написанная во время передачи, описывает то, что автор помнит в условиях спешки. Потратьте их часы на то, чего не даст никто другой: рассуждения, рабочие привычки и ответы на конкретные вопросы. Структурную картину выведите из самой системы.

Одна проверка: принимающая команда, ни разу не обратившись к уходящей, выкатывает изменение, разворачивает резервную копию в отдельном окружении и правильно отвечает на десять вопросов о системе. Если не выполнено хотя бы одно из трёх, передача не закончена, что бы ни было подписано.

Проверьте готовность к передаче.

Девятнадцать вопросов, без аккаунта и без почты. На выходе — что подтверждено, что не подтверждено и что стоит проверить до передачи, а не во время неё.

Открыть проверку готовности Или построить техническую картину