Телеграм канал «Product Developer»

Теория Ограничений Систем
"команда идёт со скоростью самого медленного"

Disclaimer: пост — ТОС на пальцах + анонс бесплатного митапа от VK, где будет мастер-класс по ТОС.

В 1984 году физик Элияху Голдратт написал производственный роман «Цель». Директор завода ведёт в поход отряд скаутов. Отряд растягивается по тропе: жирный Херби с тяжёлым рюкзаком идёт в середине, передние убегают вперёд, задние упираются в Херби. Привалы уходят на то, чтобы собрать всех обратно. Директор ставит Херби первым и раздаёт его рюкзак остальным. Тогда отряд идёт со скоростью Херби, зато весь вместе и быстрее, чем раньше.

Так Голдратт объясняет теорию ограничений: пропускная способность системы равна пропускной способности узкого места.

Переложим на команду. Шесть инженеров кодят, а ревью делают между делом. С агентами кодить стали вдвое быстрее. А cycle time задачи не изменился. Задачи стоят в очереди на ревью, и чем быстрее кодим, тем длиннее очередь.

Голдратт предлагает пять шагов:

1️⃣ Найти ограничение. Этап, перед которым задачи ждут дольше всего. В джире это колонка, в которой копятся карточки. В нашем случае это ревью.

2️⃣ Помочь ограничению. В «Цели» перед станком поставили контроль качества, чтобы станок не точил уже бракованные детали. В случае ревью это:
• маленькие PR
• линтеры и зелёный CI до того, как PR попал человеку
• описание к PR, чтобы ревьюер не восстанавливал задачу по диффу.

3️⃣ Подчинить остальное ограничению. Ревью с утра, до своего кода. Разработчик, у которого три PR висят на ревью, не начинает четвёртую задачу, он идёт ревьюить чужую. Да, писать код приятнее. Нет, команде это сейчас не нужно.

4️⃣ Расширить ограничение. Нанять, отдать первый проход агенту, автоматизировать.

5️⃣ Ограничение переехало. Вернуться к 1.

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

Голдратт просит ускорять этап, который тормозит, даже если он чужой. У него же есть фраза для тимлидов, которые считают закрытые задачи на человека: «Скажи мне, как ты меня измеряешь, и я скажу, как буду себя вести».

———

У теории ограничений есть вторая часть: мыслительные инструменты.

Главный инструмент — дерево текущей реальности. Внизу симптомы, которые бесят: задачи висят на ревью, релиз раз в две недели, на ретро один и тот же пункт третий спринт. Вверх от них стрелки «потому что», и каждую стрелку проверяют по правилам.
1. Причина существует?
2. Её одной достаточно?
3. Если причина верна, какие ещё следствия мы должны наблюдать, и наблюдаем ли?

Проверка на себе. «Ревью медленное, потому что ревьюеры ленятся». Если это правда, маленькие PR должны висеть так же долго, как большие. Смотрю в джиру: PR на 100 строк уходят за день, на 1500 висят неделю. Причина в размере PR.

Второй инструмент, «туча», для конфликтов. Разработчик хочет писать свой код и хочет, чтобы команда катила быстро. Два желания тянут в разные стороны, и команда ищет компромисс: день кодим, час ревьюим. Голдратт просит компромисс не искать. Под каждой стрелкой конфликта лежит предположение, и его надо достать и проверить. Здесь оно звучит так: «моя задача закрыта, когда я написал код». Очевидно, это не так: задача закрыта, когда всё в проде и обмазано мониторингом. А что надо чтоб оно доехало в прод? Правильно, ревью!

На VK JT TeamLead 28 октября в Питере будет Мастер-класс по теории ограничений с Александрой Брызгаловой, сертифицированным тренером по ТОС Голдратта.

Еще будут:
— Дискуссия «Лидер и стратегия: насколько глубоко тимлид должен погружаться в бизнес»
— Менторская гостиная, встреча 1–1 с тимлидом VK
— «Своя игра» по управленческим кейсам

Санкт-Петербург, 28 октября, 17:30, офис VK у Красного моста.

Офлайн, бесплатно, нужна регистрация.

Зарегистрироваться

SaaS мертв!
...да здравствует SaaS

Disclaimer: пост рекламный — мои мысли по мотивам одного из докладов предстоящей бесплатной конференции GuardConf от уважаемых господ из кибербеза.

———

Раньше решение о покупке вендорского софта принималось достаточно просто: если это дешевле и быстрее купить, чем написать - покупаем. А теперь все принялись делать свои inhouse - *aaS, потому что навайбкодить стало дешевле и быстрее.

В феврале, после выхода Claude Cowork, рынок акций SaaS компаний просел на триллион (!) баксов за неделю. Потому что инвесторы решили, что раз агенты могут написать софт за вечер, то никто больше не будет продлевать подписки. Тогда это назвали SaaSpocalypse, но отросло обратно примерно за полгода.
Т.е. все-таки подписки продолжили продлевать и немедленного банкротства не случилось.

В августе McKinsey опубликовали отчет "State of AI". Среди прочего - любопытный тренд: треть компаний хотя бы раз отказалась от покупки софта, потому что агенты могут собрать его внутри.
Очень часто "свою бесплатную альтернативу" делают энтузиасты в свободное от основной работы время. Но что люди склонны недооценивать - это стоимость поддержки. Не бывает продуктов типа "один раз написал, навсегда теперь работает". Из банального - надо патчить уязвимости, обновлять библиотеки, чинить баги. А еще постоянно появляются фича-реквесты. И вот уже есть объем работы на целую команду.

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

Мой вывод пока такой: SaaS умирает там, где вендор продавал тонкую обёртку над API. Там, где есть существенная нагрузка на поддержку — еще будет жить.

–––

Рассуждение выше навеяно докладом Антона Башарина на Guardconf. Его и ещё три из программы я бы послушал:

1️⃣ — Написать стало дешево, владеть — нет. Build vs buy, когда код пишет ИИ. Антон Башарин, AppSec Solutions.
Ровно то, о чём выше. Спикер руководит разработкой из пяти команд и разбирает, почему классическая оценка build vs buy теперь систематически ошибается: своё решение, допиленный опенсорс или коробка. Отдельно про теневой build: приложения, которые навайбкодили без решения build vs buy и без владельца.

2️⃣ — Исключение и принятие рисков ИБ без владельца и коммитментов — это бэкдор. Илья Шмаков, СберСпасибо.
Кейс перехода от разового аудита кода к проверкам на каждый PR. Что делать, когда проверка нашла риск, а релиз откладывать нельзя: единый реестр исключений, у каждого владелец, срок и причина. И ИИ-код там ревьюится так же, как человеческий.

3️⃣ — Модель монетизации как отражение продуктовой реальности. Екатерина Цыкина, Контур.
Почему одна модель монетизации работает для одного продукта и не подходит другому. На реальных примерах: как понять, что в монетизации пора что-то менять, сколько стоит ошибка и как протестировать изменение.

4️⃣ — Кейноут. Что ждёт вендоров российского ПО в 2027 году. Михаил Чухломин, Guardant, и Пётр Городецкий, «Квадрант Технологий».
Впервые покажут «Оценку российского рынка ПО участниками отрасли с прогнозом на 2027 год»: как рынок видят сами вендоры, от маленьких до больших. Для контекста, по оценке «Квадрант Технологий» российский ИТ-рынок в 2025-м просел на 3%. Золотая эра импортозамещения подошла к концу, интересно послушать версию "что будет дальше".

📍12 ноября, Лофт #2 (Ленинская слобода, 26), Москва.
Открытие в 11:00, доклады до 18:15, потом нетворкинг.

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

Зарегистрироваться

Аналитический паралич

