Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Как уйти из компании спустя 4 года работы и не оставить команду ни с чем

Всем привет, меня зовут Александр Геец и не так давно я прекратил сотрудничество с продуктовой компанией, в которой работал более 4-х лет как Front-end Developer. Все это время я работал в одной и той же команде, но при этом она менялась: люди переходили в другие команды, уходили из компании, приходили новые. Разумеется, когда ты долго находишься в одном месте, то и все это время работаешь с одной кодовой базой.

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

Как я писал выше, мой путь в этой компании закончился, и в связи с этим возник вопрос о передачи всех моих знаний своей потенциальной замене и команде в целом. Мои знания охватывают как продуктовую работу страниц сайта, так и то, как это реализовано во front-end коде, с примерами отдельных блоков кода. Передать такие знания очень важно. С одной стороны, это очень поможет команде уменьшить и так наступивший bus factor (в связи с моим уходом), не потерять темп в разработке нового функционала из-за траты времени на понимание, как же работает та или иная страница, что имеет шанс взорваться очень скоро, если забыть и не переписать какой-то участок кода, а на что можно пока опустить глаза и жить дальше.

С другой стороны, вы больше вкладываете в свой здоровый сон и шанс того, что прошлые коллеги не напишут вам с просьбой помочь разобраться, как же работает ваш код или «можно тебя буквально на 5 минут, тут какая-то непонятная функция, которая что-то сохраняет в local storage, зачем это?». Мне также искренне кажется, что грамотная передача знаний — это очень хорошая практика, которая хорошо развивает разработчика, поэтому пренебрегать этим для меня сравнимо с тем, чтобы упустить хороший шанс прокачать себя.

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

Как определить объем области знаний

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

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

Давайте обо всем поподробней.

Как работают отдельные страницы или модули

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

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

Для себя я определил, что самым простым способом является выбор отдельной страницы или модуля и разделение повествования на такую структуру:

Рассказываем, как продуктово работает страница

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

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

Указываем, как работает страница технически

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

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

Подводные камни

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

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

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

Список рефакторинга технического долга на новый квартал

Планы на будущее

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

В этой сфере я бы выделил несколько важных моментов:

Срочные планы

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

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

Если этих знаний не передать и не подготовить всех, то будет страдать как команда, впопыхах пытающаяся понять, как работает код и как обновить эти самые библиотеки, так и пользователи, для которых все работает не так гладко, как обычно. Можно подумать о том, что все должны предугадать, что так может случиться и нужно заранее что-то сделать, но мне кажется, вы, как front-end разработчик, первое звено в этой цепи и можете повлиять на ситуацию и спасти всех от тех самых бессонных ночей. Не упустите этого.

Футболка, которую мне подарила моя команда перед уходом как локальный мем-напоминание о нашем техническом долге

Долгосрочные планы

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

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

Как стоит преподносить информацию

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

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

Прежде всего важно распространить на всю команду очень глобальные вещи: как работает страница продуктово, какие user flow там присутствуют, чего не застали недавно присоединившиеся члены команды. Такая презентация способна освежить знания у «старичков», которые застали те времена, когда писался этот функционал, так и рассказать о продукте со всех сторон всем остальным членам команды. Это полезно и для осознания полной картины, и для понимания, что какой-то новый функционал не нужно добавлять, так как, например, мы его уже добавляли два года назад, и это не взлетело. Экономим время, отбрасывая повторяющиеся в прошлом гипотезы, экономим время на разработку и расширяем знания всей команды. Как мне кажется, это полезно!

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

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

Записывайте все, что можно записать

Будь то видеомитинги, статьи в confluence, комментарии с отдельными функциям в коде, тесты — все это важно записывать в любом формате. Я понимаю, что это все далеко граничит с принципами user friendly, но даже запись часового митинга куда информативнее просто видеокола, где вы можете объяснять какие-то сложные вещи и как они работают в коде. Потом у человека будет возможность пересмотреть этот митинг, и правило «слона едят по кусочку» будет выполняться.

Итоги

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

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Можете подождать пока свалят все остальные члены команды, тогда точно можно уходить

ожидание может затянуться :))))

С другой стороны, вы больше вкладываете в свой здоровый сон и шанс того, что прошлые коллеги не напишут вам с просьбой помочь разобраться, как же работает ваш код или «можно тебя буквально на 5 минут, тут какая-то непонятная функция, которая что-то сохраняет в local storage, зачем это?»

Стоит даже при передаче обсудить что после ухода — никаких рабочих вопросов)
Практика «на 5 минут» чревата тем что вы будете тащить контекст старого проекта еще год за собой)

к счастью у меня нет таких потребностей, в отличии от вашей потребности скрываться за выдуманным никнеймом и писать гадкие комментарии :)
моя передача знаний как раз и перекрыла необходимость уточнять и дергать по рабочим вопросам, о чем в этой статье я с радостью и поделился

также стоит учитывать, что есть разные компании и люди с разным уровнем тактичности(вам ли не знать о тактичности?), поэтому, в большей степени, нет строгой корреляции что «чем больше знаний оставил — тем меньше звонков получил». У каждого свои рамки приличия.

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

Слишком много воды в статье.

на мою думку ти занадто перейнявся проблемою, яка мала бути вирішена раніше: bus factor ніхто не відміняв
що трапилось би якщо б ти взагалі ніяких знань не передав?

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

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

Все зависит от объёма информации, но в моем случае это заняло примерно 2 недели

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

И еще знакомые тоже передавали проект новым владельцам (выкупили его, что ли), тоже жесть — там штук 30 микросервисов — обычно в таком случае одного инженера из «стареньких» держат на связи, так как все передать в 2 недели и даже месяц невозможно.

Из того, что помню:
1) писала список тем, которые нужно обсудить или задокументировать
2) затем напротив каждой темы 2 оценки — сложность (простая, средняя, сложная) и критичность (очень ли критично это обсуждать и/или документировать, или, если что, там легко и так разобраться)
3) в первую очередь документировали и обсуждали то, где высокая сложность и/или критичность информации

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

всё даже не сколько не так однозначно )) там его не просто «не возможно пере дать» но там его почти 146% не возможно принять

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

а весь этот knowledge sharing это туфта чистая это надувательство для всего этого нужен специально обученный knowledge owner которого держать так просто само по себе слишком дорого поэтому приходится нанимать только уже по факту даже здесь на доу была статья за то как гребцы мужественной галеры перенимали старые данные чтобы забрать проект у простых рабочих я готов угадывать они этот процесс сам процесс «передачи и актуализации» взяли отдельно деняк хотя на деле там ни чего не изменилось просто для бизнес овнеров это чистый чёрный ящик но по секрету скажу для технарей он почти 146% точно такой же ж чёрный ящик который ни когда не знаешь что там на самом деле плюс почти всегда там матрёшка внутри которой ещё чёрный ящик который в свою очередь снова матрёшка и так далее до уже чистых чёрных ящиков на пример странных объектов не делимого кода третьих фирм версий много вековой давности «а почему вы это не выбросите» «ну мы не знаем вот есть эта версия мы с ней работаем давайте попробуем её собрать на новой платформе 42 тысячи лет спустя» (к) (тм)

правильный да и единственно разумный подход как уже было упомянуто это классический bus factor на всё остальное это всё «ну такое» я понимаю берёт по своему профессиональная гордость

уйти из компании спустя 4 года работы и не оставить команду ни с чем

но правильно тут говорить ты абажди мил чилавек а этих 4 года работы ты вообще что делал )) ну селяви

а этих 4 года работы ты вообще что делал

я понимаю как это могло произойти: если в Definition of Done задачи черным по белому не прописано «и задокументировать все, что вы там наделали» или «и обновить обязательно всю связанную с этим документацию» то про документацию девелоперы забывают, активно деливерят фичи, радуя менеджера высоким велосити!

радуя менеджера высоким велосити!

=>

Как уйти из компании спустя 4 года работы и не оставить команду ни с чем

это другое (к) (тм)

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

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

если менеджмент не думает в процессе над такими вещами — почему должен парится специалист а не те кто принимают знания или непосредственный менеджер?

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

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

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

Підписатись на коментарі