Всем привет!
Меня зовут Иван Мясников, я CTO с 10+ летним стажем (серьезно, это не диагноз). Когда-то я был просто разработчиком, теперь руковожу разработкой и иногда даже понимаю, что происходит 😅

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

Если хочешь узнать, как остаться человеком, когда код снова не компилится — подписывайся, найдем ответы вместе!

#осебе

Сходил достаточно давно на подкаст, теперь есть где поделиться 😄
Поговорили про то, как общаться с коллегами на работе и вне работы, и в целом почему этот навык недооценивают, хотя все пытаются проверять софт скиллы. Доступно на ютубе и на других площадках

#спич

Мы довольно много сил в команде потратили, чтобы подружить swift и c++.. Понятно, что кейс узкий, но удивительно, что мы не нашли достаточной инфы не на одном языке (разумеется речь про английский/китайский), нас наверняка бы это ускорило 🙄
В итоге мы смогли и написали статью на хабре

#статья

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

#спич

Есть байка, что разработка трудится по принципу «работает, не трогай», но почему тогда мы все еще не продолжаем писать на перле?

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

Это позволяет создать надежный и качественный продукт в запланированные сроки (разумеется с оговорками, все-таки это не завод по производству деталей одного вида). Отсюда возникает вопрос, а зачем тогда пробовать что-то новое и эксперементировать, если есть проверенные годами решения?
Не обязательно в каждом проекте пытаться внедрить новый фреймворк или модный язык программирования, если не понятен бизнес велью. В этом подходе все зависит от конкретной задачи и ограничений. Если делаете стандартный продукт, который хорошо работает на старом стеке, не стоит изобретать велосипед, но и делать все ин-хаус тоже не лучшая затея при наличии опен-сорса.

Я советую отталкиваться от следующих критериев:
1. Есть ли у кого-то в команде опыт работы в новом направлении или все будут учиться вместе «с нуля».
2. Какую проблему мы решаем и почему это сложно (невозможно?) решить на текущем стеке, стоит поработать с аргументами за или против.
3. Есть ли время/ресурсы на ресерч и готова ли команда к тому, что часть идей и гипотез не выстрелит.
4. Точно ли мы сможем в итоге обучить или нанять специалистов, если поймем, что мы берем направление в эту сторону.

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

Часто использования проверенных технологий хватает, чтобы решать большинство задач, но не стоит забывать, что разработка — это постоянное обучение и рост над собой, соответственно эксперементы добавляют новые челенжи в команде и выводят ее из ловушки бронзовения 🧠

#софты

Метод карьерного маяка — подсвечиваем свои достижения и держим правильный курс 💱

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

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

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

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

#софты

У меня новая веха, был релокейт, не получалось найти время, но я вернулся и не с пустыми руками 😉

Как прокачать себя и команду

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

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

• В проекте технический долг неизбежен, особенно в условиях сжатых сроков, задача лида – не дать ему разрастись до уровня "снежного кома". Организуйте понятный флоу, каким образом собирается техдолг, а также регулярно обсуждать его с командой, выделяя время на его «оплату». Как вариант, заложить техдолг, как часть спринтов и определить порог, по которому вы будете понимать, что техдолг по оценке решаем за неделю/месяц, а не растет со страшной силой.

• Соблюдать сроки это важно, но необходимо еще держать качество на уровне. Ключевые метрики помогут вовремя увидеть узкие места – будь то Rework Rate, Сrashfree или Test Coverage. Попробуйте вместе с командой выработать метрики, которые помогут вам оценить и улучшить качество и стабильность проекта.

• Мы часто становимся связующим звеном между командой и другими доменами. Четкая коммуникация с коллегами и правильное распределение задач помогут избежать недопонимания и сделать приоритеты проекта более прозрачными. Поставьте регулярные синки со смежными командами, они помогают быть в курсе изменений и выстраивать работу над задачами на понятном всем уровне.

• Лид отвечает за продуктивность команды, поэтому развитие ее членов – одна из приоритетных задач. Давайте инженерам возможность проявить себя и помогайте с развитием их навыков. Даже если вы понимаете, что сделаете какую-то задачу быстрее самому, лучше научить коллегу, чтобы в будущем был еще один эксперт в этом направлении, а он потом подтянет других членов команды. Проводите регулярные 1-to-1 встречи, чтобы обсудить прогресс, трудности и зоны для роста, не бойтесь делегировать свои задачи, они позволяют сотрудникам прокачивать скиллы, и вы увидите, как растет эффективность всей команды.

Лидство – это баланс между процессами и людьми. Умение видеть за задачами реальных людей, а за результатами – реальный эффект на бизнес, поможет вам строить продуктивные процессы и поддерживать команду на высоком уровне.

Если у вас есть еще мысли на эту тему или я что-то забыл, поделитесь в комментариях под постом 😊

#софты