Agaltsov Anton | TeamLead-блог

📊 Бенчмарки LLM: как читать цифры, которым все верят «90% на MMLU», «Elo 1350 в Chatbot Arena» — за каждой такой цифрой стоит конкретная процедура прогона. Бенчмарк — это экзамен с фиксированными билетами, метрика на своих данных — способ измерить модель в вашей задаче. Первое даёт ориентацию на рынке и отсев кандидатов, второе — основу для финального выбора. Цифра бенчмарка имеет смысл только в контексте. У MMLU уровень случайного угадывания — 25%, потолок человека — около 90%. Разница между моделями в 1–2 пункта — статистический шум, а не превосходство. А когда фронтальные модели выходят на плато 85–88%, как на SWE-bench Verified, бенчмарк теряет различительную способность. ⚠️ Главные риски — загрязнение обучающих данных (модель не решает задачи, а вспоминает их) и натаскивание под формат: одна и та же модель может показать 40% в zero-shot и 80% в few-shot. Заявленные вендорами цифры — наименее надёжный источник. Больше всего доверия — независимым и слепым площадкам: Stanford HELM, Elo-рейтинг Chatbot Arena. 🔗 https://agaltsovav.ru/docs/ai/llm-benchmarks/

🏗️ Clean Architecture: правило зависимостей сильнее любой диаграммы Clean Architecture Роберта Мартина разделяет систему на концентрические слои: в центре — бизнес-логика (сущности и сценарии использования), на периферии — фреймворки, интерфейс и базы данных, объявлённые «деталями». Единственное жёсткое правило стиля: все зависимости исходного кода направлены строго внутрь, к домену. Это правило превращает архитектуру из набора красивых схем в проверяемое свойство кодовой базы: направление зависимостей измеряется статическим анализом, и нарушение можно ломать сборкой. Внутренние слои не знают имён внешних классов — поэтому домен не меняется вместе со сменой фреймворка, UI или СУБД. 💡 Мартин не претендовал на новизну идеи: гексагональная архитектура Коубёрна, Onion Палермо и BCE Якобсона — вариации одной темы. Вклад Clean Architecture — единый словарь из четырёх колец (Entities → Use Cases → Interface Adapters → Frameworks & Drivers) и связь с принципами SOLID, применёнными не к классу, а к системе целиком. Практическая граница применимости: для чистого CRUD без бизнес-правил интерактор-транзит лишь добавляет слой без содержания. Слои следуют за сложностью, а не наоборот. 🔗 https://agaltsovav.ru/docs/architecture/clean-architecture/

📊 Метрики LLM: как превратить «кажется, стало лучше» в измеримые данные LLM по своей природе вероятностны: на один и тот же запрос модель может вернуть разные ответы, а правильность нельзя проверить простым сравнением строк. Классические unit-тесты здесь бессильны — метрики превращают субъективные ощущения в объективные, воспроизводимые данные. Универсальной «одной метрики качества LLM» не существует. На практике комбинируют несколько категорий: качество генерации (Perplexity, BLEU, ROUGE, BERTScore), соответствие задаче (Exact Match, F1, следование инструкциям), LLM-as-a-judge, метрики RAG (faithfulness, релевантность контекста), безопасность и операционные характеристики — латентность, throughput, стоимость за миллион токенов. Отдельный слой — стабильность: консистентность ответов, робастность к перефразированиям и опечаткам, калибровка уверенности. Некалиброванная модель, уверенная в неверных ответах, опаснее той, что честно отвечает «не знаю». 💡 Метрики выбираются под продукт, а не наоборот. Для чат-бота это win-rate и скорость первого токена, для RAG — набор RAGAS, для кодогенерации — pass@k. Разумный старт: одна-две метрики качества под основной сценарий, пара операционных под экономику и одна метрика безопасности. 🔗 https://agaltsovav.ru/docs/ai/llm-metrics/

