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

Алексей Трошин (morroz ^[1]) в профессии почти 20 лет, в качестве Project и Product manager трудится с 2002 года. За это время работал в разных компаниях, руководил командами от 2 до 150 человек, а сейчас руководит разработкой в компании «ФИНАМ». Здесь Алексей выстроил систему, которая помогает не только распространять знания, но и мотивировать разработчиков расти в нужном бизнесу и команде направлении. Впрочем, система применяется не во всех командах. Почему? Об этом, как и применяемых подходах, узнаем под катом.

Статья основана на докладе Алексея Трошина на Saint TeamLead Conf, в котором рассказывается, как в «ФИНАМ» распространяются знания: как растёт Сила и мастерство Джедаев, как обучают Падаванов и что происходит на Тёмной стороне Силы (куда же без неё).

Продукты и команда «ФИНАМ IT»

Для начала расскажу о некоторых наших продуктах, чтобы определить контекст компании.

Сайт Finam.ru — сайт №1 по финансовой тематике, содержащий множество различных разделов с финансовой информацией, а также полезные сервисы, например, интернет-магазин акций. Можно, к примеру, прикупить одну акцию Apple и подарить её кому-нибудь на день рождения.

Торговая платформа FinamTrade, в которой также есть и тариф с нулевой комиссией для начинающих трейдеров.

Comon.ru — система автоматического повторения сделок профессиональных трейдеров — решение для начинающих инвесторов и тех, кому не хватает свободного времени на формирование собственного инвестиционного портфеля.

Соцсеть для трейдеров и многое другое.

«ФИНАМ IT» — это 150 человек, разделённые на 25 команд. Разработка только внутренняя, мы почти не привлекаем сторонние компании для наших нужд. Заглавная картинка отлично показывает, как у нас всё устроено. Состав команд может быть разным: в одних командах есть Product Owner, но нет, например, тестировщиков, в других есть тестировщики, но нет Product Owner, зато есть аналитики.

В разработке мы используем разные стеки технологий:

• Фронтенд: React.js, VUE.js.
• Языки: C#, PHP, С++, Java, mobile.
• Базы данных: MSSQL, PostgreSQL, Oracle.
• Платформы: SharePoint, 1C, Diasoft, MS CRM и другое.

Когда я только пришёл в компанию, мы попытались нарисовать команды, продукты и взаимосвязи. Получилась такая сложная схема, где кружками обозначены продукты, которые мы разрабатываем:

Цветом я показал, что команды организованы по-разному. Некоторые занимаются одним продуктом, другие делают несколько продуктов. А есть продукты, разработкой которых занимается сразу несколько команд (например, внутренний бэкофис).

Свой рассказ буду вести на примерах двух команд, условно назову их команда 1 и команда 2.

Команда 1

Первая команда разрабатывала внутреннюю информационную систему. Изначально это выглядело так:

• Один сотрудник был экспертом в текущей версии платформы. Появилась задача эту платформу перевести на новые рельсы, потому что старая версия уже не поддерживалась.
• Мы взяли нового сотрудника, который был экспертом в новой версии платформы. Он занимался переносом всей функциональности на эту новую версию.

Команда 2

Вторая команда разрабатывала несколько внутренних систем:

• Один сотрудник — это эксперт в одних системах.
• Другой сотрудник — эксперт в других системах.
• А некоторые системы разрабатывались обоими сотрудниками вместе.

Про экспертов

Выше в тексте неслучайно выделено слово «эксперт», хочу уточнить, кто такой эксперт в рамках этого разговора. Как магистр из «Звездных войн», этот человек обладает Силой: глубокой компетенцией в своей предметной области, в технологии, в продукте. Для бизнеса обычно это удобно, потому что дает одну точку входа: эксперта спрашивают, как сделать или когда будет сделано, — если речь идёт о новых задачах, или обращаются с вопросами, если что-то сломалось или работает не так.

Такого эксперта я представляю себе как магистра Джедая из фильма «Звёздные войны» — он может всё (ну или почти всё).

Но у эксперта-Джедая есть и минусы:

• Его надо долго «растить», чтобы он принял эту Силу.
• Когда он уходит в отпуск, это всегда:«Что же мы все будем делать?».

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

