Обсуждали с коллегами, что такое плохо комментированный код, ну там были истории про комментарии на румынском и т.д. Самая прикольная история была про большую компанию, которая купила другую компанию со всеми их наработками. Когда стали разбираться в коде новой компании, то выяснилось, что большая часть написана китайцами, а добил их комментарий перед злобной реализацией некого алгоритма на несколько страниц: «описание алгоритма смотри в тетрадке у Чуня». Где тот Чунь уже было неясно 🙂
Сегодня поговорим о грустном. О передаче опыта
Довольно часто передача опыта длиться две недели (мы еще не можем отказаться от Российского законодательства), у кого-то — еще меньше (по согласованию — в отпуск, и, давай — до свидания). Это не всегда увольнение, иногда — просто смена проекта, но от этого — боли не становиться меньше.
Человек уходит, и вместе с ним уходят 1-2-3-назовисвоечисло лет опыта, ошибок (из разряда за одного битого…) и истории. Мой жизненный опыт показывает, что, к сожалению, не всегда безболезненно проходит передача производственного опыта, не всегда — в полном объеме. Хотя опять же, как ты передашь каждое свое знание накопленное за годы работы проекта втискивая их в 10 рабочих дней?
В последнее время приходится часто организовывать передачу знаний. Появился материал для систематизации. Как критичны эти знания из тетрадки Чуня. Как слабы мы в условиях неопределенности…
Если, то…
Мы передаем знания устно и письменно. Кроме этого есть знания закрепленные процессами (формализованные и, порой, даже — задокументированные) и знания «опытные» из разряда ветвистых если то
— Есть регрешн тест пак…
— И что мы его весь гоняем?
— Нет, только если основной релиз. Если патчи или хот фиксы, то гоняем только первые сто тестов.
— И для всех основных релизов гоняем однообразно?
— Нет есть ядро, которое однообразно для всех и гоняется один раз и отдельные куски заточенные для отдельных клиентов.
— И что гоняем всегда так?
— Нет, если времени мало то у нас есть три приоритета в тестах, которые мы постепенно и прогоняем. Критикальные — всегда, мажорные — по возможности, медийные — если есть время… но его никогда нет.
Сколько таких «если то« для регрессии, компонент, тестирования производительности. А сколько еще таких «если то» — в общении с клиентами…
Форматы передачи знаний очень сильно разнятся. Многие предпочитают «рассказывать». Это одна из самых изощренных пыток для новичков и перенимающих опыт «я же тебе об этом рассказывал». И возразить вроде бы нечего. Действительно что-то рассказывал. И с другой стороны обижать человека не хочется — так рассказал, что и забыть удалось легче легкого.
Девушка, передающая опыт, упомянула про некоторые особенности подготовки базы данных. К концу года, возможно, выпуск новой версии продукта позволит избавиться от этого нюанса. На мой вопрос почему нюанс не задокументирован, было отвечено, что об этом сказано всем: разработчикам, тестировщикам, всем до кого можно было дотянуться. Причем сказано было людям, у которых тестирование именно с этой базой данных не являлось постоянной работой и по сути — было сказано им впервые на совещании длиной в час про разные особенности работы с базами данных…
Сказано ведь — чо.
Записать уговаривал минут пять…
Объяснять некогда — подписывай заявление
Мне кажется основная проблема людей именно в постоянном ощущении «временности» происходящего. Весь опыт скапливается в переписке, разговорах и тетрадках Чуней, а средний срок работы специалистов в проектах стремится к 10% повышению зарплаты в другом месте. И потом приходит двухнедельный рубеж, за который нужно успеть протестировать вот этот вот последний решающий критичный релиз, дать отходную и пообещать прийти на помощь в любое время — по телефону, конечно же… Ах да — передать опыт!
Грустные суровые реалии.
И вот приходишь к такому Чуне заранее, до того как он решил что ему здесь скучно, мало платят, не уважают, заставляют перерабатывать, придираются — и просишь описать свой опыт. И тут…
Нет времени или прям сейчас вечный неудобный момент
Код и так понятен или — хорошо самодокументирован
Это и так все знают
Ну ты же сам понимаешь, что написать хорошую документацию нужно много времени, а плохую писать не хочется
Ты просто придираешься
Чуни такие чуни
Хорошая документация
Про написание хорошей документации хочется остановиться отдельно.
Если пишется стратегия, то пишется серьезная стратегия на 30-60 листов.
Если пишется описание компоненты, то называют спецификацией (требований, функциональной и пр) и оставляют место для подписи руководства. И никто не смеет использовать эту спецификацию до ее полного подписания всеми заинтересованными лицами. Иногда — никогда.
Причем, многие путают документацию (информацию) которая нужна команде с документацией которая нужна клиенту, и не нужно забывать, что есть еще документация, которая нужна руководству. Команда — Клиент — Руководство — эти три кита тянут черепаху информации в три разные стороны. И почти всегда рвут ее на части. Если не понимать, что документация может быть отдельным инструментом команды, и — продуктом представляющим проект перед руководством или клиентами, то можно действительно либо ждать лучшего момента, либо — тратить на украшение документа драгоценное время перед увольнением.
В одной из моих знакомых компаний искали технического писателя. Мне кажется уже год, как ищут. Ну может быть чуть меньше. И в понимании руководителя группы это должен быть технический писатель. В понимании президента компании — это должен быть человек с хорошим разговорным и идеальным письменным английским. Цели разные — руководитель ищет собирателя информации, а президент хочет — переводчика.
Хаос источников
— Описание компоненты возьмите в вики
— В какой из?
Из подслушанного разговора
Вспоминается проект в котором использовались: 1 твики, 2 конфлюенса, один социальный внутренний корпоративный сервис и два шарапойнта — и все это чтобы хранить информацию об одном проекте. Исторически сложилось — чо. Команда была раскидана по разным локациям, потом соединили несколько проектов в один проект и появился вот такой осминожек. Причем не скажу, что там хаос, просто нужно точно знать где искать.
В другом проекте было еще интереснее.
Проекту было лет 10, может больше. Первая вики — вроде бы даже самописная, отвергнута как неудобная и тяжело поддерживаемая. Вторая уже твики — отвергнута президентом компании «too technical». Затем появился Confluence, второй конфлюенс (зачем не совсем понятно) и, в добавок, джира — это все было заполнено спеками, требованиями, тестовыми результатами и пр. и пр. и пр. Существовала логика с какого по какой год какие компоненты разрабатывались и человек определяя года шел в ту или иную систему.
И такое бывает.
И вот создается еще одна отдельная страничка о передаче опыта, и туда ссыпаются все ссылки, все документы, все пароли и явки. Видя такие страницы ты чувствуешь, как легко и просто создать неструктурированное, непонятное нечто и обозвать его планом передачи опыта
План передачи опыта
К сожалению, очень часто, в последнее время, я связан с передачей опыта. И практически всегда в самом начале отсутствует план — что передавать, кому передавать, когда передавать, что документировать, где искать и пр. пр. пр. Приходиться рассказывать, что план нужен и даже показывать на своем примере.
Простая таблица может спасти хрупкий мозг от переизбытка информации: область + подобласть + документация + приоритет + люди обладающие экспертизой + статус
Действительно, план подразумевает, что у нас
есть знания и навыки, которые нам нужно передать. Если есть возможность их желательно выразить в виде дерева, двухмерности область + подобласть на моей памяти хватало с избытком.
Должен быть один-два человека, которые понимают и умеют с этими областями общаться или обладают экспертизой.
И — должна быть документация (что бы ни называли оной), к которой эти два человека обратятся, если что-то забудут.
И давайте не забывать про приоритеты — что нужно передать хоть вырви глаз, что нужно передать, но в случае чего люди смогут сами быстро прочитать и справиться, и есть нечто — что передать желательно, но команда или проект выживут в течении полугода, даже если внезапно спустя 10 рабочих дней все таки закончится передача опыта.
И краткий статус — выполнен или в процессе выполнения. Всегда хочется знать заранее где стелить соломку для падения.
В заключение
На моей памяти самая незабываемая потеря опыта была равна 30 годам. Три человека небольшой компании: технический директор, руководитель архитекторов, руководитель разработчиков встали и ушли в один день. 30 лет. Страшная цифра. Проекты инертны и к чему приведет такая смена — покажет год, может быть — два. Но покажет.
На самом деле передача опыта это грустно. Есть человек. Ходишь ты с ним пить рюмку чая. Рассказываешь про выходные и будущие выходные. А с утра следующего дня читаешь письмо из разряда «до свидания встречаемся в 6 мне было приятно с вами работать контакты».
И все таки проект вертится. И чтобы он крутился дальше нужно уметь готовиться продолжать его крутить. Удачных вам передач опыта. Пусть они будут предсказуемыми и запланированными.
Сегодня о грустном…
