Ко мне периодически приходят инженеры с одним и тем же запросом: «Я хочу расти. Что для этого почитать, посмотреть или поделать?»
Мой короткий ответ: в первую очередь стоит искать задачи на вырост в текущей работе.
Получение информации само по себе ещё не обучение. Книгу или курс нужно переварить, связать со своим опытом и применить. Подробнее я разбирал это в материале «Как учиться осмысленно».
Для профессионального роста нужно делать что-то новое или по-новому решать знакомые задачи. Рабочая среда для этого удобнее пет-проектов: в ней уже есть реальные пользователи, ограничения, последствия и обратная связь.
Искать проблему, а не ждать задачу
Когда сложные задачи приносят на блюдечке, расти легко. Но рассчитывать на это как на стратегию наивно. В какой-то момент любая работа становится привычной, а готовые вызовы заканчиваются.
Здесь проходит одна из границ между миддлом и сеньором. Миддл учится хорошо решать поставленные задачи. Сеньор умеет сам находить проблемы и предлагать решения.
Проблемы есть в любой команде, просто со временем мы привыкаем их не замечать. Мне помогают два инструмента.
Журнал проблем
Я записываю всё, что раздражает, замедляет работу или требует лишних усилий. Это обычный бэклог наблюдений, который можно вести лично или вместе с командой.
Еженедельная рефлексия
Раз в неделю я просматриваю журнал и отвечаю себе на несколько вопросов:
- Что тормозит или бесит меня в работе?
- Что регулярно расстраивает команду?
- Куда уходит много времени при скромном результате?
- Что мешает нам работать заметно быстрее?
- Как убрать это препятствие надолго?
Начинать лучше с небольшой и достаточно бесячей проблемы. Быстрый результат даст обратную связь и поможет закрепить навык.
Проверить, что проблема стоит решения
Не всё, что раздражает, действительно важно. Если чинить всё подряд, получится бодрая деятельность без заметного результата.
Перед тем как предлагать изменения, я проверяю три вещи:
- На кого влияет проблема.
- В чём именно заключается ущерб для продукта, бизнеса, команды или процесса.
- Насколько велик масштаб этого ущерба.
После этого нужно проработать решение:
- сколько оно стоит;
- есть ли более дешёвые альтернативы;
- какие новые риски и трудности оно создаст;
- соответствует ли цена решения масштабу проблемы.
Идею полезно приносить тому, кто распределяет ресурсы, уже вместе с этим анализом. Большинство предложений всё равно отклонят. Тогда важно собрать обратную связь: чего не хватило, какие риски оказались неприемлемыми и что стоило доказать лучше.
Упражнение для первой инициативы
Однажды ко мне на менторинг пришёл коллега с запросом на развитие в сторону техлида или архитектора. Мы договорились не искать ещё один список книг, а пройти весь процесс на реальной проблеме:
- Составить список того, что можно улучшить в команде.
- Для каждой проблемы описать ущерб.
- Предложить несколько решений.
- Оценить пользу, стоимость и способ внедрения каждого варианта.
- Принести разбор на ревью и доработать его.
- Показать предложение тимлиду, собрать обратную связь и реализовать выбранное улучшение.
Сам я возвращаюсь к похожему упражнению раз в неделю или две. Регулярность здесь важнее размера первой инициативы: маленькое законченное улучшение быстрее учит замечать проблемы, договариваться и доводить решение до результата.
Три проблемы разного масштаба
Десять минут на релизную документацию
Во время релиза ответственному нужно было смотреть метрики и логи, проверять состояние подов в Kubernetes и вспоминать команды kubectl. Каждый раз ссылки и команды приходилось искать заново.
Я добавил в документ процесса релиза нужные ссылки, команды и короткую инструкцию. Это заняло около десяти минут, зато упростило релизы и онбординг всех, кто подключался к процессу.
До двадцати процентов эпика на переделки
В одной команде регулярно возникали сложности при интеграции фронтенда и бэкенда. Не хватало полей, появлялись новые требования, а иногда требовались заметные переделки.
Я посмотрел несколько последних эпиков и оценил задачи, которые заводились уже после начала разработки. Доработки могли занимать до двадцати процентов эпика.
В качестве решения я предложил API-first: спецификацию API стали проектировать после дизайна, но до разработки, и согласовывать обеими сторонами. Фронтенд и бэкенд смогли работать независимее, а число переделок заметно сократилось.
Больше полугода на изменение процесса
Самой крупной инициативой стал переход нескольких команд на trunk-based development. Бизнес был недоволен скоростью поставки, а интеграция изменений в большом монолите регулярно приносила баги.
Я изучил последние релизы: сколько времени занимала поставка и сколько дефектов появлялось в зависимости от её объёма. Простых решений не нашлось, потому что требовалась серьёзная переработка CI/CD.
Главным аргументом стала невозможность масштабирования. Подключение ещё одной команды при старом процессе окончательно остановило бы релизы. После споров решение приняли.
Переход занял больше полугода. В результате команды стали чаще синхронизировать код, количество багов на релиз снизилось на порядок, а дефекты из-за конфликтов исчезли.
Рост начинается с наблюдательности
Профессиональный рост остаётся ответственностью самого человека. Руководитель может помочь, но он не обязан постоянно подбирать интересные задачи.
Рабочие проблемы дают всё необходимое для развития: реальные ограничения, цену ошибки, необходимость договариваться и измеримый результат. Нужно научиться их замечать, проверять и доводить решения до внедрения.