Путь развития руководителя разработки

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

Большее нашлось в другой компании: интересный продукт, которому требовалось запустить новую версию, и разрешение собрать под это команду — издательский дом. Там Александр проработал около двух лет, собрал отличную команду и ушёл ровно тогда, когда она разошлась, — вслед за ней. Дальше было ещё несколько мест в роли тимлида, и в какой-то момент стало ясно: даже когда ты тимлид, ответственность за результат ограничена, ведь команда не сделает больше определённого объёма работы, а пользы хотелось приносить в большем масштабе. Сначала был небольшой стартап, который очень понравился, а потом — Tinkoff.ru, где в привлечении работало около десяти технических сотрудников и были очень большие планы на разнообразные проекты. Направление решили автоматизировать самостоятельно — и за два года выросли на порядок. К моменту доклада у Александра около ста технических специалистов, и он сразу оговаривается, что руководитель разработки в компании не один.

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

Так он попал в тимлиды и понял, что эта позиция — скорее про процессы, про людей и про инженерный подход, который нужно принести в команду. Горизонт тимлида — контекст его команды: продукт и delivery, внутренние процессы, кто заказчик. Когда команд становится несколько, добавляются приоритеты и стратегия: в каком порядке делать вещи, как распределить программистов между командами, на какие сроки коммититься с учётом сложных взаимосвязей и как разносить изменения. Мерилом здесь, как ему кажется, становится бизнес-результат, и идти нужно от цели бизнеса — зачем мы это делаем. Дальше — контролировать выбор архитектуры: бизнес часто перестаёт развиваться после определённого шага, потому что архитектуру заложили немасштабируемой, лишь бы взлететь, а переделывать потом очень дорого. Затем — сформировать правильные команды и организовать их процессы: команды вроде есть, процессов внутри нет, результат так себе. А когда это сделано, отойти в сторону, смотреть, как команды проявляют себя, выделять тех, у кого получается, и помогать отстающим.

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

Из зала спросили, что делать компаниям со слабыми процессами, которые хотят растить джунов. Ответ: сначала улучшать процессы, потом приводить джунов — в хаосе сильный специалист разберётся сам, а новичку не на что опереться, и именно тогда в него закладывается база. Свой старт Александр считает неправильным: компания без процессов, около 200 мегабайт кода, лежащего лет пять, три человека, которые в нём копаются, и сплошная копипаста; он купил «Совершенный код» и ещё кучу книг, чтобы понять, как разрабатывают промышленным способом. Правильный процесс, уточняет он, — это всё вместе, стороны одной медали: понятные обязанности, code review и техническая часть — тесты, автоматический pipeline и повторяемая инфраструктура. Роман спросил, как наладить процесс во второй команде: не изготавливать прокрустово ложе, а понять, почему в первой взлетело — ритм релизов, состав команды, — и прийти не сверху, а с общей проблемой, показав историю соседей «что было и что стало». Горизонт тут растягивается: изменение может взлететь через полгода, и привычка ждать результат за спринт демотивирует. Последний вопрос — где срезать углы: не уходить в аналитику и сразу попасть в компанию с процессами, тогда шесть лет до тимлида сжались бы года до трёх.