Junior AI PM

#мнение Место менеджмента AI-native оргструктуре Привет, читатель! Не знаю заметил ли ты, но я избегаю 3 тем: SOTA-моделей, автономных агентов и AI native команд/компаний Наткнулся на доклад AWS про команды в мире агентского ИИ. Не про инструменты, а про то, как меняется операционная модель когда стоимость владения падает: 1. Экономика AWS дает развилку Use / Compose / Build. Build оправдан только при уникальном процессе. Для большинства первичен разбор потока: где ценность, где теряется контекст, где нужна проверка. AI-native начинается не с модели, а с описания процесса как системы исполнения 2. Таланты и новые роли AWS вводит expert generalist: человек, который ведет процесс целиком. Фаулер разделяет why-loop и how-loop: человек сильнее в выборе что и зачем, агент в исполнении. Эндрю Энж: сборка ускоряется, узкое место смещается в продуктовые решения Отсюда роли. Product builder вместо PRD приносит проверяемый прототип. Product Engineer сам ближе к пользователю и метрикам. Forward deployed engineer тащит агентов в процессы клиентов, потому что между демо и продакшеном лежит слой интеграций и ответственности 3. Структура команд Четыре формы: пирамида, ромб, перевернутая пирамида, песочные часы Пирамида растит людей, но буксует на передачах. Ромб появляется когда режут джунов: пайплайн кадров умирает. Перевернутая пирамида как боевая капсула: сильные спецы и агенты. Песочные часы: автономные команды сверху, тонкий управленческий слой, обучение снизу. Team Topologies дает тот же принцип: команды вокруг потока ценности и когнитивной нагрузки. AI-native команда это не сквад с агентами, а компактная единица с ответственностью от начала до конца 4. Операционная модель Модель A: разработка строит, эксплуатация поддерживает, для агентов не работает. B: построил сам, запускаешь сам, работает в малом масштабе. C: автономные команды плюс платформа. Продолжение DevOps, не новая история. Агентский ИИ не отменяет DevOps. Он делает незавершенный DevOps дороже 5. Управление и контекст Управление агентами сводится к идентичности, правам, допустимым действиям и аудиту. Не регламент на полке, а исполняемый контур ближе к PRR из SRE. Фаулер формулирует: агент это модель плюс обвязка из правил, инструментов, проверок и контекста. Документация часть среды исполнения. Палантир-модель показывает: доменные понятия должны быть явными 6. Проджект-функция Каган разделяет продуктовые и фича-команды. ИИ ускоряет фича-команды, но не делает их продуктовыми Старая админ-функция сжимается. Отчеты, статусы, пушинг, перфоманс ревью, это компенсация плохой структуры. Новая мидл менеджер-функция это управление условиями исполнения. AI-native убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь

Уровень C1 нативный вайбкодерский

#иное Митап Agentic Harness: что под капотом 9 июля проводим открытый митап про устройство AI-агентов и агентских систем. Будем разбирать не общие разговоры про «агенты скоро всё сделают», а практическую инженерную часть: как агент получает контекст, вызывает инструменты, работает с MCP, skills, hooks, memory и внешними сервисами. Дата: 9 июля Время: 18:30–21:15 Место: БЦ «Q», ул. Желтоксан, 191, зал Jailau Формат: офлайн Алматы + онлайн трансляция Регистрация: https://luma.com/48q2s0f5 Доклады: Кастомизация агентских харнесов на примере Pi Павел Королев — Android Tech Lead в QazCode Поговорим о том, как настраивать агентскую систему под конкретные инженерные задачи: workflow, точки расширения, практические ограничения, и сравнение решений. Контекстный движок CodeAlive и code exploration benchmark Родион Мостовой — AI architect, co-founder CodeAlive.ai Родион расскажет, как в CodeAlive устроен собственный агент и контекстный движок, как команда подходит к code exploration, что измеряет в бенче и как добивается сильных результатов на Qwen 3.6. В чем настоящая ценность agent skills Артем Летюшев — Tech Project Manager в twinby.com, гильдмастер AEG Разберем, зачем нужны agent skills, чем они отличаются от обычных промптов и как становятся переиспользуемым слоем управления агентами. - - - Митап будет полезен AI-инженерам, LLM-инженерам, дата-сайентистам, вайбкодерам, техническим менеджерам и всем, кто уже собирает AI-инструменты в реальных проектах.

