Многие хорошие программисты и разработчики со временем дорастают до позиции CTO (в российской терминологии – технический директор). Но при этом, дойдя до этого уровня и отвечая в целом за продукт, они продолжают писать код. И тогда возникает вопрос: целесообразно ли одному из топ-менеджеров компании тратить на это время, не упускает ли он при этом более важные задачи? О том, стоит ли CTO продолжать писать код или лучше сосредоточиться на менеджменте, в своей авторской колонке для портала Biz360.ru рассказал сооснователь платформы по поиску репетиторов Preply Дмитрий Волошин.
Дмитрий Волошин – сооснователь и СТО международного маркетплейса для поиска репетиторов
Preply. Образование: Киевский национальный университет им. Тараса Шевченко. У Preply три совладельца: Дмитрий Волошин, Кирилл Бигай и Сергей Лукьянов. Проект запущен в 2012 году, на данный момент на сервисе зарегистрировано около 50 000 репетиторов и порядка 350 000 учеников по всему миру.
Меня зовут Дмитрий Волошин, я CTO EdTech-маркетплейса Preply. Хочу поделиться своим опытом и размышлениями о том, как это – программировать, будучи на позиции СТО: нужно ли это вообще, как удавалось совмещать несколько функций, что это даёт в работе с командой и в какой ситуации лучше делегировать написание кода.
- CTO (англ. Chief Technology Officer) – один из руководителей компании, отвечающий за разработку новых сервисов или продуктов, оптимизацию производства, поиск новых технических решений. Соответствует российскому «технический директор», «технологический директор» или «главный инженер».
На мой взгляд, роль СТО отличается в зависимости от размера компании. Я был СТО, когда у нашей компании ещё не было других разработчиков, кроме меня. Понятно, что тогда я писал код. Пока команда состояла из пяти-десяти разработчиков, я продолжал это делать. Когда же их стало больше, я сосредоточился на более стратегических направлениях – people-менеджменте и архитектурных вопросах.
На мой взгляд, если в подчинении СТО находится 20 человек, и у него при этом ещё есть время писать код, то это означает, что он фокусируется не на стратегических вещах, а занимается операционными задачами. Это не самый эффективный способ использовать время.
Если говорить о том пределе развития компании, когда СТО должно прекратить писать код, то для меня есть два основных показателя. Первый – когда организация разбивается на команды. Обычно в стартапе на первых этапах развития есть одна команда, лидером которой является СТО. Когда нас стало 20, мы разбились на три-четыре продуктовые команды, в каждой из которых появился техлид. Это важный этап, когда СТО следует отделиться, делегировать техническую часть техлидам.
Второй показатель – команда достигла такого уровня, что ей уже можно доверять самостоятельно отвечать за продукт. Здесь нужно, чтобы в команде был подходящий специалист, кому можно было бы делегировать свои функции. В идеале это должен быть человек, разбирающийся в технической части лучше, чем ты сам. Ему не страшно доверить продукт.
В нашей команде это происходило органично: у меня оставалось всё меньше времени на кодинг, и я постепенно отошёл от этого. Затем код нужно было писать только время от времени, чтобы побыть с командой, почувствовать, какая «боль» в процессах, но это точно не ежедневная и даже не еженедельная активность. Для СТО гораздо важнее уметь читать код, чтобы держать руку на пульсе.
Когда я ещё кодил сам, у меня было немало фейлов, один из которых обошёлся компании особенно дорого. При этом следует понимать, что в нашей компании действует культура Blameless Postmortems, когда каждую ошибку, приводящую к инциденту в продакшене, мы анализируем и делаем из этого выводы на будущее. При этом никого не обвиняем.
Я был автором десятков «постмортемсов», то есть допускал десятки критических ошибок, которые потом влияли на результат работы компании. Но это неотделимая часть развития. Пока у компании нет достаточно отлаженных процессов по мониторингу, аллертингу, тестированию, то ошибок и инцидентов будет много. Не стоит этого стыдиться.
Я разбил бы свои факапы на два типа: архитектурные и практичные. Пример неправильного архитектурного решения – в начале проекта у нас не было линтеров, поэтому первые три года мы писали код не в консистентном кодстайле. Другой пример – неправильно задизайненная база данных, от чего мы страдаем до сих пор. Понимаем, что если бы я 8 лет назад постарался лучше, мы сэкономили бы десятки, если не сотни часов рабочего времени разработчиков.
Мои практичные фейлы заключались в следующем. Я самостоятельно дизайнил первые пеймент-интеграции, и однажды мы выловили так называемые race conditions (ошибка программирования многопоточной системы, при которой работа системы зависит от того, в каком порядке выполняются части кода). На практике это проявлялось в том, что один платёж мог дважды сняться с кошелька пользователя. Обнаружив это, мы начали глубже зарываться в то, как работают транзакции, локи и все, что с этим связано. Это были локальные баги, достаточно болезненные для компании.
Другой пример связан с миграцией, которой я руководил. В одной из первых баз данных мы не предусмотрели, как обновится версия для реплики, и поэтому получили 15-30-минутный даунтайм. Было очень досадно.
Но все эти ошибки – часть Learning Corp. Я как лидер инжиниринговой организации осознаю, что они помогли мне понять, как лучше построить процессы для того, чтобы эти же ошибки не допускали мои коллеги сегодня.
Себе тогдашнему я бы посоветовал больше времени уделить архитектуре базы данных, систематизации информации в монолите. Я бы писал больше тестов и сразу добавлял бы линтеры к коду. Возможно, в то время когда мы начинали продукт, уже был типизирован Python и стоило его использовать с самого начала. В определённый период, когда мы несистемно пробовали разносить продукт по сервисам и микросервисам, я понял, что микросервисы не самоцель и стоит либо не делать этого вообще, либо сразу это очень системно.
В нашей работе важно не забывать о бизнес-части – пользователях. Задача не только СТО, но и любого разработчика в компании, понимать, что код и язык программирования – это инструменты, с помощью которых мы решаем проблемы пользователей и стараемся принести им как можно больше пользы.
Код часто неидеален, в нём есть ошибки. Поэтому для меня лучший разработчик – это тот, кто может решить проблему пользователя, не написав ни строчки или минимальное количество кода.
Мы стремимся к тому, чтобы не только у менеджмента, но и у всех разработчиков был фокус на клиента. Одна из ценностей компании – это Customer Obsession, и кто-либо перед тем, как начать писать код, должен задать себе вопрос: «А как это повлияет на наших пользователей? Станут ли они счастливее? Что нам скажут данные A/B тестов нового функционала?».
Это продуктовая культура, которой не хватает многим компаниям постсоветского пространства. У нас есть с чем сравнивать – в нашей команде есть разработчики в Барселоне и Бостоне – и очень ощутимо, что на локальном уровне эту культуру ещё нужно развивать.
Может ли СТО кодить в команде, в которой более 20 человек, наверняка зависит от самого специалиста. Может быть, кто-то успевает сразу всё. Мне было бы интересно самому запустить продуктовый функционал, пофиксить баги, но у меня нет на это времени. Дома для себя я тоже не программирую. Для меня важно делать всё возможное, чтобы компания стала ещё более успешной – и для этого писать код необязательно.
Когда я прекратил кодировать, то получил больше свободного времени, а команда больше ответственности. Они понимают, что уже нет СTO, который проверит их код и укажет на ошибки. Разработчики на уровне команды должны следить за качеством принимаемых ими решений самостоятельно.
Чтобы не пропустить интересную для вас статью о малом бизнесе, подпишитесь на наш Telegram-канал, страницу в Facebook, аккаунт в Instagram и канал на «Яндекс.Дзен».
