Дать доступ. Менеджер и Макс даёт доступ. Фронтовый тимлид пинает их, уточняет у нового фронтендера дали ли ему все доступы, пинаем ещё раз, если надо.
- Выдать почту на @amplifr.com
- Доступ в Slack
- Доступ в Trello
- Доступ в GitHub
- Доступ в Zeplin
- Доступ в Sentry
- Доступ в Intercom
- Доступ на деплой от Макса
Созвон с менеджером. Он должен рассказать, как работает наш процесс разработки.
Созвон с фронтовым тимлидом. После каждого пункта время на вопросы. На нём важно рассказать:
- Рассказать про ценности: пользователи — главное, если видим ошибку других — говорим, говорим об ошибках вне зависимости от иерархии, дизайн тоже в нашей области, последнее слово всегда за главной направления (дизайн за дизайнером, текст за копирайтером).
- Рассказать про подход к рефакторингу: слои поколений, в одной папке только один слой, последний слой должен быть всегда чистым, гавнокод может быть только в старых слоях.
- Показать текущие слои. Начать с самого старого поколения. Сказать вкратце какие технологии использовали и какие ошибки вынесли.
- Для каждого слоя потом отдельно подробно рассказываем про архитектуру. Заходим в каждую папку слоя, объясняем связь компонентов архитектуры и как текут данные.
- Отправляет читать «Принципы разработки».
Дальше даём задания.
Задача 1. Подготовка среды. Фронтовый тимлид скидывает новому фронтедеру задания в письме.
- Включить шифрование диска
- Установить менеджер паролей
- Сменить пароли на безопасные и уникальные для GitHub и почты
- Включить 2FA на почте, GitHub и Slack
Задача 2. Разворачивание проекта. Новичок должен пройти по инструкции и исправить инструкцию в тех местах, где он не соответствует действительности.
Дальше нужно дать простое задание для каждого слоя. Обязательное код-ревью фронтового тимлида. Важно уделять отдельное внимание в UX и качеству кода. Исправлять за нового разработчика нельзя.
Через несколько задач, новому фронтендеру ставится задача, в которой его или её предупреждают, что код-ревью специально не будет. Нужно учить ответственности.
Через месяц можно ставить на разработку большой фичи. Тут код-ревью нужен, но новый разработчик должен решить сам, когда его запросить и у кого. Мы не проверяем каждый шаг.
Через полгода нужно не боятся ставить сверхсложные задачи. Очень сложные задачи не должны доставаться только «старичкам».
Фронтовый тимлид должен раз в месяц задумываться — а не было ли у моих коллег необычного и интересного опыта. Если был — предлагать в личке вынести его в опенсорс или сделать статью или доклад.