Хороший продакт - это король Discovery, кухарка в Delivery и куртизантка на защите бюджетов.

Фух, 2026 ваще рядом!
Будет ли он лучше, чем 2025?Однозначно!
Труднее?
Несомненно!

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

Мы стали взрослыми и теперь это наша работа.

Хочу пожелать, чтобы каждую минуту у нас находился повод для улыбки.

И в 90% случаев, то, что кажется сложным и трудным сейчас попадет в список «год спустя» и будет тем, что сделало нашу жизнь лучше, а нас сильнее.

С наступающим Новым годом!
Спасибо, что читаете!
Круто знать, что столько умных, замечательных людей рядом!

#пятничное

Ну как вы там? Че по салатам?
😎 - все съел и еще приготовил!
🦄 - чисто по сушам и пицце
🔥 - еще доедаем! На 3-й день только вкуснее

Что там ждет нас после Agile?

Кому как не консалтерам из McKinsey рассказывать нам о том, как изменится работа будущего?

Что говорят нам ребята:
1.
Agile придумали для людей (все эти стендапы, 2 pizzas и прочее).
2.
Индивидуальная производительность выросла: каждый из нас может сделать больше в единицу времени (написать код, проверить гипотезу, почеленжить свои мысли, найти нужные исследования).
3.
Процессы разработки: код-ревью, ручное тестирование, декомпозиция задач и написание спецификаций, документация остались прежними.
4.
Старые метрики, такие как: DORA, velocity и т.п. уже не работают, так как не отражают происходящего. Точнее вот так: DORA - важна и нужно, но с AI не связано.

А все мы знаем, что если ускорить один этап производства, то другие становятся узкими горлышками. Тут это видно наглядно.

Agile 2.0 - это про AI native подход в процессах:

1.
Команда - это 3-5 человек, условных фулл-стек, которые управляют агентами.
2.
Spec-driven development - спецификации теперь становятся критичными. Теперь при их написании мы должны быть однозначны. Никаких расплывчатых формулировок, тупиковых веток и т.п. Четко и структурировано.
3.
Новые роли:
инженеры теперь оркестируют агентов, ищут пути, как дать максимум контекста агентам, как построить безопасную и качественную архитектуру.

Продакты сами прототипируют и проверяют свои гипотезы.
4.
Пора перестать следить за старыми метриками (DORA (все еще нужна и полезна, но AI эффект померить не позволит), Velocity и т.п.) и начинать следить именно за flow-метриками.
То есть основная ценность:
- latency от идеи до прода
- стоимость человеческого участия
- rework как сигнал плохих спецификаций
- throughput системы, а не команды.

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

А вам такие обзоры интересны, в принципе?

❤️ - да, продолжай
🎄 - ну соу, соу, не всегда интересно, но продолжай
💊 - перестань и старые удали

Если вам интересно, а какого эта фига, я приложил очень странную картинку к посту утром, то знайте:

В ТГ появилась саммаризация длинных постов.

Саммаризация не всегда работает адекватно.

И я решил собрать саммари для вас сам😉

A Vision For Product Teams - Марти Каган

Короче, статья отрезвляющая и эти мысли у меня давно в голове. Не уверен, что если вы впечатлительны, то стоит читать дальше.
Статья отлично дополняет те мысли, что я излагал в понедельник в обзоре доклада маккинзи.

1.
Марти Каган - автор топовой книги Вдохновленные для продактов рассказывает свой вижен будущего на горизонте 3-10 лет.

2.
Если вы, по сути, трудитесь в feature factory team (это когда ваша задача деливерить фичи придуманные кем-то), то в будущем ваши компетенции не будут востребованы так, как сейчас.
И да, переживать стоит. Потому что новые инструменты ускоряют как раз Деливери.
Конечно, всегда найдутся компании, кто будут продолжать «жить по старому», но это лишь даст больше времени.

3.
Если вы трудитесь в product team (это, когда 90% времени вы тратите на поиск решения, рынка, сами отвечаете на вопрос, что делать дальше и т.п.), то ваши компетенции будут все так же востребованы, но радоваться рано: Марти подтверждает, что состав команд в будущем изменится.
В будущей продакт Тим будет нужен:
-продакт менеджер
-UX дизайнер
-Инженер.

Ага, вот так вот всех по 1-му… И этого хватит.
И представляете, какая будет конкуренция за возможность быть в этой команде.

4.
Возможно, нам повезет и случится бум стартапов, в который приземлится вся наша трудовая мощь, но на сколько это вероятно?

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

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

