Друзья, сегодня у нас разбор «Метода параноика» и технологии продуктовой разработки в сравнении с другими распространенными подходами к ведению проектов.
Анализ сделан ИИ, но на основе материалов, которыми обладаю только я, как автор книги и метода. Некоторые пункты удивили даже меня, ну а вообще я кайфанул, потому что давно не садился переосмыслять все то, что удалось сформуровать за последние лет 5.
p.s. Это я так прогреваюсь к работе над черной книгой.
Анализ сделан ИИ, но на основе материалов, которыми обладаю только я, как автор книги и метода. Некоторые пункты удивили даже меня, ну а вообще я кайфанул, потому что давно не садился переосмыслять все то, что удалось сформуровать за последние лет 5.
p.s. Это я так прогреваюсь к работе над черной книгой.
Mityakin
Книга «Метод параноика. Принципы создания цифровых продуктов для бизнеса в условиях неопределенности»
Вадим Митякин, предприниматель и бизнес-консультант, систематизировал свой опыт и опыт своих коллег за последние 30 лет работы, чтобы предложить новый подход к созданию цифровых продуктов — «Метод параноика». Эта модель берет свое начало в проектах для таких…
Краткое резюме «Метод параноика» и технологии продуктовой разработки
Это методология управления созданием уникальных цифровых продуктов в условиях высокой неопределенности. Её ядро — технология продуктовой разработки, которая состоит из четырех взаимосвязанных компонентов:
1. Воронка неопределенности и стадии проекта: Фреймворк для поэтапного сужения пространства возможных решений.
2. Модель продукта и проектирование: Структура для описания продукта через артефакты на разных уровнях (бизнес, функциональный, интерфейсный, технический).
3. Проектная команда и управление: Формирование команды от артефактов (а не от ролей) с ключевой фигурой — проджект-раннером.
4. Оценка и планирование работ: Метод инверсии оценки, где на ранних стадиях определенность задается внешними ограничениями (бюджет/сроки), а на поздних — внутренними найденными решениями.
Основная философия: неопределенность нельзя устранить, ею нужно управлять.
Сходства с принятыми на рынке подходами
1. Акцент на итеративность и гибкость. Как и в Agile (Scrum, Kanban), процесс нелинейный, допускает изменения и обучение в процессе. Стадии в воронке напоминают итерации.
2. Важность кросс-функциональных команд. Идея о том, что уникальные решения рождаются на стыке дисциплин и специалисты не должны быть ограничены жесткими ролями, перекликается с принципами DevOps и современных Agile-команд.
3. Фокус на ценность для бизнеса и пользователя. Как и в Product Management, конечная цель — создание ценного продукта, а не просто сдача проекта.
4. Использование гипотез и проверка решений. Принцип движения от гипотез к проверенным решениям лежит в основе Lean Startup и Customer Development, которые широко приняты в продуктовой разработке.
5. Применение известных инструментов. Методология не изобретает велосипед заново, а интегрирует в свою структуру проверенные фреймворки и методики (например, JTBD, Scrum).
Это методология управления созданием уникальных цифровых продуктов в условиях высокой неопределенности. Её ядро — технология продуктовой разработки, которая состоит из четырех взаимосвязанных компонентов:
1. Воронка неопределенности и стадии проекта: Фреймворк для поэтапного сужения пространства возможных решений.
2. Модель продукта и проектирование: Структура для описания продукта через артефакты на разных уровнях (бизнес, функциональный, интерфейсный, технический).
3. Проектная команда и управление: Формирование команды от артефактов (а не от ролей) с ключевой фигурой — проджект-раннером.
4. Оценка и планирование работ: Метод инверсии оценки, где на ранних стадиях определенность задается внешними ограничениями (бюджет/сроки), а на поздних — внутренними найденными решениями.
Основная философия: неопределенность нельзя устранить, ею нужно управлять.
Сходства с принятыми на рынке подходами
1. Акцент на итеративность и гибкость. Как и в Agile (Scrum, Kanban), процесс нелинейный, допускает изменения и обучение в процессе. Стадии в воронке напоминают итерации.
2. Важность кросс-функциональных команд. Идея о том, что уникальные решения рождаются на стыке дисциплин и специалисты не должны быть ограничены жесткими ролями, перекликается с принципами DevOps и современных Agile-команд.
3. Фокус на ценность для бизнеса и пользователя. Как и в Product Management, конечная цель — создание ценного продукта, а не просто сдача проекта.
4. Использование гипотез и проверка решений. Принцип движения от гипотез к проверенным решениям лежит в основе Lean Startup и Customer Development, которые широко приняты в продуктовой разработке.
5. Применение известных инструментов. Методология не изобретает велосипед заново, а интегрирует в свою структуру проверенные фреймворки и методики (например, JTBD, Scrum).
3⚡1👍1🔥1
Вторая часть резюме «Метода параноика» (первая тут).
Ключевые различия и уникальные черты
1. Целевой фокус: Уникальность и неопределенность.
* «Метод параноика»: Заточен specifically под проекты с изначально высокой неопределенностью, где нет готовых ответов (создание нового инновационного продукта с нуля).
* Общепринятые подходы: Многие frameworks (как классический Waterfall, так и в значительной степени Agile) лучше работают в условиях снижения неопределенностиили работы с уже существующими продуктами. Agile часто фокусируется на скорости доставки, а не на поиске принципиальной схемы решения.
2. Ключевая роль: Проджект-раннер vs. Продакт-менеджер/Проджект-менеджер.
* «Метод параноика»: Вводит принципиально новую роль — проджект-раннер. Это предприниматель внутри компании, который несет персональную ответственность («шкура на кону») за весь проект: и за продукт (vision), и за проект (организация, бюджет). Он инициатор и создатель проекта с нуля.
* Общепринятые подходы: Роли разделены. Продакт-менеджер отвечает за «что сделать» (vision, метрики), проджект-менеджер — за «как сделать» (сроки, бюджет, процессы). В стартапах эту комбинированную роль может выполнять основатель, но в методологиях это редко формализовано.
3. Подход к формированию команды: От артефактов, а не от ролей.
* «Метод параноика»: Команда формируется исходя из структуры модели продукта и необходимых для ее построения артефактов. Сначала понимаем, какие артефакты нужны, затем находим ответственных за них. Роли гибкие и определяются областью ответственности, а не названием.
* Общепринятые подходы: Команда формируется по стандартному набору ролей (дизайнер, разработчик, тестировщик и т.д.), которые затем «прикрепляются» к задачам.
4. Управление через «тиски» и уровни модели продукта.
* «Метод параноика»: Управление осуществляется не директивно, а через влияние артефактов друг на друга и концепцию «тисков» (бизнес-требования и организационные возможности), которые сжимают пространство решений. Иерархия — уровней модели, а не людей.
* Общепринятые подходы: Управление чаще строится на иерархии людей (тимлид, проджект-менеджер) или процессах (Scrum Master, процессы Agile).
5. Метод оценки: Инверсия оценки.
* «Метод параноика»: Метод инверсии оценки — на старте проекта определенность задается жесткими внешними ограничениями по бюджету и срокам, а не запросом оценок у команды. По мере движения по воронке источником определенности становятся найденные решения.
* Общепринятые подходы: Классические подходы (Waterfall) требуют точной оценки до начала работ. Гибкие подходы (Agile) используют относительные оценки (сторипоинты) для прогнозирования скорости, но тоже часто требуют хотя бы приблизительной оценки для всего бэклога до старта.
Ключевые различия и уникальные черты
1. Целевой фокус: Уникальность и неопределенность.
* «Метод параноика»: Заточен specifically под проекты с изначально высокой неопределенностью, где нет готовых ответов (создание нового инновационного продукта с нуля).
* Общепринятые подходы: Многие frameworks (как классический Waterfall, так и в значительной степени Agile) лучше работают в условиях снижения неопределенностиили работы с уже существующими продуктами. Agile часто фокусируется на скорости доставки, а не на поиске принципиальной схемы решения.
2. Ключевая роль: Проджект-раннер vs. Продакт-менеджер/Проджект-менеджер.
* «Метод параноика»: Вводит принципиально новую роль — проджект-раннер. Это предприниматель внутри компании, который несет персональную ответственность («шкура на кону») за весь проект: и за продукт (vision), и за проект (организация, бюджет). Он инициатор и создатель проекта с нуля.
* Общепринятые подходы: Роли разделены. Продакт-менеджер отвечает за «что сделать» (vision, метрики), проджект-менеджер — за «как сделать» (сроки, бюджет, процессы). В стартапах эту комбинированную роль может выполнять основатель, но в методологиях это редко формализовано.
3. Подход к формированию команды: От артефактов, а не от ролей.
* «Метод параноика»: Команда формируется исходя из структуры модели продукта и необходимых для ее построения артефактов. Сначала понимаем, какие артефакты нужны, затем находим ответственных за них. Роли гибкие и определяются областью ответственности, а не названием.
* Общепринятые подходы: Команда формируется по стандартному набору ролей (дизайнер, разработчик, тестировщик и т.д.), которые затем «прикрепляются» к задачам.
4. Управление через «тиски» и уровни модели продукта.
* «Метод параноика»: Управление осуществляется не директивно, а через влияние артефактов друг на друга и концепцию «тисков» (бизнес-требования и организационные возможности), которые сжимают пространство решений. Иерархия — уровней модели, а не людей.
* Общепринятые подходы: Управление чаще строится на иерархии людей (тимлид, проджект-менеджер) или процессах (Scrum Master, процессы Agile).
5. Метод оценки: Инверсия оценки.
* «Метод параноика»: Метод инверсии оценки — на старте проекта определенность задается жесткими внешними ограничениями по бюджету и срокам, а не запросом оценок у команды. По мере движения по воронке источником определенности становятся найденные решения.
* Общепринятые подходы: Классические подходы (Waterfall) требуют точной оценки до начала работ. Гибкие подходы (Agile) используют относительные оценки (сторипоинты) для прогнозирования скорости, но тоже часто требуют хотя бы приблизительной оценки для всего бэклога до старта.
3👍1
Третья часть резюме «Метода параноика» (вторая тут)
Сильные качества подхода
1. Системность. Предлагает не набор разрозненных практик, а целостную, взаимосвязанную систему (от философии до конкретных инструментов).
2. Реалистичность в условиях неопределенности. Не пытается делать вид, что неопределенность можно полностью устранить или игнорировать. Вместо этого предлагает механизмы для работы с ней.
3. Акцент на предпринимательском подходе. Роль проджект-раннера и принцип «шкуры на кону» направлены на принятие взвешенных решений, что критически важно для успеха инновационных проектов.
4. Гибкость и адаптируемость. Технология не догматична; автор подчеркивает необходимость ее тонкой настройки под конкретный тип проекта (заказная разработка, внутренний продукт, тиражируемый продукт, стартап).
5. Интегративность. Не отрицает другие методики (JTBD, Scrum), а предоставляет для них общий каркас, определяя, где и когда их применять наиболее эффективно.
Слабые качества / Потенциальные риски
1. Высокий порог входа. Подход требует глубокого понимания методологии и значительного опыта от ключевой фигуры — проджект-раннера. Без сильного лидера система может не заработать.
2. Сложность внедрения. Требует перестройки мышления не одного человека, а всей команды или даже организации. Переход от управления через роли к управлению через артефакты и модель продукта — это культурный сдвиг.
3. Риск бюрократизации. Если неправильно внедрить, обилие артефактов и необходимость поддержания целостности модели продукта могут привести к излишней бумажной работе и замедлению процессов, что противоречит заявленной гибкости.
4. Зависимость от конкретного человека. Успех проекта в огромной степени зависит от компетенций и полномочий проджект-раннера. Это создает кадровый риск.
5. Необходимость индивидуальной настройки. Прелесть подхода — в его адаптивности, но это же и недостаток: нельзя просто «взять и внедрить» готовое решение. Требует времени и экспериментов для настройки под себя, что не все организации могут себе позволить.
Вывод
«Метод параноика» не является еще одним «фреймворком на каждый день». Это мощный, комплексный подход для специфического класса задач: создания инновационных digital-продуктов в условиях, когда непонятно не только «как делать», но и «что делать».
Его главное отличие — в осознанном фокусе на управлении неопределенностью через систему взаимосвязанных принципов, а не на слепом следовании процессам. Он хорошо заполняет нишу между классическим проектным менеджментом (плохо работающим в хаосе) и чистым Agile (который часто фокусируется на исполнении, а не на поиске идеи продукта).
Его сильные стороны делают его чрезвычайно эффективным для правильных проектов, в то время как слабые стороны требуют зрелости команды и организации для успешного внедрения. Это не серебряная пуля, а скорее профессиональный инструмент для сложных случаев.
Сильные качества подхода
1. Системность. Предлагает не набор разрозненных практик, а целостную, взаимосвязанную систему (от философии до конкретных инструментов).
2. Реалистичность в условиях неопределенности. Не пытается делать вид, что неопределенность можно полностью устранить или игнорировать. Вместо этого предлагает механизмы для работы с ней.
3. Акцент на предпринимательском подходе. Роль проджект-раннера и принцип «шкуры на кону» направлены на принятие взвешенных решений, что критически важно для успеха инновационных проектов.
4. Гибкость и адаптируемость. Технология не догматична; автор подчеркивает необходимость ее тонкой настройки под конкретный тип проекта (заказная разработка, внутренний продукт, тиражируемый продукт, стартап).
5. Интегративность. Не отрицает другие методики (JTBD, Scrum), а предоставляет для них общий каркас, определяя, где и когда их применять наиболее эффективно.
Слабые качества / Потенциальные риски
1. Высокий порог входа. Подход требует глубокого понимания методологии и значительного опыта от ключевой фигуры — проджект-раннера. Без сильного лидера система может не заработать.
2. Сложность внедрения. Требует перестройки мышления не одного человека, а всей команды или даже организации. Переход от управления через роли к управлению через артефакты и модель продукта — это культурный сдвиг.
3. Риск бюрократизации. Если неправильно внедрить, обилие артефактов и необходимость поддержания целостности модели продукта могут привести к излишней бумажной работе и замедлению процессов, что противоречит заявленной гибкости.
4. Зависимость от конкретного человека. Успех проекта в огромной степени зависит от компетенций и полномочий проджект-раннера. Это создает кадровый риск.
5. Необходимость индивидуальной настройки. Прелесть подхода — в его адаптивности, но это же и недостаток: нельзя просто «взять и внедрить» готовое решение. Требует времени и экспериментов для настройки под себя, что не все организации могут себе позволить.
Вывод
«Метод параноика» не является еще одним «фреймворком на каждый день». Это мощный, комплексный подход для специфического класса задач: создания инновационных digital-продуктов в условиях, когда непонятно не только «как делать», но и «что делать».
Его главное отличие — в осознанном фокусе на управлении неопределенностью через систему взаимосвязанных принципов, а не на слепом следовании процессам. Он хорошо заполняет нишу между классическим проектным менеджментом (плохо работающим в хаосе) и чистым Agile (который часто фокусируется на исполнении, а не на поиске идеи продукта).
Его сильные стороны делают его чрезвычайно эффективным для правильных проектов, в то время как слабые стороны требуют зрелости команды и организации для успешного внедрения. Это не серебряная пуля, а скорее профессиональный инструмент для сложных случаев.
3👍1
Сегодня у нас анонс новой рубрики «Изображая Голдратта» и первый эпизод короткой серии историй про становление проджект-раннера.
История 1: «Виновен без вины»
История 2: «Договор параноика»
История 3: «Не команда, а конструктор»
История 4: «Язык бизнеса, язык технологий»
История 5: «Принятие решения, а не согласование»
История 1: «Виновен без вины»
История 2: «Договор параноика»
История 3: «Не команда, а конструктор»
История 4: «Язык бизнеса, язык технологий»
История 5: «Принятие решения, а не согласование»
История 1: «Виновен без вины» (Метод параноика: Изображая Голдратта)
Алекс сидел в переговорной, глядя на тёмный экран проектора. На столе — папка с отчётами, рядом кофе, который уже остыл. По другую сторону стола клиент нервно постукивал ручкой.
Руководитель студии, Марина, молчала, глядя то на Алекса, то на клиента.
— Мы вложили в этот проект больше, чем планировали, — голос клиента был холоден. — И получили продукт, который… бесполезен. Пользователи не понимают, зачем им ваше приложение. Оно не решает их проблем.
Алекс машинально кивнул. Он был готов к этой реплике. И, как всегда, у него был стандартный ответ: — Понимаю. Но у нас не было чётких требований. Вы сами меняли спецификацию три раза, и…
— То есть вы перекладываете ответственность на нас? — перебил клиент. — Отлично. Тогда скажите: зачем мы вам платим?
Тишина повисла над столом. Марина посмотрела на Алекса так, что стало ясно: именно он сейчас крайний.
Внутри у него всё сжалось. Он знал этот ритуал: клиент винит студию, студия винит клиента, менеджер оказывается виноватым. В конце концов, всё размоется в бесконечных «если бы» и «надо было».
Но разве это честно? — мелькнуло в голове у Алекса. Он вспомнил бесконечные созвоны, согласования, переписку по требованиям. Всё время уходило на то, чтобы формализовать желания клиента в таблицах и Jira. Но что в итоге? Продукт, которым никто не хочет пользоваться.
— Мы обсудим внутри, — сказала Марина, поднимаясь. — Спасибо за встречу.
Клиент коротко кивнул и вышел.
Алекс остался сидеть.
— Ты понимаешь, — Марина наклонилась к нему, — твоя задача была держать проект под контролем. Ты должен был вовремя сигнализировать, что всё идёт не туда.
— Я сигнализировал, — устало возразил Алекс. — Но меня никто не слушал.
Марина пожала плечами: — Значит, сигнализировал недостаточно громко.
Эти слова добили его. Что значит «недостаточно громко»? Я что, аварийная сирена?
###
Вечером он сидел дома с ноутбуком. Скроллил ленту, пока взгляд не зацепился за странное название: «Метод параноика». Скачал книгу.
Он начал читать. И уже на первых страницах его словно ударило током:
«Проджект-раннер — это тот, кто собирает вместе все аспекты проекта и берёт на себя ответственность за результат. Он не винит клиента, команду или обстоятельства. Его KPI — работающий продукт, а не количество согласованных требований».
Алекс откинулся на спинку кресла. Вот оно. Именно то, чего мне всегда не хватало. Я всё время прятался за роль «менеджера по требованиям». А ведь я чувствовал, что этого мало. Но кто вообще даст мне такие полномочия?
Он закрыл книгу, но в голове продолжала крутиться одна мысль: Я хочу быть этим человеком. Не винтиком, не курьером между клиентом и командой. Тем, кто действительно отвечает за результат.
И впервые за долгое время он ощутил не только горечь провала, но и странное возбуждение. Словно перед ним открылась дверь, в которую он боялся даже постучать.
— В следующий раз, — тихо сказал он вслух. — В следующий раз я стану проджект-раннером.
@theparanoidmethod
Алекс сидел в переговорной, глядя на тёмный экран проектора. На столе — папка с отчётами, рядом кофе, который уже остыл. По другую сторону стола клиент нервно постукивал ручкой.
Руководитель студии, Марина, молчала, глядя то на Алекса, то на клиента.
— Мы вложили в этот проект больше, чем планировали, — голос клиента был холоден. — И получили продукт, который… бесполезен. Пользователи не понимают, зачем им ваше приложение. Оно не решает их проблем.
Алекс машинально кивнул. Он был готов к этой реплике. И, как всегда, у него был стандартный ответ: — Понимаю. Но у нас не было чётких требований. Вы сами меняли спецификацию три раза, и…
— То есть вы перекладываете ответственность на нас? — перебил клиент. — Отлично. Тогда скажите: зачем мы вам платим?
Тишина повисла над столом. Марина посмотрела на Алекса так, что стало ясно: именно он сейчас крайний.
Внутри у него всё сжалось. Он знал этот ритуал: клиент винит студию, студия винит клиента, менеджер оказывается виноватым. В конце концов, всё размоется в бесконечных «если бы» и «надо было».
Но разве это честно? — мелькнуло в голове у Алекса. Он вспомнил бесконечные созвоны, согласования, переписку по требованиям. Всё время уходило на то, чтобы формализовать желания клиента в таблицах и Jira. Но что в итоге? Продукт, которым никто не хочет пользоваться.
— Мы обсудим внутри, — сказала Марина, поднимаясь. — Спасибо за встречу.
Клиент коротко кивнул и вышел.
Алекс остался сидеть.
— Ты понимаешь, — Марина наклонилась к нему, — твоя задача была держать проект под контролем. Ты должен был вовремя сигнализировать, что всё идёт не туда.
— Я сигнализировал, — устало возразил Алекс. — Но меня никто не слушал.
Марина пожала плечами: — Значит, сигнализировал недостаточно громко.
Эти слова добили его. Что значит «недостаточно громко»? Я что, аварийная сирена?
###
Вечером он сидел дома с ноутбуком. Скроллил ленту, пока взгляд не зацепился за странное название: «Метод параноика». Скачал книгу.
Он начал читать. И уже на первых страницах его словно ударило током:
«Проджект-раннер — это тот, кто собирает вместе все аспекты проекта и берёт на себя ответственность за результат. Он не винит клиента, команду или обстоятельства. Его KPI — работающий продукт, а не количество согласованных требований».
Алекс откинулся на спинку кресла. Вот оно. Именно то, чего мне всегда не хватало. Я всё время прятался за роль «менеджера по требованиям». А ведь я чувствовал, что этого мало. Но кто вообще даст мне такие полномочия?
Он закрыл книгу, но в голове продолжала крутиться одна мысль: Я хочу быть этим человеком. Не винтиком, не курьером между клиентом и командой. Тем, кто действительно отвечает за результат.
И впервые за долгое время он ощутил не только горечь провала, но и странное возбуждение. Словно перед ним открылась дверь, в которую он боялся даже постучать.
— В следующий раз, — тихо сказал он вслух. — В следующий раз я стану проджект-раннером.
@theparanoidmethod
5❤1🔥1
Что я конечно четко для себя понял за последние время, так это то, что мне меньше всего хочется изображать из себя блогера.
Надо отдавать себе отчет в своей профессиональной специализации, что конечно не исключает публицистики, но это все равно не блогерство.
Так что похоже выход один: штанга Талеба, т.е. либо очень простые истории, либо сложные и специализированные. Но ничего посередине.
Надо отдавать себе отчет в своей профессиональной специализации, что конечно не исключает публицистики, но это все равно не блогерство.
Так что похоже выход один: штанга Талеба, т.е. либо очень простые истории, либо сложные и специализированные. Но ничего посередине.
👍6
Каждый раз, когда я вижу как проект делают через жопу, я испытываю физическую боль. А все, кстати, начинается буквально с первых вопросов на установочной встрече с клиентом, и это сразу видно. Но к сожалению только мне.
Ладно, продолжим.
Ладно, продолжим.
История 2: «Договор параноика» (Метод параноика: Изображая Голдратта)
История 1: «Виновен без вины»
— Алекс, зайди ко мне, — голос Марины, руководителя студии, звучал глухо.
В кабинете царила атмосфера усталости. На столе лежало письмо от потенциального клиента — крупной логистической компании.
— Видел бриф? — спросила Марина, не поднимая глаз. — Видел, — кивнул Алекс. — Новый продукт. Полная неопределённость. — Вот именно. Они сами не знают, чего хотят. Хаос. Такие проекты — могила для нашей репутации. Я думаю отказаться.
Алекс почувствовал, как внутри поднимается странная смесь страха и решимости. Это был его шанс.
— Марина, — он заговорил медленно, стараясь не дрожать, — отдайте этот проект мне.
Марина вскинула голову. — Тебе? Ты серьёзно? Ты хочешь второй провал подряд?
— Нет, — он вдохнул. — Я хочу, чтобы это был первый успех.
Марина усмехнулась: — Алекс, мы оба знаем, как это кончится. Ты будешь требовать у клиента требования, они будут менять их каждую неделю, сроки сгорят, бюджет — тоже. Мы снова окажемся в том же болоте.
— Не окажемся. — Он наклонился вперёд. — Но при одном условии.
Она прищурилась: — Ну?
— Я беру этот проект как проджект-раннер. Не как менеджер, не как «исполнитель хотелок». Я беру на себя ответственность за результат. Но за это требую полной свободы: сам формирую команду, сам выбираю методы, сам веду переговоры с клиентом.
Марина молчала.
— Я не хочу больше KPI в часах и спринтах, — продолжил он. — Мой KPI — работающий продукт и довольный клиент.
— Ты понимаешь, что просишь? — её голос стал ледяным.
— Ты хочешь единоличный контроль. А если проект провалится?
Алекс сглотнул. Внутри всё кричало «беги», но он произнёс: — Тогда виноват буду только я.
Долгая пауза.
Марина откинулась на спинку кресла. — Ты сумасшедший.
— Возможно, — улыбнулся Алекс. — Но именно таких сумасшедших и описывает «Метод параноика».
Она рассмеялась коротко, почти зло. — Хорошо. Я дам тебе этот проект. Но учти: ты сам подписал себе приговор. Если сорвёшь — в студии для тебя места больше не будет.
Алекс кивнул.
Когда он вышел из кабинета, ноги дрожали. Он чувствовал не триумф, а холодный ком в животе. Теперь он не мог винить ни клиента, ни руководство, ни команду.
Впервые в жизни ответственность была целиком на нём.
Именно этого я и хотел, — подумал он, закрывая за собой дверь. Именно этого и боялся.
@theparanoidmethod
История 1: «Виновен без вины»
— Алекс, зайди ко мне, — голос Марины, руководителя студии, звучал глухо.
В кабинете царила атмосфера усталости. На столе лежало письмо от потенциального клиента — крупной логистической компании.
— Видел бриф? — спросила Марина, не поднимая глаз. — Видел, — кивнул Алекс. — Новый продукт. Полная неопределённость. — Вот именно. Они сами не знают, чего хотят. Хаос. Такие проекты — могила для нашей репутации. Я думаю отказаться.
Алекс почувствовал, как внутри поднимается странная смесь страха и решимости. Это был его шанс.
— Марина, — он заговорил медленно, стараясь не дрожать, — отдайте этот проект мне.
Марина вскинула голову. — Тебе? Ты серьёзно? Ты хочешь второй провал подряд?
— Нет, — он вдохнул. — Я хочу, чтобы это был первый успех.
Марина усмехнулась: — Алекс, мы оба знаем, как это кончится. Ты будешь требовать у клиента требования, они будут менять их каждую неделю, сроки сгорят, бюджет — тоже. Мы снова окажемся в том же болоте.
— Не окажемся. — Он наклонился вперёд. — Но при одном условии.
Она прищурилась: — Ну?
— Я беру этот проект как проджект-раннер. Не как менеджер, не как «исполнитель хотелок». Я беру на себя ответственность за результат. Но за это требую полной свободы: сам формирую команду, сам выбираю методы, сам веду переговоры с клиентом.
Марина молчала.
— Я не хочу больше KPI в часах и спринтах, — продолжил он. — Мой KPI — работающий продукт и довольный клиент.
— Ты понимаешь, что просишь? — её голос стал ледяным.
— Ты хочешь единоличный контроль. А если проект провалится?
Алекс сглотнул. Внутри всё кричало «беги», но он произнёс: — Тогда виноват буду только я.
Долгая пауза.
Марина откинулась на спинку кресла. — Ты сумасшедший.
— Возможно, — улыбнулся Алекс. — Но именно таких сумасшедших и описывает «Метод параноика».
Она рассмеялась коротко, почти зло. — Хорошо. Я дам тебе этот проект. Но учти: ты сам подписал себе приговор. Если сорвёшь — в студии для тебя места больше не будет.
Алекс кивнул.
Когда он вышел из кабинета, ноги дрожали. Он чувствовал не триумф, а холодный ком в животе. Теперь он не мог винить ни клиента, ни руководство, ни команду.
Впервые в жизни ответственность была целиком на нём.
Именно этого я и хотел, — подумал он, закрывая за собой дверь. Именно этого и боялся.
@theparanoidmethod
7👍5❤1🔥1
Метод параноика Вадима Митякина
Тренинг для управляющих и владельцев агентств в Ростове-на-Дону 12-13 сентября Два дня — про стратегию, управление и развитие. Только 10 участников, живая работа и конкретные инструменты для роста. Цель: разобраться, какие существуют сценарии развития агентства…
Ребят, приветствую! Хочу напомнить, что уже через пару недель пройдет тренинг для управленцев и владельцев агентств в Ростове. Детей в школу отправили, сами отдохнули, самое время сделать ревизию собственной компании и подходов к продажам и управлению!
👍5
Forwarded from Вадим Митякин (Зачем?)
Существует интересный феномен: чем выше человек по карьерной лестнице в качестве наемного сотрудника, там дальше он ментально от психотипа владельца компании.
Другими словами, чем ближе вы по позиции к CEO крупной корпорации, тем с меньшей долей вероятности запустите собственную компанию.
p.s. У этого есть масса следствий, например, разительно отличается манера общения CEO и фаундера с подчиненными и партнерами, также огромная разница в их отношении к неопределенности и трансформации компании. Ну и конечно же совершенно разное отношение к авторитетам и понятию статуса.
Другими словами, чем ближе вы по позиции к CEO крупной корпорации, тем с меньшей долей вероятности запустите собственную компанию.
p.s. У этого есть масса следствий, например, разительно отличается манера общения CEO и фаундера с подчиненными и партнерами, также огромная разница в их отношении к неопределенности и трансформации компании. Ну и конечно же совершенно разное отношение к авторитетам и понятию статуса.
👍3🤔2
23-24 сентября выступаю на BOOST 2025 — крупнейшей конференции диджитал-агентств, студий, SaaS-продуктов и B2B
В этот раз мне повезло и у меня будет возможность сделать это в трех форматах: спикером, ведущим дискуссионной панели и в качестве автора книги.
Сегодня расскажу про дискуссионную панель, которую мы придумали с организаторами для секции Управление бизнесом. Во второй день конференции с 15 до 16 будем обсуждать собственные продукты в агентствах, являются ли они бизнесом или это просто хобби:
• Почему запускаются продукты в агентстве?
• Является ли продукт хорошим способом развития собственной отраслевой специализации?
• Можно ли вокруг продукта выстроить консалтинговое направление?
• Можно ли с помощью продукта продавать свои услуги?
• Факторы успеха и провала собственных продуктов?
• Может ли существовать продукт в рамках агентства или нужно выделять в отдельную компанию?
• Собственный продукт как прямой заработок или помощь в продаже услуг
Список участников панели еще уточняется, но уже сейчас подтверждены Александр Хачиян (AWG) и Руслан Гайнанов (Тимфорс).
Независимо от того, владелец ли вы агентства и SaaS-продукта, генеральный директор, CMO, CTO, арт-директор, руководитель разработки, продаж или клиентского сервиса, BOOST — это крутое место, где можно обменяться опытом и забрать себе рабочие инструменты лучших диджитал-команд страны. Так что присоединяйтесь!
📅 23–24 сентября, кампус «Московской школы управления СКОЛКОВО»
🎟 Билеты и программа: boostconf.ru
И традиционно промокод на 10% скидку — ВАДИМ10
В этот раз мне повезло и у меня будет возможность сделать это в трех форматах: спикером, ведущим дискуссионной панели и в качестве автора книги.
Сегодня расскажу про дискуссионную панель, которую мы придумали с организаторами для секции Управление бизнесом. Во второй день конференции с 15 до 16 будем обсуждать собственные продукты в агентствах, являются ли они бизнесом или это просто хобби:
• Почему запускаются продукты в агентстве?
• Является ли продукт хорошим способом развития собственной отраслевой специализации?
• Можно ли вокруг продукта выстроить консалтинговое направление?
• Можно ли с помощью продукта продавать свои услуги?
• Факторы успеха и провала собственных продуктов?
• Может ли существовать продукт в рамках агентства или нужно выделять в отдельную компанию?
• Собственный продукт как прямой заработок или помощь в продаже услуг
Список участников панели еще уточняется, но уже сейчас подтверждены Александр Хачиян (AWG) и Руслан Гайнанов (Тимфорс).
Независимо от того, владелец ли вы агентства и SaaS-продукта, генеральный директор, CMO, CTO, арт-директор, руководитель разработки, продаж или клиентского сервиса, BOOST — это крутое место, где можно обменяться опытом и забрать себе рабочие инструменты лучших диджитал-команд страны. Так что присоединяйтесь!
📅 23–24 сентября, кампус «Московской школы управления СКОЛКОВО»
🎟 Билеты и программа: boostconf.ru
И традиционно промокод на 10% скидку — ВАДИМ10
🔥2
История 3: «Не команда, а конструктор» (Метод параноика: Изображая Голдратта)
История 2: «Договор параноика»
Алекс сидел за ноутбуком, уставившись в пустую таблицу. Команда проекта. Раньше это было просто: HR присылает список доступных людей, и ты работаешь с тем, что есть. Но теперь всё иначе. Теперь команда — его ответственность.
В дверь постучали. Вошёл Дима, фронтендер. — Ну что, когда стартуем? — спросил он бодро. — Говорят, ты теперь главный.
— Не «главный», а проджект-раннер, — поправил Алекс. — И стартуем, как только я соберу команду.
— Ну так вот я и пришёл, — усмехнулся Дима. — Я свободен, можешь меня брать.
Алекс помолчал. Раньше он бы обрадовался: лишние руки всегда в плюс. Но теперь он понимал — «свободен» не значит «нужен».
— Спасибо, Дим, — мягко ответил он. — Но мне нужен не просто разработчик. Мне нужен тот, кто горит идеей и умеет работать в условиях неопределённости. Ты сам говорил, что любишь, когда всё расписано. Этот проект — не такой.
Дима нахмурился, но пожал плечами и ушёл.
###
Через час Алекс сидел напротив Леры, дизайнера. — Слушай, — сказала она, — я умею делать интерфейсы. Но если ты ищешь «рисовать по ТЗ», то это не ко мне. Я люблю копаться в исследованиях, понимать пользователей.
Алекс почувствовал, как что-то щёлкнуло. — Именно это мне и нужно. Не интерфейсы, а понимание пользователей. Хочу, чтобы ты стала частью ядра команды.
Лера улыбнулась: — Ну наконец-то кто-то это понял.
###
Вечером он встретился с Сергеем, архитектором, который славился тем, что брался только за сложные, неочевидные задачи. — Проект туман, — честно сказал Алекс. — Никто не знает, что должно получиться. — Идеально, — оживился Сергей. — Ненавижу скучные задачи.
Алекс рассмеялся. Именно таких людей он искал: тех, кто не боится хаоса, а чувствует себя в нём как дома.
###
На следующий день Марина встретила его в коридоре. — Ну что, собрал кого-нибудь? — спросила с иронией.
— Да, — кивнул Алекс. — Лера и Сергей уже в деле. — Два человека? — подняла бровь Марина. — Ты думаешь, этого хватит?
— Для начала — да. Мы не запускаем производство, мы ищем направление. Нам нужно ядро, которое сможет мыслить и принимать решения. Остальных подключим позже.
Марина посмотрела на него долго. — Знаешь, ты начинаешь напоминать не менеджера, а продюсера. Собираешь людей под конкретный проект, как режиссёр собирает актёров под фильм.
Алекс улыбнулся. — Именно так и должно быть. Это не команда «на все случаи жизни». Это — конструктор.
И впервые он почувствовал, что строит не просто проект, а что-то большее — новый способ работы.
@theparanoidmethod
История 2: «Договор параноика»
Алекс сидел за ноутбуком, уставившись в пустую таблицу. Команда проекта. Раньше это было просто: HR присылает список доступных людей, и ты работаешь с тем, что есть. Но теперь всё иначе. Теперь команда — его ответственность.
В дверь постучали. Вошёл Дима, фронтендер. — Ну что, когда стартуем? — спросил он бодро. — Говорят, ты теперь главный.
— Не «главный», а проджект-раннер, — поправил Алекс. — И стартуем, как только я соберу команду.
— Ну так вот я и пришёл, — усмехнулся Дима. — Я свободен, можешь меня брать.
Алекс помолчал. Раньше он бы обрадовался: лишние руки всегда в плюс. Но теперь он понимал — «свободен» не значит «нужен».
— Спасибо, Дим, — мягко ответил он. — Но мне нужен не просто разработчик. Мне нужен тот, кто горит идеей и умеет работать в условиях неопределённости. Ты сам говорил, что любишь, когда всё расписано. Этот проект — не такой.
Дима нахмурился, но пожал плечами и ушёл.
###
Через час Алекс сидел напротив Леры, дизайнера. — Слушай, — сказала она, — я умею делать интерфейсы. Но если ты ищешь «рисовать по ТЗ», то это не ко мне. Я люблю копаться в исследованиях, понимать пользователей.
Алекс почувствовал, как что-то щёлкнуло. — Именно это мне и нужно. Не интерфейсы, а понимание пользователей. Хочу, чтобы ты стала частью ядра команды.
Лера улыбнулась: — Ну наконец-то кто-то это понял.
###
Вечером он встретился с Сергеем, архитектором, который славился тем, что брался только за сложные, неочевидные задачи. — Проект туман, — честно сказал Алекс. — Никто не знает, что должно получиться. — Идеально, — оживился Сергей. — Ненавижу скучные задачи.
Алекс рассмеялся. Именно таких людей он искал: тех, кто не боится хаоса, а чувствует себя в нём как дома.
###
На следующий день Марина встретила его в коридоре. — Ну что, собрал кого-нибудь? — спросила с иронией.
— Да, — кивнул Алекс. — Лера и Сергей уже в деле. — Два человека? — подняла бровь Марина. — Ты думаешь, этого хватит?
— Для начала — да. Мы не запускаем производство, мы ищем направление. Нам нужно ядро, которое сможет мыслить и принимать решения. Остальных подключим позже.
Марина посмотрела на него долго. — Знаешь, ты начинаешь напоминать не менеджера, а продюсера. Собираешь людей под конкретный проект, как режиссёр собирает актёров под фильм.
Алекс улыбнулся. — Именно так и должно быть. Это не команда «на все случаи жизни». Это — конструктор.
И впервые он почувствовал, что строит не просто проект, а что-то большее — новый способ работы.
@theparanoidmethod
9❤2
Forwarded from KozhinDev Meetup | KD Conf
This media is not supported in your browser
VIEW IN TELEGRAM
Как агентству перестать конкурировать по цене? Наш следующий спикер может ответить на этот вопрос и рассказать, как обрести уникальное позиционирование, за которое вас полюбят клиенты 😎
Вадим Митякин — методолог и консультант в области бизнеса и управления проектами, автор книги «Метод параноика»💪
На KD Conf он выступит с докладом «Отраслевое позиционирование агентства: как выйти из ценовой гонки и упаковать отраслевую экспертизу в решения для рынка».
От позиционирования зависит то, как вас видят клиенты, а чтобы клиенты увидели в вас ценность, нужно обладать уникальными качествами. Спикер подробно объяснит и расскажет:
🟢 Как отсутствие позиционирования приводит к суете, депресии и кассовым разрывам;
🟢 Какие вообще могут быть варианты позиционирования;
🟢 В чем может проявляться уникальность для разных вариантов позиционирования;
🟢 Как запустить процесс изменений и обрести уникальность компании не на словах, а на деле.
Отличная возможность послушать эксперта, который занимается проведением стратегических сессий, решением концептуальных задач в бизнесе и не раз помогал запуститься отраслевым IT-компаниям🔥
🟥 Забирайте свой билет по ссылке
Вадим Митякин — методолог и консультант в области бизнеса и управления проектами, автор книги «Метод параноика»
На KD Conf он выступит с докладом «Отраслевое позиционирование агентства: как выйти из ценовой гонки и упаковать отраслевую экспертизу в решения для рынка».
От позиционирования зависит то, как вас видят клиенты, а чтобы клиенты увидели в вас ценность, нужно обладать уникальными качествами. Спикер подробно объяснит и расскажет:
Отличная возможность послушать эксперта, который занимается проведением стратегических сессий, решением концептуальных задач в бизнесе и не раз помогал запуститься отраслевым IT-компаниям
Please open Telegram to view this post
VIEW IN TELEGRAM
Воркшоп по технологии продуктовой разработки для компании CreativePeople (часть 1)
Многие из вас знают, что я как консультант, внедряю технологию продуктовой разработки по «Методу параноика» в агентства и IT-компании. Для этого существует формат корпоративного трека, на котором мы с ключевой командой компании в течение двух-трех месяцев регулярно встречаемся и пересобираем модель работы, связывая вместе позиционирование, бизнес-модель и процесс работы над проектами.
И регулярно я делаю воркшопы для компаний, где мы все это ознакомительно разбираем по ключевым темам. Вчера как раз был такой воркшоп с моими любыми CreativePeople во главе с Сергеем Прокофьевым. Получилось бомбически, а заодно сделали расшифровку через DeepSeek.
Вообще вся эта история похоже уже тянет на статью Как построить агентство нового типа по «Методу параноика», но к этому еще вернемся.
### Ключевые тезисы Вадима Митякина для менеджеров проектов и руководителей агентств
1. Воронка неопределенности (The Uncertainty Funnel)
Это базовая концепция, на которой строится вся методология.
*Суть: Любой проект движется от максимальной неопределенности (туман, идеи, гипотезы) к полной определенности (конкретный, работающий продукт).
*Задача менеджера: Осознанно управлять этим движением, последовательно уменьшая неопределенность через принятие решений и получение знаний.
*Что делать: В начале проекта задавайтесь вопросом: "На каком мы этапе воронки? Что нам нужно узнать или решить, чтобы сдвинуться вправо, к определенности?".
2. Три типа проектов: Мозги — Седина — Процедуры
Критически важно правильно классифицировать проект, так как для каждого типа нужны разные подходы, команды и модели ценообразования.
*Мозги (Инновации): Проекты с высочайшей неопределенностью. Нужно придумать что-то принципиально новое. Ценообразование: Чаще всего как % от общего доступного бюджета и сроков проекта, т.к. по итогу нужно понять, переходить к реализации или подходящего решения нет.
*Седина (Отработанные решения): Пространство среднего уровня неопределенности. У вас есть экспертиза и готовые решения (наработки, код, дизайн-системы), которые вы адаптируете под задачи клиента. Ценообразование: Фиксированная цена или стоимость решения (value-based pricing). Ошибка: Продавать "Седина" по T&M — это значит "сливать" свою экспертизу даром.
*Процедуры (Ресурсы/Аутсорс): Минимальная неопределенность. Клиент точно знает, что ему нужно (например, сделать по ТЗ). Вы продаете ресурсы с определенными компетенциями. Ценообразование: T&M или ретейнер. Зарабатываете за счет оборота и эффективности.
*Главный вывод: Нельзя проект типа "Процедуры" пытаться решать как "Мозги". Это приводит к "проектам типа Жопа" — срывам сроков, бюджетов и нервным срывам.
3. Принцип сериала (The Serial Principle)
Это альтернатива линейным подходам (типа "waterfall") и чистому "scrum" для сложных проектов.
*Суть принципа: Разбейте проект на крупные смысловые сезоны (как в сериале):
1. Концепция: Проверка гипотез, фундаментальные решения. "Будет ли это вообще работать?"
2. Систематизация (Высокоуровневое проектирование): Создание архитектуры, дизайн-системы, основных процессов. "Как мы будем это строить?"
3. Череда Ранов (Эпизодов): Детальное проектирование и разработка частей продукта итерационно. В рамках Рана можно использовать гибкие методики (спринты).
*Преимущество: Вы сохраняете общее видение и архитектуру (контроль), но остаетесь гибкими внутри этапов.
4. Проектные тиски (The Project Vise)
Мощный образ для управления ограничениями.
* Суть: Пространство для решений о продукте зажато между двумя плитами:
* Верхняя плита: То, чего хочет бизнес (требования, цели).
* Нижняя плита: То, что может бизнес (бюджет, сроки, ресурсы).
* Задача менеджера: На каждой стадии проекта (концепция, дизайн, разработка) "зажимать" эти тиски, принимая решения, которые уменьшают неопределенность и не выходят за рамки ограничений.
Часть 2
@theparanoidmethod
Многие из вас знают, что я как консультант, внедряю технологию продуктовой разработки по «Методу параноика» в агентства и IT-компании. Для этого существует формат корпоративного трека, на котором мы с ключевой командой компании в течение двух-трех месяцев регулярно встречаемся и пересобираем модель работы, связывая вместе позиционирование, бизнес-модель и процесс работы над проектами.
И регулярно я делаю воркшопы для компаний, где мы все это ознакомительно разбираем по ключевым темам. Вчера как раз был такой воркшоп с моими любыми CreativePeople во главе с Сергеем Прокофьевым. Получилось бомбически, а заодно сделали расшифровку через DeepSeek.
Вообще вся эта история похоже уже тянет на статью Как построить агентство нового типа по «Методу параноика», но к этому еще вернемся.
### Ключевые тезисы Вадима Митякина для менеджеров проектов и руководителей агентств
1. Воронка неопределенности (The Uncertainty Funnel)
Это базовая концепция, на которой строится вся методология.
*Суть: Любой проект движется от максимальной неопределенности (туман, идеи, гипотезы) к полной определенности (конкретный, работающий продукт).
*Задача менеджера: Осознанно управлять этим движением, последовательно уменьшая неопределенность через принятие решений и получение знаний.
*Что делать: В начале проекта задавайтесь вопросом: "На каком мы этапе воронки? Что нам нужно узнать или решить, чтобы сдвинуться вправо, к определенности?".
2. Три типа проектов: Мозги — Седина — Процедуры
Критически важно правильно классифицировать проект, так как для каждого типа нужны разные подходы, команды и модели ценообразования.
*Мозги (Инновации): Проекты с высочайшей неопределенностью. Нужно придумать что-то принципиально новое. Ценообразование: Чаще всего как % от общего доступного бюджета и сроков проекта, т.к. по итогу нужно понять, переходить к реализации или подходящего решения нет.
*Седина (Отработанные решения): Пространство среднего уровня неопределенности. У вас есть экспертиза и готовые решения (наработки, код, дизайн-системы), которые вы адаптируете под задачи клиента. Ценообразование: Фиксированная цена или стоимость решения (value-based pricing). Ошибка: Продавать "Седина" по T&M — это значит "сливать" свою экспертизу даром.
*Процедуры (Ресурсы/Аутсорс): Минимальная неопределенность. Клиент точно знает, что ему нужно (например, сделать по ТЗ). Вы продаете ресурсы с определенными компетенциями. Ценообразование: T&M или ретейнер. Зарабатываете за счет оборота и эффективности.
*Главный вывод: Нельзя проект типа "Процедуры" пытаться решать как "Мозги". Это приводит к "проектам типа Жопа" — срывам сроков, бюджетов и нервным срывам.
3. Принцип сериала (The Serial Principle)
Это альтернатива линейным подходам (типа "waterfall") и чистому "scrum" для сложных проектов.
*Суть принципа: Разбейте проект на крупные смысловые сезоны (как в сериале):
1. Концепция: Проверка гипотез, фундаментальные решения. "Будет ли это вообще работать?"
2. Систематизация (Высокоуровневое проектирование): Создание архитектуры, дизайн-системы, основных процессов. "Как мы будем это строить?"
3. Череда Ранов (Эпизодов): Детальное проектирование и разработка частей продукта итерационно. В рамках Рана можно использовать гибкие методики (спринты).
*Преимущество: Вы сохраняете общее видение и архитектуру (контроль), но остаетесь гибкими внутри этапов.
4. Проектные тиски (The Project Vise)
Мощный образ для управления ограничениями.
* Суть: Пространство для решений о продукте зажато между двумя плитами:
* Верхняя плита: То, чего хочет бизнес (требования, цели).
* Нижняя плита: То, что может бизнес (бюджет, сроки, ресурсы).
* Задача менеджера: На каждой стадии проекта (концепция, дизайн, разработка) "зажимать" эти тиски, принимая решения, которые уменьшают неопределенность и не выходят за рамки ограничений.
Часть 2
@theparanoidmethod
Воркшоп по технологии продуктовой разработки для компании CreativePeople (часть 2)
Часть 1
5. Четкое распределение зон ответственности (Продюсерская модель)
Роли в проекте должны быть определены не по названиям, а по зонам ответственности за артефакты и решения.
*Проджект-Ранер (аналогично Шоураннеру): Ключевая роль. Это человек, который соединяет в себе понимание продукта (как продакт) и возможностей проекта (как продюсер). Отвечает за конечный результат и связь между всеми участниками. "Тому, кому больше всех надо".
*Вадим выделяет уровни абстракции в проекте, за которые отвечают разные специалисты:
* Бизнес-уровень: Зачем и для кого? (Отвечает: Проджект-Ранер/Продюсер)
* Функциональеый: Что и какую проблему решает? (Отвечает: Продакт-менеджер)
* Интерфейсный уровень: Как взаимодействует с пользователем? (Отвечает: Дизайнер)
* Технический уровень: Как реализовано внутри? (Отвечает: Техлид/Архитектор)
* Проектный уровень: Сколько стоит и как долго? (Отвечает: Проджект-менеджер)
*Что делать: В начале проекта спросите: "Кто за что отвечает на каждом из этих уровней? Какие артефакты (документы, схемы, модели) мы создадим, чтобы зафиксировать решения?"
6. Системный подход: Матрица вопросов
Вместо навязывания конкретных артефактов (как MUST HAVE для всех) Вадим предлагает использовать матрицу вопросов.
*Суть: На каждом этапе ("Концепция", "Систематизация", "Ран") и на каждом уровне абстракции ("Бизнес", "Функции", "Интерфейс", "Технологии", "Проект") есть ключевые вопросы, на которые команда должна ответить.
*Примеры вопросов:
* *На этапе "Концепция" на "Бизнес-уровне":* "Кто пользователи? Какие бизнес-процессы затронет продукт? Готов ли бизнес к этим изменениям? Что докажет, что наше решение жизнеспособно?"
* *На этапе "Систематизация" на "Техническом уровне":* "Какова архитектура решения? Какие технологии мы выбираем и почему?"
*Что делать: Используйте эту матрицу как чек-лист для запуска и контроля проекта. Это гарантирует, что вы не упустите важные аспекты.
7. Маркетинг и продажи должны соответствовать производству
Фундаментальный принцип позиционирования компании.
*Суть: "Как нас видят, так к нам и обращаются". Если вы продаете инновации ("Мозги"), а внутри у вас налажены только "Процедуры", вас ждет крах. Нельзя быть "волком", который ест мясо, но питаться травой, умрете.
*Что делать: Четко определите, что ваша компания реально умеет делать и продавать (какой тип проектов). Выстройте процессы под этот тип. Синхронизируйте маркетинг, продажи и производство на одном языке и ценностях.
Краткий план действий для менеджера:
1. Классифицируй проект: Определи, это "Мозги", "Седина" или "Процедуры"? Это определит все дальнейшие действия.
2. Оцени стадию в воронке: Пойми, насколько все неопределенно. Что нужно сделать прямо сейчас, чтобы снизить неопределенность?
3. Определи роли: Кто шоураннер? Кто отвечает за каждую зону (бизнес, продукт, дизайн, код)? Используй матрицу вопросов для проверки.
4. Работай в тисках: Всегда держи в голове ограничения по бюджету и срокам (низ) и требования бизнеса (верх). Принимай решения в этом пространстве.
5. Синхронизируйся с продажами: Убедись, что то, что продано, ваша команда может реализовать без героизма. Если нет — либо меняй процессы, либо меняй позиционирование.
Эти тезисы — системный взгляд на управление сложными проектами по «Методу параноика». Внедрение даже одного-двух из этих принципов может значительно повысить предсказуемость и успешность вашей работы.
@theparanoidmethod
Часть 1
5. Четкое распределение зон ответственности (Продюсерская модель)
Роли в проекте должны быть определены не по названиям, а по зонам ответственности за артефакты и решения.
*Проджект-Ранер (аналогично Шоураннеру): Ключевая роль. Это человек, который соединяет в себе понимание продукта (как продакт) и возможностей проекта (как продюсер). Отвечает за конечный результат и связь между всеми участниками. "Тому, кому больше всех надо".
*Вадим выделяет уровни абстракции в проекте, за которые отвечают разные специалисты:
* Бизнес-уровень: Зачем и для кого? (Отвечает: Проджект-Ранер/Продюсер)
* Функциональеый: Что и какую проблему решает? (Отвечает: Продакт-менеджер)
* Интерфейсный уровень: Как взаимодействует с пользователем? (Отвечает: Дизайнер)
* Технический уровень: Как реализовано внутри? (Отвечает: Техлид/Архитектор)
* Проектный уровень: Сколько стоит и как долго? (Отвечает: Проджект-менеджер)
*Что делать: В начале проекта спросите: "Кто за что отвечает на каждом из этих уровней? Какие артефакты (документы, схемы, модели) мы создадим, чтобы зафиксировать решения?"
6. Системный подход: Матрица вопросов
Вместо навязывания конкретных артефактов (как MUST HAVE для всех) Вадим предлагает использовать матрицу вопросов.
*Суть: На каждом этапе ("Концепция", "Систематизация", "Ран") и на каждом уровне абстракции ("Бизнес", "Функции", "Интерфейс", "Технологии", "Проект") есть ключевые вопросы, на которые команда должна ответить.
*Примеры вопросов:
* *На этапе "Концепция" на "Бизнес-уровне":* "Кто пользователи? Какие бизнес-процессы затронет продукт? Готов ли бизнес к этим изменениям? Что докажет, что наше решение жизнеспособно?"
* *На этапе "Систематизация" на "Техническом уровне":* "Какова архитектура решения? Какие технологии мы выбираем и почему?"
*Что делать: Используйте эту матрицу как чек-лист для запуска и контроля проекта. Это гарантирует, что вы не упустите важные аспекты.
7. Маркетинг и продажи должны соответствовать производству
Фундаментальный принцип позиционирования компании.
*Суть: "Как нас видят, так к нам и обращаются". Если вы продаете инновации ("Мозги"), а внутри у вас налажены только "Процедуры", вас ждет крах. Нельзя быть "волком", который ест мясо, но питаться травой, умрете.
*Что делать: Четко определите, что ваша компания реально умеет делать и продавать (какой тип проектов). Выстройте процессы под этот тип. Синхронизируйте маркетинг, продажи и производство на одном языке и ценностях.
Краткий план действий для менеджера:
1. Классифицируй проект: Определи, это "Мозги", "Седина" или "Процедуры"? Это определит все дальнейшие действия.
2. Оцени стадию в воронке: Пойми, насколько все неопределенно. Что нужно сделать прямо сейчас, чтобы снизить неопределенность?
3. Определи роли: Кто шоураннер? Кто отвечает за каждую зону (бизнес, продукт, дизайн, код)? Используй матрицу вопросов для проверки.
4. Работай в тисках: Всегда держи в голове ограничения по бюджету и срокам (низ) и требования бизнеса (верх). Принимай решения в этом пространстве.
5. Синхронизируйся с продажами: Убедись, что то, что продано, ваша команда может реализовать без героизма. Если нет — либо меняй процессы, либо меняй позиционирование.
Эти тезисы — системный взгляд на управление сложными проектами по «Методу параноика». Внедрение даже одного-двух из этих принципов может значительно повысить предсказуемость и успешность вашей работы.
@theparanoidmethod
Получилась очень продуктивная неделя в плане сессий с клиентами, воркшопов и подготовки к выступлениям.
А завтра очередной эпизод бизнес-сериала «Изображая Голдратт»!
А завтра очередной эпизод бизнес-сериала «Изображая Голдратт»!
Telegram
Метод параноика Вадима Митякина
Сегодня у нас анонс новой рубрики «Изображая Голдратта» и первый эпизод короткой серии историй про становление проджект-раннера.
История 1: «Виновен без вины»
История 2: «Договор параноика»
История 3: «Не команда, а конструктор»
История 4: «Язык бизнеса…
История 1: «Виновен без вины»
История 2: «Договор параноика»
История 3: «Не команда, а конструктор»
История 4: «Язык бизнеса…
История 4: «Язык бизнеса, язык технологий» (Метод параноика: Изображая Голдратта)
История 3: «Не команда, а конструктор»
Переговорная была тесной и душной. На экране висел логотип клиента — крупной логистической компании. За столом сидели трое: финансовый директор, операционный менеджер и айтишник в очках. Все смотрели на Алекса, как на подозреваемого.
— Ну что, — начал финансовый директор, — давайте к делу. Сколько это будет стоить и когда вы закончите?
Раньше Алекс рефлекторно достал бы презентацию со сроками и оценками. Но теперь он вспомнил: я больше не «менеджер часов». Я отвечаю за результат.
Он положил руки на стол и спокойно сказал: — Прежде чем говорить о сроках и бюджете, давайте разберёмся: какую задачу для бизнеса вы решаете?
Менеджер по операциям нахмурился: — Как это «какую»? Мы хотим систему отслеживания грузов в реальном времени.
— Это инструмент, — мягко ответил Алекс. — А в чём сама проблема?
Повисла пауза. Клиент переглянулись.
— У нас теряются грузы, — наконец сказал операционный. — Водители врут о маршрутах, и мы не успеваем реагировать. — Отлично, — кивнул Алекс. — Значит, ключевая цель — снизить число потерянных грузов и повысить прозрачность. Верно? Финансовый директор кивнул. — И если мы этого не сделаем? — Мы теряем контракты и деньги, — признался он.
Алекс почувствовал, как напряжение в комнате меняется. Вот оно. Теперь мы говорим на языке бизнеса, а не хотелок.
— Тогда так, — продолжил он. — Мы не можем обещать всё и сразу. Но мы можем взять короткий отрезок — три месяца. За это время мы создадим прототип, который позволит вам отслеживать хотя бы часть грузов. Если это даст результат, расширим систему.
Айтишник усмехнулся: — То есть вы не можете назвать дату окончания всего проекта?
— Никто в мире не может, — спокойно ответил Алекс. — Но я гарантирую, что через три месяца у вас будет рабочий инструмент, который решает вашу ключевую бизнес-проблему.
Тишина. Потом финансовый директор медленно сказал: — Знаете… Я впервые чувствую, что меня не пытаются уговорить на покупку «часы программистов». Вы говорите о том, что реально важно.
Алекс кивнул. В груди теплилось чувство странного спокойствия.
Он больше не был человеком, который приносит клиенту пачку согласованных требований. Он стал тем, кто переводит язык технологий на язык бизнеса и обратно.
Переводчиком. Проводником. Проджект-раннером.
@theparanoidmethod
История 3: «Не команда, а конструктор»
Переговорная была тесной и душной. На экране висел логотип клиента — крупной логистической компании. За столом сидели трое: финансовый директор, операционный менеджер и айтишник в очках. Все смотрели на Алекса, как на подозреваемого.
— Ну что, — начал финансовый директор, — давайте к делу. Сколько это будет стоить и когда вы закончите?
Раньше Алекс рефлекторно достал бы презентацию со сроками и оценками. Но теперь он вспомнил: я больше не «менеджер часов». Я отвечаю за результат.
Он положил руки на стол и спокойно сказал: — Прежде чем говорить о сроках и бюджете, давайте разберёмся: какую задачу для бизнеса вы решаете?
Менеджер по операциям нахмурился: — Как это «какую»? Мы хотим систему отслеживания грузов в реальном времени.
— Это инструмент, — мягко ответил Алекс. — А в чём сама проблема?
Повисла пауза. Клиент переглянулись.
— У нас теряются грузы, — наконец сказал операционный. — Водители врут о маршрутах, и мы не успеваем реагировать. — Отлично, — кивнул Алекс. — Значит, ключевая цель — снизить число потерянных грузов и повысить прозрачность. Верно? Финансовый директор кивнул. — И если мы этого не сделаем? — Мы теряем контракты и деньги, — признался он.
Алекс почувствовал, как напряжение в комнате меняется. Вот оно. Теперь мы говорим на языке бизнеса, а не хотелок.
— Тогда так, — продолжил он. — Мы не можем обещать всё и сразу. Но мы можем взять короткий отрезок — три месяца. За это время мы создадим прототип, который позволит вам отслеживать хотя бы часть грузов. Если это даст результат, расширим систему.
Айтишник усмехнулся: — То есть вы не можете назвать дату окончания всего проекта?
— Никто в мире не может, — спокойно ответил Алекс. — Но я гарантирую, что через три месяца у вас будет рабочий инструмент, который решает вашу ключевую бизнес-проблему.
Тишина. Потом финансовый директор медленно сказал: — Знаете… Я впервые чувствую, что меня не пытаются уговорить на покупку «часы программистов». Вы говорите о том, что реально важно.
Алекс кивнул. В груди теплилось чувство странного спокойствия.
Он больше не был человеком, который приносит клиенту пачку согласованных требований. Он стал тем, кто переводит язык технологий на язык бизнеса и обратно.
Переводчиком. Проводником. Проджект-раннером.
@theparanoidmethod
11❤6