Многие компании публикуют в open-source свой код. Мы тоже не исключение. Инженеры Avito активно публикуют на GitHub свои наработки. Но ведь код — это не единственное, чем компания может поделиться с сообществом. Не меньший интерес представляет описание различных процессов, гайдлайны и лучшие практики. Сегодня мы делаем первый шаг в этом направлении и выкладываем на GitHub первую версию Avito Playbook. Что это и зачем нужно — рассказываю под катом.

Что такое плейбук

Изначально термин playbook пришел к нам из американского футбола. Это что-то вроде свода правил, по которым играет команда, и признанных ими лучших практик, принятая стратегия и тактика. Для компании он играет такую же роль — это свод стандартов, которые команда вырабатывает с течением своей жизни. Это могут быть ценности, правила найма, практики code review, да даже список любимых баров, в которые команда ходит по пятницам. Playbook вмещает в себя всю информацию, с которой вы знакомите новичка в первые недели его работы.

Строго говоря, плейбук у вас скорее всего уже есть. Это может быть пачка гуглодоков, раздел в Confluence, репозиторий в VCS. Главное, придерживаться двух основных правил: информация должна быть актуальной и структурированной.

Авито плейбук — первая версия

За 10 лет мы наработали ну очень много интересных материалов, которыми хочется поделиться. Но перед тем, как переносить их в open-source, нужно проделать много работы. Старую информацию актуализировать, недостающую собрать, секретные данные затереть и спрятать под грифом. Процесс может затянуться на долгие месяцы. Но в полном соответствии с Agile-манифестом мы решили работать итеративно и постепенно делиться новой информацией.

В первой версии мы рассказываем про:

• Авито в цифрах — сколько у нас сотрудников, разработчиков, RPS и серверов;
• миссию и ценности — куда и как мы идем;
• организационную структуру — юниты, кластеры и рабочий распорядок;
• бизнес-процессы — OKR, performance review;
• технологические процессы и практики — релизы, developer experience framework, технический радар, open-source;
• условия работы — обучение, тренинги, конференции и прочие плюшки.

В планах — закопаться во все это гораздо сильнее. Например, мы очень хотим поделиться нашими политиками релизов для сайта и мобильных приложений и практиками по автоматическому тестированию. Ещё один вариант — детально описать процесс собеседования, его структуру и поднимаемые темы.

Мы очень рассчитываем на ваш фидбэк. Если вы хотите узнать больше о каком-то аспекте работы компании, устройстве процесса или чем-то еще, то смело заводите issue на GitHub. Их же можно использовать и для того, чтобы задавать вопрос нашим инженерам по разным направлениям — постараемся ничего не оставить без ответа.