Channels

Top 100 Trending New

Categories

Crypto Gaming News Entertainment Music Sports Tech Gambling Bots and mini apps Finance Business Education Lifestyle Health Travel Auto Fashion Jobs Dating Deals and shopping

Stickers

Stickers Emoji Themes Wallpapers

Bots Gifts Tools

Currency

$ USD ₽ RUB € EUR ₴ UAH ₸ KZT ₺ TRY zł PLN ₪ ILS AED AED R$ BRL Rp IDR RM MYR ¥ JPY ₩ KRW CN¥ CNY

Theme

Português (Brasil)

Bahasa Indonesia

Беларуская

Українська

Channels Categories Stickers Bots Gifts Tools

Premium Wiki Glossary Legal

Notifications Settings Log in

Дзен ПМа: post #157 — TG.ME

Дзен ПМа@dzenpm · 377 subscribers Open in TelegramOpen

t.me/dzenpm/157

July 17, 2026 204

More from this channel

Всем привет что я вижу сейчас касательно происходящих изменений: - разработчик не пишет код, он оркестрирует агентов, его работа теперь: проектировать архитектуру, задавать права, границы и цели для каждого агента, проверять результат - код стоит сильно меньше, не бесплатно, конечно, но сравнительно зарплат разработчиков - на порядки дешевле - код и раньше не был самой затратной частью по времени, хороший разработчик в сложном проекте писал код 20-30% времени максимум, поэтому ожидать что проекты будут выполняться в 10 раз быстрее - наивно. - скорость ускорения нелинейна. Условный лендинг ускорился в 100 раз, а сложная система с интеграциями - в 1-2 раза пока максимум. Чем выше цена ошибки - тем меньше ускорение - Можно очень быстро делать херню и узнавать об этом намного позже, когда приходится разгребать говнокод от ИИ. Без долгой и кропотливой подготовки и создания нужного harness обвеса (то есть что может и не может делать агент, куда у него есть доступ и какие права, формулировки измеримых целей и результатов его работы и тд) - высокий риск получить неэффективную кодовую базу, которую потом долго и больно исправлять. Я читал что один разработчик оптимизировал в несколько раз количество кода, который написал ИИ и затраты токенов на работу с этим кодом упали в несколько раз - не стоит забывать, что чисто статистически, чем больше строк кода - тем дороже его обслуживать и тем выше шанс багов. Как говорил один скульптор, скульптура тогда идеальна, когда нечего отнять, а не есть чего добавить. Простота все еще является сложнодостжимой и наиболее эффективной. - Garbage in - garbage out все еще справедливо, если на вход ИИ подаете что то невнятное, то результат будет далек от желаемого. - Ижиниринг контекста перешел от оптимизации промтов в инжиниринг контекста для каждого агента, то есть стал масштабнее и сложнее ну и касательно работы ПМа: - стало легко получить информацию о любой части проекта - стало легко готовиться к разговорам с клиентом или менеджментом - решения все еще ответственность ПМа, как и контроль - теперь можно вести больше проектов одновременно, однако работу с командой ИИ не автоматизировал, а это достаточно большой кусок работы ПМа - ПМы без тех бекграунда сильно проигрывают теперь тем, у кого он есть. Даже Engineering менеджеры, которые какое то время назад перестали писать код - теперь снова его пишут с агентами. Наличие тех бекграунда позволяет намного быстрее быть в теме и не бояться командной строки. Так же сильно помогает знать как выглядит хороший результат с технической точки зрения. - Клиенты ожидают бОльшей подготовки ПМа и более глубоких знаний как работает AI SDLC (жизненный цикл проекта) и что ПМ может внятно обьяснить чем отличаются уровни AI assisted, AI augemented и AI native подходы. Удачи всем нам в это нелегкой время новой реальности) Отличного дня! 109·Aug 12 всем привет Очень давно мне хотелось сделать поиск по прошлым пресейлам, за последние пару лет, чтобы в клоде спрашиваешь "вот новый пресейл, что похожее у нас уже было, что мы оценивали?" и он тебе выдает что мол такой то пресейл, там было все вот так, вот что общее, вот как это оценивалось, вот что в итоге, выиграли или проиграли. Вроде бы задача то несложная на первый взгляд, тем более что базовые артефакты в пресейлах прошлых часто похожи, их три категории: входные требования + транскрипт звонка с продажниками, экселька с wbs и оценкой, пропоузал (КП) Не буду углубляться в тех детали, скажу сразу что в итоге - нельзя просто взять кучу доков, закинуть их в ИИ и ждать магию) несмотря на то, что ии умеет анализировать, но если дать ему не очень унифицированные данные - то его точность будет хорошо если 50-60%, то есть в остальных случаях на выходе будет разная степень бредовости, что сильно снижает пользу итогового продукта В моем случае мне сначала надо было прогнать кажды прошлый пресейл через определенное количество шагов, чтобы на выходе получить структурированный json и набор токенов (chunks) для векторной базы. Я прогнал штук 10 и понял что прогнать еще 100+ мне надо будет убить часов 20, проще уже сейчас все последующие пресейлы сразу делать с таким итоговым стуктурированным файлом, которые позволит использовать его как исторические данные с минимальным количеством галлюцинаций. Похожий опыт у нас был в проекте для банка где надо было классифицировать входящие документы (инвоис, чек, банковская выписка и тд) и несмотря на наличие примеров таких доков для каждой категории, точность все равно была на уровне 80%, что не сильно совпадало с ожиданиями банка, что будет магия. Оказывается, что для повышения точности нужно намного больше примеров и дополнительное обучение модели) Сейчас экспериментируем вести весь пресейл в репозитории, чтобы там были сразу все письма, прототипы, исследования по этому пресейлу синхронизированно для всех участников команды пресейла. Все равно все используют ИИ в работе над пресейлом, так почему бы не хранить все это в одном месте, а не в личном аккаунте каждого, что теряется по завершению пресейла. Пока такой подход по ощущениям очень даже неплохо, при соблюдении базовых правил работы с репозиторием, обновления статусов, коммитов и тд, чтобы не превращать в мусорку. Поделитесь, что у вас меняется в подходе к работе с клиентами как менеджер с помощью ИИ? 148·Aug 7 Всем привет Раньше в разработке как было: требования написали, тасочки нарезали, закодили, протестировали, собрали вместе в релиз, потестили вместе - и в люди. Сейчас как вырисовывается? Два крайних варианта и много оттенков среднего между ними. Первый - полностью автоматизированный процесс производства ПО. Человеки загрузили требования в беклог, а там дальше чудо агенты сами разобрали, закодили, потестили и задеплоили, все это по кругу (loop). Аналогия с "тёмной" фабрикой, где нет света, потому что роботам он и не нужен, они и так все видят. Понятно что тут надо построить обвязку всю сначала, как и на такой фабрике, то есть установить ограничения для агентов, права, правила, тесты, стат анализаторы кода, и так далее. Но потом оно все крутится и производит ПО. Но есть проблемка - не умеют модели в архитектуру, особенно если речь про сложное ПО в сотни тысяч строк кода, а если легаси - то вообще ж..а В итоге тесты все зеленые, а спустя какое то время - приходится платить долги, в данном случае речь про тех долг, и переделывать огромный кусок. Второй подход - темная фабрика та же, но в некоторых местах на линии все же включаем свет и смотрим, а не херню ли мы тут производим. Как минимум в 2х местах мы свет включаем: сначала в начале где кожаный должен завалидировать дизайн системы и архитектуру, проверить что план от ИИ подходит для решения, а затем разработчик смотрит PR'ы от ИИ перед тем как это пойдет в деплой, валидируя что получилось норм. Но тут тоже проблема - кожаный становится узким местом из-за ограниченного количества когнитивной нагрузки, которую он способен вывезти. Само собой это его ограничение очень сильно меньше объема кода, который может выдавать машина. В итоге это наше очень узкое место, ограничивающее производительность всей системы целиком. Зато тех долг не копится и можно быть уверенным что кожаный понимает как работает это ПО и где там что, чтобы в случае каких то экстренных проблем можно было оперативно по старинке знать куда ударить молотком, чтобы заработало опять. Ну и само собой между этими двумя есть бесконечность вариантов. Что-то мелкое и с низким риском можно оставить в темноте, что-то крупное с высоким риском смотреть со светом. Вопрос кто как определяет риск, насколько хорош весь обвес (harness) вокруг агентов, насколько сложный и старый код, насколько критерии приемки задачи можно описать в точных величинах которые хорошо проверяются машиной и так далее. Именно вариации ответов на такие вопросы создают все оттенки серого, про которые я говорил. Можно нырнуть глубже в эту кроличью нору и обсудить графы, состояния и флоу чарты, но я пожалуй не буду пока, оставим это разработчикам. Признавайтесь, все еще работаете с добавлением ИИ как копилота в классическом цикле разработки или все же уже ступили на острие прогресса в компании где вы работаете? 178·Jul 29 Всем привет перехожу к следующей метрике. Кстати, в эпоху ИИ метрики уже есть новые, как разберусь в них получше, тоже опишу, а пока продолжаем по известным и хорошо опробованным Lead time и Lead time distribution Время от создания тикета до его завершения. От cycle time отличается тем, что включает время ожидания в беклоге. График распределения показывает категории сколько тикетов в какой отрезок попадает (см скриншот) Что мы видим на скрине: - половина тикетов делается за 20 дней, - 85% тикетов делается за 43 дня - 95% тикетов делается аж за 67 дней Как это интерпретировать, то есть что это может значить. Опять предостерегу от быстрых выводов по одной метрике - это слишком мало информации чтобы делать выводы, это всего лишь указатель куда посмотреть поглубже Само по себе такое время - это очень долго, а в текущих реалиях непростительно долго. Это признак нестабильного деливери процесса. Здесь прямо сильно обязательно разбираться глубже в чем может быть проблема. Потенциальные проблемы исходя из такого графика (одна или несколько сразу): - команда не успевает брать задачи в работу, не хватает капасити - новых тикетов появляется больше, чем выполняется, некоторые тикеты ждут своей очереди очень долго (системная проблема) - нет SLA (то есть какого то лимита на ожидание) - есть маленькие тикеты, закрываются быстрее, в первую неделю и есть тикеты побольше, которые ждут дольше, чтобы их взяли в работу - Тикеты закрываются пачками к концу спринта или релиза независимо от того, когда реально закончена работа — отсюда пик около 12-18 дней и провалы между корзинами. - Смешение разных типов задач в одной метрике (баги vs фичи vs технический долг). У них разная естественная длительность, и сложенные вместе они дают бимодальное распределение. - Хвост — это тикеты, заблокированные внешними зависимостями (ответ клиента, доступ, стороннее API), низкоприоритетные задачи, которые постоянно отодвигают, или тикеты с расползающимся скоупом без переоценки. - Отсутствие WIP-лимитов — если в работе одновременно слишком много тикетов, они физически не могут двигаться быстро, отсюда растянутый хвост. Что делать дальше: - Разбить lead time по типу тикета (баг/фича/техдолг) — вероятно, увидите два четких распределения вместо одного смешанного - Разбить lead time на wait time (до старта) и cycle time (от старта до завершения) - Посмотреть отдельно на тикеты из хвоста (48+ дней) — обычно там небольшая группа с общей причиной (один блокер, одна команда, один клиент) Отдельно стоит упомянуть что если новых тикетов появляется больше, чем завершается, то график распределения не будет отражать реальность, получится что тикеты стоят в очереди почти столько же времени, сколько работаются. Тут стоит посмотреть график возраста тасок в беклоге и кумулятивную диаграмму потока. ну и график в динамике - он будет растягиваться все больше со временем. Растягивающийся хвост как на графике в скрине - как раз симптом такой проблемы. По закону Литтла: Lead Time = WIP / Throughput. Если входящий поток (arrival rate) стабильно превышает throughput команды, WIP растёт без остановки. А раз WIP растёт, растёт и lead time — причём не линейно, а ускоряясь, потому что каждый новый тикет попадает в очередь, которая уже длиннее, чем была у предыдущего. В заключение - lead time метрика не является основой для каких либо выводов, но помогает как дополнительная информация в наборе метрик, чтобы сделать верные выводы. Всем отличной недели! 177·Jul 17 всем привет давайте про метрики поговорим опять, возьмем первую из тула, что я шарил - Производительность по неделям например, пускай у вас есть вот такие показатели Закрытие vs поступление в неделю (из демо сценария на основе экспорта из разработки реального продукта) Неделя Закрыто 05/18 54 05/25 21 06/01 13 06/08 12 06/15 45 06/22 26 06/29 34 что мы имеем? в среднем получается примерно 26 тикетов закрывается в неделю. По идее мы можем использовать эту цифру, чтобы сказать что следующие 100 тикетов мы закроем за следующий месяц? Но есть нюанс. Наша волатильность, то есть разброс в каждую неделю - 70%, это значит что в конкретную неделю мы можем быть плюс или минус 70% от этих 26 средних и это делает утверждение про 1 месяц сильно сомнительным. Я бы не стал обещать 100 тикетов в месяц при таких условиях руководству или клиенту, сначала пошел бы разбираться что в процессе деливери приводит к такому сильному разбросу. Для того чтобы делать такие обещания волатильность должна быть не выше 20-40% иначе погрешность может быть высокая и вы сделаете в итоге 70-80 вместо 100 за месяц и будете выглядеть не очень хорошо перед лицом тех, кому вы это пообещали. При волатильность 20% вы сделаете больше 90 тикетов минимум (с большим шансом что и 100 и выше) и это будет хорошим результатом В данном случае примера проблема в длинном cycle time и узких местах, когда тикеты застревают в тестировании на много дней и долго ждут релиза. Прежде чем обещать что-то - стоит разобраться с этими проблемами и снизить cycle time в идеале до недели и меньше и/или уровень волатильности ниже 40% В вашем случае это может быть что-то другое, но такой разброс явно указывает, что вам стоит посмотреть глубже, в том числе посмотреть на другие метрики, делать выводы на основании одной единственной метрики - это почти всегда делать неверные выводы. Всем отличной недели! 194·Jul 12

An open web layer over public Telegram — search, stats and channel reading right in your browser, no account, no install.

Not affiliated with Telegram FZ-LLC; all data comes from public sources.

Catalog

Top channels Categories Countries Search

Content

Stickers Emoji Gifts Themes Wallpapers

Help

Tools Wiki Glossary Blockchain Safety Premium Advertisers Advertising

© 2026 TG.ME · G.Media network· Updated 08/28/2026 · v0.2.0 · c9ad1b1

Privacy Terms DMCA & complaints Report a violation

Similar channels

Проджект маминой подруги!1.2K subscribers

PRO PM2.4K subscribers

Junior AI PM7.4K subscribers

ИТ САМОУЧКИ2.9K subscribers

ПМ совет7K subscribers

Селиховкин - не скучно о проектах8.3K subscribers

Менеджер от боженьки25.3K subscribers

Срок - вчера692 subscribers