🎯 Product-Market Fit — точка, после которой рынок тянет продукт сам Product-Market Fit (PMF) — состояние, при котором продукт удовлетворяет реальную потребность достаточно большого рынка. Формула Марка Андриссена короткая: рынок сам тянет продукт из ваших рук. Жизнь стартапа делится на две части — до PMF и после, и управляются они по разным правилам. Соответствие продукта рынку складывается из трёх элементов. Ценность — продукт закрывает настоящую потребность, пользователи называют его «must-have». Лёгкость — путь до ценности короткий, пользователь быстро доходит до сути. Охват — аудитория достаточно велика, чтобы поддерживать растущий бизнес. Дефицит любого элемента разрушает PMF. Главный опрос для замера — методика Шона Эллиса: «Как вы расстроитесь, если продукт исчезнет?» Если «очень расстроены» отвечают более 40% активных пользователей — у продукта, вероятно, есть PMF. PMF можно потерять — это спектр, а не разовое достижение. Рынок сдвигается, конкуренты переманивают ядро, погоня за новыми сегментами распыляет разработку. Сигналы потери: снижение Sean Ellis score в новых когортах, кривые удержания ниже предыдущих, рост оттока, падение доли органики. Поэтому PMF мониторят регулярно, а не «получают один раз и навсегда». 🔗 https://agaltsovav.ru/docs/product-managment/product-market-fit/

🤖 Как развести LLM по ролям: серверный кодинг, независимое ревью и свой агент OpenCode запущен на сервере через opencode serve и доступен через WebUI по HTTPS. Задача ставится, ноутбук закрывается — агент продолжает работать: правит файлы, гоняет тесты, коммитит. Прогресс мониторится с телефона. Серверный контур превращает LLM-ассистента из «игрушки на ноуте» в удалённого разработчика, задачи больше не умирают вместе с закрытой крышкой. Для code review — отдельный инструмент и другая модель. Когда код пишет одна модель, а ревьюит другая, срабатывает эффект независимого аудитора: у моделей разные слепые зоны, а ревьюер не защищает чужой код. Связка «писал на одном, поревьюил на другом» заметно сокращает число пропущенных багов и архитектурных кривостей. Третий слой — собственный агент TaigaClaw на Go: долговременная память с семантическим поиском, knowledge graph на PostgreSQL, сабагенты и cron-планировщик. Он управляет всей домашней инфраструктурой — Mac Studio, Debian-сервер, NAS и VPS в mesh-сети — по запросу из веб-чата: проверить упавший контейнер, обновить прокси, создать поддомен. 💡 Общий принцип: не искать одну «лучшую» модель, а разводить модели по ролям и держать серверный контур, независимый от рабочего места. Доверять, но проверять — разными моделями на разных этапах. 🔗 https://agaltsovav.ru/blog/how-i-use-llm/

📋 Испытательный срок — не экзамен, а двусторонняя проверка Испытательный срок — это формальный период, в течение которого работодатель и сотрудник оценивают соответствие друг друга. Цель не «выжить», а проверить, способен ли человек достигать результатов роли и интегрироваться в команду. Критерии оценки делятся на две группы. Hard — качество задач, самостоятельность, скорость обучения. Soft — коммуникация, способность принимать обратную связь, соответствие ценностям. Главное правило: критерии должны быть зафиксированы до старта, а не сформулированы постфактум. План 30/60/90 задаёт ритм: первые 30 дней — изучение процессов и первые самостоятельные задачи, к 60-му дню — стабильное выполнение рутины, к 90-му — полная самостоятельность. На каждом этапе — регулярные встречи 1-на-1 и промежуточные ревью, чтобы не оказалось, что решение принимается в последний день. ⚠️ Типичная ошибка — использование испытательного срока как источника дешёвой рабочей силы без обратной связи. В IT специфика в том, что первый инкремент и code review дают материал для оценки раньше, чем в других сферах. 🔗 https://agaltsovav.ru/docs/people-managment/probation-period/

🧩 Как организовать работу десяти и более продуктовых команд без хаоса Team Topologies даёт типологию из четырёх типов команд: потоковая, платформенная, включающая и команда сложной подсистемы. Большинство команд — потоковые, остальные снижают их когнитивную нагрузку и передают экспертизу. Spotify Model описывает иерархию squad / tribe / chapter / guild: автономные отряды объединяются в племена до ~100 человек, а горизонтали специализаций обеспечивают профессиональный рост без разрушения кросс-функциональности. Обе модели не заменяют продуктовую команду, а уточняют её организацию при масштабировании. Они взаимодополняющие: Team Topologies отвечает за вертикальную типологию команд, Spotify — за горизонтальные пространства роста специалистов. Главное условие — организационная зрелость. Без реальной автономии команд, развитой инженерной культуры и готовности вкладываться в долгосрочное эти модели превращаются в формализм: название без содержания. 🔗 https://agaltsovav.ru/docs/team-managment/types/modern-models/

