Чуни в процессе передачи опыта

Обсуждали с коллегами, что такое плохо комментированный код, ну там были истории про комментарии на румынском и т.д. Самая прикольная история была про большую компанию, которая купила другую компанию со всеми их наработками. Когда стали разбираться в коде новой компании, то выяснилось, что большая часть написана китайцами, а добил их комментарий перед злобной реализацией некого алгоритма на несколько страниц: "описание алгоритма смотри в тетрадке у Чуня". Где тот Чунь уже было неясно :)

http://bash.im/quote/401544

Сегодня поговорим о грустном. О передаче опыта

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

Человек уходит, и вместе с ним уходят 1-2-3-назовисвоечисло лет опыта, ошибок (из разряда за одного битого...) и истории. Мой жизненный опыт показывает, что, к сожалению, не всегда безболезненно проходит передача производственного опыта, не всегда - в полном объеме. Хотя опять же, как ты передашь каждое свое знание накопленное за годы работы проекта втискивая их в 10 рабочих дней?

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

Если, то...

Мы передаем знания устно и письменно. Кроме этого есть знания закрепленные процессами (формализованные и, порой, даже - задокументированные) и знания "опытные" из разряда ветвистых если то

- Есть регрешн тест пак...

- И что мы его весь гоняем?

- Нет, только если основной релиз. Если патчи или хот фиксы, то гоняем только первые сто тестов. 

- И для всех основных релизов гоняем однообразно?

- Нет есть ядро, которое однообразно для всех и гоняется один раз и отдельные куски заточенные для отдельных клиентов.

- И что гоняем всегда так?

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

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

Я же тебе рассказывал...

Форматы передачи знаний очень сильно разнятся. Многие предпочитают "рассказывать". Это одна из самых изощренных пыток для новичков и перенимающих опыт "я же тебе об этом рассказывал". И возразить вроде бы нечего. Действительно что-то рассказывал. И с другой стороны обижать человека не хочется - так рассказал, что и забыть удалось легче легкого.

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

Сказано ведь - чо. 

Записать уговаривал минут пять...

Объяснять некогда - подписывай заявление

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

Грустные суровые реалии.

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

Нет времени или прям сейчас вечный неудобный момент

Код и так понятен или - хорошо самодокументирован

Это и так все знают

Ну ты же сам понимаешь, что написать хорошую документацию нужно много времени, а плохую писать не хочется

Ты просто придираешься

Чуни такие чуни

Хорошая документация

Про написание хорошей документации хочется остановиться отдельно.

Если пишется стратегия, то пишется серьезная стратегия на 30-60 листов.

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

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

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

Хаос источников

- Описание компоненты возьмите в вики

- В какой из?

Из подслушанного разговора

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

В другом проекте было еще интереснее.

Проекту было лет 10, может больше. Первая вики - вроде бы даже самописная, отвергнута как неудобная и тяжело поддерживаемая. Вторая уже твики - отвергнута президентом компании "too technical". Затем появился Confluence, второй конфлюенс (зачем не совсем понятно) и, в добавок, джира - это все было заполнено спеками, требованиями, тестовыми результатами и пр. и пр. и пр. Существовала логика с какого по какой год какие компоненты разрабатывались и человек определяя года шел в ту или иную систему.

И такое бывает.

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

План передачи опыта

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

Простая таблица может спасти хрупкий мозг от переизбытка информации: область + подобласть + документация + приоритет + люди обладающие экспертизой + статус

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

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

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

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

И краткий статус - выполнен или в процессе выполнения. Всегда хочется знать заранее где стелить соломку для падения.

В заключение 

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

На самом деле передача опыта это грустно. Есть человек. Ходишь ты с ним пить рюмку чая. Рассказываешь про выходные и будущие выходные. А с утра следующего дня читаешь письмо из разряда "до свидания встречаемся в 6 мне было приятно с вами работать контакты".

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

Сегодня о грустном...