Многие специалисты в IT-сфере знакомы с понятием bus factor — меры концентрации уникальных знаний в одном человеке или ряде лиц, в случае отсутствия которых (в оригинале — попадания под автобус) работа проекта будет нарушена вплоть до остановки. Этот фактор может серьёзно навредить проекту в случае появления уникума, который будет этому самому фактору подвержен. Но, согласитесь, не только уход из команды ключевого сотрудника может повлиять на результат проектов — любой сотрудник уровня middle и выше является существенной производственной единицей. С другой стороны согласно опросам (здесь и здесь примеры довольно старенького опроса на Хабре, но мой опыт говорит, что данные в нём не утратили актуальность) средний срок работы программиста в компании находится в районе 2-3 лет. Это обусловлено следующими факторами:

• Пересмотра ЗП. Компании зачастую не повышают ЗП до рынка за это время.
• Специфики проектов. За 2-3 года в средней компании человек успевает изучить подавляющее большинство систем и редко получает кардинально новые задачи.
• Челлендж при смене работы. Опять же — новые задачи, новые вызовы, новые технологии.

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

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

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

В современных реалиях смена работы становится необходимостью. Но давайте всё же вернёмся к точке зрения работодателя. Если Вы каждый раз уходите, хлопнув дверью, то не просто портите себе карму — Вы оставляете негатив, который может вылиться в последствия. Как ни странно, мир IT очень тесен. За более чем 11 лет работы (на момент написания этой статьи) я увидел множество пересечений людей, знающих тех же персон, что и я. Или знающих меня. И негативный выход может обернуться проблемой.

Но даже забыв про теорию рукопожатий, некорректный уход из компании — это просто непрофесиионально. Спросите себя: «Какие проекты, которые я разрабатывал(-а), живут до сих пор и не умерли?». Согласитесь, было бы обидно осознать, что с Вашим уходом весь труд, всё Ваше потраченное на работу время, пошли прахом и никому не нужны. Тем более, Ваше портфолио при этом не пополнилось, а значит Вы не сможете нормально показать, чем занимались на проекте. Какой след Вы оставили в истории?

Поэтому процесс ухода из компании должен быть осознанным, спланированным и обоюдно полезным (как для Вас, так и для работодателя). Работодатель при этом не должен терять экспертизу (либо теряет её по минимуму), а Вы должны получать признание и рекомендации. И, кто знает, может Вам ещё предстоит встретиться?

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

Правило 1. Не завязывайте процессы и знания на себе.

С самого первого дня работы Вы будете погружаться в специфику работы компании, её системы, архитектуру, процессы. При хорошем стечении обстоятельств и правильном построении эффективного карьерного пути Вы будете это делать до самого последнего дня работы в компании. Знания будут приходить и накапливаться. Держать их в голове — не лучшая затея. Автор книги «Getting Things Done» Дэвид Аллен говорит о нашем разуме следующее:

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

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

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

Все знания, которые Вы собираете, надо выносить в систематизтированные хранилища. Особенный акцент я делаю здесь на слово «систематизированные». Для себя я завёл следующую иерархию хранения:

• Информация
  • Оперативная
    • Личная
    • Рабочая
  • Стратегическая
    • Личная
    • Рабочая
      • Персональная
      • Командная

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

1. Сможет её быстро посмотреть
2. Сможет её быстро обновить
3. Не делает много шагов для анализа

Как правило, это оперативные вещи типа состояния системы, задач и т.д. Для этого существуют специализированные решения, такие как таск-трекеры, мониторинг, notion. Самое главное — не надеяться на хранение информации в чатах. Они не обладают структурой, следовательно, никто не поймёт где и что искать (некоторые любят закрепить какую-то информацию в pinned у Телеграм, и это плохая идея).

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

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

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

Отдельно стоит поговорить о паролях. Сколько Ваших коллег хранит пароль на стикере под клавиатурой/блокноте/файлике в notepad? Я не стану объяснять, почему это небезопасно, но в мире, где есть такие прекрасные вещи, как KeePass, вести базу паролей легко, удобно и просто. Он доступен на всех платформах, в том числе и на мобильном. Правил несколько:

1. KeePass файл должен быть един для тех, кто имеет к нему доступ
2. KeePass файл должен актуализироваться каждый раз при смене паролей или заведении новых аккаунтов. В данном контексте очень удобно хранить пароли в корпоративном облаке.
3. Каждый пароль должен заводиться на корпоративный аккаунт email
4. Каждая запись в KeePass должна содержать комментарии о том, что это за система, зачем она используется и кто за неё ответственен
5. Используйте структуру папок в KeePass, чтобы пароли разделялись по тематическим разделам

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

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

Правило 2. Стройте процессы.

Львиная доля Вашей деятельности может и должна подчиняться правилам и алгоритмам. Они облегчают решение проблем хотя бы потому, что не заставляют думать над тем, КАКОЙ следующий шаг сделать. Если Вы разработчик, то стройте процессы своего рабочего дня и делитесь ими с другими. Стройте процессы ревью, работы с документацией и т.п.

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

• резервирование
• регламентирование

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

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

Правило 3. Автоматизируйте.

Автоматизация — это подвид процесса, в котором решение, которое подчиняется алгоритму, полностью или частично избавляется от необходимости ручного взаимодействия. Самый яркий пример здесь — это CI/CD. Как ни странно, в 2020м году я всё ещё встречаю крупные компании, в которых код доставляют на production без CI/CD и тестирования. А ведь процесс доставки кода не только упрощает саму эту деятельность, но и помогает Вам не наделать ошибок.

Правильное построение доставки кода, разумеется, зависит от проекта, но общие правила всё же есть:

1. Разделение слоёв разработки. У Вас есть отдельная воспроизводимая автоматически «песочница», персональная для каждого разработчика. Дальше есть общая dev-среда, где происходит централизованное тестирование внутри R&D, stage — для тестирования со стороны заказчиков и production. Да, разумеется, если у Вас есть pet-project или Вы разрабатываете сайт на фрилансе, такой сложный процесс будет лишним — я постил перевод статьи, мнение из которой разделяю, тут.

2. Zero-downtime. Ваши пользователи не должны страдать от релизов. Поэтому изучайте стратегии деплоя — blue-green (посмотреть можно здесь), canary и т.д. Система должна быстро переключаться между версиями и быстро же откатываться назад в случае проблем.

3. Тестирование. Ручное и автоматическое, юнит, интеграционное, end-to-end, smoke — тестов много не бывает. И прекратите уже просить время у бизнеса на написание тестов. Тесты — это часть разработки, написания кода. Конечно, есть особо упоротый бизнес, который приходит к разработке и говорит, что тесты не нужны, «давайте фичи пилить», но Вы же понимаете, что с таким бизнесом не стоит работать? 🙂 А если серьёзно, то всегда можно и нужно говорить с бизнесом на языке денег. Если тестов нет, может упасть ЛЮБАЯ часть системы. Потому что, работая без нормального тестирования, Ваш процесс разработки похож на игру Дженга.

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

5. Статический анализ кода. Если у Вас в команде есть code-review — это очень здорово. Но статические анализаторы кода (они же «линтеры») помогают избавиться от багов до компиляции и ревью, обозначая недопустимые для языка конструкции, а также следование кода правилам, установленным в команде.

Отдельно стоит сказать про процесс бэкапирования. Не стоит думать, что snapshot системы или дамп БД защитят Вас от всех проблем. Дело в том, что база данных может разворачиваться из бэкапа несколько часов. Насколько быстро при этом Ваши пользователи вновь получат доступ к системам? Поэтому начните с оценки своей системы резервного копирования. Насколько быстро она позволит Вам вновь работать, если злоумышленник или кусок плохого кода положат её на лопатки? И да, задокументриуйте процесс бекапа, чтобы те, кто будет работать после Вас, понимали, что делать с системой в случае падения.

Итого

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

Контрольные вопросы:

• Как ставятся задачи?
• Может ли менеджер, не привлекая Вас, понять статус интересующей его задачи?
• Все ли системы имеют резервную копию?
• Не теряется ли актуальность данных из-за редкого снятия бэкапов?
• Как долго производится восстановление из бэкапа?