#мнение Какие проджекты сейчас не нужны Здравствуй, дорогой читатель. Тема болезненная. Но попробую без эмоций, чисто по рыночной логике Я полагаю ты заметил как попритихли чаты, группы, конференции и образование. Рынок перестал покупать не проектное управление как таковое, а harness management. Давай разберемся, кто именно попадает в зону риска 1. Проджект-администратор Ведет Jira. Собирает статусы. Двигает карточки. Напоминает про дедлайны. Пишет отчеты. Организует созвоны. Раньше это выглядело как полноценная работа - процесс был тяжелым, контекст размазан по головам, автоматизации минимум. Сейчас это всё чаще выглядит как дорогая операционная обвязка, которую либо автоматизируют, либо распределяют внутри команды. Человек-напоминалка с зарплатой мидла 2. Проджект-прокси Не понимает продукт. Не понимает домен. Не понимает техническую часть. Просто берет слова заказчика, несет разработке. Берет слова разработки, несет заказчику. Классический глухой телефон, только с окладом. Часто это любят оправдывать областями управления стейхолдерами и коммуникациями. Такой человек не снижает неопределенность - он добавляет еще один слой искажения. В мире, где контекст можно за 15 минут собрать из кода, документации, логов, аналитики и истории решений, роль посредника-пересказчика выглядит всё слабее 3. Ритуальный agile-проджект Да простят меня все agile/scrum/kanban/modern ManOps коучи. Умеет проводить дейли, ретро, планирование, груминг и ревью. Не умеет объяснить, зачем именно этот набор ритуалов нужен конкретной команде в конкретной ситуации. Спринты есть - значит, у нас скрам! Ретро проводим - значит, мы agile! Если скрам, канбан и Confluence живут не потому, что помогают быстрее принимать решения, а потому что так принято - это уже не управление. Это налог на скорость. Карго-культ в чистом виде. Ритуалы без эмпирики, церемонии без обратной связи, процесс ради процесса 4. Непогруженный delivery manager Отвечает за сроки и часто упоминает управление end-to-end и оптимизацию потока ценности, но не понимает инженерную реальность. Не может сам прочитать базовую документацию, глянуть MR, разобраться в логах, понять, где реально риск, а где команда просто плохо объяснила. Казалось бы, зачем ПМу лезть в инженерку?? Затем, что без минимального технического контекста ты не можешь отличить реальный блокер от плохо сформулированного статуса. Ты не снижаешь неопределенность - ты её маскируешь красивым отчетом. И быстро превращаешься в человека, который давит на команду снаружи, но не помогает ей внутри Давление без понимания - самый токсичный вид менеджмента. И, к сожалению, самый распространенный в кровавом энтерпрайзе 5. Менеджер-маршрутизатор На требования зовет аналитика. На архитектуру - техлида. На приоритеты - продакта. На конфликт - Head of. На сложное решение - CTO Сам при этом остается фасилитатором чужой работы. Роутер с зарплатой сеньора Часто совмещено с типом 2. Человек вроде отвечает за результат, но почти ничего не может решить сам. Ни экспертизы, ни полномочий, ни собственной позиции. Тач тайм на проекте стремится к нулю, а в расписании - сплошные эскалации Если единственный твой инструмент - позвать кого-то умнее, то зачем ты в цепочке? 6. General management без домена Я умею управлять людьми и процессами - раньше звучало солидно. Сейчас звучит как: я всё и ничего Рынок образования тоже это подтверждает. Классические MBA теряют часть привлекательности. Студенты уходят в прикладные треки - data, AI, finance, supply chain, domain-specific skills. В Китае вообще жестко: университеты массово режут устаревшие management-программы и добавляют технологические Широта без глубины перестает продаваться. Рынку нужен T-shaped профиль: широкий кругозор + глубокая экспертиза в конкретном домене. Просто менеджер - это уже не профессия, это описание активности - - - P.S. Из всего этого не следует, что проджекты больше не нужны. Это слишком плоский вывод, и я его не делаю/ Скорее так: больше не нужен проджект как человек-обвязка

