Привет! На связи Митя Кожевников и Юра Соколов из Mindbox, и это третья, финальная часть гайда по софтам для джунов. В первой части мы говорили о том, что значит «приносить пользу» в разработке. Во второй — об ориентации на результат. В этой части речь пойдет о развитии: что делать, чтобы расти быстрее. 

О гайде. Этот гайд — внутренний документ разработчиков Mindbox. Его писали не один год, опираясь на ошибки тех, кто давно стал мидлами и синьорами. И хотя Mindbox — продуктовая компания с особенной культурой, большинство советов из гайда подойдут и для работы в других командах. 

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

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

Совет 1. Задавать вопросы

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

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

• Перед тем как спросить, искать ответ самостоятельно. Не стоит закапываться и сидеть часами — достаточно 15–30 минут. Обычно за это время находят ответы на простые вопросы, либо погружаются в тему и потом лучше воспринимают ответы, обсуждают вопрос детальнее — в любом случае это облегчает работу наставника. 

• Говорить, где и как искали ответ. Например, «в ранбуках и карточке посмотрел, в Google поискал». Благодаря этому собеседник понимает, что вы действительно проделали подготовительную работу, — так отвечать на вопрос приятнее. К тому же он видит уровень погруженности и может адаптировать под это ответ. 

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

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

Митя Кожевников

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

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

Митя Кожевников

Вторая история обратная — когда незаданный вопрос привел к проблеме. У стажера была задача изменить синтетические данные в отчете в демо продукта. Для этого нужно было завести новую таблицу для хранения данных и по готовности переключить код сервиса на работу с новой таблицей с помощью feature toggle (об этом процессе рассказывали в статье про релизный цикл).

Чтобы подключить новую таблицу, нужно было проделать дополнительную работу в промежуточном сервисе. Стажер этого не знал, отложил регистрацию таблицы в сервисе, и переключил feature toggle раньше времени — в итоге не получил ожидаемого результата и на демо пропали данные.

Избежать этой ситуации помог бы вовремя заданный вопрос. Как данные из таблицы попадают в отчет? В какой момент можно переключить feature toggle? А еще лучше, если бы стажер принес ментору на валидацию план переключения: «Добавляю данные в таблицу, переключаю feature toggle и регистрирую таблицу в сервисе. Всё верно?» Ментор бы сразу его остановил.

Совет 2. Учиться на ошибках

Ошибки — это нормально, их делают все. Плохо повторять ошибки раз за разом. Чтобы не делать этого, полезно писать постмортем.

Постмортем — это письменный разбор причины факапа. Он состоит из ответа на вопросы:

• Что произошло?

• Какие события предшествовали этой ситуации?

• Какая первопричина проблемы?

• Что поможет устранить первопричину и избежать ошибку в следующий раз?

Пример заполненного постмортема

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

Юра Соколов

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

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

Совет 3. Ставить цели

Цели в профессиональном развитии полезны по трем причинам:

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

Юра Соколов

На старте я столкнулся с расфокусом. Мне нравилось быть разработчиком, но помимо этого меня привлекала роль наставника и скрам-мастера. Я не стал выбирать между направлениями и попытался делать все: и код писал, и встречи проводил, и к подготовке стажеров подключился.

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

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

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

Юра Соколов

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

Чтобы поставить профессиональные цели, можно использовать методику OKR — Objectives and Key Results. OKR состоит из двух компонентов:

• Цели (Objectives) — вариант будущего, который хочется достичь. Он должен быть крупным и амбициозным настолько, что выполнить его даже на 70% — уже круто. Например, стать мидлом и получить повышение или оффер на новое место; довести пет-проект до релиза; затащить сложный проект, например, редизайн главной страницы.

• Ключевые результаты (Key Results) — измеримые показатели, чтобы отслеживать прогресс в достижении цели. Они должны быть конкретными, ориентированными на действие и служить показателями успеха или неудачи.

Пример OKR

Цель — устроиться веб-разработчиком на фуллтайм.

Ключевые результаты:

• 1 месяц. Начать обучение на двух онлайн-курсах по фронтенд-разработке.

• 2 месяц. Построить и развернуть три персональных проекта, используя изученные технологии (например, HTML, CSS, JavaScript).

• 3 месяц. Получить обратную связь от опытных разработчиков по проектам и улучшить их согласно предложениям. Завершить онлайн-курсы. Пройти 10+ техсобесов и получить хотя бы 2 оффера.

Чек-лист быстрого профессионального роста

Если в какой-то момент кажется, что прогресса нет, это можно проверить, ответив на несколько вопросов:

1. Задаю ли вопросы, когда что-то непонятно? Пытаюсь найти ответ сам? Помогаю собеседнику ответить мне: проговариваю, где искал ответ, и формулирую решение самостоятельно?

2. Какие ошибки совершил за последнее время? Какие из них произошли не впервые? Что делаю, чтобы не повторять их и те, что произошли в первый раз?

3. Есть ли глобальная цель, к которой двигаюсь? Насколько я близок к ней? Какие ключевые результаты уже достигнуты? Какие в работе? Что я делаю для того, чтобы достичь цели?

Бонус: что прочитать, что научиться ставить цели по OKR

1. Книга «Measure What Matters: OKRs: The Simple Idea that Drives 10x Growth» или «Измеряйте самое важное. Как Google, Intel и другие компании добиваются роста с помощью OKR» Джона Дорра. 

2. Книга «High Output Management» или «Высокоэффективный менеджмент» Энди Гроува. 

? Больше о работе и росте разработчиков в Mindbox — на странице с рассказами наших нынешних и бывших сотрудников.