📊 Проект, программа или портфель — в чём разница? Проект создаёт уникальный результат в ограниченных рамках — время, бюджет, ресурсы. Программа объединяет связанные проекты ради выгоды, недостижимой по отдельности. Портфель — это все инвестиции организации в изменения, отобранные под стратегию. Ключевое слово для каждого уровня своё: проект — про результат, программа — про выгоду, портфель — про ценность. Смешение этих понятий приводит к тому, что руководители говорят о разных вещах, используя одни и те же слова. Отсюда — конфликты ожиданий и хаос в приоритетах. Не каждый крупный проект — это программа. Программа возникает только тогда, когда связанные проекты создают синергию: выгоды в ней не складываются, а умножаются. Если проекты можно выполнять независимо без потери ценности — это не программа, а просто набор проектов. Портфель — это не список всех проектов организации, а осознанный выбор под стратегию. Именно элемент отбора делает портфель инструментом управления, а не реестром намерений. 🔗 https://agaltsovav.ru/docs/project-managment/project-program-portfolio/

👥 Матричная структура — когда один человек подчиняется двум руководителям постоянно Матричная модель отличается от проектной команды тем, что двойное подчинение здесь — не временное явление под проект, а постоянный способ организации. Сотрудник числится в функциональном отделе (например, бекенд-разработки), где отвечает за карьеру и стандарты работы. Одновременно он приписан к проектной ячейке, и руководитель проекта определяет, какие задачи он делает прямо сейчас. В управленческой литературе это описывается двумя линиями. Solid line — основное подчинение, обычно функциональному руководителю: найм, оценка, повышение, отпуск. Dotted line — проектное подчинение: содержание работы и приоритеты, но не кадровые вопросы. ⚠️ Главная сложность матрицы — рассогласование ответственности и полномочий. Проектный руководитель отвечает за результат перед бизнесом, но не контролирует людей административно. Функциональный руководитель контролирует кадры, но не отвечает за проект. Это требует зрелой культуры разрешения конфликтов и прозрачного ресурсного планирования. Матрица хорошо работает в многопроектных организациях с дефицитом узких специалистов, в энтерпрайзе и аутсорсинге. Плохо — в молодых продуктах с быстрым циклом релизов и в командах до 20–30 человек, где накладные расходы превышают пользу. 🔗 https://agaltsovav.ru/docs/team-managment/types/matrix-structure/

🏗️ Монолит — не устаревшая архитектура, а отправная точка Монолитная архитектура — это система как единое приложение: все модули работают в одном процессе, делят общую базу данных и деплоятся одним артефактом. Компоненты обращаются друг к другу обычными вызовами методов, а границы между ними существуют лишь на уровне исходного кода и соглашений. Слово «монолит» возникло как контрастный термин — потребовалось дать имя тому, что микросервисы противопоставляют себе. Отсюда ошибочное восприятие монолита как «плохой» или «устаревшей» архитектуры. На деле это базовый стиль, с которого начинается подавляющее большинство систем. Виды монолита различаются строгостью внутренних границ. Единый монолит — спагетти-код без чётких разделений. Модульный монолит — структура с продуманными границами модулей, которые позже могут превратиться в сервисные. Распределённый монолит — антипаттерн: несколько сервисов, жёстко связанных и деплоящихся только вместе. 💡 Рекомендация Мартина Фаулера: начинать почти всегда с монолита, а к микросервисам переходить, когда организационная боль от монолита станет осязаемой. Монолит и микросервисы — не соперники, а этапы одного пути. 🔗 https://agaltsovav.ru/docs/architecture/monolith/

🎯 Проектная команда: временная сила под конкретную цель Проектная команда (task force) — это кросс-функциональная группа, которая собирается под конкретный результат: запустить продукт, провести миграцию, потушить кризис. После достижения цели команда распускается, а участники возвращаются в свои постоянные отделы. Ключевое отличие от матричной структуры — одинарное подчинение. На время проекта участник подчиняется только руководителю проекта. Функциональный отдел выступает «источником кадров», а не второй линией управления — двойного подчинения нет. Модель работает лучше всего для разовых задач с чёткой целью и сроком: запуск MVP с нуля, переезд инфраструктуры, кризисные доработки. Но для непрерывной продуктовой разработки она не подходит — проектная команда сдаёт результат и уходит, а продукт требует постоянного владения. Оптимальный размер — 5–12 человек. Больше — уже не единая команда, а набор подкоманд с координационным ядром. 🔗 https://agaltsovav.ru/docs/team-managment/types/project-team/