Идея продукта есть, а разработчика нет. Нанимать дорого, учиться программировать долго. Третий вариант появился недавно: вайбкодинг, когда описываешь словами, что хочешь, а AI пишет код за тебя. Звучит как магия, но на практике сразу возникают вопросы: • С какого инструмента начать, если ты не из IT? • Что реально работает, а что — красивые демо из твиттера? • Как довести прототип до продукта, которым можно пользоваться? В телеграм-канале «Это вайбкодинг» команда, сделавшая 100+ SaaS за год, рассказывает, как создавать рабочие продукты, прототипы и автоматизации без помощи разработчика. Простым языком для предпринимателей, маркетологов и менеджеров. Подписывайся на «Это вайбкодинг» — разбирайся в AI-разработке без единой строки кода.

☝🏻☝🏻☝🏻 Как же хорошо сказано, Артём как боженька молвил. Добавлю еще про смерть героев старой школы. Я обычно улыбчивый и няшный, но читать надгробные записки тоже умею. Эпитафия сеньорам Уважаемый сеньор старой школы, который отлично умеел раскладывать архитектуру, проектировать партиционирование базы данных, продумывать проект как от миллиона пользователей перейти на 10 миллионов, знающий, как с Оракла мигрировать на Кассандру. Раньше ты был звездой. Ты качался до этого 10 лет, и в команде у тебя было звание почти Святого Гавриила. Но пришла новая школа, новый уклад. Пришли великие агенты и AI. Ты смотришь на это, и тебе кажется, что это порождение нейрослопа для школьников, которые теперь могут писать B2B SaaS за три дня, а твои навыки незыблемы, и тебе эти AI-помогаторы не нужны Так вот, дорогой друг, у тебя теперь два стула. Выбирай любой. Стул первый - это продолжать игнорировать AI-агентов. Ты также будешь руками читать архитектурные защиты и поучать разработчиков, как правильно делать архитектуру. Но проблема в том, что теперь они будут приносить тебе таких проектов в 10 раз больше, и руками сидеть с ними ты будешь вечерами и ночами. Ты раньше был гением, который мог проработать проект длиной в три месяца для команды из пяти человек, затрагивающий изменения в десяти микросервисах. Это у тебя занимало две недели, но результатом потом гордился весь отдел. Проблема в том, что теперь у тебя таких проектов будет семь. И руками вдумчиво сделать это уже не получится, только через овертаймы. А новые ожидания этого не позволят. Если ты осознанно решишь не обучаться возможностям современных агентов, то за следующий год ты довольно быстро проиграешь войну чувакам-мидлам, которые освоили эти инструменты профессионально. Тебя просто не будет хватать на их всех, и с точки зрения производительности тебя обскочит средний мидл, умеющий в четыре сессии разрабатывать и архитектуру, а еще вести проекты. И в итоге, какой бы ты ни был умный, в новом мире ты будешь работать на скорости х0,3 и буквально через полгода тебя может заменить человек, которого ты нанимал. Но есть и второй путь, дружочек. В этой альтернативной реальности ты откладываешь всё и с головой уходишь в claude code, codeх или open code. Понимаешь, как правильно вместе с ними проектировать ту же архитектуру, которую раньше ты делал две недели - за два дня. Понимаешь, как завернуть эти скиллы в AI агента-архитектора, который работает автономно, и к которому твоя команда может приходить с вопросами. Понимаешь, как создать постоянный код-ревью в рамках своей части сервисов, который масштабирует тебя и твои знания в десятки раз. Да и в целом ты сможешь, заперевшись в темной комнате, обложившись десятью вкладками Claude Code, за неделю дня сделать работу, которую в прошлом мире делала бы команда из пяти человек целый месяц. И с такими знаниями и умениями ты с уровня Архангела Гавриила превознесешься до архитектора Матрицы. ——— Все совпадения случайны. Не принимайте близко к сердцу Эпитафия касается не только сеньоров, а спецов на любых уровнях. Мастерство с AI-агентами кратно ускоряет ваши возможности и потенциал, мультиплицирует их. Если вы не знаете ничего, то вы будете в 10 раз большей слоп машиной. А если у вас есть базис, то этот базис ускоряется в 10 раз. Так что качайте базу и качайте мастерство AI инструментов. ——— P.P.S: забыл один важный момент. Текущим сеньорам в среднем по 30-40 лет. И в этом возрасте частенько наступает нежелание разбираться в чем-то большом и новом, похожее на то, как миллениалам после инстаграмма было влом понимать фишку Snapchat. С AI агентами - похожая тема, нужно пересилить себя и поесть грязи первые пару месяцев, мозг должен чуть повернуться. Буквально, помню как затирал одному руководителю службы (моложе меня) тему про авто-генерацию SQL агентами и получение данных из БД по естественным запросам, а он говорит: "Лёх, я слишком стар для этого дерьма, пусть молодые играются". Не надо так други, чуть чуть покопать и там внизу золотые горы.

