Передача знаний: о зрелости, врагах и жертвах

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

В канун 1 сентября давайте поговорим о знаниях.  О том откуда их брать в проектных командах и как ими делиться. Это интересная и нужная тема. Она всегда актуальна - и в быстрорастущих командах, и в стабильно не меняющихся. И даже в тех, которые думают, что для них это не актуально. По моему скромному подсчету количество последних - Легион.


Я выделяю следующие основные пункты-ступеньки в процессе управления знаниями продукта:
1) Передача знания по факту
2) Подготовка проектной документации
3) Подготовка документации о приложении
4) Программа подготовки новичков (вводный инструктаж)
5) Постоянный процесс распределения знаний в команде (производственный инструктаж)

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

Передача знаний по факту

По факту - это тот самый печальный момент "давай до свидания через две недели". Это может быть мобильная миграция в копании, а может быть очередной успех специалиста в поиске зарплаты на 20% больше. Задача заполнения пробела в ресурсах и знаниях в предельно короткие сроки может возникать внезапно, а может тихо тлеть, ожидая выплаты годовых бонусов. Результат в любом случае печален.   

Что есть в запасе у команды и руководителя, чтобы порешать эту печальку? Из основных - три вещи:
1) Найти кому передать (человек или группа)
2) Определить профиль знаний специалиста (или группы специалистов)
3) Спланировать и провести тренинги (распределить знания между теми кто еще остается или только что пришел)

Поиск ресурсов - отдельная больная тема. Уход специалиста в 99,9% случаев внезапен и болезнен. Человека (или группу людей), в голову которого (ых) в течении двух недель, должна сложиться картинка за последние 1-2-назови-свое-количество-лет-теряемого-опыта можно назвать жертвой обстоятельств. И у этих жертв, как правило, не появляется свободное время просто так из ниоткуда (ибо если есть свободное время тогда зачем нам столько людей). Жертвы все 8 часов вынуждены работать свою работу и, в довесок, внимать знания. В некоторых случаях на передачу знаний действительно уходит 8 рабочих часов в день и все две недели, но это две недели, а не месяцев или потерянных лет.

Профиль знаний - что это?

Стандартный профиль знаний включает в себя список проектов за последние год-два, список компонент системы и степень знания об этих компонентах у одного сотрудника или у команды в целом (это могут быть 0 или 1, а может быть коэффициент от 0 до 100). В профиль могут включатся ссылки на страницы в корпоративной вики, файлохранилища (как место сосредоточения центральных знаний - спецификаций) и это постепенно становится чеклистом для новичка.

К сожалению, профиль в Легионах не готовиться. Ни до, ни после увольнения. Передача в большинстве своем не планируется. Она случается и принимается по факту в конце давай-до-свидания срока.

У каждой процедуры и процесса есть враги. Главный враг передачи знаний по факту  аргумент -  "я им все рассказал (а)".

Вспоминается как в студенческие годы, в далеком 1998 году, на -, студентов первокурсников пытались учить текстовому процессору Майкрософт Ворд. Преподаватель на доске в течении первых пяти минут по методичке чертила меню и окна редактора. Я помню у меня даже глаз задергался. Спустя пять минут с дальней парты кто-то (все таки те кто сидит дальше от преподавателя всегда обладали большей отвагой) спросил:
- А мы все команды так будем проходить
- Да
- А... мммм... а может мы сами почитаем методичку и просто на лабораторных будем сдавать
- А вы сможете?
30 человек студентов, будущих программистов, которым до этого, наверное, день или два назад читали лекцию по ассемблеру и также рисовали команды на доске подтвердили, что они смогут. 

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

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

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

Проектная документация и документация приложения

Документация - это следующий шаг к повышению сеньорности процесса управления знаниями.

Есть достаточно известное разделение документации на проектную документацию и документацию приложения.

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

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

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

Легионы не любят нового, они любят стабильного "не трогайте нас" нежного отношения.

Программа подготовки новичков (вводный инструктаж) 

Следующая более зрелая ступень, хотя и не обязательно внедренная последовательно - программа подготовки новичков.

Новичок это тоже жертва. Но жертва периодически-постоянная. Новичков часто отдают на растерзание аргументам-врагам: "придет, посмотрит и сам научиться" и "все так учились".

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

Как можно помочь новой жертве?

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

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

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

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

Этап номер два. Этот этап включал в себя сдачу лабораторных. Тебе не читали лекцию, тебе давали задание. Все задания были инцидентами на проде - запросами клиентов или реальными багами. Человек должен был решить проблему и ответить на вопрос почему вот так вот работает, что нужно ответить заказчику, как настроить систему и пр. Это было действительно исследование. Нужно было порыться в спецификациях, почитать документацию, задать правильные вопросы коллегам (вопросы можно было задавать, но они не должны были звучать как "подскажи, что сделать нужно", вопросы должны были звучать "где найти доку, есть ли спецификация и пр.).

Это действительно был интересный и правильный процесс. Как я уже говорил - видел я его только один раз за всю свою айтишную жизнь.

Постоянный процесс распределения знаний в команде (производственный инструктаж)

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

Постоянно должны выявляться знания

Постоянно должны выявляться владельцы знаний

Постоянно должны проводится тренинги, чтобы владельцы не были в одном единственном лице

Постоянно должна поддерживаться мотивация узнавать другое

Постоянно должна быть ротация в команде

Всему такому постоянному мешает самый самый главный враг-аргумент при построении любого процесса - "исторически сложилось" (краска высохла, работа осталась).

Люди в течение длительного времени наблюдающие одно и тоже поведение, считают, что это поведение само собой, своим существованием подтверждает свою необходимость и самодостаточность.

Глаз замыливается.

Мозг затуманивается.

Процесс деградирует.

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

Мой сын идет в первый класс и меня пробило на знания. Надеюсь - в правильном направлении.

Удачного вам и вашим близким нового учебного года.

Знаний вам в голову, отсутствия Легионов и малого количества катализаторов ожидаемо пристального внимания.

Лето кончилось. Осень пришла. С 1 Сентября!