📦 Roadmap — это не проектный план, а коммуникационный инструмент Дорожная карта продукта отвечает на вопрос «что и в каком порядке мы делаем», оставаясь выше уровнем, чем backlog. Это связующее звено между стратегией и повседневной работой команды: какие направления получают приоритет, в какой очерёдности и ради какой ценности. Современная best practice — outcome-based roadmap в формате Now / Next / Later. В Now указываются конкретные темы с временными рамками. В Next — направления на ближайшие месяцы. В Later — только стратегические ориентиры без дат. Даты появляются лишь тогда, когда инициатива переходит в зону Now. ⚠️ Главная ошибка — позволить roadmap стать проектным планом с жёсткими датами для каждой фичи. Это превращает дорожную карту в обещание, которое невозможно выполнить в условиях неопределённости, и разрушает доверие стейкхолдеров. Roadmap — живой документ, который пересматривается ежеквартально. Его цель — синхронизация ожиданий, а не отслеживание задач. 🔗 https://agaltsovav.ru/docs/product-managment/roadmap/

👥 Продуктовая команда: кросс-функциональная автономия от идеи до релиза Продуктовая команда — это 6-10 человек с разными навыками, которые вместе владеют вертикальным срезом продукта: от проектирования до поддержки в продакшене. Фронтенд, бекенд, QA, дизайн, аналитика и продуктовый владелец в одной команде — без хэндофов в другие отделы. Product owner решает, что делать. Команда сама решает, как — планирует спринты, разбивает задачи, принимает технические решения. Одинарное подчинение: все участники отвечают перед одним руководителем, никакого двойного управления как в матричной структуре. Модель известна под разными именами: stream-aligned team из Team Topologies, feature team из Spotify и LeSS, two-pizza team из Amazon. Суть одна — автономная кросс-функциональная команда, которая доставляет ценность целиком. Цена автономии — требования к зрелости. Без CI/CD, автотестов, мониторинга и feature-флагов продуктовая команда просто не сможет безопасно релизить сама. А при масштабировании свыше 5-10 команд появляется потребность в выделении платформенной команды. 🔗 https://agaltsovav.ru/docs/team-managment/types/product-team/

🔧 Типы как доказательство: что такое Type Driven Development TDD означает разное для разных разработчиков. В Test Driven Development движущая сила — тесты: сначала пишется проверка, потом код. В Type Driven Development движущая сила — система типов: компилятор становится автоматическим пруфером, который отсекает целые классы ошибок ещё до запуска программы. Суть подхода — кодировать инварианты и бизнес-правила прямо в типах. Если функция принимает только положительные числа, то отрицательное значение не пройдёт компиляцию. Отдельный тест для такой проверки не нужен: тип гарантирует корректность на уровне сборки. Подход нишевый и требует языков с выразительной системой типов — Haskell, Idris, F#, OCaml, Scala, TypeScript в strict-режиме. На мейнстримных языках с примитивной типизацией применить его в полной мере нельзя, но принцип «делать невозможные состояния непредставимыми» остаётся полезным на любом стеке. 🔗 https://agaltsovav.ru/docs/development-managment/tdd-type-driven-development/

👥 Функциональная команда — когда специализация важнее скорости Бэкенд отдельно, фронтенд отдельно, QA отдельно. Функциональная структура группирует людей по специализации: каждый отдел — это центр экспертизы со своим руководителем, стандартами и карьерной вертикалью. Продукт собирается из результатов, которые передаются по цепочке между отделами. Ключевая особенность модели — хэндофы. Фича проходит путь: аналитика → бэкенд → фронтенд → QA, и каждый переход требует согласования интерфейсов, протоколов и критериев приёмки. Координация становится отдельной и заметной статьёй расходов. Модель хорошо работает в зрелых платформах и регулируемых отраслях, где цена ошибки высока, а глубокая экспертиза важнее времени выхода на рынок. Аутсорсинг и системная интеграция тоже естественно ложатся на функциональную структуру. ⚠️ Главная болезнь — «бросание через стену»: отдел передаёт результат дальше и считает задачу закрытой, а проблемы на стыке становятся ничьими. В продуктовых IT-командах от этой модели чаще уходят в сторону продуктовых команд. 🔗 https://agaltsovav.ru/docs/team-managment/types/functional-team/

🏗️ Микросервисы — не упрощение системы, а перераспределение сложности Вместо одной большой программы — много маленьких, каждая из которых заменяема целиком. Этот архитектурный стиль переносит сложность с уровня отдельного приложения на уровень взаимодействия распределённых компонентов. Микросервисы обменивают жёсткую связность монолита на гибкость независимого деплоя и масштабирования, но добавляют сетевые и операционные задачи. Каждый сервис владеет своими данными и не делит базу с соседями. ⚠️ Мартин Фаулер предупреждал: большинство команд должно начинать с монолита и переходить к разбиению только тогда, когда организационная боль от монолита станет осязаемой. 🔗 https://agaltsovav.ru/docs/architecture/microservices/

