Универсальный шаблон приветственной страницы: упрощаем онбординг в команду
Привет! Это Маша, технический писатель в группе документации Ozon. Мы делаем внутреннюю документацию в департаменте «Поиск, рекомендации, реклама», в который входит 40 команд разработки. Наш департамент постоянно развивается, появляются новые команды и люди, которым нужно побыстрее влиться в компанию и коллектив. Недавно одна из команд планировала набирать новых сотрудников, и коллеги попросили помочь сделать приветственную страницу для новичков — онбординг.
Чтобы страница была полезной и простой, мы пообщались с командами и разработали страницу онбординга. Она получилась настолько хорошей, что мы сделали из неё универсальный шаблон, которым пользуемся сами и которым хотим поделиться. Он будет полезен любой IT-команде: разработчикам, тестировщикам, техническим писателям, продактам, проджектам и другим специалистам.
Шаблон скачивайте по ссылкам:
Варианты, как оформить онбординг
Про онбординговые процессы написано много, и о них лучше расскажут HR-специалисты. Но онбординг — процесс обширный, в каждой команде есть свои нюансы. Чтобы учесть их, лучше взять всё в свои руки и собрать для команды Wiki-страницу с регламентами, инструментами и инструкциями по получению доступов. На её заполнение уйдёт пара часов, а новичкам в первое время поможет ориентироваться и задавать меньше «глупых» вопросов.
Такие страницы не всегда бывают полезными и красивыми. Например, в онбординге, собранном на скорую руку, может быть слишком много или слишком мало информации. Если в команде давно не было новичков, информация на странице может устареть. Это, кстати, одна из причин, по которой команды отказываются заводить страницы для новичков и передают информацию «по запросу». Такой подход мы не осуждаем, а понимаем. Поддерживать страницу при найме одного сотрудника в год — непродуктивно, быстрее созвониться и всё рассказать.
Но если выходит один новичок в неделю или месяц, командный онбординг упрощает жизнь. Мы решили помочь коллегам из департамента и разработать шаблон для приветственной страницы. Чтобы в этом шаблоне было максимум пользы, изучили плюсы и минусы разных типов онбординга и выбрали оптимальный вариант.
Плюсы | Минусы | |
Страницы с онбордингом нет | — Не нужно следить за актуальностью. — Наставник сильнее вовлечён в обучение новичка (но не всегда). | — Важная информация передаётся лично и нигде не зафиксирована. Из-за этого наставник может забыть передать часть сведений, а новичок может стрессовать, что он не всё запомнил. — Наставник может не уделять новичку должного внимания из-за своей загруженности — и период обучения и адаптации растянется. — Если держатель знаний уволится, вся информация пропадёт вместе с ним. |
Есть страница с онбордингом, собранная командой | — Информация на странице точно пригодится новичку. — Важная информация находится в одном месте — достаточно дать ссылку. — Уменьшается уровень стресса у новичка. | — У страницы хаотичная структура (но не всегда). — Слишком много или слишком мало информации (но не всегда). — Если в команду новички приходят редко, информацию не актуализируют. |
Есть онбординг по шаблону | — Фиксированная структура страницы — автор не забудет добавить нужные блоки. — Легко адаптируется — некоторые блоки можно убрать или добавить. — Важная информация находится в одном месте — достаточно дать ссылку. — Уменьшается уровень стресса у автора и новичка. | — Информацию нужно актуализировать. |
Какую задачу решали
Задача: собрать полезную страницу для новичков с понятной структурой. Ozon — компания большая, мы начали исследовать подобные страницы других команд в поисках best practices. Нашли много классных страниц, но ни одна не решала все вопросы нашего департамента. Поэтому возникла идея сделать универсальный шаблон, который был бы полезен любой команде разработчиков.
Чтобы реализовать идею, мы выделили критерии оптимального варианта. Итак, шаблон должен:
напоминать про важные блоки;
иметь общую предзаполненную часть — так авторам будет проще, чем писать с нуля;
подстраиваться под специфику команд.
Как делали
На основе онбордингов, которые мы сохранили как референсы, мы перешли к созданию структуры нашего шаблона. В книге «Презентации в стиле TED. 9 приёмов лучших в мире выступлений» пишут, что идеальное выступление состоит из трёх больших блоков, которые поделены на три подблока. Я подумала, почему бы такой приём не применить для создания шаблона, чем онбординг не презентация компании и команды?
Так родилась структура первого варианта, состоящая из введения с кратким рассказом о команде и блоков:
«Первые действия» — блок с чек-листами, подсказывающими, что нужно сделать в первый рабочий день, неделю, месяц или в течение испытательного срока.
«Ресурсы» — блок про чаты, инструменты и проекты, с которыми работает команда.
«Дополнительные материалы» — блок про организационную часть работы в команде с полезными ссылками.
Чтобы понять, насколько полезным получился шаблон, мы протестировали его на страницах онбордингов нескольких команд. Так выяснили, что структура требует доработки: не везде набиралось материала для первых задач, информация о ресурсах располагалась хаотично и возникали другие трудности. Также ни в одном блоке не нашлось места для документации. Как технические писатели мы не могли такого допустить. Ведь если и прививать культуру документирования, то делать это «с порога».
В общем, спустя несколько итераций мы пришли к тому самому варианту шаблона, которым хотим поделиться.
Что получилось
В итоговом варианте мы сохранили структуру с тремя блоками и тремя подблоками в каждом, но ещё добавили по одиночному блоку в начало и конец. Страница выглядит аккуратно и понятно:
Как шаблон выглядит «вживую», смотрите по ссылке.
Если вы скачали шаблон и у вас возникли вопросы, что хотел сказать автор — используйте таблицу ниже. В ней итоговая структура с проблемами, которые решают блоки, и пояснения, что должно быть внутри. Мы рассматриваем шаблон для команд разработки, но большая часть блоков актуальна и для других IT-команд без адаптации.
Важно! Если уже есть инструкция к конкретному инструменту, написанная ответственной командой, не нужно копировать из неё текст. Лучше приложить ссылку на исходник — так вы снимете с себя ответственность, если что-то поменяется.
Проблема | Какой блок решает проблему | Что в блоке |
Новичок ничего не знает про команду | Приветственное слово | Вступление к статье и описание зон ответственности команды. |
Новичок не понимает, что ему нужно сделать в первые дни, и теряется в потоке новой информации | В первую очередь | Список, что должен сделать новичок в первые дни. |
Инструменты для работы | ||
Новичок не в курсе, какой софт одобрен специалистами по информационной безопасности компании. Может установить программу, из-за которой у компании будут проблемы — например, пиратский или уязвимый софт | Программы для установки | Сторонние программы, которые можно и нужно установить на рабочую технику. |
Новичок не знаком с инструментами, которые разработаны компанией. Узнавать об инструментах по ходу работы — не лучшая практика. К чему-то может понадобиться доступ здесь и сейчас, а у новичка его не будет | Инструменты компании | Инструменты, разработанные компанией, например тестовые и продовые стенды. Также описываем, как получить доступ к этим инструментам. |
Новичок не знает, какими инструментами пользуются в компании — могут не вовремя возникнуть проблемы с доступами | Другие инструменты | Остальные инструменты, которыми пользуется команда, например Airflow. Также описываем, как получить доступ к этим инструментам. |
Ресурсы | ||
Новичок потерялся в чатах и каналах, в которые его добавили, не знает, куда смотреть в первую очередь. Важная информация может пройти мимо него | Чаты | Список чатов и каналов, в которых общается команда или смежные команды. |
Новичок не сохранил и не запомнил, в каких репозиториях работает команда. Придётся всё уточнять у коллег и получать доступы к новым репозиториям отдельно | Проекты | Список репозиториев с кодом, в которых работает команда. Также описываем, как получить к ним доступы, если они нужны. |
Новичок не знает, на какие графики и метрики смотреть, когда выкатывается фича | Графики и метрики | Список важных графиков, за которыми следит команда. Также описываем, как получить к ним доступы, если они нужны. |
Работа в команде | ||
Новичок не понимает, как устроены дежурства в команде | Дежурства | Регламенты и расписания дежурств. Если в компании нет дежурств, этот блок можно заменить. Например, на расписание встреч команды. |
Новичок не может найти правила работы. Например, когда разрешено релизить новые фичи: он сделает релиз в пятницу, а в компании это запрещено | Организация работы | Основные организационные вопросы работы в команде. Например, правила деплоя, написания release notes и так далее. |
Новичок не хочет тратить время на документацию. Все накопленные знания будет хранить в своей голове | Документация | О процессе документирования в команде. Если технического писателя нет, а вам нет дела до документации, замените этот блок. Но вариантов замены не скажем :) |
Новичок хочет узнать больше о команде, об инструментах или процессах | Полезные материалы | Список полезных книг, выступлений или других материалов для саморазвития сотрудника. |
Из 40 команд департамента такой шаблон мы уже внедрили в десяти, получили хорошие отзывы и не собираемся останавливаться. Но тут нужно раскрыть маленький секрет.
Когда мы создавали шаблон в пространстве Confluence, мы пошли на хитрость и добавили в него подборку общих инструментов и ресурсов, которыми пользуются все. Такую страницу легче дозаполнить, потому что на ней уже есть предзаполненная полезная информация. Ещё мы оставили подсказки в режиме редактирования — они помогают авторам понять, как заполнить тот или иной блок. Коллегам, которые делали страницу по шаблону с подсказками, очень понравилось, что часть информации за них уже заполнена — работы осталось совсем чуть-чуть.
Как оформить в Confluence
Если вы будете делать страницу с онбордингом в Confluence, у нас есть пара советов, которые упростят жизнь.
Чтобы шаблоном пользовались все, его нужно завести в формате шаблона в пространстве. Тогда каждая команда, которая пользуется пространством, сможет создать страницу для новичка по шаблону и заполнить её. Это сэкономит время: шаблон не нужно искать, копировать и удалять из него неактуальную для команды информацию.
Кроме того, в шаблон в Confluence можно вставить скрытые подсказки для авторов — они будут отображаться только в режиме редактирования страницы.
На онбординговые статьи можно навесить метки «onboarding». С ними все статьи для новичков можно будет легко найти и быстро актуализировать, если какой-то процесс изменится во всей компании.
Что в итоге
Шаблон страницы с онбордингом упростит жизнь любой команде — не нужно думать, что написать и как это оформить. Кроме того, если у команд похожие инструменты для работы или процессы, их можно подсмотреть и нагло скопировать у коллег, у которых онбординг уже готов.
Также страница с онбордингом будет полезна не только новичкам, но и старичкам. Информация структурирована, инструкции и ссылки хранятся в одном месте — кто от такого откажется?
