— Алексей, давайте начнем наш разговор с того, какими базовыми навыками нужно обладать, чтобы развиваться в вашей сфере?
— Могу выделить несколько принципов, которые считаю базовыми и важными для развития в целом. Путь долгий, так как развитие в IT требует постоянного обучения, которое будет длиться всю жизнь. Поэтому, чем раньше выработаешь верные привычки, тем быстрее будешь двигаться и расти.
Стратегия по расширению зоны комфорта. Я считаю, что мне очень помогала стратегия «собрать разный опыт». Я начинал с работы в одной из самых больших IT-компаний — mail.ru (VK), где познакомился с культурой «профессиональной» разработки. В ЦИАН я пришел в период активного роста продукта и технической команды и получил возможность брать на себя больше ответственности, делать проекты целиком, а также учиться хорошему менеджменту у руководителей разработки. Затем в стартапе Hotelchat я получил в распоряжение «всю песочницу» и смог применить на практике все, чему учился до этого. Допускаю что далеко не всегда легко продумать наперед свой путь, но я мог бы однозначно рекомендовать периодически вытаскивать себя из зоны комфорта, если хочется расти.
Постоянство в любопытстве. Очень полезно задавать вопрос «как это работает» и периодически проверять себя на «иллюзию знаний», когда ты думаешь, что знаешь, как что-то работает, но при попытке это объяснить — встаешь в тупик. Умножая это на долгую дистанцию — ты либо будешь все больше оперировать черными коробками и терять понимание системы, либо обретешь широкий кругозор.
Фильтруйте знания, которые вы в себя загружаете. Базовые знания вечны и более важны для роста. Хорошие книги в вашей предметной области могут выпускаться раз в несколько лет — и изучение уже не новой, но хорошо построенной книги может оказаться в разы полезнее бесконечного просмотра мнений и лент в Твиттере.
Прислушиваться к своим ощущениям и желаниям. Искать свой «икигай» полезно, как и даже просто знать о таком термине. Ищите свой путь, так как на шаблонных путях больше конкурентов, а без удовольствия от каждого этапа может пропасть и мотивация идти дальше. Мне вот очень нравится понимать, как что-то работает целиком, и как строить что-то большое и полезное, нравится оптимизировать и искать полезные проекции между знаниями в разных предметных областях. Если бы этого интереса не было, я бы вряд ли я захотел и смог потратить столько времени на изучение процессов и технических систем.
— Расскажите, как эксперт: как работает программный слой и как научиться решать задачи от данных до UI, чтобы дорасти от frontend-разработчика к full-stack?
— Здесь есть три минимальных и очевидных области для изучения: сеть, бекэнд и базы данных. Ведь приложению нужно передавать данные, их нужно обрабатывать по какой-то логике, а также где-то хранить.
Имея фундамент javascript / typescript, минимальным порогом входа в бекенд будет платформа NodeJS, поскольку язык не изменится, но расширится контекст его применения. Стоит разобраться в основах — как этот рантайм поверх движка V8 в целом работает, в чем суть его event-driven архитектуры и non-blocking I/O модели. Далее можно выбрать любой популярный фреймворк (Express.js, Koa, Fastify) и изучить на его.
Следующий этап — основы по базам данных. Принципы проектирования сущностей в базе данных и выполнения CRUD (create, read, update, delete) операций над ними, ACID-характеристики, индексация данных, отличие реляционных от нереляционных баз данных.
В результате этого перехода вы должны уметь создавать:
— Какое значение на данном пути имеют devOps, архитектура и System Design?
— Я бы сказал, очень значительное. Это еще одна большая и важная область. Из необходимых навыков в ней можно выделить контейнеризирование приложений, построение CI/CD процесса по непрерывной проверке качества и доставке новых версий приложения до пользователей, системы оркестрации контейнеров (docker swarm, kubernetes).
Алексей Шевцов
Здесь базовая цель — понять как ваше приложение развернуть в облаке, поддерживать его стабильность и незаметно для пользователей и надежным образом обновлять его до новых версий.
Архитектура и System Design помогают проектировать систему и решать задачи верным способом. Как и с архитектурой в любой другой предметной области — от устройства организмов до проектирования городов — в цифровом мире есть конкретные типы систем, для которых уже есть проверенные способы решения.
— Можете привести пример из вашего опыта, как вы работали над решением этих сложных задач?
— В онлайн-редакторе документов mail.ru (VK) у нас было монолитное приложение, в котором было большое количество абстрактной логики, и команда в разные моменты времени очень верно инвестировала время в разные архитектурные вопросы. Мы вкладывались в мощную систему автоматического тестирования верной отрисовки docx-документов, чтобы быть уверенными в том, что каждый новый функционал не ломает отрисовку. После появления react, typescript и flux архитектуры мы инвестировали силы в их внедрение. Спустя некоторое время, проект окреп и позволил развивать его еще быстрее, так как стал проще для понимания и сам помогал отлавливать баги в коде, связанные с типизацией.
Здорово работала микросервисная архитектура сайта ЦИАНа, где я работал старшим разработчиком. Команда в то время росла кратно год от года, и за разные страницы, куски продукта, вертикали отвечали разные команды. Меньшая зависимость разных сервисов друг от друга, в отличие от монолита, позволяла командам параллельно делать множество проектов, выкатывать и тестировать их, и минимально затрагивать работу других команд.
— А как грамотно перейти от разработчика к техническому менеджеру?
— Переход от разработчика к техническому менеджеру предполагает, что теперь ты строишь систему, которая решает проблемы.
Это значительный сдвиг, включающий в себя изменение обязанностей. Теперь нужно мыслить не только в категории «техника», но и управлять процессами, людьми и проектами. Техническая экспертиза все еще остается важной, но потребует новых навыков.
Команда. К каким целям двигается команда, как и чем она мотивируется — важные вопросы, на которые теперь ты должен знать ответы. Возникает конфликт — твоя задача помочь его решить. Теперь тебе важно подавать пример команде и становиться для них помощником и примером.
Проекты/продукт. Оценка и планирование проектов, распределение ресурсов, ответственность за следование графику, управление возможными рисками, обеспечение качества — этому также придется уделять время тебе как менеджеру команды.
Процессы. Здесь снова работает принцип непрерывного улучшения. Ты постоянно ищешь способы ускорения процесса, повышения качества и производительности.
Коммуникация. Крайне важно развивать межличностные навыки и софт-скиллы, так как предстоит и общение со своей командой, и плотное взаимодействие с представителями других. Без эмпатии не получится понять людей и помочь им быть эффективными и расти вместе.
Стратегическое мышление. На чашах весов при принятии технических решений теперь лежит больше камней: цели бизнеса и продукта, техническое развитие платформы, контекст твоей и соседних команд. И твоей важной задачей является формирование верного вектора движения, чтобы балансировать все эти составляющие.
— Давайте представим, что мы прошли все эти важные шаги и стали техническим менеджером. Есть ли, куда расти дальше?
— Конечно, от технического менеджера можно дорасти до CTO и отвечать за общий результат и строить систему силами своих менеджеров.
У CTO похожие зоны контроля, но шире контекст — он должен принимать решения, заботясь обо всей компании и всех командах. Стратегическое принятие решений, исследование новых технологий, определение их ценности для бизнеса, стимулирование инноваций в команде, управление бюджетом, оценка ROI технологических инициатив, и соответствие технической стратегии долгосрочным целям бизнеса, лидерство в масштабе, управление несколькими командами, техническими менеджерами, коммуникация с другими руководителями продукта и бизнеса, широкая техническая компетенция, — все это необходимые качества для хорошего СТО.
На этом уровне важно уметь ставить верные задачи нужным людям. Задачи по степени своей неопределенности можно разделить на 4 типа — выполнить алгоритм, решить задачу и достичь цель, устранить проблему, найти возможность или избежать проблему. Младшим разработчикам или новым членам команды корректно выдавать простые задачи, решающиеся по четкой последовательности шагов, алгоритму. Старшие разработчики должны решать задачи и достигать цели, самостоятельно предлагая разные алгоритмы решения и выбирая верный. Лидер команды должен уметь решать проблемы по типу: сайт стал медленно работать, поиск плохо ищет, команда не укладывается в сроки. Наконец, руководитель разработки должен предвидеть основные будущие проблемы и готовиться к их решению. В сумме здесь мы уже строим систему для других систем и организм из команд.
