Когда это нужно
Уходите из команды, меняете работу, устали от собственного проекта и отдаёте желающему, уходите в отпуск на месяц.
Плохая передача выглядит так: человек получает ссылку на репозиторий и слова «там всё понятно». Через неделю он не может запустить, а вы уже недоступны.
Что подготовить
Работающую инструкцию по запуску. Проверьте на чистой машине. Почти всегда выясняется, что чего-то не хватает: у вас оно давно установлено и вы про него забыли.
Список доступов. Где хостинг, где база, где почта, где домен, где учётки для внешних служб. С указанием, как передать сами ключи — не текстом в чате.
Описание в общих чертах. Из каких частей состоит, что где лежит, куда смотреть в первую очередь.
Список известных проблем. Честно: что работает криво, что временное, где костыль и почему.
Что запланировано. Задачи с приоритетами, чтобы человек понимал, куда всё идёт.
Про что рассказать голосом
Есть вещи, которых нет ни в коде, ни в документации:
Почему сделано именно так. «Тут выглядит странно, потому что была вот такая история».
Куда не надо лезть. «Этот кусок хрупкий, там завязано вот на это, лучше не трогать без нужды».
Что регулярно ломается. «Раз в месяц отваливается вот это, чинится так».
Кто важные люди. Кому писать по хостингу, кто разбирается в этой части.
Часа разговора хватает, и он экономит новому человеку недели.
Порядок передачи
Сначала запуск. Пусть человек поднимет проект у себя, пока вы на связи. Это выявит все дыры в инструкции.
Потом маленькая задача. Пусть сделает что-то небольшое и выложит целиком, сам. Пока вы рядом и можете подсказать.
Потом рассказ. Устройство, решения, слабые места. После того как человек руками потрогал, — так рассказ ложится, а не пролетает мимо.
Потом период поддержки. Неделя-две, когда вы ещё отвечаете на вопросы, но не делаете сами.
Как понять, что передача состоялась
Простая проверка: человек самостоятельно выложил изменение в рабочую версию. Не посмотрел код, не покивал на созвоне, а прошёл весь путь до конца.
Пока этого не произошло, передача не завершена, чем бы ни казалось.
Чего не делать
Не сваливать всё в один разговор. Три часа рассказа не запомнятся.
Не передавать «когда будет время». Назначьте даты, иначе растянется до вашего ухода и не случится.
Не оставлять доступы на себе. Через месяц вас никто не найдёт, а ключ понадобится.
Не делать вид, что всё идеально. Про костыли надо сказать. Человек всё равно их найдёт, но уже без объяснения, зачем они.
Обратная сторона
Если проект принимаете вы — требуйте того же самого. Инструкцию, доступы, разговор, период поддержки.
И задавайте главный вопрос, который забывают задать: что здесь ломается чаще всего и почему. Ответ на него полезнее любой архитектурной схемы.
Хватит читать — пора делать
На CohortX можно найти команду под пет-проект и получить тот самый опыт, о котором спрашивают на собеседовании.
Похожие статьи
- Agreeing on technical decisionsWhy technology arguments drag on, how to tell an important decision from an unimportant one, and what to record so you don't argue twice.
- Как договариваться о технических решенияхПочему споры о технологиях затягиваются, как отличить важное решение от неважного и что записывать, чтобы не спорить дважды.
- Handing a project over to someone elseWhat to prepare, what to say out loud, what the code won't tell them, and how to know the handover actually happened.