Но все равно, что касается AI-агентов, то все это безусловно прекрасно и безусловно будет работать, только останется один ключевой вопрос — что на самом деле хочет (и что ему нужно) клиент.

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

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

А после уже можно и AI-агентов)

История 6: «Не сдача проекта, а запуск бизнеса» (Метод параноика: Изображая Голдратта)

История 5: «Принятие решения, а не согласование»


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

Вечером, в переговорной клиента, собрались все: операционный директор, финансовый директор, несколько менеджеров. На экране — карта с маленькими зелёными точками. Грузы в пути.

— Честно, я не верил, что вы это сделаете, — признался операционный директор, глядя на экран. — Но теперь я вижу… это реально работает.

Марина, руководитель студии, которая пришла посмотреть на демонстрацию, бросила на Алекса быстрый взгляд. В её глазах впервые не было иронии.

###

На следующий день Алекс приехал в офис клиента, думая, что это будет формальная «сдача проекта». Но вместо этого его встретили хмурые лица сотрудников логистического отдела.

— Нам неудобно, — пожаловалась одна из диспетчеров. — Мы привыкли работать в Excel, а тут новая система. Всё тормозит. — Да и вообще, — добавил другой, — зачем нам эта лишняя морока?

Алекс понял: если сейчас он просто «подпишет акты» и уйдёт, продукт умрёт. Люди найдут способ обойти систему, и всё рухнет.

Он глубоко вдохнул. — Давайте так, — сказал он. — Сегодня вечером соберём воркшоп. Я хочу понять, как именно вы работаете и что мешает. Мы вместе подстроим процесс так, чтобы система помогала, а не мешала.

###

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

— Так будет проще, — сказала диспетчер, когда они нашли новый порядок работы. — Даже быстрее, чем раньше.

Алекс улыбнулся. Вот он, настоящий результат. Не софт, не код. А то, что бизнес начал работать иначе.

###

Через неделю финансовый директор пожал ему руку: — Мы не просто получили систему. Мы изменили работу компании. И это
благодаря тебе и твоей команде.

Марина подошла позже, тихо, чтобы никто не слышал: — Знаешь, Алекс… я ошибалась. Ты действительно проджект-раннер.

Алекс кивнул. Он больше не чувствовал страха. Только уверенность.

Теперь он знал: его работа — не «сдавать проекты». Его работа — запускать бизнесы.

И это стало его новой идентичностью.



p.s. Это была последняя часть истории, которую я решил создать в качестве эксперимента, вложив идеи из «Метода параноика» в формат Цели Голдратта.

На этом эксперименте я точно не буду останавливаться, посмотрим, что будет дальше.

@theparanoidmethod

Сентябрь, полный мероприятий

Воркшоп «Управление проектными командами по «Методу параноика»

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

Материал основан на его опыте и книге «Метод параноика» о продюсерской модели управления проектами. Подход вырос из проектов для Яндекса, Microsoft, VISA, Сбера, а также ЛитРес, «Коммерсанта», «Связного» и др.

Содержание воркшопа:
— Введение в технологию продуктовой разработки и принципы работы в условиях неопределённости
— Сборка комплексной модели продукта на уровнях: бизнес, функциональный, интерфейсный, технический
— Роли и зоны ответственности участников на разных стадиях проекта
— Подходы к оценке и планированию проектной работы

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

Книга «Метод параноика»: https://mityakin.com/redbook

Телеграм-канал: https://t.iss.one/theparanoidmethod

Афиша на сентябрь 2025:

17 сен — Обсуждаем с Антоном Кравченко (Crauch) агентства нового типа, построенные по продюсерской модели (онлайн)

20 сен — Провожу воркшоп про управление проектными командами по «Методу параноика» на OpenConf в Ростове-на-Дону

22 сен — Живая встреча в Москве с участниками Клуба Digital Сфера (Анна Караулова) про книгу, агентский бизнеса и менторский формат

23 сен — Выступление на BOOST25 в секции Управление проектами про технологию продуктовой разработки в агентствах

24 сен — Веду дискуссию на BOOST25 в секции Управление бизнесом про создание собственных продуктов в агентствах

24 сен — Представляю на BOOST25 свою книгу «Метод параноика» в формате автограф-сессии (Книжный клуб Skolkovo Alumni Book Club и Migel Agency)

25 сен — Проводим в московском офисе компании .redev (Сергей Костин) живую встречу владельцев агентств

27 сен — Открытая встреча в Клубе проджект-раннеров

Иногда очень даже хорошо, что kpi не выполнены)

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

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

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

Как говорит Вадим, везде есть хитрость 🙃

Тысяча благодарностей за диалог, знания и, конечно, книгу ❤️

Когда я спросил у коллег, как при таком подходе выглядит постановка задачи, то мне перечислили все то же, что сейчас обычно принято считать проектированием: user story/use cases (это абсолютно две разные вещи и обе херовые по факту), макеты, нефункциональные требования, ну и дальше по списку. Короче все как обычно, только кодить будут не архитектор/тим лид/разработчики, а рой агентов.

Другими словами, разработчикам как обычно кажется, что дело в коде, а не в сути продукта. Ну ок)


Еще жестче высказался мой товарищ по методологическому кружку Василий Корешков:

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


Вася знает, что говорит, они эти эксперименты ставили еще в прошлом году:

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


Короче люди как делали проекты через жопу, так и делают))) Все это конечно могло быть подводкой к новому треку в клубе проджект-раннеров по проектированию продуктов, но оно и само по себе доставляет, особенно рассуждения про AGI (т.е. общий ИИ как его себе представляют эти клоуны):

https://habr.com/ru/companies/technokratos/articles/947152/

Сегодня я хочу анонсировать специализированный трек по проектированию продуктов

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

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

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

По формату это похоже на обычный трек, т.е. так же 1,5 месяца, когда мы раз в неделю в субботу на несколько часов собираемся с группой и разбираем на практике все аспекты:

— Введение в технологию продуктовой разработки и принципы проектирования
— Высокоуровневое проектирование: цели бизнеса и образ продукта
— Функциональная модель и ключевые сценарии
— Интерфейсы и детализация решений через пользовательский опыт
—Техническая архитектура продукта и её связь с моделью
— Интеграция всех уровней и разбор кейсов участников


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

На этой неделе заканчивается первый такой трек, а новый мы начинаем в субботу 4 октября.

Подробности на сайте клуба, там же условия и способ записаться: https://mityakin.com/club

Немного ироничный пост, но зато отлично показывает как именно работает модель Мозги/Седина/Процедуры!

Лидер потому и лидер на рынке, что он задает новую модель работы (Мозги), остальные вынуждены ее копировать (Седина), превращая инновацию в стандарт, а дальше идет эволюционное развитие (Процедуры) до новой инновации.

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