В русском IT до сих по не могут сойтись во мнении, что такое техдир. HR говорят одно. Бизнес-управленцы — другое. Разработчики видят третье. Тестировщицы просто падают в обморок.

И только техдиры тихонько управляют процессами и посмеиваются в усы. Им не до споров — без них проект с большой долей вероятности развалится.

Мы уселись за живительные две чашки капучино с Иваном Елизаровым, техническим директором, который оттрубил 10 лет от звонка до звонка, — и взялись за вопросы, которые обычно техдиры обходят стороной, например, «Как стать техдиром?»

Сферический конь в вакууме в центре всех процессов

Есть много трактовок, что такое «техдир». IT-специалисты понимают по-своему. HR видят совсем по-другому. У бизнес-управленцев ещё один взгляд на эту роль в компании. Как вы сами считаете, кто такой техдир? Какая у него роль в компании? И почему без него невозможно обойтись?

«Без СТО невозможно обойтись» — это не аксиома. Каждый сотрудник компании должен приходить не для заполнения пустоты в штатном расписании, а для решения конкретных задач. На мой взгляд команда (подразделение) до 7-8 человек вполне справится без CTO при условии, что её работа выстроена согласно Agile парадигме, в её составе работают ответственные сотрудники и среди них есть настоящий, то есть пользующийся общим уважением, teamlead.

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

В компаниях с более распространённой «каскадной» системой управления CTO становится «единым окном», через которое любые иные подразделения и руководство могут общаться с загадочными и таинственным миром IT-специалистов. В такого рода компаниях с жёсткой структурой CTO в принципе незаменим, как человек, умеющий превращать воду в вино.

Быть CTO значит быть ответственным за создание комфортных условий для подразделения, за выбор и поддержание правильного пути развития. Вообще мне больше нравится восприятие должности именно как технический директор, в котором директор – производная от direction, то есть иными словами человек, ответственный за направление развития.

И, разумеется, CTO – это первый, кто должен принимать на себя ответственность за любые неудачи своего подразделения. А вот успехи лучше делить на всех.

И опыт сын ошибок трудных...

Расскажите о вашем опыте технического директора. Какие запоминающиеся, интересные примеры задач и решений вам вспоминаются?

За более чем 10 лет в этой должности наша команда запустила не менее 100 проектов «от мала до велика». Какие-то были просты, над какими-то сидели ночами в течение долгих недель, где-то приходилось искать нестандартные решения – в общем типичная для современного мира картина. Поэтому выделить среди всех лет какие-то интересные с технической точки зрения эпизоды мне сложно. Но до сих пор люблю вспоминать один из наших самых старых проектов, кажется 2010 года, как пример известных слов «то, что не убивает, делает нас сильнее».

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

В проекте участвовала: промо-команда, путешествующая по городам России по определённому графику и маршруту, арт-директор (полностью взявший на себя всю визуальную часть сайта, отображающего путешествие промо команды), Flash-разработчик, 3D дизайнер, backend разработчик, я в качестве техдира (фактически в роли системного архитектора и проджект-менеджера), менеджеры, контент-менеджер и даже один из учредителей в роли примера для подражания — как можно не спать несколько ночей подряд.

Концепция проекта (Picnic High Five Tour) заключалась в том, что на сайте мы должны были визуализировать реальное путешествие промо-команды и делать это чётко по времени одновременно с передвижением команды. Визуальная концепция была утверждена прямо перед стартом тура, поэтому заранее удалось подготовить только бэкэнд.

Арт директор должен был собрать и скомпоновать для каждого города узнаваемые образы, оформив их в нужной стилистике, предоставить их 3D дизайнеру, чтобы он создал из двумерных объектов псевдо-двумерные для будущей интеграции в flash движок, построенный по 3 измерениям, а затем контент менеджер должен был получить от промо-команды набор фотографий и видео (в 2010 году залить видео на хостинг из регионов было не всегда просто). Таким образом, каждое перемещение промо-команды в новый город сопровождалось определённой цепочкой действий, в которую были выстроены все задействованные коллеги: ожидание концепции следующего города, создание моделей по ней, подключение моделей в движок, выпуск анонса для аудитории, затем ожидание самого мероприятия, фото и видео материалов, выпуск обновления и далее по кругу до самого завершения тура.

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

Этапы самого себя

Как вы сами стали техдиром, какие вехи в профессиональном и карьерном развитии прошли?

