Касательно 2го кейса, да существует в производстве такое понятие как switching cost, но наш подход не твердит, что вся команда должна переключаться на продукт А или Б, или В. может быть расстановка где 1 человек на А, 2 человека на Б и 1 на В. Любые комбинации возможны. Главное все обсудить и запланировать.

Владимир, вопрос хороший! 1й кейс: приоритетность продукта поднимает не его успешность, а потенциальная ценность отдельной функции (истории) для всего проекта BetterMe. Например, если фича Х сделает продукт Б успешней чем лидирующий продукт А, то конечно мы дадим высокий приоритет такой задаче. Итого, не важна успешность продукта, важен прирост, который может дать новая история для всего нашего бизнеса

Денис, недавно пришли к тому, что если релиз требует длительного периода реализации, то необходимо проводить: 1) периодическую коректировку плана, учитывая реалии; 2) регулярное демо, где команда говорит на сколько идет в ногу с планом. Адаптация плана — это нормально. + это позволяет «выкидывать» лишнее, если наблюдаем сильное отклонение от плановой оценки сроков.

Извините, я не понял ваш вопрос про бутиковый путь развития.

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

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

Хочу отметить, что когда у вас сильная команда, то от вас не требуется постоянный «пушинг», оценка, контроль. Очень важно жестко отбирать команду на ранней стадии; это перекроет большой ряд вопросов.

Дмитрий, спасибо за вопрос. В моей практике, кейса когда реальный срок отличался от запланированного в 4 раза — небыло, поэтому затрудняюсь ответить. Кроме того, мы всегда стараемся дробить функционал и тестировать идеи минимальными усилиями.

Не буду с вами спорить, так как у вас свои реалии и опыт. В том то и дело, что этот подход прошел тестирование, учитывая «обязательства по срокам к стейкхолдерам\кастомерам». Мы не аутсорс и команда отвечает за результаты перед самими собой, поэтому в эффективности заинтересован каждый.

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

Денис, спасибо за вопрос. Спринтов, как таковых, нет. Разработка идет параллельно 2-3х продуктов; а может разрабатываться и 1н продукт, если он сейчас самый приоритетный и требует фокусировки усилий.

Тарас, вопрос хороший. Тут просто важен навык приоритезации. Поверьте, в рамках 3х продуктов всегда можно найти самые приоритетные вещи, которые при Х усилий должны принести 2Х результата; наоборот, такой подход позволяет/заставляет отсекать лишнее, а его очень много, как правило. Согласно нашему подходу, за расстановку приоритетов между продуктами отвечает CPO.