Задать вопрос Поделиться знаниями Редактировать страницу
Knowledge Conf 2019. Добро пожаловать на борт: вводим новых разработчиков в команду. Глеб Дейкало (Badoo)
Чем больше у вас в компании крутых ноу-хау и своих кастомных сервисов, чем сложнее инфраструктура, тем большую цену приходится платить при найме новых сотрудников. Даже самому крутому rock star придётся изрядно попотеть, погружаясь в терминологию вашей компании, знакомясь с вашим инструментарием и стандартами.
Важные мысли из этого доклада:
-
онбординг: почему это проблема?
-
на адаптацию тратит время не только новичок, но и опытные сотрудники, которые рассказывают и показывают;
-
краткосрочная цель онбординга: сократить время вхождения в должность;
-
долгосрочная цель: воспитать самостоятельность;
-
-
день 1: первая встреча:
-
ментор (человек, который ведет новичка);
-
экскурсия по офису (интерактивная карта офиса);
-
снижаем затраты времени (пакет новичка включает настроенное рабочее место с ПК и телефоном, чек-лист на оборудование и софт;
-
автоматизация получения паролей к сервисам;
-
автоматизация бытовых задач;
-
-
способы передачи знаний:
-
личная беседа (не масштабируется, фрагментированность знаний, нельзя перечитать, не помогает развитию самостоятельности);
-
семинары по технологиям, в т.ч. в записи (тяжело актуализировать);
-
Wiki: отдельная страничка для новичков (плохая структура, ссылки на объемные манускрипты, нет закрепления на практике, тяжело актуализировать);
-
-
неделя 1-2: Quick Start:
-
список инструментов и технологий (от простого к сложному);
-
первые главы, методика подачи;
-
оставшиеся главы дали другим опытным ребятам;
-
небольшие практические задачи, проводим по реальному флоу (придуманные, но близко к реальным);
-
задачи помогают отслеживать актуальность документации;
-
полезные инициативы от новичков по доработке quick start;
-
на прохождение QS мы заводим тикет с сабтасками для отслеживания прогресса и закрепления флоу;
-
-
неделя 3-4: закрепляем знания тестом с вопросами (анонимный, отслеживаем как в целом проходится тест, чтобы актуализировать и выявлять сложные вопросы);
-
пару месяцев спустя: system design;
-
даем большую фичу (можно уже существующую в продукте) и просим спроектировать задачу по базовым требованиям (техническая архитектура);
-
через неделю новичок "защищает" свой проект перед коллегами коллективно, но не оцениваем, а скорее помогаем увидеть детали;
-