Я начинал свой путь в 2006 году в качестве разработчика на Delphi + Firebird в тогда ещё молодом агентстве Grape, там же освоил PHP и PostgreSQL, писал на psql хранимые процедуры.

Но нравилось мне больше не кодить, а решать комплексные задачи, обсуждать с коллегами из других подразделений все нюансы, смотреть на задачу со стороны менеджеров и дизайнеров, а не только как разработчик. Поэтому, когда мой коллега из Grape, Павел Буриан вместе со своими партнёрами Николаем Степановым и Яном Оськиным решил основать новое агентство Pichesky и предложил мне с нуля создать отдел разработки, я согласился.

Так я стал формально CTO, хотя до фактического превращения в технического директора ещё прошло, пожалуй, пару лет.

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

Игорь Олемской, гендир Southbridge, рассказывал, что вы были первым крупным клиентом компании. Можете вспомнить, когда и как всё это было?

Да, я помню, разумеется. :) С Игорем мы так же познакомились в Grape, и он обратил на себя внимание тем, что вёл себя совершенно не так, как знакомые мне сисадмины: он не прятался от постановщиков задач (разработчиков и менеджеров проектов), а наоборот — шёл к ним с предложениями. Это было тогда удивительно для меня.

Помню, как Игорь безуспешно пытался провести выполнение своих предложений через старшего системного администратора, очень консервативного коллегу. Поскольку я тоже был открыт для изменений, мы с Игорем регулярно обсуждали его предложения, я делился своими мыслями. И в тот момент, когда я занял новую должность, Игорь предложил внедрить его идеи по инфраструктуре в нашей новой команде. Тогда я не слышал ничего про CI/CD, но фактически именно этим и был занят Игорь в 2008 году. Инфраструктура разработки была рассчитана на специфику производства проектов для рекламного рынка: быстрое производство, малый период поддержки (проекты жили в основном несколько месяцев). Основой тогда послужил Redmine и svn (в последствии заменённый на git). К слову, данная система с некоторыми изменениями до сих пор живёт в компании благодаря надёжности и простоте, а Southbridge всё-так же является постоянным подрядчиком услуг администрирования серверов Pichesky.

Кто такой вообще технический директор?

Дмитрий Симонов в интервью сформулировал, что «главное качество техдира — это привычка побеждать». А как бы вы сформулировали важные качества и навыки технического директора?

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

Что должен знать технические директора из сферы профессиональных знаний независимо от направленности деятельности компании?

Технический директор должен говорить на одном языке со всеми коллегами. Если тимлид предлагает ввести новые технологии в существующий стек, техдир обязан понимать принцип работы. Практически невозможно овладеть всеми технологиями, которые использует команда, но разбираться зачем и почему среди вашего инструментария есть та или иная технология — важно. Знать специфику работы творческих департаментов: дизайнеров, креативщиков, копирайтеров. Представлять, как строится работа у аналитиков и QA.
И среди самого главного: понимать задачи подразделения с точки зрения бизнеса, ведь все мы: от акционеров, до младших сотрудников работаем ради прибыли, кто бы что ни говорил.

Этапы жизни компании

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

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

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

В нашем случае расширение компании по сотрудникам было, если не ошибаюсь, почти двукратным (с 25-30 до примерно 70). Разумеется, это повлекло за собой много трудностей по реорганизации процессов, много новых людей нужно было вовлечь в существующую систему ценностей, режим работы. Это была сложная работа, особенно для самих учредителей компании.
В контексте отдела разработки было проще нарастить мощности. Я и ранее часто использовал фриланс, поэтому в момент роста просто перераспределил проекты в большей степени за счёт привлечения удалённых сотрудников. Так как мы имели свою отлаженную инфраструктуру разработки, больших трудностей мы не испытали — новые люди относительно быстро понимали наши принципы работы и ограничения.

Тайна, которая не тайна

И, конечно же, вопрос который волнует немало IT-специалистов: «Как стать техническим директором? Как вырастить себя для этой роли?»

Для начала нужно определиться — нужно ли это вообще именно вам. :)

С точки зрения дохода — высококвалифицированные разработчики сейчас могут зарабатывать намного больше некоторых CTO. С точки зрения амбиций — тоже большой вопрос. Ибо любой современный руководитель, а особенно руководитель в сфере IT должен обладать уважением среди своих коллег, иначе он становится просто формальным начальником, а не лидером. Добиваться успехов и признания можно на любой позиции.

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