Нашей главной головной болью был вопрос «Что будет, если с экспертом что-то случится, как с магистром Йодой на картинке ниже?»

А ещё вы наверняка слышали о понятии Bus factor.

Bus factor

Bus factor — это мера сосредоточения информации среди отдельных членов проекта.

В определении из Wikipedia написано, что этот фактор определяет количество участников проекта, после потери которых проект не сможет быть завершён оставшимися участниками. Условно это означает, сколько человек должен переехать автобус, чтобы с проектом произошла непоправимая беда.

Когда у вас эксперт один, то Bus factor равен одному, то есть все риски проекта находятся в руках одного человека, и это плохо.

Пример из истории: в 2010 году под Смоленском произошла авиакатастрофа, в которой погибло 96 человек, включая высшее руководство Польши. После этого события в Польше было утверждено правило — четыре высших руководителя государства (президент, премьер-министр, спикер сената, спикер сейма) ни при каких обстоятельствах не должны летать вместе. Это вариант защиты от Bus factor.

Как вы понимаете, в командах 1 и 2 эксперты не были взаимозаменяемы, и это создавало потенциальные проблемы. Нужно было что-то делать, чтобы увеличить Bus factor, а компетенции Джедаев-экспертов расширить. Мы предприняли следующие шаги.

Шаг 1. Увеличиваем Bus factor

Джедай не должен быть один. Поэтому необходимо тренировать и обучать Джедаев, чтобы их стало больше.

Уточню, что Джедай — это роль, а не компетенция. Джедая можно вырастить. Вторая роль (если уж говорить в терминах «Звездных войн») — это Падаван, ученик Джедая. Он стремится к полноте знаний Джедая и замещает его, когда тот в отпуске. Причем, Падаван может быть не один — если команда большая, мы можем взращивать сразу несколько Падаванов. Но Джедай всё равно остаётся главным ответственным лицом, принимающим ключевые решения.

Когда определились, кто становится Джедаем, договариваемся о Падаванах, распределяем роли и визуализируем их в менеджерской таблице:

Здесь по горизонтали продукты, области или модули. Например, если продукт — 1С, это могут быть «Зарплата и кадры» или «Бухгалтерский учёт» или другие модули. По вертикали в столбцах указаны сотрудники. На пересечении вписываем роли — кто Джедай, кто Падаван. Так получается понятное распределение.

Есть некоторые правила, о которых мы договорились для начала распределения.

Правила распределения, ч.1:

1. Один продукт, область или модуль — один Джедай. Мы же помним, что хотим сохранить удобство «одного окна», эксперта и ответственного.
2. Не менее одного Падавана. Это как раз про Bus factor, чем их больше, тем лучше.
3. Равномерное распределение Джедаев. Чтобы не перегружать сотрудников, по справедливости.

Вроде бы всё логично распределили, и получилось так:

В первой команде, работавшей над одним продуктом, один человек занимался старым продуктом (Sunset), другой — новым (Sunset 2.0). В «своей» версии продукта сотрудник считался Джедаем, в «чужой» — Падаваном, учеником другого сотрудника.

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

Шаг 2. Контролируем обмен знаниями

Но как проверить, что Падаван вырастет в Джедая, обладающего всей Силой знания?

Фиксируем знания

Для этого мы фиксируем знания по нашим продуктам: составляем список всех знаний и складываем в таблицу. По каждому из продуктов на отдельной странице Confluence просто записываем те знания, из которых состоит продукт и декомпозируем их. Декомпозировать знания можно по-разному, и я напомню, что эти таблицы рисуются под страницей с распределением Джедаев и Падаванов. Например, для команды 1, одна страница для знаний Sunset, другая страница для знаний Sunset 2.0.

Дальше несколько скриншотов из нашего Confluence с примерами декомпозиции.

По модулям продукта. Например, у одного из продуктов есть отдельные программные модули: кредиты, вклады, валютный контроль — мы их просто расписали и стали с ними работать.

По функциональности. Тут единицы знания мы расписали по страницам и разделам системы.

По техническим знаниям. Некоторые продукты мы раскладывали просто по техническим знаниям команды.

