Как стать техническим директором, что делать во внештатных ситуациях, как добиваться повышения зарплаты и карьерного роста, а также как устроена разработка Am.ru — об этом мы беседуем в четырнадцатом выпуске ток-шоу для программистов «Oh, My Code».


Ведущий программы — технический директор медиапроектов Павел Щербинин, гость — Александр Мельничук, технический директор Am.ru.

Расскажи немного о себе.
Я закончил ИТМО. Пытался учиться в аспирантуре, занимался малоугловой рентгеновской дифракцией. Потом началась эпоха интернета, все начали делать порталы. В 2009 году позвонил мой знакомый и сказал, что его друг — Олег — хочет начать свой проект и собрать команду в Питере. Мы встретились у метро. С тех пор я работаю в am.ru. Во время первой встречи Олег сразу же захантил двух человек: меня, тогда руководителя разработки, и Сергея, ведущего разработчика. То есть, мы и написали первые строки кода.

«Пойдете к нам техническим директором?» — «А сколько у нас будет людей в подчинении?» — «Пока только вы».
Про технического директора тогда никто не говорил. «Технический директор» — вообще очень странная позиция. С одной стороны, это некий менеджмент, с другой — технический специалист. Есть разные вариации. Например, когда технический директор пишет много кода. Фактически, это лид-разработчик. Тогда у него обычно возникает серьезное недовольство по поводу различной менеджерской работы. В моем случае всё наоборот. Я 100 % своего времени управляю командами. Код я перестал писать примерно с 2009-го, потому что на это просто нет времени. Я могу его писать, но тогда надо отправить меня во вражескую команду.

Но всё-таки ты технический директор. Ты должен быть в курсе развития технологий, знать, как развивается фронтенд, бэкенд.
Я постоянно что-то читаю, смотрю, общаюсь с разработчиками. Понимаю, что и как сделано. И потом, до этого 8 лет я сам что-то писал. Конечно, это не было rocket science. Но читать код я могу и сейчас.

Как стать техническим директором?
Прежде всего, надо хотеть им стать. Нельзя сказать, что технический директор — это что-то суперклассное, лучше всего остального. Все профессии хороши. Можно быть счастливым разработчиком и радоваться этому. Директором надо хотеть быть. Разгребать менеджерские задачи — это определенный навык. Нужно понимать, что в большинстве случаев код писать не будешь. Иногда в вакансиях указывают, что нужен технический директор со знанием Symfony, да ещё и удаленно. В общем, какой-то ад. Эти люди себя обманывают. А иногда под «техническим директором» понимают архитектора, такое тоже встречается достаточно часто.

Сколько сейчас человек в твоей команде, и какая у неё структура?
43 человека. Структура плоская, то есть все эти люди административно подчиняются мне. У нас нет проджект-менеджеров и тимлидов. Зато достаточно развитая логическая структура из 5 отдельных команд, как узкопрофильных, так и широкопрофильных, которые занимаются сразу несколькими направлениями. Все команды абсолютно самостоятельные, работают над своими участками проекта. У них самоуправление, и это очень хорошо.

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

Наверняка у многих наших читателей возникнет вопрос: зачем нужен ты? Задачи идут напрямую в команду, команды клевые, самоорганизованные. Вроде бы, технический директор даже не существует.
Один мой знакомый как-то сказал, что задача директора — выстроить работу в команде так, чтобы его можно было спокойно уволить. Мы к этому стремимся, но пока не достигли.

Интересное стремление к тому, чтобы тебя уволили.
Мечты, мечты…

Тебе не кажется, что многие стремятся к должностям лидов и директоров с целью меньше работать?
Вчера я ушел с работы около 22 часов. Я, будучи техническим директором, очень часто завидую разработчикам. Это же так прекрасно: пришел, у тебя есть задача, которая тебе нравится, ты её сам выбрал, сделал, увидел эффект. Всё супер. Устал — попил кофе, поиграл, отдохнул. Если у тебя возникли какие-то сложности — поговорил с коллегами и сделал задачу. Можешь надеть наушники, слушать любимую музыку и делать свою работу. Если тебе плохо, ты можешь работать дома, можешь что-то придумать ночью.

У технического директора всё совершенно не так. Мой обычный день начинается с листа бумаги А4, где я записываю, что хочу сделать сегодня. Записал. Потом еще вот это, вот это, потом беру второй лист, потом третий. В течение дня задачи вычеркиваю. Их огромное количество, они маленькие, они постоянно меняются. Когда делаешь что-то одно, возникает следующее, и следующее.

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

