#мнение
Какие проджекты сейчас не нужны

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

Я полагаю ты заметил как попритихли чаты, группы, конференции и образование. Рынок перестал покупать не проектное управление как таковое, а 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. Из всего этого не следует, что проджекты больше не нужны. Это слишком плоский вывод, и я его не делаю/ Скорее так: больше не нужен проджект как человек-обвязка

#иное
Митап 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-инструменты в реальных проектах.

#мнение
Место менеджмента 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 убирает мидл-менеджера как диспетчера передач. Но может сохранить функцию как инженерный контур: границы, контекст, поток, готовность, обратная связь