Скрытый текст

Если в вашей практике налажен процесс передачи знаний от команды другой команде, от коллеги команде и так далее То прошу бегло пробежаться по статье. В противном случае — если ваша команда испытывает трудности в передаче/получении знаний, то прошу уделить 5 минут вашего внимания публикации.

Введение

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

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

Общий сценарий

Уважаемые читатели, сталкивались ли вы с ситуацией, когда нужно было за некий промежуток времени вникнуть в чужой проект или вовсе ваша команда должна была перенять проект смежной команды? Если у вас достаточно длительный опыт работы, то наверняка у вас была практика приема/передачи знаний. Давайте рассмотрим сценарий, когда есть некоторая система, построенная по принципу микросервисной архитектуры. Предположим, что на протяжении длительного времени, например, 2 года — над системой трудятся три команды, одна из которых поддерживает и развивает бизнес‑логику микросервисов с кодом A (см. ниже на схеме), вторая команда работает над микросервисами с кодом B (см. ниже на схеме), третьей команде принадлежат сервисы с кодом C. В рамках сценария предлагается: команде А забрать полностью сервисы команды B. При этом требуется перенять перечень развитийных задач, в т.ч. обеспечить интеграции с новыми системами и доработать контекст взаимодействия с сервисами C. Команда B должна передать знания и приступить к разработке новой системы.

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

Рисунок 1 - Перечень сервисов и их схематичное представление взаимодействия

Риски

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

Исходя из практики могу сухо выделить следующие риски:

Риск выбора стратегии передачи знаний. При передаче знаний, команда B может быть сфокусирована на закрытии дефектов и текущих развитийных задач по принципу — оставить меньше «текучки» коллегам, чтобы у них была возможность спокойно войти в рабочий темп. Но при этом на актуализацию документации практически не остается времени, поэтому документация остается коллегам из команды A неконсистентной, что в перспективе приведет к ряду уточняющих вопросов, активностей в части реверс‑инжиниринга, хуже, если приведет к ряду некорректных постановок или исправлений багов/дефектов.
Риск выбора стратегии передачи знаний (продолжение). Напротив, команда B фокусирует внимание на актуализации документации, рефакторит код. Если бизнес ожидает реализацию, ранее были оговорены сроки поставки новых функциональностей, то у команды A возникнет авральный режим работы.
Риск экспертизы. Не каждый аналитик и разработчик понимает бизнес‑логику соседнего сервиса в системе. Да в общих чертах понимает, но как правило — зачастую практикуются разделения зон ответственности внутри проекта. Аналитик и разработчик работают над определенным рядом сервисов. Таким образом сложно выделить одного аналитика на актуализацию всей документации, а другого оставить на развитии всех задач. Хуже, если вышеописанный сценарий касается команд, где нет системных аналитиков и проект связан с непростой предметной областью, например, тот же финтех.
Риск доверия. Две дружественные команды доверяют друг другу и потенциально команда A может надеяться на помощь со стороны коллег из команды B в дальнейшей перспективе. Да, с этической точки зрения — помощь коллегам всегда приветствуется. Но если команда B будет загружена и не сможет в ответственный момент прийти на помощь команде A из прошлой системы?
Риск неравноценного обмена. Допустим у команды А есть два аналитика: один занимается проектированием, а второй выделен на принятие экспертизы от команды B. У команды B — три аналитика и у каждого достаточно объемные зоны ответственности. В такой ситуации риск очевиден, более того существует огромный риск «перегреть» специалиста и впоследствии вырисовывается уже организационный риск — человек может попросту уйти из команды.
Риск ухода члена команды из команды A или B. В ответственный момент, при передаче знаний, один из центров компетенций может решить уйти. Таким образом у нас получается вложенность в задаче передачи знаний. Да, такое запросто может быть и к такой ситуации нужно быть готовым. Более того, если это принимающая сторона, на которую возлагались дальнейшие надежды, то это привносит большие неприятности для принимающей стороны, в нашем случае — для команды А. Здесь нужно понять, что человек успел гарантированно перенять, осмыслить, зафиксировать. Нужно быть готовым к тому, что команда B уже не сможет полноценно выделить время для повторной передачи знаний.
Риск потери артефактов: если при передаче знаний не фиксируются ссылки на документацию, репозитории, матрицы коммуникаций и так далее. То риск команды B очевиден — придется потом либо самим все искать, либо пытаться выяснить это.
Риск технологического стека. Хорошо, если команда B принимает у команды А сервисы с таким же стеком технологий, но если у команды А стек отличается и есть некоторые особенности, например, в сборке проекта, то команде А нужно было бы провести воркшоп и показать все на примере.
Риск временной неопределенности. Допустим, что команда B может эскалировать проблему, сообщить о том, что знания были переданы несвоевременно, некачественно, если команда A не сможет опровергнуть эти суждения, то вероятнее всего будет продолжать вести активности по передаче знаний, но только уже совмещая это с активностями в новом проекте.

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

Решение для митигации рисков

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

Определение ответственных сторон

Ответственные передающей стороны	Ответственные принимающей стороны
Фамилия Имя, роль, контакт
..

Тут все просто, определите всех причастных к приему/передаче экспертизы.

Срок передачи знаний

Начальный срок передачи компетенций	Конечный срок передачи компетенций
DD.MM.YYYY	DD.MM.YYYY

Определяете приемлемую дату окончания срока передачи экспертизы.

Организационные договоренности (манифест)

Приведу ряд договоренностей в качестве примера:

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

Стратегия передачи знаний

Стратегия или основные цели передающей стороны должны быть прозрачны и понятны принимающей стороне и всем заинтересованным

В качестве примера, привожу стратегию или активности передающей стороны:

Активности команды передающей стороны (в период передачи компетенций – акцент должен делаться на совершенствование текущих механизмов и подготовки артефактов для передачи)

Рефакторинг кодовой базы.
Доработка текущих задач.
Приведение в порядок документации проекта.
Тестирование и выявление дефектов уже работающей логики.
Онбоардинг принимающей стороны.

Перечень вопросов

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

Наименование	Ссылка	Комментарий принимающей стороны	Признак ознакомления принимающей стороны
Раскрыть механизм передачи события о результатах выполнения транзакции	Тут приводятся ссылки.	Была проведена встреча с аналитиком. На встрече были представлены ответы.	Оценка: 9
…

Перечень артефактов

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

Например,

Артефакты архитектуры

Наименование	Ссылка	Комментарий принимающей стороны	Признак ознакомления принимающей стороны
ADR
HLD
SLA
…

Артефакты развертывания

Наименование	Ссылка	Комментарий принимающей стороны	Признак ознакомления принимающей стороны
Конфигурации
Скрипты
…

Митигация организационных рисков

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

Итог

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

Ответственные процесса
Длительность процесса
Организационные договоренности (манифест)
Перечень вопросов, где принимающая сторона фиксирует степень удовлетворенности полученными знаниями
Перечень артефактов

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

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