Для тех, кто не смотрел «Друзей»

Моника Геллер — персонаж культового ситкома 90-х, безумно одержимая порядком. Её чек-листы для чек-листов, лейблы на лейблах и фетиш сортировки по цвету и размеру превратили её в мем про педантизм. Но именно Моника в сериале всегда вытаскивала друзей из провалов: когда нужно было за 3 часа организовать свадьбу, найти документы за 5 лет или просто понять, кто последний брал фондюшницу.

В реальной жизни мы живём не в квартире с purple дверью, но законы Моники работают лучше любого скрам-майнд-сета.

Истории из жизни

Мой первый день в ИТ

09:00 — Я вхожу в офис своей первой IT-компании.

Ожидание: кофе, знакомство с командой, тёплые объятия корпоративной культуры.

Реальность:

• 09:01 — «У тебя с собой ноутбук? Отлично!»

• 09:02 — Показывают рабочее место

• 09:03 — «Так, ну что, открывай ноут, нужно сделать макеты очень срочно. Как сделаешь, отправляй мне на согласование».

Какие макеты, как их делать, где брендбук? Ответить на эти вопросы может только единственный человек — сеньор, который «все знает, спрашивай у него».

А сеньор — это интроверт в наушниках, который на каждый вопрос показывает свое недовольство, неохотно вынимает один наушник, и отвечает «ну что там у тебя?».

Это был не стартап в гараже. Это была компания с 50+ сотрудниками. И это был мой диплом взрослой жизни: там, где заканчивается структурирование, начинается ад героического самообучения.

Результат: вместо 3 часов работы — 3 дня правок, стресс и ощущение собственной некомпетентности.

Мои настоящие дни в ИТ

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

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

Почему так происходит

• Знания только в голове — никакой документации.

• Иллюзия экономии времени — «объяснить быстрее, чем писать».

• Отказ делиться информацией — то ли из-за страха потерять ценность, то ли из-за нехватки времени.

• Команда не настаивала на документации — все привыкли, что «Игнатий разберётся».

Вывод

Практически на каждом новом месте работы я сталкивалась с похожим положением дел.

• Документация — скорее исключение, чем правило. В большинстве случаев сотрудники предпочитают хранить все знания в своих головах.

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

• Ну, и, конечно, в каждой команде существует синьор, который работает больше 10 лет в компании. Именно он знает все, чинит все, если ломается, и очень трудно идет на контакт с кем бы то ни было.

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

Так вы не останетесь с горящей головой во время любых отсутствий Игнатия.

Почему мы не документируем: психология самоубийства

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

1. «Коллеги всё равно не читают» — 66%

2. «Нет времени, горят дедлайны» — 33%

3. «Я и так помню» — 33%

4. «Это ж надо ещё и писать» — 16%

5. «А вдруг я перестану быть нужным?» — 15%

6. «Другая причина» — 7%

Давайте разберемся с каждым из возражений по порядку.

1. «Коллеги все равно не читают»

Цифра в 66% — это не просто статистика. Это крик души тех, кто потратил время на написание инструкций, а потом слышит: «А где про это написано?» или «Ты мне просто скажи!».

Но прежде чем обвинять коллег в лени, давайте разберёмся: почему документацию не читают? Здесь может быть несколько причин.

1. «Я не знал, что это существует»

   Инструкция есть, но она:

   • Зарыта в 15-й папке с названием «Архив 2018–2020».

   • Не упомянута в онбординге.

   • Не привязана к задаче.

2. «Написано так, что проще спросить»

   Документация есть, но она:

   • Написана для себя, а не для новичка («Жмём ту кнопку, потом чиним тот костыль»).

   • Нет скриншотов и понятно описанных действий.

   • Не структурирована (сплошная стена текста).

   • Устарела (инструкция для версии ПО, которой уже нет).

   Пример: гайд по деплою

   Запусти скрипт deploy.sh. Если будет ошибка — поправь конфиг. Дальше понятно

   

   Что не так

   • Где взять deploy.sh?

   • Какой конфиг и куда «поправь»?

   • Какие ошибки возможны?

3. «Мне быстрее спросить, чем искать»

   Даже если документ идеален, коллеги:

   • Тратят и свое, и чужое время на поиск ответов.

   • Не верят, что там есть ответ («Уже искал — ничего нет»).

   • Привыкли к устным ответам (и получают их).