Ну че, кто что думает?

❤️ - Марти Каган столб индустрии. Дело говорит.
🔥 - отставить панику, особо ничего не изменится.
💊 - ну вот, я на панике!

Остап Бендер плохого не посоветует!

Так что давайте-ка в понедельник прямо и начнем!

🔥 - если ты уже горишь и рвешься к трудовым буржуазным будням!
❤️ - если ты еще не готов и ищешь поддержки
💊 - ееееее-ма-ееее, уже пятница! Ну за чтоооо

#пятничное

Ладно, раз уж это пятница, я считаю, такая двойная, то забирайте еще 2-й мем!

Классические модели оценки Storypoints, Functionpoints не работают!

А что если я вам скажу, что Storypoints, Functionpoints имеют мало общего со сложностью задач?
И мысль тут не моя, а ребят из Stanford - Егора Денисова-Бланш и его коллег.

Но как так получилось?
Они разработали модель, натренировали ее на 100+ тыс.репозиториях и 10 экспертах в разработке, а затем проверили и убедились, что лучшая метрика - это сколько инженерного усилия и сложности было в фактических коммитах!

Обычно, вот эта задача оценки сложности хм…сложная!
Но статья ребят раскрывает то, как это посчитать.

Фактически, метрика комплексная и состоит из следующих:
1.
Сколько времени (в часах) в этом коммите “закодировано”
2.
Насколько трудной была задача, судя по коду и контексту
3.
Какие объективные признаки сложности есть внутри изменений (кохезия, сложность, coupling, архитектурные изменения, объём и тип модификаций)

И как менеджер вы скажите мне:

«Да нафига мне оценки сложности уже после написания когда?»

И тут я сижу «сижу на двух стульях» вместе с вами и ребятами, кто готовил статью:
1.
Как менеджер, я хочу знать оценку до старта.
Но оценка до старта - это гипотеза. Фактически, это шум!
2.
Но как эксперт я понимаю, что люди отваритетельно оценивают задачи и планируют.

Авторы прямо пишут, что их результаты «подсвечивают ограничения традиционных forward‑looking методов» и что backward‑оценка по коду даёт более точную меру усилия.

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

А разве умение учиться на основе прошлого не ключевой навык менеджера?

«Storypoints - это гипотеза.
Код - это факт.
Без измерения факта гипотеза никогда не станет лучше.»

А вы верите в умение людей оценивать сроки?

🔥 - да, люди умеют оценивать сроки с достаточной точностью
🦄 - ох о чем вы, сроки мы особо оценивать не умеем
😎 - оцениваю сроки с точностью до минуты

Это на фото я такой умный, красивый и здоровый, в реальной жизни я в 8 утра на электрофорезе🤣
На самом деле - это о взрослом отношении к себе.
К сожалению, чудес не бывает и со временем все тяжелее поддерживать ритм, здоровье, спорт, семью, работу. А так как прожить хочется яркую, длинную и здоровую жизнь и стать частью той самой «серебряной экономики» не в виде развалины, то задумываться о себе приходится уже сейчас. При условии, что таких возможностей у нас дофига (ОМС прекрасно работает), то почему нет.

Так что, сначала курс электрофореза (я не могу перестать ржать от этого слова), а затем уже курс массажей.

В общем, не только спортом 3-4 раза в неделю тело живет, но и о восстановлении не забываем.
Еще бы сна дотянуть до 8 часов, но это так, из области фантастики.

#пятничноеневпятницу

Пу-пу-пууууу
В общем, долги то отдавать приходится, получается!

1.8 млн. инженеров (ghost engineer) ничем не занимаются на работе!

Ну че, помните я вам тут в понедельник рассказывал о модели, которую придумали ребята из Стенфорда для оценки сложности решенной задачи?
Ну вот они пошли дальше и написади статью (статья не является строго научной!), в которой ввели термин ghost engineer и вот, что они нам говорят (вот тут видос, если что):
1.
Эти парни делаю лишь 10% работы от медианы в рамках эффективности в своей компании. То есть делают только 10% работы от средней нормы в своей организации.
2.
В публичных описаниях приводятся характерные признаки «призраков»:
• 58% из них делают меньше трёх коммитов в месяц;
• 42% ограничиваются тривиальными изменениями на одну строку/символ.

Что вызывает спорные чувства?