Людям хочется верить, что они контролируют будущее и исходы своих решений. Отсюда желание всё измерить. Отсюда же data-driven культура в корпорациях.

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

Аналитический паралич — это когда менеджеру не хватает яиц, чтобы принять решение, и он зависает в попытках получить хоть какой-нибудь значимый результат A/B-теста или исследования. Это, в целом, довольно частая побочка data-driven культуры.

Когда услышал первый раз, термин показался мне модным, из серии «скорость принятия решений в условиях неопределённости».

В оригинале — analysis paralisys, красиво, рифмованно, убедительно. Рифма как довод — вообще гениальный приём.

Словосочетание встречается в тексте впервые в 1928г, почти 100 лет назад, в речи какого-то там епископа.
В 1950х-60х было несколько статей и докладов про менеджмент, где так или иначе звучало: "не сдохните, принимая решения интуитивно, и не впадайте в паралич от анализа." В The Times самые ранние употребления «analysis paralysis», относятся к 1970-м.

То есть модному термину больше 50 лет!

Обожаю такое 🙂

На этот пост меня навели мысли из последнего эпизода Make Sense с Вадимом Дороховым из VK Видео. Если решение упёрлось в «давайте ещё померим», а мерить нечего — надо сказать вслух: данных под эту развилку не будет, принимать решение нужно самостоятельно. И дальше в ход идёт сценарное планирование. Будущее не контролирует никто, но каждый его вариант можно заранее написать план. Именно это и отличает решение без данных от решения наугад.

Follow-up к Avito.Tech.Conf

Посмотрел запись конфы, делюсь двумя докладами.

1️⃣ — Александр Лукьянченко, CTO Tech Platform. Как меняется разработка с внедрением агентов

Признание ошибки и наш таймлайн адопшена AI агентов в Авито.

1. Февраль 2025: Мы файнтюнили свои модели на кодовой базе Авито. Адопшен шёл довольно плохо, решения были слабые.
2. Июнь 2025: Вышли открытые модели уровня Qwen3-Coder, агенты впервые начали доводить задачи до конца, но адопшен был все еще низкий.
3. Февраль 2026: Признали, что не можем с той же скоростью создавать те же инструменты, что индустрия, и в этом нет смысла. Свои модели отложили, взяли двух самых крупных вендоров. А дальше все силы вложили в инструменты для получения агентами контекста. Написали больше 100 MCP-серверов для всего: мессенджер, таск-трекер, документация, исходники,... А еще пошла какая-то бешеная гонка по написанию скиллов. Получилось больше 4 тысяч скиллов, пришлось делать golden-сеты, чтобы отобрать реально полезные.

2️⃣ — Артём Арюткин, Developer Experience. Как реально меняется PDLC

Померили, куда уходит время инженера в Авито.
20% — написание кода (бенчмарк по индустрии — Майкрософт, 11%).
25% — техническое дискавери, то есть поиск нужной API, доки и человека.
15% — тесты.
8% — дебаг.
18% — чаты (у менеджеров около 50%).
14% — встречи.

Отсюда вывод: кто ускоряет AI-агентами кодинг, — ускоряют только пятую часть работы.

Моё любимое: запустили DevEx-опросы для агентов, удобно ли им пользоваться внутренними тулами. Агенты отвечают лучше людей.

И прогноз на 2027: код в эпоху агентов будет нестабильным, фокус уедет в observability. Хотя Change failure rate пока проблемы не показывает, этим надо заниматься превентивно, потому что проблема накопится.

———

Записи: YouTube, VK. Лукьянченко с 00:09:17, Арюткин с 00:50:52.

Какой из тезисов у вас не сходится с тем, что видите у себя? Еще ревьюите код людьми?

Кого и почему заменят AI-агенты

Пост наполнен ненавистью, я вас предупредил.

Это вторая часть, первая тут.
В прошлый раз я писал, что AI-агент — это тула, и тула сама по себе никого не заменит.
Это как если бы сисадмины боялись, что ci/cd пайплайны их заменят.

