Многие компании публикуют в 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. Их же можно использовать и для того, чтобы задавать вопрос нашим инженерам по разным направлениям — постараемся ничего не оставить без ответа.
Комментариев нет:
Отправить комментарий