Можешь рассказать про самые часто повторяющиеся задачи или, например, что-нибудь интересное из вчерашнего дня? Что входит в твои основные задачи?
Основная задача — чтобы всё работало, чтобы мы релизились без задержек, четко по графику, выполняли те задачи, которые поставлены продуктовой дирекцией, чтобы проекты сдавались в срок. Как я это буду делать — мои трудности. Сложности бывают самые разные. Например, приехали люди в дата-центр выгружать серверы, а грузчика не пускают, потому что у него паспорт подозрительный. Или сотрудники службы безопасности просят какую-то информацию, и надо найти того, кто эту информацию даст. Или продукт меняется, соответственно, появляются новые задачи и сроки, надо эти задачи как-то встроить в план и решить их.

Как у вас Agile вписан в систему разработки?
Мы целиком живем по Agile. У нас есть команды, работающие по Scrum, а есть команды, работающие по Kanban. Я даже не знаю, как бы мы без этого справились. Давным-давно, когда я еще не знал этого термина, мы пытались выстроить подобную систему, но у нас не получалось потому, что это была самодеятельность без учебника, на чутье. Например, давно уже была «аллергия» на проджект-менеджеров и людей, которые должны раздавать задачи и закрашивать квадратики. Проджект-менеджеров у меня никогда не было.

Как устроена работа команды?
У нас есть общий CPO (Chief product owner. — Прим. ред.) который говорит, как будет развиваться продукт. Дальше есть ряд APO (Area product owner. — Прим. ред.), которые отвечают за свои направления. На самом деле, организационная структура немного сложнее, но я описываю логику. У каждого направления есть отдельная команда. Команды берут задачи у APO, а иногда ставят сами. Задачи вносят в общий бэклог, затем формируют бэклог спринта и дальше их выполняют.

В начале каждого спринта проводится планирование. Раздельно во всех командах. Возникает вопрос: «Что с координацией общих целей?» Существует общее планирование на уровне владельцев продуктов. Сюда приходят задачи, предварительно скоординированные между направлениями. Кроме того, нам нужна техническая координация, которая осуществляется несколькими способами.

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

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

Для составления плана проводится PBR (Product backlog refinement. — Прим. ред.). Разработчики оценивают задачи и помогают владельцам продуктов в составлении планов и их приоритезации. PBR может проходить как в одной команде, так и между несколькими командами. Иногда проводится планирование с внешней командой, если продукт подразумевает интеграцию.

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

Дальше каждая команда проводит свою ретроспективу, на которой обсуждают организационные вопросы. Если команда не может что-то решить внутри себя, то вопросы выносятся на межкомандное retro. Проводим мы его раз в две недели и решаем то, что касается всех команд, всего офиса и всего продукта. По результатам retro за каждой задачей закрепляется ответственный, который сможет её решить или проследить за её решением, если это зависит от внешних служб. К следующему retro или Master Sync ответственные рассказывают, что они сделали или не сделали, по каким причинам, какие обнаружились преимущества и недостатки.

Расскажи о какой-нибудь неожиданной, нештатной ситуации.
Нештатные ситуации бывают, но всё реже и реже. Например, однажды у нас на сайте перестал работать весь JS на десктопе. Самое главное было найти причину проблемы и решить её. Если говорить научными терминами, то мы прибегли к Andon-методологии: остановили все процессы, вся команда занялась поисками причины. Нашли достаточно быстро. Больше времени потребовалось на решение проблемы.

В чём же была причина?
Еще немного подолью масла в огонь. Во фронтенде мы ничего не обновляли. И почему всё сломалось, никто не понимал. Но сломалось сразу везде. Оказалось, что мы зарелизили небольшой служебный инструмент, который за собой подтянул стороннюю JS-библиотеку, в которой была ошибка. Эта библиотека сразу же заменилась во всём коде. В результате JS посыпался. Никто не ожидал, что совершенно посторонний инструмент в админке системы управления может всё сломать.

Ты упомянул Andon-методологию. Что это такое?
У всех есть какая-то специализация. Я технический директор, есть фронтенд-разработчики, мобильные разработчики, системные администраторы, DevOps и т.д. Казалось бы, если я C++ программист, то буду писать на С++. Но если во фронтенде сломался JS? «Что такое JS? Что-то непонятное из гуманитарных наук, не буду я это делать. — А я вообще системный администратор или DevOps. Я вообще ни при чем, тяните сами свой JS».

Andon была разработана для того, чтобы таких ситуаций не возникало. У нас сломался проект, он наш общий. Мы все начинаем искать, где сломалось. В описанном мной случае причину нашел обычный бэкенд-разработчик, который просто сел и начал искать, не рассказывая, что он не пишет на JS, что он чего-то не знает. То есть Andon заключается в том, что все бросают дела и начинают решать проблему по мере своих сил.

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

