Кодить нельзя управлять: должен ли СТО писать код или ему лучше сосредоточиться на менеджменте

«Когда я еще программировал, у меня было много файлов»

IT-инструменты, которые использует Дмитрий Волошин

  • 15 Пять
  • Вещи 3
  • Jira
  • Trello

Многие хорошие программисты и разработчики со временем достигают должности технического директора (в русской терминологии – технический директор). Но при этом, достигнув этого уровня и неся ответственность за продукт в целом, они продолжают писать код. И тогда возникает вопрос: а целесообразно ли одному из топ-менеджеров компании заниматься этим, не теряет ли он более важные должности? Дмитрий Волошин, соучредитель платформы репетиторов Preply, рассказал в своей колонке для портала Biz360.ru о том, следует ли техническому директору продолжать писать код или лучше сосредоточиться на управлении.

Досье

Дмитрий Волошин – соучредитель и СТО международного рынка репетиторских исследований Preply. Образование: Киевский национальный университет. Тараса Шевченко. У Preply три совладельца: Дмитрий Волошин, Кирилл Бигай и Сергей Лукьянов. Проект был запущен в 2012 году, в настоящее время около 50 000 преподавателей и около 350 000 студентов по всему миру работают в сервисе.

Разница между ролью CTO в стартапе и крупной компании

Меня зовут Дмитрий Волошин, я технический директор EdTech-маркетплейса Preply. Хочу поделиться своим опытом и мыслями о том, каково это программировать, быть в позиции СТО: это необходимо, как вам удалось совместить разные функции, что это дает в работе с командой и в какой ситуации это кодирование лучше делегировать.

  • CTO (Chief Technology Officer) – один из руководителей компании, отвечающий за разработку новых услуг или продуктов, оптимизацию производства и поиск новых технических решений. Соответствует российскому «техническому директору», «технологическому директору» или «главному инженеру».

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

Читайте также:  Производство искусственного мрамора

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

Когда техническим директорам следует прекратить программировать

Если говорить о пределе развития компании, когда АЗС должна перестать писать код, то для меня есть два основных показателя. Первый – когда организация делится на команды. Обычно в стартапе на ранних стадиях развития есть команда, лидером которой является АЗС. Когда нас было 20 человек, мы разделились на три или четыре продуктовые группы, в каждой из которых был технический менеджер. Это важный этап, на котором СТО должна отделиться, передать техническую часть техническим менеджерам.

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

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

Ошибки в должности CTO при совмещении административной работы с кодированием

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

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

Читайте также:  Тонкие материи: как молодая мама развивает бренд нижнего белья для кормящих женщин

Я бы разделил свои подделки на два типа: архитектурные и практические. Пример неудачного архитектурного решения: у нас не было линтера в начале проекта, поэтому в течение первых трех лет мы не использовали единый стиль кода. Другой пример – плохо спроектированная база данных, от которой мы до сих пор страдаем. Мы понимаем, что если бы вы попробовали это лучше 8 лет назад, мы бы сэкономили десятки, если не сотни часов рабочего времени разработчика.

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

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

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

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

Читайте также:  Развлекательный бизнес

Внимание заказчику программистов

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

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

Мы стремимся к тому, чтобы не только руководство, но и все разработчики были ориентированы на клиентов. Одна из ценностей компании – одержимость клиентами, и прежде чем мы начнем писать код, каждый должен задать вопрос: «Как это повлияет на наших пользователей? Будут ли они счастливее? О чем нам расскажут данные A / B-тестирования. Новые функции?».

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

Что получает команда, когда технический директор прекращает программировать

Сможет ли АЗС закодировать в команде из более чем 20 человек, вероятно, зависит от самого специалиста. Может у кого-то есть время сделать все сразу. Мне было бы интересно лично запустить функцию продукта, исправить ошибки, но у меня нет на это времени. Дома я тоже не занимаюсь программированием. Для меня важно сделать все возможное, чтобы компания стала еще более успешной, поэтому кодирование необязательно.

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

Кодирование нельзя контролировать: магазин должен писать код или сосредоточиться на управлении

По материалам biz360

Рейтинг
( Пока оценок нет )
pitovaxi/ автор статьи
Понравилась статья? Поделиться с друзьями:
Идеи малого бизнеса
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: