Записки CTO про код и карьеру

Я выложил свои скиллы для ведения базы знаний в опенсорс В прошлом посте я рассказывал, как перепоручил ведение базы знаний AI-агенту — собрал персональную LLM Wiki по мотивам заметки Андрея Карпати. Меня попросили поделиться навыками. Выкладываю. Репозиторий: github.com/anatoly-tech/obsidian-skills Внутри тири навыка: - compile — разбирает сырые источники из inbox/ в атомарные заметки, строит связи, обновляет MOC. - vault-health-check — быстрая проверка здоровья базы: битые ссылки, сироты, устаревшие заметки. - deep-audit — глубокий аудит: структура, связи, валидность утверждений и провенанс. Плюс всё, что делает их рабочими: правила ведения заметок (типы, теги, wikilinks, провенанс, язык), инструкции CLAUDE.md, шаблоны Obsidian и хук нормализации имён файлов. В репозитории есть живой результат работы его содержимого. Я прогнал compile на той самой статье Карпати. Она разложилась в 13 связанных заметок (саммари, definition notes, evergreen-тезисы, MOC). Можно открыть Obsidian и посмотреть в graph view, как источник превращается в вики. Пока это копия моей рабочей системы, а не готовый продукт. Берите как основу, адаптируйте под себя и расскажите как вам 🙂

Как я перепоручил ведение базы знаний AI-агенту Я уже довольно давно веду свою базу знаний в Obsidian. И как у любого уважающего себя «хомяка», у меня накопился запас необработанных материалов. Репосты и ссылки из любимых каналов в телеграме, ссылки «прочитать» в to-do листе, рекомендации книг, которые некогда разобрать. Пару месяцев назад вышла нашумевшая статья Андрея Карпати про LLM Wiki. Я давно думал, как использовать LLM для такой работы. Карпати добавил недостающих пазлов в мозаику. И я решил попробовать подход в деле. Основная идея простая. Перепоручить ведение базы знаний AI-агенту, чтобы суммаризацией, систематизацией и построением связей занимается машина. В результате получается та самая LLM Wiki, с отобранными тобой источниками. Важно! LLM Wiki не заменяет чтение и мышление. Она убирает рутину вокруг них: разбор бэклога, первичную суммаризацию, связи между заметками, поиск по своим материалам. Что у меня получилось? Отдельная папка inbox со всеми исходными материалами. Телеграм-бот копирует сюда посты, web clipper тексты статей, а PDF с white papers я кладу руками. Отдельная папка AI workspace для самой Wiki. Только в ней агенту разрешено делать изменения. Такое ограничение даёт спокойствие, что остальная часть базы будет не тронута массовыми правками и галлюцинациями. Сделал три новых навыка Claude Code 1) compile — обрабатывает заметки из inbox по моим правилам ведения базы и обновляет AI Wiki. 2) vault-health-check — быстрая проверка. Чинит сломанные ссылки, заметки без ссылок, устаревшие заметки, незакоммиченные изменения. Полезно запускать после ручных правок. 3) deep-audit — глубокий аудит заметок: структура, связи, валидность утверждений и ссылок на источники. Как работать с базой? Я прошу агента искать ответы в первую очередь в базе. И при необходимости собирать ответ в новую заметку. Например, спрашиваю: «какие есть лучшие практики использования ИИ при разработке ПО?». Получаю суммаризацию статей и собранные вместе мысли из evergreen notes. Такой конспект можно быстро прочитать и провалиться глубже по ссылкам. Если информации в базе не хватило, прошу собрать дополнительные материалы и ссылки из моих источников. Сохраняю, компилирую, уточняю. И так по кругу 🙂 Какой результат? • обработал весь накопившийся за годы текстовый бэклог, около 250+ источников; • разобрался в темах, до которых не доходили руки: geospatial AI, тренды по ИИ в разработке, паттерны агентных систем; • база стала не просто архивом ссылок, а рабочим инструментом. Теперь не нужно вспоминать, где именно видел нужную мысль. Достаточно задать вопрос агенту и провалиться в источники; В итоге мне зашло. Я наконец-то разгрёб старые запасы ссылок «на потом». И получил процесс, в котором база знаний не просто копится, а сама помогает думать. Промпты, формат заметок и audit-сценарии я ещё дорабатываю. Но направление выглядит очень перспективным.

Пост написан по мотивам моего доклада на весеннем Podlodka Teamlead Crew (16 сезон). В докладе раскрыто чуть больше деталей и примеров https://www.youtube.com/watch?v=DADogPVo0CI

👀 Как переводить инженерные идеи на язык бизнеса Ситуация: приходишь к продакту с идеей рефакторинга, автотестов или quality gates. Кажется, всё логично: багов будет меньше, код улучшится, жить станет веселее. А в ответ: «Не сейчас». Знакомо? Часто так бывает из-за того, что разработка объясняет задачу на техническом языке, а продукт принимает решения на бизнесовом — через эффект, метрики и приоритеты. В какой-то момент для себя я понял: если хочется побеждать в этой игре, нужно уметь думать как продакт. По сути — стать продакт-менеджером технического бэклога. Чтобы принять решение, ему нужно получить ответы на три вопроса: 🔴 Зачем мы это делаем? 🔴 Какой эффект это даст бизнесу? 🔴 Почему этим нужно заняться именно сейчас? Ответить на них мне помогает фреймворк ICE Это три коэффициента: 🔴 Impact — насколько сильно задача влияет на важную метрику 🔴 Confidence — насколько мы уверены в этой оценке 🔴 Ease — насколько задача проста в реализации Для инженерных задач обычно сложнее всего оценить Impact. Здесь помогает разделение на два типа инициатив: 🔴 Операционные задачи улучшают то, что уже работает: багфиксы, ускорение страниц, quality gates, автотесты. Главные метрики для таких задач — уменьшение сбоев, скорость релиза, рост конверсии 🔴 Задачи роста открывают новые возможности: монетизация существующих и создание новых сценариев, эксперименты. Здесь мы говорим о сокращении TTM или о том, что эта инициатива станет энейблером для чего-то большего Шкалы простые: 🔴 Impact: 1–2 — слабый эффект, 3–4 — локальное улучшение, 5–6 — заметное улучшение важного сценария, 7–8 — сильный эффект на ключевую метрику, 9–10 — большой эффект на стратегически важный показатель 🔴 Confidence: 0,1–0,2 — интуиция, 0,3–0,6 — есть аналоги у конкурентов, 0,7–0,8 — пилотный запуск, 0,9–1 — есть исторические данные или A/B-тест 🔴 Ease: 10 — пара часов, 5 — спринт, 1 — долго и сложно Допустим, нужно выбрать между рефакторингом корзины и исправлением потери корзины при сбоях. Для этого мы можем рассчитать ICE Score по формуле: ICE Score = Impact × Confidence × Ease Рефакторинг корзины: I = 10 — энейблер для других задач, C = 1 — провели ресёрч и написали ADR, E = 2 — проект большой. ICE = 20 Исправление сбоев корзины: I = 8 — эффект чуть ниже, C = 1 — уверены в своей оценке, E = 9 — задача простая. ICE = 72 Поэтому в работу логичнее брать вторую задачу. ❗️ Важно помнить, что ICE — это не точная математика, а язык разговора о приоритетах Нельзя просто прийти к продакту со словами: «У меня тут ICE Score 72, значит, делаем». Но можно иметь на руках понятную логику: вот эффект, вот уверенность в оценке, вот стоимость и вот ответ на вопрос, почему эта задача сейчас в приоритете. После этого техдолг, рефакторинги и автотесты перестают быть вечным «не сейчас» и становятся нормальными кандидатами на приоритизацию. ⏩️ А больше постов про разработку и управление командами можно найти в моём личном канале. Подписывайтесь: 💬 @Yandex4Teamleads

