Поздним вечером генеральный названивает и требует, чтобы релиз выкатили через шесть часов — утром у него встреча с инвесторами в Китае. У разработчиков — в порядке важности для проекта — почесуха, отпуск, профессиональное выгорание, кружок макраме и пикет «зелёных» по защите прав морских свинок. Тестировщики уже разъехались по домам. Тимлид рыдает, как «девушка в автомате» — у неё дела сердечные. Офисный кот опрокинул вазу с водой на документы с мокрыми печатями. Релиз нужно выкатить с китайской и корейской локализацией. А ближайшие специалисты по языкам Азии — таджики в общаге через дорогу.

Вы вздыхаете и принимаетесь за работу. Через шесть часов всё работает. Релиз задеплоили. Генеральный доволен. Разработчики бодры, веселы и рады стараться.

Обычные будни техдира.

На Слёрме DevOps собралось немало технических директоров. После интенсива я поговорил с Эдуардом Медведевым об IT-этике, с Артёмом Галонским об исчезающих профессиях и DevOps. А ещё мне повезло познакомиться с уникальным техдиром-экстравертом, способным организовать, что угодно, и найти общий язык с кем угодно.

Дмитрий Симонов ctorecords, основатель Техдирского клуба и создатель канала «Записки Техдира», https://t.me/ctorecords, рассказал, как стать техническим директором, эдаким Jack of all trades в IT-сфере.

Дмитрий Симонов и голубая то ли лама, то ли альпака от eLama.

Карьера техдира

Ты ведёшь канал «Записки техдира». Как ты находишь время на это в круговороте техдирских задач? Что это для тебя: хобби, самореализация, IT-евангелизм?

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

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

Только что вернулся со Слёрма DevOps, где поднимал свою квалификацию. По менеджерской части я активно прохожу платные курсы — и часть мыслей из этих курсов попадают в канал.

Таким примером стали «Управленческие Задачки», https://t.me/ctorecords/1126. Это описание сложных ситуаций, которые нередко возникают в работе. Важно понимать, что в реальной жизни технический директор может оказаться на любой из описанных ролей. Его задача — суметь выбраться из сложившейся ситуации с максимальным выигрышем и наименьшими потерями. Критерий правильности решения заключается в исчезновении конфликта. Фишечка тут заключается в том, что почти всегда любая роль не бывает этически безупречной: либо генеральный директор хочет сэкономить на ком-то денег, или сотрудник хочет продать ресурсы компании, или ещё какая-нибудь муть творится.

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

Как ты сам стал CTO, какой путь прошёл? Какие наиболее важные вехи в пути ты можешь выделить? Что ты в процессе этого пути понял важного?

В 1995 году, ещё в университете, я пошёл работать «в интернет» — и с тех пор 25 лет всегда работал в одной и той же профессии. Шаг за шагом проходил стадии всех вариаций программистов, тимлидов и, наконец, дорос до техдира. Переехал в Москву и прошёл весь этот же путь заново второй раз — подтвердил навыки в Рамблере, Яндексе и Мейле. А уже затем начал строить собственные технические решения и команды.

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

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

NB: Основная задача техдира — найти общий язык со всеми, убрать противоречия, чётко обозначить условия победы и пути к ней. Замотивировать своим примером команду. Техдир — это капитан корабля.

IT-сообщество и клуб техдиров

Планируешь ли ты как-то развивать канал «Записки техдира». Другие платформы? Или книгу написать? У тебя там реальных историй, поучительных и забавных, уже на целую книгу.

Да, историй забавных поднакопилось много. Например:

Друзья занимаются интеграцией со службой доставки. Рассказали, что их API не принимает заказы после 21:00. Ни на завтра, ни на послезавтра, вообще ни на какую дату нельзя сделать заявку на доставку, если заявка происходит после 21:00.

Ооооооок. И такие чудеса бывают. 

На одном из прошлых моих стартапов собрались в 2014м году выкатываться в Индонезию. Продуктовая часть вроде бы была готова, добивали техническую.

Примерно за 2 недели до часа Х стучится ко мне в скайп наш Гениальный (время примерно  18:00 мск):
- Дим! Ну чё там по срокам?
- Всё норм, всё по срокам.
- Ты знаешь... Я тут в Джакарту прилетел, у меня завтра в 7:00мск презентация нашего сервиса местным министрам! Успеваешь?