А сейчас у вас есть Docker в production?
Да.

То есть вы активно перешли на Docker и пользуетесь им?
Это одно из основных направлений нашей работы.

Как впечатления?
Хорошо. Я даже не знаю, как бы мы жили без этого. Раньше у нас был PHP — катнем скрипты, и понеслась. А сейчас без контейнеров жить нельзя никак.

Ты, как технический директор, занимаешься «здоровьем» команды. Расскажи немного про это.
Одно из основных моих качеств: я люблю слушать людей. Пытаюсь поставить себя на их место, это даёт возможность понять их настроение, проблемы, почему они принимают те или иные решения, почему так себя чувствуют. И это помогает мне найти правильный выход из ситуации, принять правильное решение. Для меня крайне важно «здоровье» команды, «самочувствие» каждого человека: хорошо ли ему, комфортно ли в команде, к каким целям он движется, чего хочет достичь.

Однажды разработчик в личной беседе сказал: «Раньше я мечтал стать техлидом или техническим директором, чтобы получать больше денег, иметь власть и так далее. Сейчас я работаю в плоской структуре, у нас нет техлида. Зато есть технический директор, который выполняет менеджерские задачи, а технические решения принимают разработчики. Куда мне стремиться? Как мне жить? Жизненные принципы сломаны. Куда дальше идти, непонятно».

Постепенно я понял, что дело не в этом. Человек должен быть счастлив. Задачи, которые он выполняет, должны ему нравиться. И он может выбирать их себе. Карьерная лестница даёт финансовый рост, но его можно достичь и по-другому: ты решаешь более сложные задачи, помогаешь другим, твоя команда работает быстрее, вы быстрее поставляете сложные фичи. Вот тебе и карьерный рост, растет зарплата, ставка. Изменения в трудовой книжке вторичны. Работаете хорошо — получаете от этого наслаждение. А если это будет положительно сказываться на продукте, то и зарплата будет расти, и должность в трудовой книжке изменится.

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

Бывает и наоборот: человек объясняет команде, как нужно что-то делать, и команда его признает. Это самые лучшие тимлиды. Если хочешь стать тимлидом, ты им будешь. А если не хочешь, то и не будешь.

Ты говоришь, что любишь слушать разработчиков, приводишь много примеров, когда они тебе что-то рассказывают. Но разработчики обычно интроверты, вытащить из них слово иногда бывает сложно. Как ты с этим справляешься? Как разговорить разработчика?
Все интроверты. Все ненавидят людей. Не в этом суть. Мы же вместе работаем. Я стараюсь периодически беседовать с людьми один на один. Это крайне полезно — получить обратную связь. Однажды я не мог понять, что происходит с человеком. Тогда мы договорились, что будем встречаться раз в две недели и разговаривать. И после этого всё пошло на лад. Я рассказываю, что не нравится мне, он рассказывает, что не нравится ему. Мы находим общие точки, принимаем решения, обсуждаем, что дальше будем делать вот так. И двигаемся вперед. Это очень хорошо работает. Надо больше общаться.

Наш небольшой блиц-опрос. Какую ОС выберешь?
Mac OS.

Какое лучшее IDE?
JetBrains.

Последнее приложение, сайт, стартап, который тебя впечатлил?
Мобильный банк от «Тинькофф Банка».

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

Еще вчера тенденцией было mobile first. Сегодня machine learning first. Что будет завтра?
На одном тренинге рассказывали, что есть специальные люди, которые определяют, что будет завтра, даже рисуют по этому поводу карты и продают их за деньги. Машинное обучение это некий хайп. Также есть big data, виртуальная реальность, нано- и биотехнологии. Я видел подобную карту: этакий клубок запутанных связей, которые двигаются в разных направлениях. Предсказания на уровне астрологии. Я бы сказал, что завтра будет не machine learning, а big data. О любом человеке, который выходит в интернет, уже известно очень много. Надо только научиться правильно это использовать. Эти знания собираются, обрабатываются, являются источником дохода.

Когда тебя заменят роботы?
Можно сказать, что уже заменили. Я купил себе робот-пылесос.

В чем оцениваете таски: в часах или в Story Points?
И в Story Points, и в часах. Кто как хочет.

Что последнее ты не смог себе позволить?
Subaru Ascent.

Сколько у тебя биткоинов?
Ноль.

Не интересуешься этой темой?
Это хайп.

Что твои друзья чаще всего спрашивают про am.ru?
Когда мы захватим мир.

А когда?
Скоро.