И последний пост из серии, про одну из самых сложных задач руководителя - приоритизацию.

💡 Как превратить сырую идею в понятную цель Когда долго работаешь над одним продуктом, идеи начинают копиться сами собой. Хочется исправить баги в одном месте, попробовать AI для разработки в другом, отрефакторить легаси, вынести что-то из монолита в микросервисы и поднять автоматизацию тестирования. И в этот момент легко попасть в ловушку «ну тут же и так всё понятно, просто делаем». Проблема в том, что такой список очень быстро начинает выглядеть как обычный бэклог, работу над которым можно откладывать бесконечно долго. В итоге новые идеи просто теряются на фоне, и даже сильные инициативы становится сложно объяснить и защитить. 🅰️ Инструмент 1. Working Backward Суть метода в том, чтобы сначала мысленно переместиться в будущее, в котором все ваши идеи уже реализованы. Что именно изменилось? Что это дало команде, пользователям и бизнесу? Например, вы сократили time to market, ускорили разработку или улучшили качество продукта. А дальше — идти в обратную сторону и раскладывать, что должно произойти, чтобы прийти к этой картинке. Working Backward особенно полезен, когда в бэклоге накопилось много разрозненных инициатив. По отдельности исправление багов, рост покрытия автотестами и работа с легаси выглядят как технические доработки, которые легко отложить. Working Backward помогает собрать их в одну более крупную и понятную цель. Например, те же задачи могут сложиться в цель «улучшить качество продукта». После этого уже проще увидеть, что из бэклога действительно работает на результат и чего ещё не хватает. Часто в этот момент появляются и новые шаги, которые раньше вообще не планировались. 🅰️ Инструмент 2. OKR — переведите идею в измеримый результат После Working Backward у вас появляется ориентир и набор шагов, которые помогают к нему прийти. Эти шаги хорошо подходят как кандидаты для OKR. OKR (Objectives and Key Results) — это фреймворк, который помогает поставить цель и сразу договориться, как мы поймём, что к ней пришли. В OKR есть две части: 🔴 Objective — сама цель, амбициозный конечный результат для пользователя или бизнеса 🔴 Key Results — измеримые признаки того, что эта цель достигнута Важно не допускать двух частых ошибок: 1️⃣ Не писать вместо Objective название проекта или список работ 2️⃣ Не писать вместо Key Results список действий Например, «повысить автоматизацию тестирования» — слабая формулировка для Objective. Это скорее направление работы. Лучше так: «Сделать релизный цикл быстрее и надёжнее за счёт автоматизации smoke-проверок». Тогда ключевые результаты могут быть такими: 1️⃣ 90% smoke-тестов автоматизированы 2️⃣ Прогон smoke-набора занимает не более 30 минут 3️⃣ Время на приёмку перед релизом сократилось на 2 часа 🅰️ Как это работает вместе Working Backward помогает понять, к какому большему результату вы хотите прийти, и собрать вокруг него разрозненные инициативы. OKR помогает зафиксировать это в виде цели и измеримых ключевых результатов. Мне нравится эта связка тем, что она помогает вытащить сильную идею из состояния «ну тут вроде понятно, что надо делать» и превратить её в цель, под которую уже можно собирать команду и строить работу. Подписывайтесь: 💬 @Yandex4Teamleads

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