OMG...  Ситуация - жесть полная. Но что-то же делать надо? Что у нас в наличии? В принципе действительно всё неплохо, надо пару мест подпилить - и выкатится без пары фич. Тогда преза получится норм. 

Договариваюсь со всей командой... Ну, как договариваюсь... Кому-то денег обещаю, кому-то отпуск, кому-то увольнение... Решили, короче. Собрались и начали жечь. 

Не хватает самой малости - листа текста А4 на индонезийском языке. Без него сервис не будет говорить на родном языке индонезийцев. И обойтись никак. Стучусь к Гениальному:

- Нужен текст на индонезийском!
- Ничем не могу помочь. Я даже на английском не разговариваю!
- Эм.... А ты сейчас где? В такси? Можешь попросить таксиста текст перевести с английского на индонезийский?
- Не могу. Он не знает никакого языка кроме индонезийского...

Ооооооооок! Чешу репу. Снова стучусь к Гениальному:
- А отели какие-то знаешь в Джакарте?
- Да! Хилтон!

Время уже где-то 00:30 мск. Чё делать-то? Терять нечего. Позади Москва. 

Звоним в отель, объясняем, что мы несчастные русские стартаперы, хотим осчастливить Индонезию своим стартапом, не хватает листа А4 на индонезийском. 

- Вот наш e-mail, присылайте текст, мы переведём!

Через 2 часа мы получили текст и запустились. 

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

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

О книге я задумывался и возможно даже в этом есть смысл, но я подожду, когда в ней появится явная потребность. Хочется, чтобы такое желание возникло «органически», а не путём какого-то пиара.

Как ты оцениваешь развитие IT-сообщества в России? В каких городах оно наиболее развито? Что ты считаешь критериями развития и становления?

IT в России (и не только в России) стал социальным лифтом, который поднял талантливых молодых людей до уровня не только мировых специалистов, но и просто хорошо обеспеченных людей. Лифт настолько эффективный, что некоторые бравируют не столько своими успехами, сколько успехами, достигнутыми благодаря общему хайпу.

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

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

Что же им нужно? Что нужно этим специалистам, попавшим в описанное Жаном Бодрийяром общество потребления?

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

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

Закрытый Техдирский Клуб стал ответом на запрос группы высокопрофессиональных айтишников уединиться в место, где они смогут обсуждать наиболее щепетильные вопросы, и чтобы при этом не отвлекаться на мнения джунов/пионеров. Дело в том, что настоящие «шахматисты» просто устали от многочисленных Остапов Бендеров, которые вместо реальных обсуждений постоянно саморекламируются и проталкивают мысли в стиле «Шахматная мысль, превратившая уездный город [Нью-Васюки] в столицу земного шара, превратится в прикладную науку и изобретет способы междупланетного сообщения». Очевидно, что профи из разряда авторов Котлина, Тарантула или Постгреса интересуют вещи вполне конкретные и чёткие. Эти парни сфокусировали все свои устремления и цели в жизни на профессиональную направленность.

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

Темы пока поднимаются довольно узкотехнические — я изредка делаю выборки цитат. Одна из опубликованных в публичном канале — вопросы по техническому процессингу логов.

В ближайшее время, насколько я знаю, ты планируешь выступать на митапе. Расскажи подробнее, о чём будешь рассказывать, какие проблемы разбирать.

??Да. 9 октября в 19.00 в офисе SkyEng будет Team Lead Meetup по управлению командой и знаниями от тимлидов-практиков. Трансляция по этой ссылке: https://youtu.be/Y9Sxg14pads

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

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

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

Команда топов требует точные сроки и оценки по ресурсам при минимуме точных формулировок для технической команды.

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

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

«День Техдира» в Питере 3 сентября удался. Планируешь развивать это мероприятие? И почему именно 3 сентября, когда «все переворачивают календари»?

День Техдира прошёл очень ударно — зарегистрировалось более ста человек, среди которых были генеральные и технические директора, руководители команд, архитекторы, продакты и проджекты. Удивительно, что из приготовленного запаса пива и лимонада очень хорошо как раз разошелся лимонад, а пива больше половины осталось. Ещё один стереотип можно выбросить.

