Что будет, если не делать вид, что всё понял на новой работе

Вступление

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

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

Я довольно быстро пришёл к выводу, что в начале работы полезнее вести себя наоборот: не демонстрировать понимание раньше, чем оно действительно появилось. Причём речь не о том, чтобы спрашивать коллег обо всём подряд. Смысл в том, чтобы вовремя отделять известные факты от собственных догадок.

1. Первое, что изменится: ошибок станет меньше, но вопросов временно больше

Если перестать автоматически отвечать всё понятно, довольно быстро обнаруживается, сколько информации на новой работе раньше просто додумывалось.

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

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

Перед началом новой задачи я бы советовал проверить хотя бы следующее:

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

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

2. Вы быстрее поймёте настоящую систему, а не только документацию

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

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

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

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

Если бы я решил, что спрашивать неудобно, то, скорее всего, долго искал бы ошибку в правильном SQL.

3. Вы научитесь проверять не задачу, а своё понимание задачи

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

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

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

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

Перед сложной задачей полезно самому себе ответить:

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

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

4. Коллеги обычно начинают доверять быстрее, а не медленнее

У новичков часто есть страх, что большое количество уточнений создаст впечатление слабой подготовки. На практике всё сильно зависит от качества самих вопросов.

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

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

Именно такой подход я считаю самым безопасным:

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

Тогда вопросы перестают выглядеть как просьба выполнить работу за тебя. Они становятся частью технического анализа.

Есть и ещё один эффект. Когда сотрудник открыто говорит, где заканчивается его понимание, другим людям проще оценивать риски. Руководитель знает, где понадобится помощь. Коллега понимает, какую часть контекста нужно добавить. Ревьюер заранее замечает потенциально спорное место.

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

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

У такого подхода есть и минус, который стоит учитывать. В первые дни скорость иногда действительно падает.

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

Но сравнивать нужно не время до первого коммита, а время до правильного результата.

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

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

Первый сотрудник начал писать код быстрее. Второй закончил задачу раньше.

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

6. Через некоторое время вопросов станет меньше

Самое интересное происходит через несколько недель. Если задавать вопросы осознанно, постепенно начинает формироваться внутренняя карта проекта.

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

После этого вопросов обычно становится меньше.

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

Мне кажется, именно этого и стоит добиваться на новой работе.

Вывод

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

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

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

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

А вот неудачную переделку, которая заняла у нескольких человек два дня, могут запомнить гораздо лучше.