Есть проект, фронтовая часть написана на nuxt3. Мы знаем, что через 2 недели разработчик, который в данный момент решает задачи проекта, уходит в отпуск на стандартные 2 недели. Значит, нам нужна замена на эти 2 недели. Я, как руководитель отдела, решаю, исходя из нагрузки на разработчиков, кому я передам этот проект.
И встаёт задача, нужно организовать процесс передачи проекта.
Как в целом это выглядит сейчас в компании:
- Я выбрал разработчика. Описываю ему ситуацию. Даю доступы в репозиторий, разворачивается проект локально. Ридми проекта строго описывается по установленным форматам, так что там есть вся инфа как его запустить. Благо у фронта тут всё попроще, чем может быть у бекенда
- Ставлю менеджеру задачу, устроить созвон с командой и познакомить человека с проектом и его контекстом.
- Устраиваю созвон 2х разработчиков, в котором ставлю задачу уходящему в отпуск, познакомить с кодовой базой, рассказать про имеющиеся фичи, особенности реализации тех или иных частей проекта. Описать работу основных модулей\сущностей. Возможно, если такие моменты есть, обратить внимание на костыли. Рассказать, что делается сейчас, что уже сделано, а что может потребовать доработок. Если есть различные ветки в git, то описать, что находится в этих ветках, на каком этапе.
По мнению вышестоящего руководства, этот процесс можно описать в виде некого документа\чек листа ибо текущий им кажется размытым, лишённый деталей. Я пока что скептически отношусь к их мнению, потому как вижу много разных контекстов у различных проектов, которые сложно описать. Ведь при обсуждении 2х разработчиков, 1 рассказывает, 2й задаёт вопросы и складывается диалог и какое-то понимание. Где-то человек может попросту забыть рассказать о проблемах или фичах, или особенностях работы той или иной фичи. Например, упустить пару моментов при работе с каким-то новым для нас сервисом или виджетом.
Простой