Праздник проходил синхронно в Санкт-Петербурге в Селектеле и в Москве в Скайенг. Мы устроили полноценный видео-мост между столицами и поздравили друг друга.

По результатам договорились не только проводить ежегодно День Техдира в столицах, но и распространить праздник на все города миллионники по типу франшизы. Сейчас собираем заявки на участие (пишите на dsimonov@gmail.com!)

Что такое техдир?

HR, которые выступали на Дне Техдира, неоднократно говорили, что очень трудно сформулировать, кто такой CTO, что за зверь, с чем его едят, и как на него охотиться и хэдхантить. Как ты сам определяешь, что такое техдир? И как развивалась эта профессия?

Техдир — это звучит гордо! С моей точки зрения техдир — это синоним слову «победитель», который верит в себя, верит в свою команду, верит в победу! И он побеждает. Не может не победить — в противном случае это не техдир, а просто возомнивший о себе невесть что разработчик. В этом главная его задача — побеждать трудности, убеждать коллег, реализовывать планы. Но самое главное — видеть свою победу и подробно в мелочах понимать, как она будет достигнута. Что такое мелочи? Это детали, значения которых техдир не понимает. Какой же это тогда Техдир?

В этом случае, каким бы профессионалом он ни был, он проиграет любую битву, сольётся и подробно-подробно расскажет акционерам, почему не получилось. С презентацией, отлично поставленной речью и обоснованием. А потом будет долго ходить по конференциям и рассказывать не о том, как строить проекты, а о том, как не надо их строить. Это будет профессионал того, почему проект не получится. Я периодически встречаю таких людей в пич-клубах. Их слова всегда начинают с «Сейчас я расскажу, почему у вас ничего не получится!»

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

Если бы ты выбирал техдира на параллельный проект, по каким бы критериям ты вёл отбор?

На HH по запросу CTO/CIO в Москве находятся многие сотни резюме. Если внимательно посмотреть профили, то на самом деле это wanna be CTO/CIO резюме. Бывшие руководители и менеджеры, которые хотят попробоваться в Chief должностях. То есть те, кто себя считает CTO или хочет им стать. Как среди этих многочисленных кандидатов разобраться, кто чего стоит? О чём их спросить?

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

   
   

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

   
   

3. Перечень самостоятельно запущенных проектов с урлами и описанием роли на проекте. Обязательно должно быть какое-то железобетонное доказательство действительности этой роли, а не просто «рядом постоял». Этот пункт про то, что кандидат привык свои проекты доводить до ума. Если такого скилла у него нет, он вполне может ему научиться — за ваш счёт.

   
   

4. Описание того, по каким принципам кандидат будет составлять таблицу фот с нарезкой по специальностям с оплатой фикс в месяц и/или почасовой оплатой. ФОТ всегда торпедируют и если у кандидата есть привычки по его формированию, значит, знает и какие бока прикрывать при торпедировании.

   
   

5. По возможности, примеры самостоятельно составленных документов. Например, стратсессии, расписанная фича с технической декомпозицией, куски ТЗ, документы по испытаниям, план графики, детальные план-графики и вот это вот все. Эти все документы, конечно же, являются коммерческой тайной или ДСП. Их в руки вам никто не даст.

   
   

Здесь важно убедиться, что кандидат привык работать с такими документами, имеет сноровку и ему не впервой. Это всё должно быть устоявшимся в его голове. Если он думает, как эти документы строить, а не строит — это показатель отсутствия опыта. Привычки, закреплённые на уровне автомата, ооооочень о многом говорят.

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

Самое важное, суметь по каждому кандидату понять, как он привык работать, что он делает «на автомате». Именно эти навыки он будет использовать в любых сложных ситуациях.

Есть ли точные должностные инструкции, параметры и критерии у Техдира или это мифический Jack of all trades?

Четверть века назад были мальчики-вебмастера. Потом появились мальчики-вебпрограммисты. Потом появились мальчики-фулстеки. В целом от мальчиков требовалось прийти и всё сделать. (смеётся) Сейчас таких мальчиков называют техническими директорами!

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

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

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

Но личность определяется тем, что способна сама задавать тенденции. Например, выпустить собственные плагины и доделки для известных систем мониторинга — заточенные под его собственные нужды.

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

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