На текущем этапе я бы не стал готовиться к тому, что у нас будут AI-сокомандники, и им нужно будет писать "доброе утро" в командных чатах.

Но! Тула делает ценнее того, кто умеет ей пользоваться, поэтому заменят на самом деле не AI-агенты, а люди, которые умеют ими пользоваться.

Без современного тулинга сейчас уже просто невозможно успеть сделать достаточный объем работы, чтобы не выглядеть лоу-перформером на фоне сокомандников. Серьёзно. Если вы ждали какого-то сигнала, вот он. Поставьте себе Клода или Кодекс, заплатите 20 баксов и начинайте учиться.

Но предупреждаю о последствиях и зависимости.
Возникнет неконтролируемое и неосознанное желание отдаться AI-агенту полностью:
— принимать решения чисто как клод говорит
— общаться с коллегами прямо копипастя туда-сюда текстовки
— писать документы и не вычитывать их

Это экономит когнитивный ресурс, а человек — существо ленивое.
Поэтому очень легко стать "мясным прокси" без добавленной ценности.

И вот таких заменят в первую очередь.
Во-первых, потому что они начинают приносить больше вреда, чем пользы.
Во-вторых, просто потому что они очень бесят.

За прошедший месяц у меня было три бесячих ситуации от трёх разных людей.

———

Ситуация 1. Продакт составил документ по новой инициативе для внутренней защиты. С техническими деталями и архитектурой, но очень странными. Как позже выяснилось, тимлида и инженеров продакт не привлекал.
— Паша (обращаюсь к тимлиду), есть пара уточнений по архитектуре, можем сейчас обсудить?
— Впервые вижу эту архитектуру, док без меня готовил Вадим.
— Вадим (обращаюсь к продакту), подскажи пожалуйста: ... (пара сутевых вопросов)
— Не знаю, это клод нарисовал, я тут вообще не шарю, думал Паша расскажет.
— ¿?¡!

———

Ситуация 2. Скидывают документ на 11 страниц, "почитать". То что слог слоповатый и постоянно противопоставления "это не тёплое, это мягкое" — подбешивает, но ладно, уже привык.
К сутевой части возникли вопросы. Внутри в том числе организационный сетап новой команды и перечислено, кого надо нанять.
Читаю: собрались нанимать сисадмина в команду. Это очень странно, потому что инициатива продуктовая и должна по идее спокойно лечь поверх текущей техплатформы. А если и нанимать сисадмина, то опять же в техплатформу. В продуктовой команде ему просто нечего будет делать.

Задаю вопрос. Оказывается, эту часть читать не надо было. Документ читать надо вместе с автором на встрече, чтобы он показывал пальцем: «тут читай, тут не читай, тут ллм нафантазировал».

Бл#%ть! Почему я должен тратить время на чтение документов, на написание которых автор не потратил времени?! Это тупо неуважение к читателю.

———

Ситуация 3. Общаемся в чате с руководителем соседнего юнита на тему передачи одного инженера в его команду. С моей стороны запрос: покажите роадмап, чем будет этот инженер заниматься, и где там конечная точка чтобы поддержать нашу инициативу. А чувак кажется просто в чатжпт скармливает мои вопросы и копипастит ответ.
Читать невозможно: плотность смысла около нуля, странные термины, через абзац опять же «это не тёплое, это мягкое».

И в этой переписке решается, передавать ли одного живого FTE из команды в команду.
Судьбу человека решает чатжпт. Менеджер при нём — просто мясной прокси.
Бесит.

———

Что общего у всех троих — отсутствие добавленной ценности к тому, что выдал агент. Ни проверки, ни принятия решения, ни ответственности. Уберите их из цепочки, результат не изменится.

Заменят ли агенты кожаных? Вот таких — да.

Хорошая напоминалочка каждому: почаще задаваться вопросом "а какая моя добавочная ценность?"

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