Можно декомпозировать любым другим образом, главное, чтобы знания по своему продукту вы смогли бы распылить на большее количество атомарных элементов.

Добавляем документацию

После того, как детализировали списки знаний, мы добавили в таблицу столбец «документация» и начали его постепенно заполнять — на каждую строчку знаний своя страница с описанием.

Сразу скажу, что это не быстрый процесс, у нас он занял несколько месяцев, но со временем список документации заполнился, и в конце концов во всех областях знаний по продукту у нас написана какая-то документация.

Добавляем оценки

Дальше справа от столбца «Документация», добавили по столбцу для каждого члена команды и оценили, насколько каждый сотрудник этими знаниями владеет.

Расшифрую оценки:

• 1 — если не видел и не трогал этот участок знаний.
• 2 — что-то видел или слышал, знает, где находится. Например, прочитал документацию, запросил доступы к серверу или в репозиторий.
• 3 — видел, трогал, может делать. Например, правил баг в этой части кода, проверял руками что-то.
• 4 — работал не раз, может рассказать другим.

В первой версии у нас было пять оценок — школа приучила считать от 1 до 5. Но потом выяснилось, что хватает четырёхбалльной системы, на ней и остановились.

При выставлении оценки для ревью знаний мы можем задать контрольные вопросы. В одной из команд для введения новичков в проект есть часовое видео, которое нужно посмотреть и ответить на вопросы по чек-листу. Если человек ответил не на все вопросы, считается, что он ничего не понял, видео нужно пересмотреть, ведь в нём есть все ответы.

Шаг 3. Визуализируй это

На третьем шаге встал вопрос — как мне, менеджеру, видеть сразу и понятно, каким образом происходит наращивание знаний внутри команды?

Мы визуализировали текущее состояние, покрасив квадратики Джедаев и Падаванов в разные цвета: зеленый — обучение завершено, серый — в процессе обучения, красный — не приступал к изучению. В самом начале обычно много красного, но в конце концов все должны «позеленеть».

Сначала мы играли в светофор и думали, что между красным и зеленым должен быть желтый, но оказалось, что яркий желтый цвет отвлекал нас от сути. Поэтому мы от него отказались и пришли к серому цвету. Собственно, главное же как можно быстрее избавиться от красного. Картинка с примером светофора:

После этого мы ещё немного доработали наши правила.

Правила распределения, ч.2:

• Джедаи должны «позеленеть» первые. То есть делаем упор на прокачке Джедаев. Главный ответственный должен максимально быстро стать компетентен. Особенно в случае, если это новый сотрудник.
• Хотя бы один Падаван должен быть зелёным, закончившим обучение полностью. Но он может не спешить догонять знания Джедая, тут главное не останавливаться.
• Остальные Падаваны могут быть в процессе обучения. Наша задача — не забывать «размазывать» знания, делать так, чтобы области знаний сотрудников пересекались и покрытие было максимальным.

Дифференцируем требования

Для первого этапа запуска системы, на котором только начинается описание и оцифровка знаний, есть хорошая практика: разделить требования к Джедаю и Падавану.

Давайте вспомним оценки: Падаван получает зеленую метку за «тройку», если он делал хоть что-то в данной области, а Джедай должен в этой же области ориентироваться отлично, на «четвёрку». Также, для Джедая плохо (красный цвет) если не получены доступы, не написана документация и т.д., то есть нижний порог у него «два». Этот подход иллюстрирует таблица ниже.

Для начала работы этого оказалось достаточно. На следующем этапе можно поднять планку и сказать, что теперь у всех цифры должны быть одинаковые.

И вот наши таблички окрасились и всё стало интереснее и понятнее:

К некоторым зелёным картинкам мы шли полтора года. Мы не спеша собирались с тимлидами, раз в две недели или месяц, смотрели, что происходит, что-то постоянно уточняли.

Когда мы добавляли новую функциональность, появлялись красные плашки. Тогда на следующей тимлидской встрече мы проверяли, остались ли они красными. Если да, то начинали выяснять, почему за две недели обучение не продвинулось. Если красный ушёл, остались серые квадратики, мы периодически и их проверяли. Результаты тимлидской встречи записывали в Confluence в чек-листы, где отмечался статус. Например:«Сотрудник 1 — прокачка 10 из 20». Если за две недели эти значения не изменились, смотрели, почему.