👥 Типы команд в IT: пять моделей и как их различать Все командные структуры в IT сводятся к пяти типам: функциональная, продуктовая, матричная, проектная (task force) и современные модели — Team Topologies и Spotify. Разница между ними определяется тремя осями: постоянство состава, однородность специализаций и количество линий подчинения. Самая частая путаница — между матричной и проектной структурами. Матричная модель постоянна: сотрудник числится в функциональном отделе и одновременно приписан к проекту с двойным подчинением. Проектная команда временна: собирается под конкретную цель, подчиняется одному руководителю и распускается после завершения. Выбор модели зависит от задачи: продуктовая команда даёт максимальную скорость доставки в непрерывной разработке, функциональная — глубину экспертизы, матричная решает проблему дефицита узких специалистов. Если команда формируется с нуля под продукт, де-факто стандартом становится продуктовая модель как ядро, дополненное платформенными командами по мере масштабирования. 🔗 https://agaltsovav.ru/docs/team-managment/types/

📦 Продуктовая стратегия — это не план, а система выбора Майкл Портер в 1996 году провёл границу между операционной эффективностью (делать то же, что конкуренты, но лучше) и стратегией (выбирать иное положение на рынке). Главное в стратегии — не то, что компания решает делать, а то, от чего она сознательно отказывается. Сильная стратегия отвечает на шесть вопросов: кого обслуживать, какую проблему решать, какую ценность предлагать, чем отличаться, как зарабатывать и какое место занимать в сознании клиента. Эти компоненты не независимы — изменение одного затрагивает остальные, и именно системность отличает стратегию от набора разрозненных решений. Самый распространённый провал — «стратегия в столе»: документ существует, но команда не использует его при принятии решений. Симптом очевиден — никто не может воспроизвести стратегию своими словами, а roadmap не связан со стратегическими ставками. 🔗 https://agaltsovav.ru/docs/product-managment/product-strategy/

🎯 Product Owner — не должность, а роль с единоличной ответственностью за бэклог Product Owner — это роль, определённая Scrum Guide. Один человек отвечает за всё: что входит в бэклог, в каком порядке и в какой формулировке. Двух PO на один бэклог не бывает — иначе исчезает единая точка принятия решений. Частая путаница: Product Owner и Product Manager — не одно и то же. PO работает на операционном уровне — спринты, приоритизация, приёмка готового функционала. Product Manager отвечает за продукт целиком — стратегию, рынок, roadmap на кварталы и годы. В небольших компаниях один человек совмещает обе роли, но по мере роста это становится перегрузкой. Главная метрика работы PO — доступность для команды. Если Product Owner недоступен, когда у разработчиков возникают вопросы по требованиям, спринт буксует. Уточнение краевых случаев и принятие мелких решений — это ежедневная рутина, без которой команда не может двигаться дальше. Давление стейкхолдеров — самая частая сложность. Каждый стейкхолдер считает свою задачу самой важной. Задача PO — говорить «нет» или «позже», не разрушая отношения, и обосновывать приоритеты данными, а не эмоциями. 🔗 https://agaltsovav.ru/docs/overview/product-owner/

👥 Онбординг — не выдача доступов, а процесс длиною в месяцы Свести адаптацию новичка к инструктажу по доступам и экскурсии по офису — самая частая и самая дорогая ошибка. Человек получает учётку, но не понимает, как здесь принято работать, и месяцами не выходит на полную отдачу. Здоровый онбординг идёт по четырём уровням одновременно: организационная, техническая, социальная и культурная адаптация. Техническая закрывается за неделю — поднял окружение, сделал первый коммит. Социальная и культурная тянутся месяцами и реже попадают в формальный план. Ключевая метрика — time-to-productivity: интервал от первого рабочего дня до момента, когда сотрудник начинает приносить ценность на уровне команды. Без карты территории новичок неделями делает простые вещи «в лоб», не зная о готовых инструментах и процессах. Цена слабого онбординга скрыта: затянутый выход на продуктивность, ранние увольнения в первые 3–6 месяцев и потеря доверия к руководству, которая формируется именно в первые недели. 🔗 Онбординг (адаптация сотрудника): https://agaltsovav.ru/docs/people-managment/onboarding/