1.
Написание кода - лишь малая часть работы. Хотя модель ребят из стенфорда пытается учитывать и это пусть и косвенно через сложность задач.
2.
Подобный подход никак не позволяет учесть менторство, ревью, проектирование архитектуры, время на встречах.
Хорошо бы в эту модель докрутить Google InSession (ранее рассказывал о подходе Гугла для анализа информации по ивентам, куда уходит время у разработчиков).

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

А как вы оцениваете наличие ghost engineer в вашей компании?

❤️ - у нас таких нет
👍 - от 5 до 10%
🔥 - от 11 до 25%
🦄 - только я и работаю

Е-ма-е, а я то пропустил:

10 января каналу исполнилось 3 года!

Офффигеть, просто!

За 3 года канал изменился,
я изменился,
вы изменились!

Стали ли мы лучше и опытнее? Однозначно!

Выросли ли мы с вами?
Ну как можно с этим спорить!

Изменился ли рынок?
Да просто, капец!

Стали ли мы умнее?
Сомнений ровно 0!

Блин, спасибо вам, что вы читаете! Правда и искренне!
Мне безумно приятно осознавать, что мои рекомендации, обзоры книг и статей, мои советы и мой опыт вам помогают и делают этот мир чуточку лучше!

Один из моих руководителей всегда заканчивал поздравления постой фразой:

Дальше больше!

Так и у нас с вами «дальше больше».

Всех обнял, приподнял, покружил и на место поставил!

🎉 - если ты с каналом больше 2-х лет
🦄 - если ты тут от 1 до 2-х лет
😎 - если меньше года

#пятничное

❤️ - если жиза
💊 - если все не так
🔥 - поддержать бедолаг

Так-с, давайте договоримся, что вот в следующем году никаких «после праздников», а то потом вот эта вся фигня случается.

Договорились?

❤️ - да, погнали
😎 - давайте уже после майских обсудим
😭 - если ты там плачешь

А сможете доказать ROI от AI в разработке?

Продолжаю разбирать выступления Егора Денисова-Бланша (Yegor Denisov-Blanch) и сейчас разберем его выступление на конференции AI Engineer Code Summit 2025 в Нью-Йорке с таким провокационным вопросом :-)
Ох, и поверьте, разбираю я все это не просто так: готовится кое-что интересное для вас😉

Доклад основан на результате двухлетнего исследования влияния AI-инструментов на продуктивность разработчиков, охватывающего 120 000+ разработчиков в 600+ компаниях (ох какие вкусные цифры тут).

И я все размышлял об этом видео и думал, о чем же оно?

И как будто это видео - диагноз или наоборот индульгениця всем нам: мы видим рост продуктивности от AI локально, но как, блин, повысить эффективность на круг и посчитать экономику? Че там по ROI?

1.
Качество от использования AI зависит от индекса чистоты окружения: качество кода, документации, модульность кода и т.п. В общем, техдолг и тут мешает. Так что бегом проверять, что у вас там с ним.

2.
Использование AI = рост энтропии/тех.долга. Так что, давайте попросим ребят инженеров засучить рукава и следить за качеством кода, генерируемого AI.

3.
Много токенов не равно, что вы молодцы и получаете нужные эффекты. При росте свыше 10 млн.токенов на инженера эффекта уже не наблюдается, скорее даже такие команды показывают результаты хуже.
Моя гипотеза тут в том, что это говорит о низком качестве того самого индекса чистоты окружения => много токенов тратится на контекст.

4.
Средний прирост продуктивности составил 10%. Однако, есть значительная разница между лидерами и остальными.

Ииии самое важное, как мерить-то Егор нам предлагает:

Engineering Output - собственно говоря, та самая продуктивность. Если я верно понимаю, то Денис тут предлагает использовать их же ML модель про которую я уже рассказывал: модель, симулирующая оценку 10-15 экспертов, позволяющая оценить ретроспективно сложность решеной задачи.

Конечно, не стоит забывать и про Guardrail metrics и Егор о них не забыл:
Rework & Refactoring, Code Quality & Risk, People & DevOps

Мне прямо очень нравятся мысли Егора, но сам подход все больше напоминает хм…прогрев аудитории перед запуском чего-то, а-ля консалтинга и т.п.😁


А у вас уже был опыт расчета эффектов от AI?
😭 - это я не плачу, это мне «Эксель в глаз попал»: считал и вовсю
🔥 - прямо сейчас в процессе
🦄 - пока «естественный» тренируем

Смотрите какая мне красота приехала?
Будем читать и рассказывать

Кажется, это лучшее объяснение для понимания жизни в корпорациях, да и не только в них.

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