Меня репостнули и продолжили мысль, делюсь с тобой, дорогой читатель!

#мнение Эпитафия разработчикам Традиционный разработчик старого толка должен исчезнуть. Не инженер. Не человек, который думает архитектурой, данными, рисками и продуктом. А именно разработчик, который до сих пор считает, что его главная ценность - руками писать привычный код привычным способом ИИ не убивает качество разработки. Он убивает узкие места и оправдания. Уже июнь 2026 года, запомните этот пост: - Писать тесты и держать coverage - база - Настроить CI - база - Знать, что такое quality gates - база - Думать про архитектуру и защитное программирование - база - Делать работу, которая раньше занимала спринт, за день-два - база - Вести пару проектов параллельно - база Раньше это называли высокой инженерной культурой. Теперь это минимальная гигиена Странно руками открывать DevTools и тыкать всё самому, если агент может пройти сценарий, снять логи, проверить DOM, найти ошибку и принести гипотезу. Странно руками писать миграции. Вы же модельки руками не пишете? А что так? Контракт first, схема first, миграция first, тест first - агенту вообще по барабану, ему не лень. Странно руками собирать зависимости, конфиги, workflow, nginx, Dockerfile, pre-commit и линтеры, когда это давно должно генерироваться, проверяться и фикситься автоматически. Это совершенно обычный сетап Традиционный разработчик говорит: ИИ пишет не так, как я люблю. И что? JavaScript тоже компилируется не в тот ассемблер, который тебе привычен. Ты просто его не видишь. А тут увидел diff и начал защищать не качество, а свой вкус Код - это побочный продукт требований, контрактов, тестов, ограничений, контекста и обратной связи. Коллаборации людей в общем Хороший разработчик теперь не тот, кто лично написал каждую строчку. Хороший разработчик тот, кто построил систему, где агент может быстро писать код, тесты ловят ошибки, линтеры держат стиль, CI режет мусор, rollout снижает риск, observability показывает последствия, а архитектура не расползается после третьего промпта ИИ делает баги - да. Люди тоже делают баги. В моем опыте даже больше. Просто раньше вы называли это разработкой, а теперь внезапно стали эстетами качества Наша бизнес-логика слишком сложная, ИИ не поймёт - значит вы плохо видимо разбирались если кодовая база меньше 2 млн строк кода вдруг сложная и не проглатываемая агентом с специальными обвязками вроде контекстного движка, кодграфа и внешней памяти фактов Кто-то скажет. Я не хочу работать с кодом, который не понимаю - значит, пора учиться понимать систему и выстраивать ее, а не каждую строку. В 2026 вопрос уже не внедрять ИИ или нет в разработку. Вопрос: что нужно поменять в себе, команде, процессах, архитектуре и продукте, чтобы ИИ стал нормальной частью разработки —— Здесь лежит традиционный разработчик. Он ревьюил каждую строку инлайном, спорил с агентом про стиль, боялся больших diff, презирал AI-слоп, презрительно говорил фу вайбкодеры, ломал своими правками чужие тесты и не мог написать документацию за код и любил три недели продумывать архитектуру, но до последнего был верен тому, что его призвание писать чистый код

#мнение Эпитафия вайбкодерам Вайбкодеры старого толка должны исчезнуть. Вайбкодинг родился не из любви к инженерии, а из усталости её ждать. Идея была красивой: берёшь Cursor, v0, Vercel, Supabase, пяток SaaS-костылей и собираешь продукт чисто человеческим языком, вообще не вникая в скучный код Первые часы это правда работало как наркотик. v0 рисовал UI, Supabase заменял бек, Cursor плодил файлы, а модель ласково пела, что архитектура теперь cleaner and scalable. А потом наступала реальность Ты понимал свой проект ровно до тех пор, пока он влезал в .cursorrules. Дальше шли ARCHITECTURE.md, DATA_MODEL.md и простыни текста с мольбой не трогать то, что чудом работает. Ты не владел системой,ты руками пересказывал системе саму себя, потому что модель опять забыла, что у юзера есть profile Старый добрый вайбкодинг - это не магия свободы. Это был чистый error-driven development. Запустил, упало, скопировал логи из терминала (агент сам их прочитать не мог!), получил You're absolutely right, агент поменял три файла - упало в другом месте. Нужен SQL? Идешь в DBeaver сам, потому что дать агенту выполнить миграцию самому страшно и не факт что выполнимо. Просил схему? Копируешь в Swagger руками спеку, и сам выполняешь потому что сгенерированные curl-запросы падали даже от факта своего существования Мы боялись shell-команд. Любое "заодно очищу временные файлы" звучало как хоррор. Смотришь на rm -rf и гадаешь: он сносит dist или сейчас выпилит полпроекта ради clean state? А режиму Plan Mode радовались не потому, что повзрослели. Просто до этого агент лез в код с энтузиазмом джуна и сносил всё подряд. План хотя бы давал шанс сказать "остановись, родной, поправь кнопку, остальное НЕ ТРОГАЙ" Промпт-инженер не стал профессией, это теперь базовая грамотность, как умение гуглить. Контекст-инженер тоже не стал шаманом с markdown-бубном. С вайбкодером будет так же. Ты либо учишься собирать продукт в AI-native workflow, либо честно пилишь прототипы на коленке. Всё, что посередине -> очень дорогой театр непонимания —— Здесь лежит вайбкодер: описал проект в .cursorrules, схему проверил, SQL запускал, молился на Supabase, боялся shell-скриптов, дифф не дочитал, но агент сказал что все ок, значит деплоим и пишем в чат вайбкодеров о новом кейсе и просьбе апваоута на продуктхант

#сообщество Гильдия ИИ Инженеров: что получилось за 5 дней Дорогой читатель, за 5 дней с запуска чата Гильдии мы незаметно пробили планку в 350 участников. Но главное не цифры, а сдвиг в поведении: вместо разгонов про очередные новости вроде как верно идем в прикладное комьюнити. К нам присоединились крутые авторы: Валерий Ковальский, AI и грабли, Max: AI, Engineering and Startups, Поляков считает, Константин Доронин, AI-Driven Development,  Тимур Халалев про AI Coding , DEKSDEN notes, Neurogen, drugoi.dev, Meet Deadlines! За эти дни мы успели: - Написать 1.5к+ сообщений; - Меня все же соблазнили на тулзу rtk, и по итогам я накатал статью на Хабр; - Докрутил и выложил скрипт для синхронизации GitLab, Confluence и локального проекта, который сильно экономит время тем кто перестал писать ТЗ руками; - Чтобы закрепить теорию делом, мы запустили первый мини кампейн и пишем открытый парсер телеграм каналов под сбор вакансий для ИИ специалистов; - На следующей неделе проведем открытый стрим по оркестрации агентов; - А в начале июля организуем оффлайн митап в Алматы и еще авось где, пока секрет. Мы строим не очередной душный канал с новостями, а распределенное инженерное комьюнити без воздуханства. Среду, где авторитет измеряется реальным вкладом и публичными артефактами Пока полет отличный, работаем. Поставьте пожалуйста больше 💩, это меня изрядно развлекает и интригует

#сообщество Гильдия ИИ-Инженеров: строим ламповое комьюнити Дорогой читатель, есть кое-что, чего мне давно не хватало: место, где ИИ-инженеры собираются не ради хайпа, а ради дела. Где можно поделиться рабочим промптом, разобрать архитектуру агента или показать свой опенсорс и получить нормальную обратную связь. Где люди будут постоянно и активно делиться своими наработками Поэтому мы запускаем Гильдию ИИ-Инженеров 🤖 Пять базовых принципов: 1. Макрокомьюнити: открыто для всех. Дата-сайентисты, ML-инженеры, вайбкодеры, бухгалтеры с Cursor. Без элитаризма и снобизма 2. Open Source и реальный вклад: мы не просто чатимся, а создаем осязаемую пользу вместе 3. Практика: реальные кейсы, дебаг и живые проекты вместо красивых скриншотов из ЧатгПТ 4. Неангажированность: дружелюбие ко всем продуктам, рынкам, странам и подходам. Неважно, Cursor это и его комьюнити, или Claude. У нас одинаково теплый прием для любых авторов, инструментов и компаний 5. Единая площадка: точка сборки для авторов и крутых контрибьюторов. Чаты Глеба, Валеры, Рината, Макса, Дениса и других ребят безусловно крутые, но у них своя атмосфера. Они не очень подходят для совместного билдинга крупных комьюнити-штук, а мы хотим делать именно это В основе будет вклад Вот несколько примеров вклада от автора этого сообщения: - Прикладная платформа метрик процессов вроде lead time/velocity и тп: https://github.com/letya999/process_metrics_platform_v2 - Инструмент для синхронизации документации с Confluence и GitLab прямо из локальной папки: https://github.com/letya999/confluence-gitlab-sync. Аналитиков утомляет копировать из ИИ инструментов ТЗ - Пулл-реквест в паблик опенсорс: https://github.com/zereight/gitlab-mcp/pull/498, чтобы проще переключаться между гитлабами и совмещать пару работ - Статья "Ультимативный гид по Codex CLI»: https://habr.com/ru/articles/1040296/" о том как настроить Codex CLI базово - Комьюнити-стрим по Codex CLI для канала LLM4dev: https://t.me/LLM4dev/526 Что будем строить вместе Помимо живого чата, стримов, воркшопов и прочего будут несколько конкретных задач: Ивенты: митапы, конференции, вайбатоны (да, именно так). Форматы, где можно не только поговорить, но и поделать. Сетап-маркетплейс: опенсорс-альтернатива skills.sh и mcpmarketplaces.com с поддержкой директив agents.md, memory-банки и хуков. Место, где можно найти и поделиться готовыми агентными сетапами иплагинами Заходи: https://t.me/ai_engineers_guild

