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

Выпишите, что мешает сделать следующий шаг

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

Список неизвестного может выглядеть совсем просто:

• кто отвечает за данные о статусе заказа;
• почему один сервис нельзя вызывать напрямую;
• где описан формат события;
• что команда называет «ручной сверкой».

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

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

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

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

После разговора с коллегой полезно отправить короткое подтверждение: «Правильно ли я понял, что мы не повторяем запрос автоматически, потому что операция может выполниться дважды?». Это одновременно проверка понимания и шанс исправить ошибку до того, как она попадёт в решение.

К разговору с коллегой лучше прийти с версией ответа: «Я вижу это так, но здесь не сходятся два условия». Исправить конкретное предположение легче, чем отвечать на просьбу «расскажи, как тут всё устроено».

Сохраняйте решения, к которым придётся вернуться

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

Например:

Повторная отправка платежа. Клиент может не получить ответ, хотя операция уже выполнена. Поэтому повтор разрешён только с тем же ключом идемпотентности. Детали — в спецификации API.

Если такая запись лежит в Рундике, рядом можно оставить вопрос «Почему новый ключ при повторе опасен?». Он проверит причинную связь, а карточка вернёт спецификацию и детали решения. Такой формат особенно полезен для знаний, которые нужны редко, но ошибка в них дорого стоит.

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

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

Вопросы следующего новичка обнаружат пропущенный шаг, нерасшифрованное сокращение или фразу «тут всё понятно», за которой скрывается неделя опыта.

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

Нарисуйте карту людей и источников

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

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

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

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

Отделите обучение от попытки выглядеть знающим

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

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

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

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