Статья составлена на основе выступления Александра Афенова «Трудно быть Колей: теория и практика knowledge sharing (обмена знаниями) в Lamoda» на конференции Knowledge Conf 2019.
Речь пойдет о тех принципах, которые применяются в разных компаниях в области обмена знаниями для адаптации новых сотрудников. С какими проблемами сталкиваются люди, если обмен знаниями «хромает» и какую выгоду получают, если обмен знаниями развивается в лучшую сторону.
Проблемы в компании N
Для примера возьмем небольшую компанию N с низким bus фактором* и отсутствием практики обменом знаний.
*bus factor — мера сосредоточения информации среди отдельных членов проекта. Если bus factor=1 — это означает, что достаточно уйти одному сотруднику, чтобы потерять все знания о продукте.
При трудоустройстве на работу нового сотрудника (разработчика) руководителю команды требуется потратить на него определенное количество личного времени, что не всегда удается сразу. Поэтому новый разработчик какое-то время остается в неведении о своих задачах и компании (поиск в местной wiki не дает плодотворных результатов из-за слабоструктурированной и неактуальной информации в ней).
Работая над целым проектом в небольших группах (2-3 человека, все из которых — разработчики) возникают проблемы:
- отсутствие актуальной документации;
- отсутствие структурированных ресурсов, чтобы передать артефакты по проекту (use case, диаграммы классов, компонентов, состояний, функциональные / нефункциональные требования);
- bus factor по проекту распределен только среди участников текущего проекта – если все из них уволятся, то не останется людей, которые смогут разобраться в проекте.
Испытывая такие проблемы, менеджмент компании пытается мотивировать людей остаться в компании (з/п, помощники), но такая мотивация не решает проблему обмена знаниями среди сотрудников компании.
В итоге люди уходят по разным причинам, а компания оказывается с продуктом, который никто не знает, как поддерживать.
Ввод в проект нового сотрудника на примере компании Ламода
Знакомство
В противоположность рассмотрим крупную компанию с выстроенными процессами адаптации новых сотрудников. Проектные команды в такой компании составляют около 10 человек (аналитик, тестировщик и другие), поэтому новому сотруднику трудно запомнить всех в команде. На помощь приходит внутренняя база знаний (ведётся в Confluence), в котором созданы разделы:
- команда — в нём содержится информация о членах команды (с указанием должностей и контактов сотрудников). Также в данном пространстве содержится информация о проведенных командой ретроспективах по спринтам.
- проекты — здесь приведено описание проектов команды;
- раздел, посвященный разработке, где дежурный описывает возникающие проблемы. Или документация по старым модулям, в которых кто-то пытался разобраться и описать.
Встречи о компании. Для знакомства с компанией организуются специальные встречи. На них выступают представители разных подразделений компании (логистика, поставки и другие), где за несколько часов формируется общее представление обо всей компании.
Tech onboarding – встреча в первый месяц для новых IT-специалистов. Тематика встречи – всё что связано с IT внутри компании. На этой встрече рассказывается, как принято работать в IT, статистику сервисов и команд (с описанием стека технологий).
IT Gathering – мероприятие, на котором рассказывают об успехах / провалах IT за последний квартал, что собираются сделать. Подобные мероприятия также проводятся в компании для других сфер (логистика, закупки).
Кроме того, для сотрудников доступна возможность поехать к «пользователю» (например, на склад), чтобы понять, что именно приходится автоматизировать, на кого повлияют изменения.
Приступая к разработке
В компании поддерживается идея умных коммитов (smart commits). Привязка к коммиту кратких сообщений о внесенных изменениях и использование в названии комита номера задачи, дает ряд преимуществ (подробнее на https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html):
- поиск задачи в Jira;
- упоминание в Confluence;
- сборка в Bamboo (или в других системах);
- выполнение команд.
Если в ходе разработки результат задачи изменяется, то изменение вносится строго в описание самой задачи. Крайний случай: блокировка задачи, пока не появится его полное описание.
В компании существует виртуальная роль support-разработчика, которая еженедельно делегируется разным членам команды. Этот разработчик помогает команде поддержки, тем самым ощущая на себе их боли и погружаясь в вопросы клиентов.
Оповещение о релизах
Кроме текущих проектов, компания создала в Jira деплойный тикет – в нем каждый раз создаются задачи, когда планируется релиз. В данном тикете отражается информация:
- какой проект выходит на релиз;
- на какие площадки выкатывается релиз;
- какие задачи вошли в релиз.
Это позволяет задать некоторый график выхода релизов; понять, что именно пошло не так (и самое главное – где) при детальном анализе. Единственный минус деплойных тикетов – они уступают по оперативности другим инструментам. Альтернатива, используемая в компании – telegram-канал deploy fm. В этом канале содержится информация о релизах:
- какой релиз (задача) выкатывается;
- что сломалось;
- какие последствия произошли;
- инициатор релиза;
- завершилось ли это успехом.
Для изучения истории изменения документации, могут использваться:
- комментарии в Jira (вкладки «логии» и «история изменений»);
- отдельный плагин в Jira (история изменения задачи и комментариев);
- аналогично для Confluence – история правок, комментариев.
Кажется, что данной информации достаточно для оперативного воздействия на систему. На самом деле нет. Пример: ночью перестали отправляться заказы на склад – выясняется, что эта ситуация не аварийная, а плановая – выполняется релиз (плановый downtime). Как дежурный разработчик должен был об этом узнать? Ответ: с использованием RFC (request for change) и календаря.
В календаре создаётся отдельный пользователь, от лица которого создаются события с RFC. Задачи с описанием RFC ставятся в отдельный проект в Jira, который позволяет зафиксировать важные / опасные изменения и согласовать их деплой в прод. RFC полезен, когда случается:
- изменение контракта;
- изменение структуры базы данных;
- обновление инфраструктурных сервисов;
- крупная миграция данных;
- плановый релиз крупной фичи.
Благодаря этому подходу появляется возможность планирования релизов без накладки на другие крупные изменения.
Запиши для себя будущего
При возникновении инцидентов (неисправностей) компания создала в Jira проект Происшиествия, в котором разработчики (и не только) указывают время и суть инцидента, а также инструменты (скрипты, sql-запросы), позволяющие быстро устранить инцидент (bus factor инцидента не будет равен одному человеку, который этот инцидент исправил).
То же самое можно делать в пространстве Confluence.
Если инцидент прошел со статусом major, то он впоследствии анализируется: почему он произошел, время на его решение, причина, система-источник инцидента. Разбор таких инцидентов проводится коллегиально; если что-то сломалось, потому что событие (релиз) не был добавлен в календарь, то люди приобретают дополнительную мотивацию для последующего добавления событий в календарь (то есть система саморегулируется).
После анализа «IT» объясняет «бизнесу» необходимость проведения определённых мероприятий (например, дополнительное тестирование), чтобы такие ситуации больше не повторялись.
Как team lead помогает созданию базы знаний
Ответственный team lead всегда задается вопросом: как стимулировать появление документации в проектной команде? Для этого используется совокупность нескольких методов:
Первое, что он предлагает: писать обязательные test notes – такой формат позволяет 1) облегчить работу тестировщикам, 2) понять, на какие компоненты следует обратить внимание.
Второе: учет времени на документацию в оценке задач в ситуациях с нетривиальными задачами. В этом случае документацию создают сами разработчики.
Третье: применение шаблона описания задачи в формате why-what-dod:
- why – почему решено начать работу над данной задачей (информация от бизнеса, может быть ссылкой на эпик или статью в конфлюенс с подробным описанием);
- what – что именно будет сделано;
- dod (definition of done) – список пунктов, соответствие которым свидетельствует о выполнении задачи.
Чтобы обеспечить обмен знаниями (в том числе обмен опытом), в компании существует ряд мероприятий:
- team lead talks – еженедельные собрания тим лидов, которые рассказывают о своих проблемах в команде;
- tech crunches – ежемесячные собрания, где команды рассказывают всем желающим о своих наработках, возникших проблемах и решениях;
- «как у нас в целом все работает» — рассказ о практиках работы проектных команд.
Системный архитектор
Компания должна быть заинтересована в обмене знаниями / опытом на уровне системного архитектора (или человека, который может внести серьезные правки в используемый стек технологий).
Системные архитекторы из других команд собираются вместе в архитектурный комитет, на котором обсуждается корректность нововведений: по результатам схема (решение) либо утверждается, либо отправляется на доработку.
Благодаря таким встречам люди из других команд узнают о новых архитектурных (и не только) нововведениях в компании.
Формирование культуры обмена знаниями
Как сформировалась культура обмена знаниями в компании?
История публичных мероприятий началась с Lamoda IT brand Circa 2016: на нем был 1 доклад и 4 митапа. На текущий момент представляется около 20 докладов ежегодно; ведутся статьи на Хабр.
Чтобы помочь сотрудникам начать обмениваться знаниями, компания предпринимала следующие действия:
- Подготовка спикеров для внешних выступлений (вне компании).
- Рассказ коллегам обо всей компании в целом (внутри компании).
- Повышение вовлеченности сотрудников компании в обмен знаниями.
Постепенно формировалась культура проведения регулярных мероприятий, на которых люди рассказывают о своей деятельности в компании.
Проведение еженедельных выступлений – одна из мотиваций, чтобы делиться знаниями. Вторая мотивация – осознание ценности результата для всей системы, ощущение единения с ней (ownership).
Как итог: формируется идея коллективной ответственности за распространение знаний.
Итог по подходу к формированию базы знаний
Формирование культуры knowledge sharing может строиться на некоторых пунктах:
- грамотные онбординги, где можно узнать, что происходит в компании с точки зрения бизнеса; для технических онбордингов – знакомство со стеком используемых технологий;
- регулярные встречи в масштабах IT / компании;
- развитие ownership и заботы о команде;
- простейшие трюки уровня интеграции источников знаний друг с другом (например, smart commits);
- обмен опыта между командами;
- сильный devrel — человек / группа, который сможет управлять продвижением знаний / достижений компании вне ее пределов; подготовка людей к публичным выступлениям (speakers club, необязательно для маленьких компаний).