8961: MOSCOW, RUSSIA
AMER. CTR. FOR EDUCATION & TESTING
2 LENINSKII PROSPEKT / ROOM 530
MOSCOW, RUS 117049

Phone 7 495 2304550

Но если учесть, что 2 дня прохождения тренинга эквивалентна 2 дням чтения брейндампа, то можно сделать вывод, что усилия требуются одинаковые. Пока писал коммент повысил планку CSPO в своих же глазах

http://swpm.ru/2010/08/npdp-and-cspo/

И туда же свободное поле Ваш skill и Ваш рейтинг ?

И ещё – давайте не путать организационную структуру, тем более функциональную (функциональные подразделения) и продуктовую команду.

Тогда как быть с позиционированием продукта, анализом рынка и другими маркетинговыми мероприятиями занимается отдел маркетинга?

Т.е. вы выполняете сервисную функцию для различных подразделений, а не определяющую функцию? Иными словами, не вы даете задания маркетингу, а маркетинг запрашивает у вас информацию?

Что касается размышлений про подходы к управлению и степень вхождения ПдМа в функциональные области – абсолютно правильные размышления, все дейсьтвительно зависит и от продукта и от компании и от рынка и т.д., в общем-то с небольшой добавкой, о которой я говорил- здравая оценка своих возможностей, скилов и навыков, помня основную заповедь «Не навреди».

Да, и кстати, я так же как и в предыдущем комментарии не совсем согласен с тем, что успешность работы ПдМа можно измерять продажами\распространением, хотя как один из показателей – он вполне нормально подойдет, но только как один из пачки других.

Я бы не стал использовать постулат о том, что успех ПдМ – это успех продукта на рынке. Факторы успеха продукта на рынке могут лежать как внутри так и вне компании и это больше характеристика всей организации от CEO до инженера кол-центра. Думаю нам надо бы придумать другой, более однозначный показатель успешной работы ПдМ

Спорно потому, что без пояснения авторов, кажется, что треугольник неправильный. Потребители влияют скорее на Объем и Сроки (им нужно больше и быстрее). Конкуренты тоже влияют прежде всего на Сроки и Объем, а Технологии на Бюджет и Сроки. При этом конечно такую стройную картинку не нарисуешь ))). Но можно чуть по-другому:

Расположить БОС не по углам, а по сторонам. Тогда можно (с некоторой, оправданной для целей упрощения схемы, натяжкой) пристроить Конкурентов к Срокам, Потребителей к Объему, а Технологии к Бюджету… Получится тоже не идеальная схема, но по-моему более понятная.

В общем – ждем пояснений…

Кстати, я мог бы расписать возможности Облака, ориентированные на продуктовое управление, можно ли опубликовать пост у вас?

Обязательно учту в следующей версии.

понятие «маркетинг» потеряло изначальный смысл и под ним теперь понимают «кружки и футболки», а не изучение и понимание рынка. Мы не будем изменять это представление, а освободившуюся нишу (слушать и понимать рынок) передаем продакт-менеджменту.

«Особенности управления требованиями в продуктовой разработке» я писал. Спасибо!

На мой взгляд, различие в разработке для нужд компании (=заказной разработке) и разработке для рынка – это, собственно, и есть различие между управлением проектами и управлением продуктами.

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

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

Да, на 28 слайде сильное упрощение. Заменю в следующей версии.

Не совсем понял слайд о том, что «продукт – это результат ряда проектов». То ли речь идет об очевидном то ли что-то упущено, отчего мысль автора не понятна.

Понравился слайд «Особенности управления требованиями в продуктовой разработке». Откуда он?

- ПМ не нужен для компании с 1м продуктом. Он нужен, когда появляется 2й и т.д. продукт. Иными словами компания должна достигнуть определенного этапа/размера прежде, чем возникнет потребность в ПМ
- ПМ координирует/взаимодействует с маркетингом, продажами и РнД с целью добиться того, чтобы продукт (его функционал, продвижение, продажи и проч.) соответствовал реально существующей рыночной проблеме.

А вот что лично мне показалось немного сомнительным в статье – это разделение маркетинга и ПМ. Конечно, если подходить с таких позиций, что маркетинг – это кружки и футболки… Но это вряд ли про B2B.

Ну и, конечно, thumbs up to: «…agile development isn’t so much a new approach to programming as it is a response to bad management…»

Пара комментариев к презентации:

1. Продуктоводство это не только разаработка боксового продукта, а заказная разработка чаще всего является одним из этапов развития продукта именно по-этому, на мой взгляд, в России очень долго данная дисциплина не была распространена – все продакты сидели у заказчика за рубежем, а тут были только центры разработки.

2. Продукт может быть и не боксовый, а для внутренних нужд компании – и там тоже присутствуют все этапы развития продукта, да они несколько отличаются от боксовых но они есть.

3. На 28 слайде этап разработки концепта выпал, где маркетинг? и точно ли продажи идут после разработки? на мой взгляд там не так все линейно.

С уважением,
Игорь.

Это один из хороших примеров для демонстрации разницы между проектом и продуктом.

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