Кто такой Project Runner и зачем он нужен?

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

Первое впечатление Меня метод зацепил с самого начала, показался чем то родным как будто всю жизнь так и делал. Но одновременно с этим внутри было какое-то сопротивление, неочевидное, подсознательное. Знаете, из серии: «Это классно, но у нас не взлетит. Это ведь про какой-то идеальный мир».

И только к финалу книги щёлкнуло — я всё это время смотрел на метод через призму аутсорса. На самом деле метод — это не про «под ключ». Это про продюсирование результата, про то, как довести проект до смысла. И в этом контексте всё встало на свои места.

Многослойный пирог Метод кажется безумно логичным: все части на своих местах. Когда читаешь — ощущение, что «вроде бы и так делал», но на самом деле — нет. Он многослойный, охватывает все уровни продукта и фазы развития. Книга делит проекты на три типа: — Мозги: уникальные задачи, стартапы, поиск решений в условиях неопределенности. Здесь Project Runner — ключевая фигура. — Седина: когда нужно адаптировать уже известное, внедрить в конкретный контекст. — Процедуры: рутина, где всё формализовано. Но и здесь Project Runner может быть "спящей ролью", которая следит, чтобы процессы не вывалились в хаос.

Метод помогает понять, на какой стадии сейчас находится проект, и какие инструменты, роли и подходы включать. Это не «фреймворк для всего», а система включения нужных ресурсов в нужный момент. Первая мысль: ресурсы не должны быть включены "всегда". Они подключаются только в нужный момент, как завещали дяди из Toyota. Не нужно тянуть на старте проектировщика интерфейсов или дизайнера, если мы ещё в стратегической концепции. И наоборот — не держим стратегов, когда уже клепаем кнопки.

Вторая мысль: каждая задача, решение, встреча должны снижать неопределённость. Не просто "что-то делать", а делать то, что убирает туман. Если задача этого не делает — возможно, она не нужна. Если она увеличивает неопределённость — её точно не надо делать. А скорость снижения неопределённости должна быть выше, чем скорость сжигания бюджета. Всё просто: туман должен рассеиваться быстрее, чем заканчиваются деньги.

Третья мысль: важно задавать правильные вопросы на правильном уровне — это матрица: по горизонтали — стадии проекта: Концептуализация → Систематизация → Проектирование → Реализация; по вертикали — уровни: бизнес → функциональный → интерфейсный → технический → организационный.

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

Метод учит видеть эту матрицу и работать с ней. Без перегрева, без «давайте всё сразу». Только нужные вопросы, нужные роли, в нужное время.

👉 На сайте — самое интересное: чем Project Runner отличается от обычного PM, почему разработка — это не начало, а финал, и помогает ли метод в реальных проектах, где еще применим, и выводы, которые стоит повторять каждую пятницу.