📎 Как действовать в условиях неопределённости Всем привет! На связи Толя Панов, CTO Яндекс Карт и админ Yandex for Teamleads на этой неделе. Допустим, вам нужно принять важное решение, которое повлияет на развитие продукта. В такой ситуации хочется учесть все риски и возможные сценарии, но в 2026 году рассчитывать на полностью предсказуемое будущее уже не приходится. В этот момент кажется, что надо ещё посчитать, доисследовать, подумать... но для идеального выбора вам всегда будет не хватать данных. И как же тогда действовать? У меня есть несколько фреймворков, которыми я сам постоянно пользуюсь. 1️⃣ Представьте, что каждое решение — это дверь 🔴 One-way door (дверь в одну сторону). Вошёл — и назад не вернёшься. Это фундаментальные выборы, где нужны максимальная осторожность, анализ и согласования. 🔴 Two-way door (дверь в обе стороны). Зашёл, посмотрел, если не понравилось — вышел обратно. Это решения, которые всегда можно откатить. Стремитесь к тому, чтобы ваши решения были two-way, а не one-way door. На мой взгляд, это один из самых полезных способов снизить тревожность вокруг неопределённости. Не каждое решение требует многонедельного анализа. Во многих случаях лучше специально проектировать выбор так, чтобы он был two-way, а не one-way. Тогда вы не пытаетесь угадать идеальное будущее. Вы просто оставляете себе пространство для манёвра. 2️⃣ Анализ трендов Когда нужно принять решение о внедрении новой технологии, полезно сначала понять, насколько она вообще зрелая. Один из удобных инструментов для этого — кривая хайпа Gartner. Она позволяет оценить, где сейчас находится любая технология: от набирающего популярность фреймворка до искусственного интеллекта. Ось X — это время, которое прошло с момента появления технологии. А ось Y — это её видимость в публичном поле. Чтобы определить место технологии, нужно задать себе несколько вопросов: 🔴 Как давно она появилась? Как давно о ней говорят в сообществе? Чем дольше — тем правее будет стоять точка. 🔴 Кто её уже использует в бизнесе? Есть ли не просто пилоты, а рабочие кейсы? Чем больше успешных внедрений, тем выше должна находиться ваша точка. 🔴 В скольких отраслях она прижилась? Используется только в IT или уже в финансах, ретейле, медицине? Например, AI уже давно вышел далеко за пределы одной индустрии. Чем больше позитивных ответов, тем выше стоит точка. Чем правее и выше технология находится на кривой, тем безопаснее её внедрение. Чем левее — тем больше рисков, но и потенциальная награда тут может быть выше. Анализ трендов помогает взвесить риски и принять решение: готовы ли вы к эксперименту сейчас. 3️⃣ Сделайте премортем до того, как что-то пошло не так Есть постмортем — когда вы с командой уже после инцидента разбираете, что именно пошло не так. А премортем — это когда мы пробуем перенестись в будущее и сделать постмортем для того, что ещё не произошло. Допустим, мы решаем внедрить новую технологию. Мы переносимся в будущее и смотрим, что может пойти не так и какие будут проблемы. Например, не хватит железа, у разработчиков не будет необходимых компетенций или что-то ещё. Дальше мы определяем, что можно сделать с этими рисками. Например, не хватает знаний — организуем обучение, нет денег — пересмотрим бюджет, не готовы специалисты — перенесём сроки. Премортем помогает заранее найти слабые места в плане и подумать, как их укрепить. 🔹 Что в итоге Когда данных недостаточно, задача не в том, чтобы принять идеальное решение. Задача в том, чтобы принять достаточно хорошее решение с понятной ценой ошибки. 🐚 А как вы действуете в условиях неизвестности? Делитесь в комментариях! Подписывайтесь: 💬 @Yandex4Teamleads

На этой неделе я веду тим лидскую колонку в канале @Yandex4Teamleads. Буду делиться с вами репостами от туда 🙂 Встречайте первый пост Как действовать в условиях неопределённости