#кейс_стади Разбор кейса про Илью Я бы не давал 300 сразу и не отказывал бы в лоб. Я бы дал 250->260 сейчас, признал бы вклад и договорился бы о следующем пересмотре через квартал, но не через тупой ИПР ради ИПР, а через нормальную фиксацию того, что человек реально делает и что компания реально покупает Потому что в этом кейсе оба молодцы. Илья пришел с менеджерским туманом. Я много тащу, я закрываю риски, со мной клиенты спокойны, рынок такой, рекрутеры пишут. Это не кейс. Это ощущение собственной полезности Но CTO тоже хорош. Два года человек держал сложных клиентов, серую нагрузку и весь этот веселый энтерпрайзный цирк, а руководитель заметил его ценность только когда человек пришел за деньгами Ну классика. Пока клиент не орет, значит само работает 👍 В комментариях заметили важную штуку. Возможно, Илье нужно не только бабло. Ему нужно, чтобы его наконец увидели. Но сказать спасибо, ты молодец вместо денег после двух лет без повышения -> это не менеджмент, а корпоративный стендап Еще важен контекст 2026 в СНГ. Рынок сейчас не такой, что Илья завтра красиво хлопнет дверью и уйдет на 350. Может и не уйдет. Но если его просто обломать, он может остаться и внутренне уволиться. А это хуже, чем кажется. Он не будет саботировать. Не делать то, что компания считала бесплатным приложением к его зарплате. И вот тогда внезапно окажется, что само работало не само Почему не 300 сразу Потому что это покупка тревоги. Человек не принес факты, он принес ощущение. Если за это сразу платить 300, завтра придет следующий с таким же набором слов, и вы будете торговаться не с вкладом, а с эмоцией Почему не отказ Потому что отказ тут тоже тупой. Это ставка на то, что человек никуда не денется. В 2026 это часто сработает. Но потом не надо удивляться, почему сильные люди перестали делать что то сверх минимального скоупа Нормальный ход -> частичный пересмотр сейчас, признание косяка руководителя, разбор серой нагрузки и факты за квартал Что Илья делает сверх роли. Что из этого компании нужно. За что она готова платить. Что нужно убрать, если платить не готовы. Какие результаты зависят от Ильи, а какие просто красивая KPI шиза, которую любят рисовать в табличках Главный вывод простой Илья плохо продал свою ценность. Но CTO еще хуже ей управлял. Однако у нас СНГ (можно сколько угодно говорить как правильно в проектных офисах, что надо чтобы был честный перфоманс ревью и тд, ага, щас). Если ценность менеджера становится видна только после просьбы о повышении, проблема не только в менеджере

Приглашаем на Пиэмную — бесплатный митап ЮMoney для руководителей IT-проектов ✅ Спикеры из ЮMoney и основатель «Школы развития Доверия» расскажут, как управляют проектами и командами, а после докладов ответят на вопросы зрителей. О чём поговорим на митапе: 🟣 Ловушки коммуникации: как выходить победителем из игры без правил. 🟣 Управление доверием в команде: лидерская компетенция, которой не учат в MBA. 🟣 ИИ для менеджера проектов: с чего начать. 🟣 3 х 30: история адаптации в роли менеджера проектов ЮMoney. 📍21 мая, четверг, 19:00 (мск) приходите на митап в Санкт-Петербурге или подключайтесь онлайн. Чтобы попасть на митап, нужна регистрация. Все подробности — на сайте Пиэмной 🔥

