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

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

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

Как организовать передачу знаний

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

Шаг 1. Составьте план передачи знаний

• Определите список тем, за которые отвечает эксперт.

• Приоритезируйте темы: сначала самые критичные для работы команды.

• Разделите объемные темы на короткие блоки, чтобы работать с ними постепенно.

Этот шаг требует отдельного внимания. Мы разберем его более подробно в следующих разделах.

Шаг 2. Назначьте ответственных

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

За каждой темой закрепите человека из команды, который будет:

• Выгружать знания из эксперта.

• Фиксировать информацию в документации.

• Задавать уточняющие вопросы при необходимости.

Шаг 3. Проводите регулярные встречи

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

• Записывайте встречи.

• Завершайте каждую встречу кратким итогом: что зафиксировано, какие остались пробелы.

Шаг 4. Фиксируйте знания в документации

• Используйте инструменты и форматы, принятые в команде. Это могут быть подробные описания архитектуры, отдельных модулей во внутренней Wiki, схемы связей между сервисами в Miro и текстовые файлы с инструкциями в репозитории рядом с кодом.

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

• Вносите правки при необходимости: улучшайте объяснения, добавляйте детали, исправляйте неточности.

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

Шаг 5. Отмечайте прогресс

• Используйте чек-лист с планом передачи знаний.

• Ставьте задачи по каждому из пунктов и отслеживайте, какие области уже покрыты, а какие еще требуют работы.

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

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

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

Какую информацию важно сохранить

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

К критичным знаниям о продукте, которые следует покрыть документацией, можно отнести:

• Ключевые архитектурные решения:

  • Архитектура системы: как она устроена, какие компоненты взаимодействуют, какая выбрана база данных, какие особенности и связи. Это поможет команде понять, почему система работает именно так и что делать в случае проблем или необходимости изменений.

  • Исторические архитектурные решения: как и почему были приняты.

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

• Взаимодействие с внешними сервисами и API:

  • Описание всех важных интеграций: для чего и каким образом.

  • API-документация и подробности по взаимодействию с другими сервисами.

• Рабочие инструкции:

  • Развертывание и настройка окружений.

  • Восстановление системы в случае сбоев.

• Бизнес-логика и потребности клиента: специфичные требования или нестандартные решения, которые неочевидны для других членов команды.

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

Как работать с картой компетенций

Карта компетенций — это инструмент для оценки распределения знаний и навыков в команде.

Карта компетенций может быть представлена в виде таблицы. Она наглядно показывает, какие области покрыты командой, какие критически зависят от одного человека и кто сможет их перенять.

Как сделать

1. Составьте список областей компетенций. Его пункты — это все ключевые знания о продукте: архитектура, алгоритмы, бизнес-логика, интеграции. Можете ориентироваться на приведенный выше список критичных знаний.

2. Оцените уровень владения компетенцией, уровень знания каждого члена команды (или только ключевых) по каждому пункту. Важно, чтобы оценка была честной и объективной. Можно использовать следующую шкалу:

   • 4 — Эксперт: способен обучать других и глубоко понимает тему.

   • 3 — Продвинутый: знаком с темой, хорошо ориентируется и имеет опыт работы.

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

   • 1 — Начальный: минимальные знания, требует дополнительного обучения.

Пример

Предположим, что у нас есть продукт с несколькими основными модулями. И разработчик Паша скоро покинет команду.

Как читать и применять

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

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

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

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

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

Заключение

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

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