Каждый новый сотрудник всегда оказывается в красной зоне, ему надо как можно скорее обучаться и прокачиваться. Но каким образом?

Шаг 4. Прокачка знаний и навыков

Наполнение: заполнение документации

Мы пришли к пониманию, что нужно стремиться к тому, чтобы одна строка декомпозированной таблицы продукта соответствовала одному знанию (одной странице документации).

В этой таблице как раз видно неидеальное описание. Это значит, областей знаний в левой колонке слишком сильная детализированы, а с правой стороны, вероятно, один большой лист документации, который сложно читать и по которому сложно обучаться. То есть, прочли одну страницу документации, и прокачали сразу 5 строк знаний — нелогично как-то получается. Лучше, чтобы одна строка соответствовала одной странице в Confluence. Так проще поставить галочку (число) о том, что вся страниц изучена и усвоена.

Мы используем два способа наполнения:

1. Пишем по памяти (экспертный способ). Тот, кто знает, как что-то делать, садится и начинает записывать свои шаги, например, дополняя описание скриншотами.
2. Второй способ — исследовательский — что вижу, то пишу. Таким способом мы воспользовались, когда работали с системой, о которой никто не помнил, что с ней делать. Сотрудник сел разбираться и по шагам записывал всё, что делал: тут надо запросить права, а тут написать письмо и т.д. Таким образом заполнилась документация по той части, которую он исследовал.

Бывает, интересы разработчиков в плане саморазвития не совпадают с тем, что нужно компании. Здесь можно поиграть с коэффициентами. Например, вам нужна прокачка навыков аналитики, значит, на аналитику ставим коэффициент 0,5. Становится понятно, что там можно быстрее «позеленеть». А вот там, где интереснее самим сотрудникам, но не команде, коэффициенты больше. В этих разделах на прокачку уйдёт больше времени.

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

Итак, мы задокументировали всё, что нужно. Следующий этап — актуализация.

Актуализация

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

Если ваша команда в вашем пространстве Confluence подписана на эти изменения, она получит уведомления, где что дополнилось, изменилось, улучшилось, потому что в Atlassian Confluence есть:

• История изменений страницы — всегда можно посмотреть, что и когда менялось.
• Подписка на уведомления об обновлениях страниц.
• Удаление через корзину.

Удобно, что есть удаление через корзину. Если кто-то случайно нажмёт «Удалить страницу», она всё равно не потеряется. Её можно восстановить и разобраться, почему кто-то пытался эти знания выкорчевать из вашего пространства.

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

Основной критерий качества обмена знаниями для меня — это уход сотрудника в отпуск. Если человек уходит в отпуск, и мне никто не пишет, не звонит и ничего не спрашивает, то я считаю, что в этой команде всё в порядке.

А если перед уходом в отпуск на планировании идут обсуждения «а что же мы будем без него делать», для меня это повод на личной встрече с тимлидом обсудить, что происходит с передачей знаний в его команде.

Надо понимать, что документация — это не всегда о том, что надо что-нибудь прочитать или узнать. Часто нужно что-то сделать: запросить доступ, установить программу, что-то открыть в программе. По ходу этих действий происходит актуализация. Например, пришёл новый человек, стал запрашивать доступ по инструкции. Сотрудник, который раздавал доступы раньше, уже не работает, нашли другого сотрудника. Документация обновилась.

Использование

Зачем всё это делать?

Легче распределять баги и задачи

Это очень хороший инструмент для распределения нагрузки на сотрудников. Очень удобно с этими таблицами обосновывать приоритизацию задач и сроки для бизнеса. Мы можем говорить о том, что оценили задачу в 4 часа, если ей займётся наш Джедай. Но мы будем делать её полтора дня, потому что хотим, чтобы ещё хоть кто-то в ней разобрался. Иначе, если Джедай пойдёт в отпуск, у нас будет беда. Когда у нас есть такая матрица, руководство начинает видеть процессы глазами команды, повышается прозрачность критериев для принятия решений. Вы приходите и объясняете, почему сейчас надо притормозить и заняться обучением.