#кейс_стади Задача на подумать для менеджера Вы CTO в P-Systems. Делаете llm guardrails для банков и крупняка: защита корпоративных ИИ-агентов от обработки и ответов на опасные запросы. Снаружи 🦋 🦄 модный рынок, хайп, венчур, все хотят поработать. Внутри комплаенс, туча правок, коллективное принятие решений по приемке у клиентов. Есть PM Илья. Два года в компании. Зарплата 220к Не рок-звезда для конференций, обычный душный PM, на котором держатся два самых мерзких клиента. Первый, банк с кредитным скорингом. Там смэрт. Второй ритейл с ИИ поиском товаров, вместо эластика. Там бизнес стабильно меняет требования перед релизом, потому что у CОО появились новые мысли и надо обсудить Илья это тащит. Без героизма и корпоративного пафоса. После его встреч ИБ не стопорит релиз. Ритейл не переписывает весь роадмап. Поддержка не долбит разработчиков напрямую. Молодой PM с соседнего проекта не тонет, потому что Илья его неформально натаскивает и сапортит Когда Илья работает хорошо, ничего не происходит. Клиент не орет. CEO не получает письмо. Команда не дерется. Релиз едет. Криво, но едет. А раз ничего не происходит, то оно само так работает, не благодаря, а вопреки, наверное... На 1:1 Илья вам говорит: «Хочу пересмотреть зарплату. Сейчас 220, хочу 300. Я давно делаю больше, чем написано в роли» Вы просите факты. Илья приносит классический менеджерский туман: - "я много тащу"; - "я закрываю риски"; - "рынок сейчас такой, мне рекрутеры пишут, а замену вы мне не найдете"; - "со мной клиенты спокойны и несут деньги". Оффера нет. Метрик нет. Громких кейсов нет. Менторство соседнего PM нигде не оформлено. Позиция слабая Но вы-то понимаете, что если Илья завтра начнет работать строго по должностной инструкции, будет весело. Молодой ПМ захлебнется. Поддержка снова пойдет напрямую к разработке. Банк начнет эскалировать. Ритейл начнет переписывать релиз за неделю до выкладки Бюджет на повышения ограничен. Есть еще 6 ПМ и двоим легко обосновать рейз, Аня приходила с понижением на испытательный и подруга 2 тимлидов, Рустам катается постоянно к ведущему вашему клиенту и этот контракт кормит половину компании Дать 300 сразу странно. Он не принес бизнес-кейс, он принес ощущение собственной полезности. Отказать тоже странно. Возможно, вы наказываете человека ровно за то, что он хорошо делает работу: не дает проблемам стать красивыми пожарами для отчетов. Сказать продолжай бесплатно делать серую работу, а теперь еще докажи, что она существует тоже можно Прямо сейчас человека не видно. Что бы вы сделали на месте CTO?

AI-assisted разработка в 2026: что реально работает, а что просто хайп? Сегодня AI пытаются использовать почти все — и те, кому он действительно нужен, и те, кому просто “надо, потому что все делают”. 16 мая на Manager’s Conference 2026 мы обсудим это на панельной дискуссии. На сцене встретятся два взгляда — фаундеров и продакт-лидеров. Фаундеры смотрят на AI как на возможность ускорить бизнес и рост. Продакты — как на инструмент, который должен давать конкретный результат в продукте. Участники панели: — Артем Панферов, Founder of AI LAB & Angel Connect — Саша Давыдов, Product Lead в HUMO — Артем Летюшев, Senior Project Manager в Twinby, IT Founder — Родион Мостовой, Co-founder & CEO CodeAlive — Рустам Хамдамов, Co-founder & CEO BILLZ — Никита Шилов, Cursor Ambassador в Центральной Азии На панели разберём: — когда AI действительно помогает ускорять разработку — какие инструменты команды реально используют в работе — где AI даёт результат, а где становится лишними затратами — как меняются роли разработчиков, продактов и менеджеров Это будет открытый разговор без слайдов и заготовленных ответов — с разными точками зрения и реальными кейсами. Регистрация на конференцию уже открыта. 👉 Программа, расписание и регистрация на сайте https://pmconf.uz/. Официальный телеграм-канал: @managersconf

#иное Практическая конференция Дорогой читатель, меня утомили споры про ИИ-кодинг "заменит/не заменит" и "да/нет". Уже 2026 год, давайте обсудим нужен ли интернет. У меня кое-что новое На https://pmconf.uz/ в Ташкенте у нас будут практические дебаты: безопасность skills/mcp, внедрение через анархию или диктатуру и о том стоит ли уже отказываться от IDE И главное: как не превратить ускорение разработки в ускорение бардака Буду рад увидеться с вами! Мне составит компанию @ai_driven