Я понял вас, спасибо за статью. Но простите конечно, тогда это не риск менеджмент вовсе. Это чистый факап со стороны Прожект менеджера, который просто не доделал свою работу. Ведь без реестра рисков можно работать (просто постепенно его наполняя), а без журнала нет.
Если честно не увидел самого главного, то как риски обрабатываются. Ок у вас есть реестр рисков, в нем отмечаются риски и стратегии их обработки + обязательно прописываются: План А и План Б. Есть журнал рисков, в котором отмечаются риски на регулярном собрании (которые вытаскиваются из реестра). Также на встрече отмечается хозяин риска, которой несет ответственность за реализацию Плана А. При чем тут "мы предупреждали" - есть хозяин риска и план, который он должен был выполнить и отчитаться на следующей встрече как обрабатывал риск и зафиксировать действия/ последствия. Не смог обработать, значит вступает план Б, возможно с эскалированием до вышестоящего ответственного.
Игорь, в целом хорошая техническая статья, но хочется ответа на вопрос: Зачем это всё? В том числе для какой аудитории эта статья? И что это решает? Это можно понять есть только прочитать все и попробовать вникнуть.
Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Как продакт, который сам много работает с UI, текст в целом откликнулся. Очень точно показан разрыв между «красиво в Figma» и тем, как интерфейс реально живёт в цеху — с железом, шумом и людьми, которые работают на рефлексах, а не по гайдлайнам.
При этом посыл сильный и правильный. Круто, что дизайн показан как часть продукта и инженерная работа, а не как «наведение красоты». Если после изменений оператору реально стало проще и спокойнее работать — значит UI сделан правильно, независимо от трендов и наград.
Читаю как продакт и не могу отделаться от ощущения, что это очень аккуратно упакованный гайд про процесс, а не про стратегию.
Текст подробно объясняет, как писать, согласовывать и защищать стратегию, но почти не отвечает на самый сложный вопрос — какие реальные решения приходится принимать и чем за них потом расплачиваться.
В жизни стратегия — это не CJM и не six-pager. Это моменты, когда ты говоришь «нет» деньгам, рынку, командам или популярным идеям. Это конфликты приоритетов, ошибки и решения, которые нельзя просто откатить. Именно этого в статье не хватает больше всего.
Фреймворки описаны корректно, спору нет. Но фреймворки сами по себе ничего не решают — они просто фиксируют уже принятые решения. Без живых кейсов Avito, цифр, провалов и неприятных компромиссов всё выглядит как универсальный корпоративный шаблон.
Думаю, для продактов, которые только начинают работать со стратегией в большой компании, статья будет полезной. Но для тех, кто реально отвечает за рост, P&L и портфель продуктов, нового здесь немного.
Было бы гораздо интереснее прочитать честный разбор одного конкретного стратегического решения в Avito: что выбрали, от чего отказались, кто был недоволен и какую цену за это заплатили. Вот в этом месте и начинается настоящая продуктовая стратегия, ваша компания постоянно отжимает у нас кучу денег за продажу товаров на вашей площадке, очень было бы интересно узнать про что-нибудь реальное, а не пустую писанину.
Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.
Я понял вас, спасибо за статью.
Но простите конечно, тогда это не риск менеджмент вовсе.
Это чистый факап со стороны Прожект менеджера, который просто не доделал свою работу. Ведь без реестра рисков можно работать (просто постепенно его наполняя), а без журнала нет.
Если честно не увидел самого главного, то как риски обрабатываются.
Ок у вас есть реестр рисков, в нем отмечаются риски и стратегии их обработки + обязательно прописываются: План А и План Б.
Есть журнал рисков, в котором отмечаются риски на регулярном собрании (которые вытаскиваются из реестра). Также на встрече отмечается хозяин риска, которой несет ответственность за реализацию Плана А.
При чем тут "мы предупреждали" - есть хозяин риска и план, который он должен был выполнить и отчитаться на следующей встрече как обрабатывал риск и зафиксировать действия/ последствия. Не смог обработать, значит вступает план Б, возможно с эскалированием до вышестоящего ответственного.
Игорь, в целом хорошая техническая статья, но хочется ответа на вопрос: Зачем это всё? В том числе для какой аудитории эта статья? И что это решает?
Это можно понять есть только прочитать все и попробовать вникнуть.
А… вы иронизируете. Ясно ясно
Не спорю с вами, даже в некотором роде согласен.
Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Как продакт, который сам много работает с UI, текст в целом откликнулся. Очень точно показан разрыв между «красиво в Figma» и тем, как интерфейс реально живёт в цеху — с железом, шумом и людьми, которые работают на рефлексах, а не по гайдлайнам.
При этом посыл сильный и правильный. Круто, что дизайн показан как часть продукта и инженерная работа, а не как «наведение красоты». Если после изменений оператору реально стало проще и спокойнее работать — значит UI сделан правильно, независимо от трендов и наград.
Будет ещё больше неподдерживаемого ковнокода.
Читаю как продакт и не могу отделаться от ощущения, что это очень аккуратно упакованный гайд про процесс, а не про стратегию.
Текст подробно объясняет, как писать, согласовывать и защищать стратегию, но почти не отвечает на самый сложный вопрос — какие реальные решения приходится принимать и чем за них потом расплачиваться.
В жизни стратегия — это не CJM и не six-pager. Это моменты, когда ты говоришь «нет» деньгам, рынку, командам или популярным идеям. Это конфликты приоритетов, ошибки и решения, которые нельзя просто откатить. Именно этого в статье не хватает больше всего.
Фреймворки описаны корректно, спору нет. Но фреймворки сами по себе ничего не решают — они просто фиксируют уже принятые решения. Без живых кейсов Avito, цифр, провалов и неприятных компромиссов всё выглядит как универсальный корпоративный шаблон.
Думаю, для продактов, которые только начинают работать со стратегией в большой компании, статья будет полезной. Но для тех, кто реально отвечает за рост, P&L и портфель продуктов, нового здесь немного.
Было бы гораздо интереснее прочитать честный разбор одного конкретного стратегического решения в Avito: что выбрали, от чего отказались, кто был недоволен и какую цену за это заплатили. Вот в этом месте и начинается настоящая продуктовая стратегия, ваша компания постоянно отжимает у нас кучу денег за продажу товаров на вашей площадке, очень было бы интересно узнать про что-нибудь реальное, а не пустую писанину.
Тут и да и нет. В зависимости от типа управления, я могу выделить примерно 6 типов:
Команда → процессная / функциональная
Инициатива → проектная
Продукт → продуктовая
Организация → матричная
Бизнес в целом → портфельная (если >1 проекта)
В зависимости от типа управления, и структуры CLVL: видение, стратегия, а также риски будут по-разному разделены между управляющим составом.
Но в любом случае PO/ CPO будет нести основную ответственность.
Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.