Ещё одно достоинство нашей системы в том, что тимлид начинает видеть реальную загруженность каждого разработчика. Он может с этим пойти к руководству и сказать: «У меня есть человек, он загружен задачами по этой области. Давайте его разгрузим, пусть он начинает всё документировать и передавать знания коллеге».

Надо помнить, что Джедай — это роль, а не уровень технической прокачки. Если один опытный разработчик в роли «Джедай», второй человек в этой же области знаний может быть Падаваном, даже если он не уступает Джедаю по технических скиллам. У человека в роли Падавана может не хватать времени на прокачку, мы это понимаем и говорим: «Сейчас ты Падаван вот этой системы, но давай ты начнёшь поглядывать в документацию. Потому что в случае чего к тебе же прилетят проблемы с проекта».

План развития новичков

Это также очень хорошая помощь для развития новичков. Например, говорите новому сотруднику, что в первый месяц нужно по строчкам таблицы 1, 2, 3, 4 хотя бы прочитать документацию. Человек чётко понимает, где эта документация, что именно ему надо прочитать и сделать. Требуется меньше времени на вводные объяснения. Критерии чёткие и понятные, известно, что значит 1, 2, 3, 4. В каких частях системы новичку надо разбираться тоже известно.

Мотивация «морковка спереди»

Если в вашей компании есть система KPI, то вы можете вешать морковку спереди и говорить: «Чтобы в конце квартала добиться такого-то KPI в этой области, нужно сделать то-то и то-то по тем знаниям, которые уже расписаны». Если человек просит повышения, можно показать, что люди, зарабатывающие больше, выполняют вот столько. Больше ответственности — больше денег.

Получается и удобный способ мотивации — сотрудник может посмотреть на свою работу, на зону своей ответственности, на свой рост глазами руководителя.

Уменьшить Bus factor

У меня сейчас есть кейс: на одном проекте есть всего один разработчик, который делает систему. Я понимаю, что риск bus-фактора здесь равен единице, но сейчас нет никого, кто бы в этой системе горел разбираться, такая вот проектная команда из одного человека. И мы договорились о следующем: все его завершённые задачи не закрываются, а скапливаются в одном месте. Примерно раз в месяц мы заводим отдельную задачу на документирование, где он описывает всю логику своей работы по этим накопленным задачам. Код в этом случае ревьюить бесполезно, так как перед этим нужно разобраться, как система работает. Но всё, что пишет, он комментирует. Задача по документации у него занимает от полудня до дня раз в месяц. Тимлид другой команды со смежным стеком технологий читает документацию и говорит: «Да, в принципе я понимаю. Если что-то здесь сломается, я починю».

Тёмная сторона Силы

Хочу предостеречь от Тёмной стороны Силы, которая проявится, когда начнёте пользоваться этим инструментом. Он позволяет вытащить знания из ключевых сотрудников (экспертов) и перераспределить их. Но бывают сотрудники, которые много знают, но не спешат делиться знаниями. Желательно не использовать этот инструмент для Тёмной стороны (распределить знания и избавиться от человека). Так люди будут бояться и недобросовестно работать с базой знаний. Вообще, страх — это плохо. Расширение опыта не должно быть угрозой.

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

Выводы

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

«Но остерегайтесь Тёмной стороны Силы! Она может всё испортить». Это мой вольный перевод слов Чубакки. Но Чубакка фигни не посоветует!

Спикеры TeamLead Conf 2020 ^[2] расскажут ещё больше о мотивации сотрудников, Тёмной стороне силы и доверительных отношениях в команде. В этот раз мы сделали акцент на практике и добавили в программу воркшопы ^[3] от Максима Дорофеева, основателей «Стратоплана», Кирилла Анастасина или Дмитрия Лазарева. Если вы уже купили билет, то выбирайте и регистрируйтесь ^[4] на один из них. Если всё ещё раздумываете, стоит ли участвовать в конференции, посмотрите расписание ^[5] и обзоры докладов ^[6], подпишитесь на рассылку ^[7] с новостями или telegram-канал ^[8] и решайтесь. Увидимся 10 и 11 февраля!

Автор: Роман Ивлиев

Источник ^[9]