Совершенно бомбическая рецензия на метод, книгу и трек в Клубе проджект-раннеров от Алексей Петрова, одного из участников!

Не пожалейте время, прочитайте полный вариант статьи по ссылке из этого поста 👌️️️️️️

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

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

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

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

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

Метод помогает понять, на какой стадии сейчас находится проект, и какие инструменты, роли и подходы включать. Это не «фреймворк для всего», а система включения нужных ресурсов в нужный момент.

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

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

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

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

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

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

Так, тут Вадим Митякин (канал Метод параноика) в гостях у Диджитал-Радио нашего CEO Андрея Терехова рассказал про позиционирование диджитал-агентств/продакшенов в разрезе текущей ситуации. В традиционном для радио аудио-формате: 22 минуты хорошей экспертизы и полезных размышлений – самое то для субботнего вечера 👻

По мотивам вопросов, которые возникли в ответ на мой аудиоподкаст про позиционирование у Андрея Терехова, сделал небольшое уточнение про проекты типа «Седина»:


В отличие от Процедур (суть которых в выполнении задач, от рисования баннеров и до запуска типовых рекламных кампаний), Седина — это решение проблем клиента с предсказуемым результатом.

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

1. Управление ресурсами (умение подбирать специалистов с необходимыми компетенциями, развивать их и собирать из них команды)
2. Управление проектами (навыки по ведению проектов в определенной области, например, проведение рекламных кампаний или разработке цифровых сервисов)
3. Управление продуктом (знания о том, как именно должен быть устроен тот или иной продукт — информационный или технический)
4. Управление бизнесом (знание специфики той или иной отрасли, для которой идет поиск решения)

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

Как создавать цифровые продукты, которые покупают | Вадим Митякин

Вы когда-нибудь задумывались, почему одни цифровые продукты взлетают, а другие проваливаются, несмотря на крутую идею и большие вложения? В чём секрет успешных IT-проектов — в инновациях, грамотном управлении или чем-то ещё?

В этом выпуске подкаста эксперт по цифровым продуктам Вадим Митякин раскрывает секреты создания востребованных решений.

Обсудили с гостем:

✔️почему бизнес и разработчики часто говорят на разных языках и как найти общий знаменатель

✔️принципиальная разница между цифровым и бизнес-продуктом на примере Яндекс.Такси и других кейсов

✔️кто такой проджект-раннер — незаметный, но критически важный «дирижёр» проекта, без которого даже гениальная идея может развалиться

✔️когда Agile работает, а когда только вредит

✔️как собрать команду и почему одни команды выдают результат, а другие бесконечно спорят о мелочах

✔️что такое воронка неопределённости и как постепенно превращать хаос в четкий план действий

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

Смотреть в ВК
Смотреть на YouTube

Мы давно хотели с Сергеем Гуровым объединить наши наработки по проектированию и дизайну продуктов, и вот наконец это случилось!

🚀 Дизайн как искусство проектирования: поиск продуктовых решений на стыке дизайна, бизнеса и технологий
📅 18 августа – 22 сентября

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

Что даст курс?
🔹 Системный подход к проектированию:
— от функций → к композиции → к интерфейсу
— построение функциональных карт продуктов на основе требований бизнеса
— проектирование пользовательского интерфейса
— сборка дизайна на уровне композиции и сценариев

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

Что вы получите?
✅ Систематизированную технологию работы
✅ Практический опыт ее использования
✅ Примеры функциональных карт
✅ Готовые макеты для портфолио

А еще узнаете:
🔎 Как работать с бизнесом и выяснять реальные потребности
🔎 Как структурировать процесс разработки по стадиям
🔎 Как распределять зоны ответственности в команде
🔎 Как работать в условиях неопределенности

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

Программа курса:
📌 3 онлайн-лекции:
— Функциональное проектирование цифровых сервисов
— Дизайн и композиция интерфейсов
— Организация работы продуктовой команды

📌 Практика + консультации с менторами
📌 Финальный разбор работ
📌 Живые дискуссии

Даты и стоимость:
📅 18 августа – 22 сентября

💰 Полное погружение (лекции, практика, консультации, доступ к Figma)
— 45 000 ₽
— 40 000 ₽ (при оплате до 3 августа)

💰 Без сопровождения (лекции + записи, доступ к Figma без редактирования)
— 20 000 ₽
— 16 000 ₽ (при оплате до 3 августа)

👨‍🏫 Авторы и преподаватели:
Вадим Митякин:
Исследователь и консультант, автор книги «Метод параноика» о принципах создания цифровых продуктов для бизнеса в условиях неопределенности.
Опыт работы с: Яндекс, Майкрософт, VISA, Сбер, Литрес, Коммерсант, Связной и др.

Сергей Гуров:
Независимый RnD-дизайнер. Программный директор мастерской ОСНОВА.
20 лет опыта. Клиенты: Bang Bang Education / OFFF / Intel / Pepsi / Citroen / AIC / Skillbox / СБЕР / Yandex

По вопросам записи и покупки пишите @samenameee

Спасибо большое всем, кто написал/позвонил и напомнил про мои 48)

В июле прошла встреча клуба проджект раннеров.

Основная тема обсуждения — борьба с неопределенностью.

Поясню: в мире создания ИТ проектов (хотя в стройке тоже такое наблюдал) неопределенность, особенно в запуске новых продуктов, стремится к 100%.

Не ясны сроки создания проекта, бюджеты, требуемые специалисты — до момента, когда концепция, ТЗ и архитектура проекта будет спроектирована (но и здесь есть место неопределенности)

Задача специалистов (продактов/предпринимателей), снижать неопределенность, по мере создания проекта от этапа к этапу.

С Вадимом (лидер клуба и автор книги «метод параноика») мы познакомились, обсуждая тему хаоса неопределености при создании проекта на его подкасте.

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

Ключевую дилемму в ИТ определяем так: на старте проекта, невозможно предсказать стоимость и сроки проекта.
Когда проект — хотим мобильное приложение. Далеко не всегда приложение нужно и стоит вернуться к основой бизнес задаче.

Напрашивается тезис — кто виноват и что делать.

Шаг 1. Определить зачем козе баян какая бизне цель и набор гипотез, которые мы планируем проектировать
Шаг 2. Пройти этап исследования (проектирования), проверяя рискованные гипотезы и доуточняя концепт продукта, опираясь на рынок, требования стейкхолдеров и возможностей/ограничений системы (ресурсы, сроки и тд)
Шаг 3. Создать динамическую команду с одним ответственным и ключевым держателем концепции
Шаг 4. Перейти в созданию проекта с циклами перепроверки и короткими выпусками продукта на рынок.

P.S. интересная заметка на последок:
Почему не достаточно просто посмотреть конкурентов

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