Решение

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

1. При возникшем вопросе не пытаться объяснять устно/в чатах, а скинуть ссылку на статью, где есть все ответы.

2. Прежде чем задать вопрос, коллега должен:

   • Проверить базу знаний.

   • Прислать ссылку на документ + конкретный пункт, который непонятен.

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

4. Следить за актуальностью документации.

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

2. «Нет времени, горят дедлайны»

Сюда же предлагаю отнести и причину «Это ж надо ещё и писать».

Да, писать документацию — это время. Но сколько времени тратится потом на объяснения одних и тех же вещей?

Типичная ситуация:

• Вы тратите 15 минут на устное объяснение коллеге.

• Через неделю тот же вопрос задаёт новый сотрудник — ещё 15 минут.

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

Итого: 1,5 часа потеряно vs 30 минут на изначальное создание гайда.

Решение

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

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

3. «Я и так помню»

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

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

Что касается рабочих задач, вот что вас ждет:

• Через месяц вы забудете половину нюансов.

• Через год будете с нуля разбираться в задаче, которую вы делали сегодня.

Решение

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

4. «А вдруг я перестану быть нужным»

Наверное, один из самых больших страхов сотрудника — перестать быть востребованным.

Соответственно, вполне логично предположить, что если тебя просят составить гайд/инструкцию, то твоя ценность станет меньше. А, может, и вовсе нейросеть по описанному тобой же (!) алгоритму будет делать всю работу за тебя!

Но на деле всё наоборот:

• Тот, кто документирует процессы, становится экспертом и наставником.

• Компания ценит не «тайные знания», а тех, кто помогает расти другим.

• Компании нужны те, кто масштабирует процессы, а не тормозит их.

• Умение объяснять и преподать информацию так, что будет понятно даже бабушке, один из скиллов, которые высоко ценятся на рынке

Решение

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

Как я начала документировать всё

Шаг 1. Личные заметки

Могу с уверенностью сказать, что если хочешь что-то изменить — начни с себя!

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

1. Нюансы по повторяющимся задачам.

2. Часто используемые скрипты.

3. Описание бизнес логики.

Шаг 2. Онбординг для новичков

Далее количество и качество документируемого мной контента начало увеличиваться.

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

Что я описала в онбординге

• как и какой софт нужно установить

• чем вообще мы занимаемся в команде + зона ответственности каждого

• к кому обращаться и за какой помощью

• чек-лист по типовым задачам

• шаблоны задач, описание ожидаемого результата

• FAQ

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

Шаг 3. Документация как KPI

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

Начало вырисовываться что-то вроде документации.

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

Нужно ли говорить, что взаимозаменяемость повысилась в разы? Почти каждый из коллег (да, мы тоже пока не смогли сделать так, чтобы это были все) отдыхает в отпуске спокойно, без необходимости быть на связи 24/7, лететь на отдых только с рабочим ноутбуком.

Где документация спасает даже вне IT

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

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

Выбор квартиры

Не важно, аренда это или покупка, вам будет гораздо проще найти «свое» жилье, если вы подойдете к этому системно.

1. Составьте список критериев, важных именно для вас (местоположение, цена, время до работы, наличие парков/детских площадок и т.д.)

2. Каждому критерию можно присвоить свой «вес». Например, важнее всего для меня это внутреннее обустройство квартиры — планировка, интерьер и т.д. Значит, этому критерию присвоим вес 5. Локация тоже важна, но не так существенна, значит, вес 4. И так далее по каждому из критериев из п.1.

3. Составить список потенциальных объектов, которые вам приглянулись.

4. Каждый объект оценить по 5-ти бальной шкале каждого из критериев п.1.

5. Посчитать общую оценку объекта — умножить вес критерия из п.2 на оценку из п.4.

6. Готово! Вы получили ранжированный список всех рассматриваемых квартир, и эта полученная оценка основана не на ваших ощущениях, а на реальном положении дел. И вы имеете четкое представление о рейтинге конкретного объекта.

Поиск работы

Аналогичную схему можно применять и для поиска работы!

1. Составить список из критериев для «работы мечты»

2. Все предложения от работодателей ранжировать по схеме выше

3. Оценить тройку лидеров, которые набрали наивысшие баллы

4. Принять решение и устроиться на работу мечты!