28 марта буду на Dream Teamlead. Это практическая конференция Яндекса для тимлидов, руководителей и технических лидеров — про управление людьми, сложные решения и развитие команд. Я буду участвовать в круглом столе «За кулисами кода: один день из жизни руководителя разработки». Поговорим о том, что на самом деле стоит за работой CTO: как выглядит рабочий день, как расставляются приоритеты, как устроена работа со стейкхолдерами, как принимаются решения, — и обо всей той управленческой рутине, которая обычно остаётся за кадром. Кроме этого, в программе будет ещё много интересного. Например, доклад Жени Антонова о разных типах лидерства, выступление Саши Поломодова о том, как ИИ меняет инженерную культуру, и дискуссия о том, как ИИ трансформирует повседневные задачи тимлида. Как и в прошлом году, я был в программном комитете и помогал собирать программу. По ощущениям, в этом году она получилась такой же сильной и интересной. Так что регистрируйтесь — https://ya.cc/t/m2Ap7qfY8vN3YD Если можете, приходите офлайн — буду рад увидеться и пообщаться. А если не получится, подключайтесь онлайн.

Почему изменения в больших командах буксуют Прочитал пост Жени Антонова про внедрение новых процессов. Женя пишет, что процессы можно внедрять: 1. директивно — с поддержкой административного ресурса руководителя. Обычно это проще и быстрее. 2. через вовлечение людей — нужно создать у них потребность и убедить, что изменения им полезны. Мысль абсолютно верная. Но на практике для больших команд такие чёрно-белые схемы часто не работают. Когда команда — это 100 или 500 человек, довольно сложно убедить всех в полезности изменений. Я чаще пользуюсь «моделью влияния» McKinsey. Она говорит, что человек меняет своё поведение, когда сходятся четыре условия. 1. Понимает, что делать — я понимаю, что от меня хотят, и это выглядит логично. 2. Видит ролевое поведение — я вижу коллег, которые уже ведут себя по-другому. Поэтому важно, чтобы были амбассадоры изменений. 3. Есть навыки — у меня хватает знаний и умений, чтобы работать по-новому. 4. Есть поддерживающие механизмы — процессы и правила поддерживают новое поведение. Например, за это хвалят, повышают или лучше оценивают работу. Несмотря на мою любовь к этому подходу, я иногда про него забываю. Потом удивляюсь: «что-то изменения плохо идут». Рука тянется, чтобы надавить и директивно ввести изменения. Но сначала я пытаюсь разобраться. И часто оказывается, что я просто забыл один из четырёх пунктов. А если его поправить, изменения начинают двигаться гораздо легче.

Tech Strategy Canvas — закрытое бета тестирование Мы с Анатолием Пановым и командой достаточно давно работаем над инструментом, который называется Tech Strategy Canvas — это специальный фрейм внешне сделанный наподобии Lean Canvas, но заточенный под разработку именно технической стратегии. Чем он может помочь: он сильно задает мыслительный процесс по которому должна формироваться тех стратегия и поэтапно проводит нас от диагностики к замыслу и действиям. С ним вопросы "с чего начать?", "что делать дальше?" и "что должно получиться?" закрываются сами собой. План: сделать его полностью open source и выложить в публичный доступ. Канвас прошел уже очень длинный путь, был опробован и на тестовых кейсах, и на реальных (например, актуальную тех стратегию с моей командой мы делали с помощью него). Чтобы оценить длину пути, скажу только, что текущая версия имеет номер 11.7. Я как всякий инженер не хочу катить в прод не проведя последний тест — в этот тест я приглашаю вас. Сразу скажу, тест закрытый и канвас мы отправим ограниченному количеству людей. Основной критерий — применимость в реальных условиях в ближайшие месяц-два. Если вы прочитали это и поняли, что именно канваса вам не хватало вот прямо сейчас — заполните вот эту форму и в течение недели мы отправим (или не отправим) вам материалы. Stay tuned

