Джуниорский селфчек: бетонная стена

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

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

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

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

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

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

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

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

Эн по-умолчанию 60 минут. Снижается до 30 когда нужен более интенсивный онбординг и повышается до 90, когда в приоритете самостоятельность.

Тут важно понимать, что процесс организации подобной помощи — это не про отвлечение руководителя, не про стыд, не про обучение, не про дружбу, это чисто бизнесовая метрика, которая напрямую влияет на перфоманс отдела разработки. А раз это важная штука, нельзя “стесняться” её делать или бояться отвлекать кого-то ради этого. Надо договориться о правилах игры, засетапить процесс и соблюдать его.

Другой важный элемент этого процесса — качество задаваемых вопросов. На любой вопрос хорошо бы сперва попробовать найти ответ самостоятельно (за пару минут), потом хорошо сформулировать, потом выдохнуть, перечитать и только потом отправить. Этап с формулировкой и перечитыванием нужен не только для ради заботы о том, кого вы спрашиваете. Обычно когда вы нормально пишете вопрос, вы внезапно находите ответ. Это, блин, не шутка, это реально так. Я до сих пор иногда пишу вопрос в Слаке, потом перечитываю и понимаю, что я знаю, что мне ответят. Удаляю сообщение, еду дальше.

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