Раз уж заговорили о профессиях, есть мнение, например, мне его высказал Артём Галонский из «Бюро-Бюро», что инженера DevOps не существует в природе, что эта новая профессия выдумана. И чаще всего такое самоназвание служит для запроса более высокой зарплаты на рынке труда, а на самом деле DevOps-инженер — всего лишь админ со отличным знанием Kubernetes. Как бы ты сам определил, что такое DevOps-инженер? Тебе уже приходилось нанимать такого сотрудника?

Мир разработки стремительно ускоряется на «последней миле», когда идёт сама реализация на уровне спринтов, но ранее существовавшие технические и организационные инструменты системного администрирования не могли с этим справляться и стали узким горлышком.

Разработчики (Dev) и админы (Ops) вечно устраивали взаимные бои друг с другом. Если возникала проблема, то Ops говорили, что в коде проблема, а Dev — что в настройках серверов.

Тогда и придумали методологию, для которой необходимо построение команды таким образом, чтобы Dev и Ops на регулярной основе обменивались опытом по разработке и сопровождению проекта. Она обеспечивает командное решение задач по поддержке и развитию разработки и доставки программного обеспечения средствами многочисленных инструментов, обеспечивающих работу с кодом, сборками, тестированием, менеджментом артефактов сборки, релиз-менеджментом, конфигурированием, мониторингом и логированием.

На мой взгляд, для devops одного k8s мало, нужно понимать в архитектуре и разработке, уметь выстраивать надёжные системы и деплой, где нужно, писать код и разбираться в нем, хотя бы немного. Я с интересом смотрю на учебные курсы Слёрм, обучающие DevOps и SRE-инженеров, но пока сам предпочитаю пользоваться не услугами одиночек, а работой команд. Это связано с тем, что команды из центров компетенций дают гарантию стабильности моей инфраструктуры при цене одного-двух инженеров.

На it-рынке порой появляются «модные», «хайповые» профессии, которые существует один-два года — и исчезают. Когда-то, лет пять назад все компании ринулись искать специалистов по настройке Jira, потом, года три назад все решили, что невозможно работать, если в команде нет scrum master. Как сейчас чувствуют себя эти профессии? И не ждёт ли через пару лет то же самое DevOps-инженеров?

Специалисты по Jira и Скраму сформировали своё небольшое сообщество и я, кстати, регулярно заказываю у них какие-то услуги. В зависимости от глубины проработки они зарабатывают больше или меньше денег.

Devops скорее всего расслоится на суб-специальности и в таком виде возможно даже поглотит часть специальностей по разработке.

Как стать техдиром?

Я видел, что в твоём канале часто новички задают вопрос, как стать техдиром. У тебя есть рецепт?

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

Конечно же, нужно обладать техническими навыками. Сейчас идут активно споры о том, из кого лучше получаются техдиры — из девопсов, из sre или разработчиков. Без таких знаний ничего не получится — просто не хватит знания матчасти, но бизнес ждёт от техдиров, кроме знания матчасти, ещё и бизнес-навыков, софт-скиллов и способности договориться со всеми. Где это всё приобретать? Я посылаю всех на турник — на биржи фриланса, где можно получить несколько десятков проектов и суметь их прожевать или самостоятельно, или в составе собственной команды.

На биржах фриланса тоже всё очень непросто и там, как сейчас принято говорить, своя атмосфера. Очень жёсткая конкуренция, при которой фрилансеры со всей страны вкладывают по 10-30 тысяч в месяц на собственную рекламу, чтобы получать заказы. Я честно всех предупреждаю, несколько раз проговариваю, что просто не будет, так как теория — это одно, а практика — совсем другое. Это единственный неиссякаемый источник выбора моря задач. Там можно брать заказы для самопальных команд. С конкуренцией они либо справятся, либо недостойны стать техдирами.

Конечно не все готовы идти на биржи фриланса и ковыряться с задачами вида «сделайте мне за 10 тыр клон профи.ру», а некоторые выросшие техдиры туда заглядывали мельком. Но это таланты, которые своим путём пришли, увидели и победили. Этому предшествовала огромная тяжёлая работа, которая даёт понимание о спектре трудностей, связанных с идеями, людьми, софтом и техникой.

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

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