Tech Strategy Canvas - закрытое бета тестирование Готовим с Игорем публичный релиз нашего стратегического фреймворка. Мы довольно много тестировали его предыдущие версии. Предпоследней я пользовался сам в прошлом году — при составлении технической стратегии Яндекс Карт. Фреймворк получился достаточно универсальный: он помогает структурировать стратегическое мышление и подходит не только для технических стратегий, но и для более широких управленческих и продуктовых задач. Но как истинные перфекционисты мы хотим протестировать свежую версию перед публичным релизом. Если вам это откликается и вы работаете со стратегией — заполните короткую форму. Мы поделимся материалами и попросим честный фидбек, чтобы сделать финальную версию сильнее.

📚 Архитектура микросервисов: что читать, если хочется понять Микросервисы давно уже стали нормой. Кто-то успел их внедрить, обжечься и вернуться к монолиту. Кто-то построил империю из тысячи сервисов — и остался жив. Я собрал короткий список материалов, которые когда-то помогли мне разобраться в теме. Они до сих пор актуальны и местами уже стали классикой. 🔹 Building Microservices — Sam Newman Всё ещё актуальная классика. Про базовые принципы проектирования и декомпозиции микросервисов. 📖 amazon.com 🔹 Microservices Patterns: With examples in Java — Chris Richardson Вторая классическая книга. Глубже и техничнее, с набором более сложных паттернов: Saga, CQRS, API Gateway, API Composition. Плюс инфраструктурные: Sidecar, Circuit Breaker, Distributed Configuration. У Криса отличный сайт 👉 microservices.io 📖 amazon.com 🔹 12 Factor App Принципы проектирования облачных приложений. Старый, но до сих пор рабочий чеклист. Многое уже считается базой, но всё ещё актуально и подходит для быстрой самопроверки архитектуры. 🌐 12factor.net 🔹 Learning Domain-Driven Design — Vlad Khononov Подходы DDD хорошо ложатся на проектирование микросервисов: помогают выделять границы между сервисами и избегать излишней связанности. Сам ещё не добрался до книги, но слышал много очень хороших отзывов. 📖 amazon.com 🔹 Предметно-ориентированная микросервисная архитектура от Uber Для тех, кто уже дошёл до 500+ сервисов и пытается понять, как теперь с этим жить. 📄 RU на Хабре 📄 EN на uber.com Если есть что добавить в список — пишите в комментариях.

В июле я выступил с докладом «Быть заметным и расти: как руководителю взять развитие в свои руки» на первой конференции Яндекса для тимлидов — Dream Team Lead. Делюсь ключевыми идеями и полезными материалами. «Стеклянный тупик» Многие руководители рано или поздно сталкиваются с этим ощущением: работаешь, стараешься, задачи усложняются, а роста — нет. Кто-то в такой момент ждёт, что его «заметят» или подскажут путь. Но, на мой взгляд, развитие — это зона личной ответственности. Не обязательно идти на дорогое обучение — можно собрать кастомный план развития под себя. DIY-подход, который я сам использую и рекомендую другим. Что помогает расти: — Диагностика через матрицы компетенций Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки: • TL roadmap • Avito Tech Lead Profile • Dropbox Career Framework — Развитие скиллов Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами». — Работа с майндсетом Применять знания часто мешают внутренние барьеры — страх, самозванец, установки и т.п. Тесты вроде Hogan и Gallup помогают понять себя и дают инструменты для изменения. — Окружение Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать: • GetMentor • Solvery • No Flame No Game (бот в Telegram) • IT-мастермайнды Где посмотреть доклад: • VK Video • YouTube • Слайды Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.

ChatGPT vs performance review На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе? Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими. Чаще всего LLM используют в двух случаях: 1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер. 2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт. Как не потерять ценность ревью, если в него вовлечены LLM? - Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую. - Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM. - Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже. - Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂 А что нас ждёт дальше — с учётом того, как быстро развиваются модели? С развитием агентности в моделях, я думаю, мы придём к полностью автоматической генерации самоотзыва. Представьте, у вас есть набор агентов: — один собирает проекты из таск-трекера — второй вытаскивает инженерные детали из коммитов — третий анализирует A/B-тесты и метрики релизов — четвёртый сводит всё в внятный отчёт Часть из этого уже можно автоматизировать. Остальное — вопрос времени. Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...