Пароли

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

Думаю, многие слышали историю 2021 года о том, как немецкий программист забыл пароль от кошелька с $220 млн в Bitcoin.
Иллюзия «ну этот пароль я точно не забуду» бьется о реальность.

Устанавливать везде одинаковый пароль — тоже очень плохая идея: если вас взломают, то взломают везде.

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

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

Как внедрить культуру документирования

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

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

Чек-лист: как начать и продолжить

Предлагаю действовать плавно и не пытаться изменить все и сразу.

1. Начните с себя

На личном примере будет проще показать и аргументировать то, что вы пытаетесь донести до коллег.

• После решения сложной задачи — запишите шаги.

• Если вам задают один и тот же вопрос много раз, создайте статью, в которой будет ответ на этот вопрос. И в следующий раз скидывайте ссылку на эту статью

2. Сделайте документацию частью процесса

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

• Внедрите правило: «Нет документации — нет завершённой задачи».
  Хороший тимлид не примет работающий код программиста, потому что в нем нет комментариев. В этом коде разбирается только один человек, что делает код не рабочим.

• Не ждите идеала. Лучше рабочий гайд сейчас, чем идеальный — никогда. Достаточно описать:

  • Ключевые шаги.

  • 1 скриншот/пример кода.

  • Контакт, кто знает больше.

• Внедрите еще одно правило: «Сначала поищи».
  Прежде чем задать вопрос, коллега должен:

  1. Проверить базу знаний.

  2. Прислать ссылку на документ + конкретный пункт, который непонятен.

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

3. Мотивируйте команду

• Продемонстрируйте математику времени: «Ты сэкономишь время себе и другим».

  Написание гайда: 30 мин.
  Объяснения без гайда: 15 мин × 10 повторов = 2,5 часа.
  Чистая экономия: 2 часа.

• Введите ревью документации, как код-ревью.

• Оценивайте документацию по заранее прописанным критериям. Награждайте тех, кто организовал четкую, понятную и структурированную документацию

• Статья помогла, и вопрос отпал? Просите коллег ставить реакции/лайки на тот контент, который был полезен. А по результатам этих оценок автора самой эффективной и полезной статьи премируйте и, конечно, хвалите!

• Статья не помогла, и вопросов стало еще больше? Это означает, что Игнатий плохо справился с документированием своей области ответственности. Тут можно рассмотреть и вариант депремирования.

4. Сделайте так, чтобы коллеги читали документацию

• Упрощайте доступ и делайте документацию видимой
  Добавляйте ссылки туда, где люди ищут (чаты, задачи).

• Пишите для других
  Не думайте, что и так все всем понятно: пишите так, будто объясняете своей бабушке.

• Вознаграждайте за использование
  Важно отмечать не только тех, кто пишет документацию, но и тех, кто ее использует! Это не менее важно. «Вася сэкономил нам 2 часа, потому что прочёл гайд».

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

• Нет предела совершенству
  Ну, и, конечно, чтобы документация улучшалась важна обратная связь. Собирайте фидбэк, дополняйте инструкции, пишите о том, что действительно нужно!

4. Автоматизируйте

• Генерируйте документацию из кода (Swagger, JSDoc).

• Используйте чек-листы и шаблоны.

• Создайте чат-бота, который не только отвечает на типовые вопросы, но и прикрепляет гайды.

Конкретный пример

Повторить шаги для следующей темы, следующего проекта, постепенно внедряя культуру документирования.

Итого

В сериале «Друзья» над Моникой смеялись. В реальности именно она спасала друзей от проваленных вечеринок, испорченной индейки на День благодарения и квартир, захламлённых IKEA-коробками.

Когда у вас горит продакшен и в отпуске единственный человек, который «всё знает», вам не до смеха. Вам нужен его README, а не его «сорян, в часовом поясе UTC+8, Wi-Fi только у бассейна».

Документация — это не время, потраченное впустую. Это страховка на случай, если завтра вас или коллегу съедят мамонты. Или, что более вероятно, если вы просто захотите в отпуск без телефона.

Так что откройте новую вкладку прямо сейчас и напишите первый пункт:
«Как собрать еженедельный финансовый отчёт».

Не для компании.
Для себя будущего — который точно не вспомнит, где лежит SQL-скрипт с хардкодом «project = 'X' AND date >= '2023-07-15'»