У меня ощущение, что проект полностью вышел из-под контроля. Когда мы наконец получим работающий продукт?На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным.
Хороший продакт-менеджер берет на себя ответственность за успех или провал проектаЭто не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика
Нечеткая коммуникацияТо, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ
Игнорирование обратной связи. Хороший продакт-менеджер открыт для конструктивной критики и готов учиться. Плохой игнорирует замечания и советы команды и заказчика.Смешались в кучу мухи, котлеты, кони, люди... Смотрите, в нормально выстроенной работе у вас есть понятные стадии (упрощу до уровня второклассника, чтобы не душнить): 1. Сбор, валидация, оформление БТ. Все советы от заказчика принимаются и фиксируются на этом этапе.
Когда этап завершен и БТ зафиксированы подписью заказчика, никакие советы от него больше не принимаются. Либо принимаются, но на аналогичный этап версии 2.0 продукта. Иначе вы БТ не соберете никогда, потому что заказчику новые идеи (одна охуительнее другой просто) приходят примерно 2-3 раза в сутки
2. Продуктовая проработка и составление концепта ТЗ (ответ на вопросы "Что и зачем должен делать продукт?") На этом этапе продакт активно обращается к заказчику, но не за советом, а за ответом на вопрос "Я вижу, что продукт должен делать сепульку, чтобы закрыть клиентские потребности 1,2,3 из БТ. Но я предложу добавить к сепульке еще какульку (вот UI прототип), тогда сразу закроем еще потребность 4,5,6. Вы согласны с таким решением?"
3. Техническая проработка (ответ на вопросы "Насколько это вообще реализуемо технически" и "Как должен работать продукт?"). Финал этапа - оформленное ТЗ, под которым подписались архитекторы, лиды разработки, лиды эксплуатации
На этом этапе собирается и обрабатывается вся обратная связь от команды. После подписания ТЗ любая обратная связь от команды (обычно в стиле "Ой, блядь, мы вот здесь херово подумали" или "А тут вот вышел фреймворк Х, давайте на нем сделаем") идет в раздел "Техдолг" продуктового бэклога, более нигде не учитывается
"На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным."
- Посмотрите немного шире на пример ответа. Неправильность не в форме самого ответа с план-графиком, а в том, что продакт довел до ситуации, где заказчик/стейкхолдер не понимает что происходит. Тут про прозрачность и управление ожиданиями.
"Это не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика"
- Путается немного терминология и определения. Если продакт менеджер отвечает за соответствие бизнес требованиям заказчика, то это больше похоже на проджекта, которому говорят, что делать. Если же под бизнес требованиями подразумеваются бизнес цели, которых хочется достичь, в том числе через продукт, то соглашусь.
По теме product manager/owner как роли в РФ это примерно про одно и то же. У тебя есть бизнесовая цель и ты отвечаешь за нее через продукт и доверенный ресурс (команда разработки). За бугром функционал ролей может разниться.
"То, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ"
Согласен.
По пунктам далее прокомментирую.
П.1 Дополню, можно и не собирать на самом деле БТ, а сильно экономить время и в процессе диалога сразу выяснить "Зачем? И как это поможет нашим целям?". Тупо сэкономите время.
Но такое возможно опять же, если роль продакта полноценная, оунерская вашими словами.
У меня ощущение, что проект полностью вышел из-под контроля. Когда мы наконец получим работающий продукт?На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным.
Хороший продакт-менеджер берет на себя ответственность за успех или провал проектаЭто не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика
Нечеткая коммуникацияТо, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ
Игнорирование обратной связи. Хороший продакт-менеджер открыт для конструктивной критики и готов учиться. Плохой игнорирует замечания и советы команды и заказчика.Смешались в кучу мухи, котлеты, кони, люди... Смотрите, в нормально выстроенной работе у вас есть понятные стадии (упрощу до уровня второклассника, чтобы не душнить):
1. Сбор, валидация, оформление БТ. Все советы от заказчика принимаются и фиксируются на этом этапе.
Когда этап завершен и БТ зафиксированы подписью заказчика, никакие советы от него больше не принимаются. Либо принимаются, но на аналогичный этап версии 2.0 продукта. Иначе вы БТ не соберете никогда, потому что заказчику новые идеи (одна охуительнее другой просто) приходят примерно 2-3 раза в сутки
2. Продуктовая проработка и составление концепта ТЗ (ответ на вопросы "Что и зачем должен делать продукт?") На этом этапе продакт активно обращается к заказчику, но не за советом, а за ответом на вопрос "Я вижу, что продукт должен делать сепульку, чтобы закрыть клиентские потребности 1,2,3 из БТ. Но я предложу добавить к сепульке еще какульку (вот UI прототип), тогда сразу закроем еще потребность 4,5,6. Вы согласны с таким решением?"
3. Техническая проработка (ответ на вопросы "Насколько это вообще реализуемо технически" и "Как должен работать продукт?"). Финал этапа - оформленное ТЗ, под которым подписались архитекторы, лиды разработки, лиды эксплуатации
На этом этапе собирается и обрабатывается вся обратная связь от команды. После подписания ТЗ любая обратная связь от команды (обычно в стиле "Ой, блядь, мы вот здесь херово подумали" или "А тут вот вышел фреймворк Х, давайте на нем сделаем") идет в раздел "Техдолг" продуктового бэклога, более нигде не учитывается
"На такой вопрос есть только один правильный ответ: в установленные графиком работ сроки. И этот ответ вы почему-то считаете неверным."
- Посмотрите немного шире на пример ответа. Неправильность не в форме самого ответа с план-графиком, а в том, что продакт довел до ситуации, где заказчик/стейкхолдер не понимает что происходит. Тут про прозрачность и управление ожиданиями.
"Это не продакт менеджер, а product owner (с немного другой мотивационной схемой, кстати). Тот да, берет на себя еще и всю бизнес составляющую и отвечает за успех или провал. А продакт менеджер отвечает за продукт и его соответствие бизнес-требованиям заказчика"
- Путается немного терминология и определения. Если продакт менеджер отвечает за соответствие бизнес требованиям заказчика, то это больше похоже на проджекта, которому говорят, что делать. Если же под бизнес требованиями подразумеваются бизнес цели, которых хочется достичь, в том числе через продукт, то соглашусь.
По теме product manager/owner как роли в РФ это примерно про одно и то же. У тебя есть бизнесовая цель и ты отвечаешь за нее через продукт и доверенный ресурс (команда разработки). За бугром функционал ролей может разниться.
"То, о чем пишите вы - это не про коммуникацию, а про умение ставить ТЗ"
Согласен.
По пунктам далее прокомментирую.
П.1 Дополню, можно и не собирать на самом деле БТ, а сильно экономить время и в процессе диалога сразу выяснить "Зачем? И как это поможет нашим целям?". Тупо сэкономите время.
Но такое возможно опять же, если роль продакта полноценная, оунерская вашими словами.
П.2.3 Да, обычная операционка.