Юрий Тюрин: Навыки и путь CTO

Юрий Тюрин

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

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

Есть простое определение: технический директор, CTO (chief technology officer) — человек, отвечающий за всю технологическую сторону компании. Но в реальности должностные обязанности такого человека в разных отраслях будут значительно отличаться, особенно в компаниях, где ИТ не является основной деятельностью (обычно в таких компаниях должность называется CIO — Chief Information Officer, ИТ-директор).

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

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

Если попробовать обобщить обязанности, то получится такая картина:

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

Как видите, CTO — это довольно разносторонний специалист.

Расскажи про свой карьерный путь?

Стандартный карьерный путь CTO выглядит так: Developer — Team Lead — CTO, по нему я и шел.

Свою карьеру в МД Аудит я начал Java Backend-разработчиком 8 лет назад, в 2014 году. Тогда это была ещё другая компания, которая занималась заказной разработкой мобильных приложений и информационных систем. Проекты, над которыми мы работали, были сложными и разнообразными, что позволило мне за несколько лет значительно развить свой кругозор: помимо того, что отлично выучил Java, даже получил два сертификата Oracle (OCA и OCP), я успел получить опыт в проектировании катастрофоустойчивых систем, построении DevOps CI/CD пайплайнов, разработке Web (Angular/Vue) и мобильных приложений, реализации множества интеграций. Так, шаг за шагом я становился экспертом в своей области.

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

Показав свою эффективность при работе с одним джуном, я начал пробовать внедрять улучшения процессов в другие команды: организация эффективного Code и Design Review, пересмотр взаимодействия с другими отделами (Sales, Marketing). Не всё срабатывало с первого раза, некоторые улучшения давали отрицательный результат, но я не сдавался — делал выводы и пробовал снова. Вся эта активность привела к тому, что я стал сначала тим-лидом команды Backend-разработки, а затем и руководителем департамента, который включал команды мобильной и веб-разработки, тестирования, аналитики.

После получения должности руководителя департамента я знал куда стремиться, и что для этого нужно. Я начал детальнее изучать как работает наш бизнес: откуда мы получаем прибыль, на что тратим деньги. Это мне позволило переориентировать свое мышление с техники на бизнес — я начал смотреть на задачи не только с точки зрения того, какие технологии использовать, но также сколько денег это решение будет стоить компании и какую пользу оно принесет. И в один прекрасный день наш, на тот момент, CTO и по-совместительству Co-Founder решил, что я готов к этой должности, и отдал мне свое место, перейдя на другой проект.

Вот примерно так я стал CTO.

Что конкретно ты делаешь в своей компании?

Компания МД Аудит занимается разработкой одноименного ИТ-продукта, так что значительная часть моих обязанностей связана с ним.

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

Какие навыки помогли тебе добиться своего положения?

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

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

• оценить убытки, которые приносит данная проблема;
• проработать несколько вариантов решения, сравнить и подготовить обоснование, почему конкретно это решение лучшее.

Важно! Даже вынесу это в отдельный абзац. Нужно сделать так, чтобы предлагаемое решение тратило минимальное количество ресурсов руководителя. Если для решения проблемы руководителю придется самому потратить X дней, либо идти к своему руководству и выбивать дополнительное финансирование, то с большей вероятностью он откажется от этой затеи. А вот если вы предложите решение, которое может быть и менее оптимальным, но вы сможете сделать его сами, а руководителю всего только и нужно, что дать разрешение, то она, скорее всего, будет одобрена, а вы сможете показать себя.

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

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

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

Какие минусы должности CTO?

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

Для всех уровней понятен набор навыков, которыми должен обладать сотрудник:

• для уровня Middle нужно решать задачи без помощи наставника;
• для Senior — надо отлично знать свою сферу;
• для тим-лида — уметь управлять командой,
• для CTO — разбираться в бизнесе.

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

Второй минус — максимальная ответственность. Теперь ты самый главный (ну, почти), и все решения остаются за тобой. И как мы помним: «С большой силой приходит большая ответственность». Так что за все, даже самые маленькие ошибки, придется отвечать тебе. Упал прод — ты виноват, сделал недостаточно отказоустойчивую архитектуру. Команда не успела в сроки — снова ты виноват, недостаточно оптимизировал процессы. Конечно, не бывает достижений без ошибок, поэтому нужно учиться с ними работать, и это поможет справиться со стрессом ответственности.

Что бы ты посоветовал людям, желающим стать CTO?

Основной совет: научиться ориентироваться на бизнес, а не только на техническую сторону работы

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

Разработчик, обычно, начинает ругать бизнес за то, что приходится писать неподдерживаемый код, который потом рано или поздно придется переписывать. Ведь время, потраченное на разработку «плохого» кода и на его последующее переписывание будет значительно больше, чем если сразу написать «хороший» код. Так почему сразу не потратить больше времени, но сделать хорошо — бизнес же сэкономит на этом! Логично? Да, но только с одной стороны. Если разработчик, делая хороший код, не уложится в сроки, то бизнес может потерять значительную прибыль, и проект вообще может закрыться, и, получается, что его «хороший» код никому и не нужен.

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

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

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

Второй совет: расти «вширь», развивать кругозор

Знания CTO должны охватывать множество областей, помимо самого кода: общение с командой, руководством и клиентами, юридические вопросы (увольнение), финансы (расчет затрат на команду/инфраструктуру) и т.д. Почему это важно? Как то раз, смотря очередной макет от дизайнера, я понял, что не могу сформулировать, почему мне не нравится предложенный вариант. Вроде дизайнер учел все требования ТЗ, но выглядело это как-то «не так». Я понял что такие пробелы в знаниях снижают качество моей работы, и на следующий день я записался на полугодовые курсы по UI/UX дизайну, чтобы говорить с ними на одном языке.

Третий совет: научиться адаптироваться

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

В такой ситуации можно, конечно, ругать вышестоящий менеджмент: «Почему они не могли предусмотреть это заранее?». Но в бизнесе такие моменты практически неизбежны, так что в такой ситуации нужно сделать выводы и идти дальше.

Четвертый (последний) совет: рассказывать про свои достижения, не стесняться этого

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

Тогда я изменил подход — помимо перечисления проектных задач, я стал рассказывать про любые, даже незначительные достижения себя и своей команды. Причем не просто так, а используя шаблон «Что сделали — Какой профит получили». Пример: «Внедрили библиотеку X. Это позволит в дальнейшем сократить трудозатраты на разработку похожих задач на Y процентов». После первой встречи, в которой я применил такой подход, руководство изменило отношение ко мне и к команде — мы стали получать похвалы и первыми выдвигаться на премии. А мне это в итоге помогло пойти выше по карьерной лестнице и стать руководителем департамента разработки.

Вместо заключения

Большое спасибо Юрию за такие подробные ответы на вопросы. В самом конце хотелось бы обратиться к разработчику, который только что прочитал статью. Надеемся, что этот рассказ о нюансах работы CTO поможет понять: нужно тебе стремиться сюда или нет. И если ты хочешь пройти такой же путь, как Юрий, то смело иди вперед. У тебя есть для этого вся нужная информация, осталось только приложить усилия, и все получится.

Автор: Александр Миронов