Как объяснить топам, что у нас всё хорошо с качеством? Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие: - соблюдение SLA на исправление багов (aka zero bug policy); - надёжность ключевых пользовательских сценариев (aka «девятки», 99.99); - среднее время восстановления после сбоя (Mean Time to Recovery) - скорость работы интерфейса (например, Time to Interactive, Freeze Time); - и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью. Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию. Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой. Для общей логики хорошо заходит идея: смотрим на то, насколько продукт кажется пользователю качественным. Её легко объяснить бизнесу. А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов. Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог: Quality Score = Σ (вес метрики × значение метрики в шкале) На выходе получаем один показатель, который отражает общую картину с качеством — и выглядит вполне понятным для бизнеса. Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728

Сначала команды, потом код: как оргдизайн меняет архитектуру Последние месяцы я много обсуждаю с командой оргдизайн. Кому-то даже может показаться, что я чересчур много времени трачу на это. Ведь CTO должен фокусироваться на технологиях, а не на «вот этом вот всём». Но, на мой взгляд, умение выстроить правильную структуру и коммуникации в команде — это чуть ли не более важный навык, чем выбор технологий и фреймворков. Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной. Про связь оргдизайна и архитектуры говорит «закон Конвея»: организации проектируют системы, которые копируют структуру их коммуникаций. Из него вытекает «обратный манёвр Конвея»: чтобы достичь желаемой архитектуры, нужно сначала организовать команды и их взаимодействия так, чтобы они отражали целевую структуру системы. В итоге, если мы хотим сделать действительно крутую архитектуру, важно посмотреть на то, как устроены наши команды. И начать стоит не с нового стека технологий, а с «обратного манёвра Конвея».

Коллеги попросили меня поделиться списком материалов для тим лидов, которые лично мне запомнились и зацепили чем-то. Задача оказалась довольно трудная, но я справился! :) Решил запостить в канал топ-3 из тех, что пришли в голову. 1. “Agile менеджмент” - Юрген Аппело https://alpinabook.ru/catalog/book-agile-menedzhment/ В оригинале называется “Management 3.0”. Эта книга мне очень зашла, когда мы внедряли Scrum и думали с командой над вопросом: “А зачем нужен менеджер в самоорганизующихся командах?” Автор рассказывает про стиль управления servant leadership (лидер-слуга) и подкрепляет всё понятными примерами из своего опыта. Потом оказалось, что на позиции CTO это вообще must have, так как ты уже работаешь только с опытными, самостоятельными и организованными менеджерами. И управление в концепции лидер-слуга позволяет лучше понять свою добавленную стоимость и приносить пользу команде. 2. “Джедайские техники” (обе части) - Максим Дорофеев https://www.mann-ivanov-ferber.ru/catalog/product/dzhedajskie-texniki/ https://www.mann-ivanov-ferber.ru/catalog/product/put-dzedaia-dopolnennoe-izdanie/ На мой взгляд, это лучшие книги по тайм-менеджменту на русском. Максим собрал и агрегировал много разных советов, идей и подходов в стройную систему. Книжки очень практичные, я до сих пор пользуюсь советами оттуда :) 3. Подходы к системному ведению заметок: Zettelkasten, Метод PARA, Вечнозеленые заметки (Evergreen notes) и программа Obsidian Удивительно, но я только недавно узнал, что такое вообще существует. Хотя практики не новые, в айтишных кругах почему-то редко про них говорят. Практики очень полезные, когда изучаешь много нового контента. Помогают хорошо систематизировать знания и не забывать важные мысли. Каких-то конкретных материалов хороших не могу посоветовать, собирал свое представление из кусочков. Свои мысли об этих подходах писал тут: https://t.me/cto_notes_panov/11