Software Product Management Russia

Концепция – один из важнейших документов при создании программных продуктов. 26 ноября Векленко Ирина и Сурова Ирина проводят семинар на тему «Разработка концепции ПО»:

26 Ноя	Разработка Концепции ПО CustIS Чт, 26 Ноября 2009 в 19:00

Дочитал одну из книг, которые заказывал летом в Amazon, - Expert Product Management, написанную руководителем консалтинговой компании 280group Brian’ом Lawley. В остальных пока прочитал только самое интересное. Обзоры будут позднее.

Информация о книге:

На Amazon.com

На сайте 280group

На Google Books

Содержание:

Глава 1. Введение

Глава 2. Roadmap продуктов

Глава 3. Проведение программ Beta-тестирования

Глава4. Запуск продукта

Глава 5. Проведение Review-программ

Что понравилось

Дано очень понятное и «с картинками» описание того, какие бывают Roadmap и какой тип Roadmap для каких случаев стоит применять. В обзорную версию на Google Books влезла значительная часть главы, можно почитать. Картинки с типами Roadmap можно посмотреть в разделе «продукты» на сайте 280 group (они продают весь набор шаблонов за $99). Эта классификация Roadmap, похоже, явлется гордостью компании и даже изображена на обложке книги. Также просто и понятно описаны процессы Beta-тестироввания, запуска продуктов и проведения Review-программ.

Итого

Это не учебник по управлению программными продуктами. Это лишь брошюра (92 стр.) с описанием опыта автора в указанных в содержании направлениях. Главной ценность книги является классификация Roadmap вместе с шаблонами и описанием. В целом – полезное чтение.

Перевод статьи из блога http://onproductmanagement.net (Saeed Khan).

Ссылка на статью:

http://onproductmanagement.net/2008/10/28/agilescrum-and-product-roadmaps/

——перевод——↓

При обсуждении Agile / Scrum часто возникает вопрос о создании и поддержке Roadmap в Agile среде. Замешательство возникает из-за того, что Scrum основан на коротких циклах разработки и постоянной приоритизации и реприоритизации функциональности в Product Backlog.

Итак, есть ли здесь противоречие, которое помешает созданию и поддержке Product Roadmap в Agile среде?

Ответ – абсолютно нет. Вкратце: Scrum – это методология разработки, а Roadmap – это инструмент бизнес-планирования и общения. Эти две вещи не зависимы друг от друга, и внедрение Scrum должно оказывать слабое влияние на поддержку Roadmap.

Не удовлетворены? Тогда предоставлю вам более развернутый ответ.

Прежде всего, определимся чем НЕ является Roadmap.

Это НЕ на 100% гарантированное и непоколебимое описание того, что мы безусловно будем делать в ближайших релизах нашего продукта.

Нет, Roadmap этим не является. Даже несмотря на то, что многие продавцы хотят, чтобы так было.

Кстати (небольшое отступление), есть небольшой трюк, позволяющий справиться с продавцами, которые хотят абсолютно фиксированную, определенную Roadmap на будущее.

Скажите им, что менеджмент продукта сделает такую Roadmap, когда команда продавцов подготовит абсолютно фиксированный и определенный объем продаж на 4 квартала. Посмотрите на их реакцию. Я сомневаюсь, что будут желающие.

Итак, что такое Product Roadmap?

Roadmap – это планируемое будущее, изложенное в общих чертах, то есть в виде планируемых релизов или перечислений высокоуровневых функций, примерно связанных с определенными временными промежутками (обычно по плановому календарю или финансовым кварталам) обычно с глубиной в 2-3 значительных релиза.

Для стартапов или компаний, работающих на быстро меняющихся или растущих рынках, эти 2-3 релиза могут покрывать только ближайшие 12 месяцев. Для более зрелых компаний, работающих на менее динамичных рынках, эти релизы могут покрывать несколько лет.

Я выделил слово «планируемый» выше. Планы – это просто планы. Это только наши представления о будущем, основанные на том, что мы знаем и во что верим сегодня. Это не обязательства. Большинство презентаций Roadmap, которые я видел, и практически все презентации, которые делали публичные компании, начинались с оговорки о том, что компания снимает с себя всякие обязательства относительно того, что указано в Roadmap.

И люди, слушающие эту презентацию Roadmap, принимали это как должное. Они понимают, что будущее неопределенно. Что они хотят услышать, так это заявление о намерениях, которые достижимы и заслуживают доверия, и которые могут помочь спланировать их собственное будущее.

Заметьте, что ничего из этого никак не связано с методологией разработки, которая используется для потенциальной реализации этой функциональности. И если кто-то спросит вас об этом, хороший ответ может выглядеть следующим образом:

Наши команды разработки используют гибридный подход к разработке, который позволят использовать лучшее из существующих Agile методологий, соединенное с наиболее предсказуемыми и устойчивыми элементами водопадной методологии. Это дает нам гибкость, которая позволяет нам адаптироваться к изменяющимся условиям рынка и потребностям пользователей, а также устойчивый фундамент в части циклов разработки, что позволяет нам создавать высококачественные релизы год от года.

Если нет никаких других обстоятельств, люди будут кивать головами и никогда больше не спросят о вашей методологии разработки.

Наконец, большинство Product Roadmap настолько лишены полезной информации, что они представляют собой просто перечень пунктов или список кодовых имен релизов на одном слайде. Это дает большое пространство для маневра презентатору (топ-менеджеру, менеджеру продукта, маркетологу продукта или кому-либо другому) для того, чтобы нарисовать светлое будущее, но ни к чему не быть обязанным.

Вот несколько РЕАЛЬНЫХ Roadmap, которые я нашел в Интернете. Какая из этих компаний использует Agile в разработке? Вы можете сказать? Это имеет значение?

Перевод статьи из блога tynerblain.com.

Ссылка на статью:

http://tynerblain.com/blog/2006/05/11/requirements-documents-one-mans-trash/

——перевод——↓

Существует несколько способов документирования требований при разработке программного обеспечения: MRD, PRD, SRS, FRS и документы проектирования системы. Каждый из участников имеет представление о том, что описывается в каждом из документов, но каждый из участников имеет свое собственное представление о том, на какие вопросы отвечает каждый из этих документов.

Процесс разработки программного обеспечения

Разработка программного обеспечения состоит из трех фаз:

• Определить, что делать;
• Определить, как делать;
• Сделать.

Мы можем представить это в виде трех вопросов:

• Зачем мы делаем это?
• Что мы хотим сделать?
• Как мы это сделаем?

В зависимости от роли в команде, мы получаем различные ответы на эти вопросы.  Следующая диаграмма демонстрирует весь процесс разработки:

Процесс разработки программного обеспечения в данном представлении разбивается на пять категорий:

1. Рынок. Определение проблем и возможностей, которые должны быть решены. Рассматривайте их как требования рынка;
2. Требования. MRD и PRD. Описание того, что должно быть сделано для удовлетворения потребностей рынка безотносительно к способу реализации;
3. Спецификация. SRS или FRS. Структурированное описание технологических решений, которые позволят реализовать требования;
4. Проект системы. Стратегия реализации спецификации;
5. Продукт. Код и тесты. Реализация.

Представления команды

Существует четыре различных представления процесса для ответа на три указанных выше процесса («Зачем», «Что» и «Как»). Мы можем определить роли, которые несут знамя каждого из взглядов.

• Менеджер продукта. Мыслитель, который находится в поисках перспектив создания хорошего программного обеспечения;
• Ведущий разработчик. Изобретатель, который находится в поиске лучших технических решений поставленных задач;
• Разработчик. Исполнитель, который старается сделать наиболее эффективное решение проекта системы;
• Тестировщик. Контролер, задачей которого является обеспечение того, что мы делаем правильную вещь и делаем это правильно.

У каждой из этих ролей есть свой взгляд на процесс разработки, и они по-разному отвечают на три вопроса «Зачем», «Что» и «Как». И каждая из ролей выбирает различные этапы процесса разработки для ответа на эти вопросы. Следующая диаграмма показывает связь пяти категорий из предыдущей диаграммы с четырьмя ролями.

Менеджер продукта

• Зачем? Рынок говорит нам, зачем мы должны делать что-либо. Мы ищем возможности и оцениваем их;
• Что? Наши требования четко отражают проблемы, которые мы хотим решить и что необходимо для их решения;
• Как? Спецификация – практическое описание того, что должно быть сделано.

Ведущий разработчик

• Зачем? У нас есть требования, которые определяют рамки мероприятия;
• Что? Спецификация говорит нам, что должно быть сделано;
• Как? Проект системы показывает нам подход к решению задачи.

Разработчик

• Зачем? Спецификация четко описывает наши обязанности;
• Что? Проект системы говорит нам, как решить поставленные задачи лучшим образом;
• Как? Мы ответственны за продукт, который мы создаем.

Тестировщик

• Зачем? Требования должны быть реализованы;
• Что? Проект системы должен быть надежным. Доверяй, но проверяй;
• Как? С помощью тестов мы гарантируем качество того, что мы делаем.

Заключение

У людей в команде различные обязанности. И эти люди рассматривают разные этапы процесса разработки как «источник вдохновения». Также они ответственны за различный результат.

Что такое OpenUP

OpenUP – облегченная версия RUP, основанная на идеологии гибких методологий разработки ПО. OpenUP разрабатывается в рамках интересного проекта Eclipse Process Framework. См. сайт проекта и wiki, в которой представлены все проекты.

Для знакомства с OpenUP почитайте статью Пера Кролла на русском языке, там все хорошо описано.

Полное описание OpenUP см. в wiki здесь.

Существует и русскоязычная версия, но переводится вариант OpenUP для маленьких команд - OpenUP/Basic (совсем облегченный процесс). Перевод осуществляется на принципах wiki, так что каждый может внести свою лепту. Я участвую.

Шаблоны Vision в RUP и OpenUP

С точки зрения управления продуктами нас в этих методологиях интересует, прежде всего, такой документ как Vision. См.:

• Шаблон vision в RUP
• Шаблон vision в OpenUP

Сравните 14 страниц первого шаблона и одну страницу второго. Действительно облегченная версия

Перевод заметки по созданию Agile roadmap от консалтинговой компании Enthiosys.

Оригинал здесь:

http://www.enthiosys.com/problems-we-solve/agile-roadmaps/

Текст в значительной степени рекламный, но это не мешает ему быть интересным.

——перевод——↓

Roadmap продукта – критический элемент любой продуктовой стратегии и основной инструмент каждого менеджера продуктов. Roadmap ликвидирует разрыв между долгосрочными стратегическими планами и планированием релизов и итераций. Содержательные, согласованные, актуальные roadmap удерживают продуктовые команды от блужданий и позволяют достичь целей компании гораздо быстрее.

Agile roadmap - фундамент гибкости бизнеса. Они предоставляют основу для принятия решения о том, когда планы должны быть изменены, как повлияют изменения на связанные продукты / релизы / цели и служат инструментом взаимодействия при написании планов.

Осмысление roadmap

Менеджеры продуктов не делают успешных продуктов, реагируя на каждый выпад конкурентов, жалобу пользователей или предложение маркетологов / разработчиков. После выявления фундаментальных потребностей потребителей, менеджеры продуктов должны определить коммерческую сторону (рынок, продажи, маркетинговые исследования и т.д.) и техническую сторону (разработка, поддержка и т.д.) мероприятия и отразить в одном документе. Под этим мы понимаем совместное и глубокое понимание сегментов рынка, функций и преимуществ продукта, своевременность вывода на рынок функций в различные сегменты рынка, маркетинговые мероприятия и архитектуру, которая позволят развивать продукт в соответствии с планом. Лучшие roadmap создаются кросс-функциональными командами, которые провели хотя бы один день в непрерывном взаимодействии.

Мы называем этот документ agile roadmap продукта. В нем рассматриваются четыре ключевые условия успешности программного продукта в его коммерческой жизни:

• Рынок: мы помогаем создать карту рынка, на которой отражены ваши целевые рынки, и определяем порядок, в котором вы должны создавать предложения для них (набор продуктов и услуг, которые предоставляют для них ценность).
• Функции и преимущества: здесь должны быть отражены ключевые функции продукта, которые вам необходимы для каждого из сегментов рынка и их преимущества. Каждая функция может иметь ценность более, чем для одного рыночного сегмента. Однако они могут предоставлять не те же самые преимущества. Разработчики должны понимать замысел и сущность будущих функций и преимуществ, чтобы создать такую архитектуру, которая поддерживала бы их.
• События и ритмы: события – это то, что происходит в бизнесе ваших клиентов, что вы можете и должны учитывать. Например, ретейлеры не могут использовать новые релизы в течение сезона распродаж. Ритмы – это то, что клиенты, разработчики, продавцы и другие участиники хотелы бы видеть в релизах. Например, клиенты не могут быстро принимать релизы, но могут быть недовольны, если релизы происходят слишком редко. А продавцам необходимо много времени для подготовки к новому релизу.
• Архитектура: у вашего решения должны быть такая архитектура, которая позволяла бы разрабатывать необходимые функции для каждого из сегментов рынка вовремя. Мы помогаем определить существенные функции для каждого из сегментов рынка и обеспечиваем, чтобы ваша архитектура поддерживала их.

Хорошие roadmap предоставляют также основу для сценарного планирования и создания «roadmap of roadmaps».

Модель взаимодействия и результаты

Создание roadmap – процесс, требующей серьезного взаимодействия. В типовой процесс вовлечены основные заинтересованные лица (менеджеры продуктов, разработчики и архитекторы, маркетологи, консультанты) для создания начальное версии roadmap продукта, а в дальнейшем происходят ежеквартальные собрания для пересмотра и обновления roadmap. Многие клиенты Enthiosys расширили этот процесс до создания «roadmap of roadmaps» для управления портфелем продуктов.

Мы определили пятишаговый процесс для каждого совещания по roadmap:

1. Уточните ваши бизнес- и продуктовые цели и задачи, бизнес-планы, существующие roadmap и другую документацию;
2. Инициируйте создание черновой версии roadmap (обычно начинает одна продуктовая команда);
3. Распределите задачи и установите сроки по сбору информации;
4. Инициируйте разработку финальной версии roadmap;
5. Определите план публикации, корректировки и обсуждения roadmap.

<…> пользуйтесь нашими услугами <…>

Roadmap – долгосрочный план выпуска продукта. Этот документ – один из основных в управлении продуктами. Roadmap связывает долгосрочное планирование продукта и краткосрочный план релизов / итераций.

Как написать roadmap? Существует некоторое количество готовых шаблонов roadmap.

Для общего представления о том, что такое roadmap, привожу несколько шаблонов из английской Википедии:

Многие компании разрабатывают свои шаблоны. Некоторые из них распространяются бесплатно, некоторые – за деньги.

Вот бесплатные шаблоны известной консалтинговой компании Enthiosys:

• Простой в Excel
• Сложный в Excel
• Простой в Visio
• Сложный в Visio

А вот здесь http://www.280group.com/productroadmaptemplates.htm можно посмотреть целый пакет материалов для создания roadmap от также достаточно известной консалтинговой компании 280group. Этот пакет распространяется уже за деньги (99$).

Бесплатные материалы по roadmaps от 280group:

Feature Prioritization Matrix

Перевод статьи из блога The Productologist.

Ссылка на статью: http://www.theproductologist.com/index.php/2009/06/22/mrds-too-much-of-a-bad-thing/

Перевести эту статью меня подтолкнул вот этот диалог: http://agilepod.ru/?p=14

MRD – Market(ing) Requirments Document (Требования рынка)

PRD – Product requirements document (Требования к продукту)

TDD – Technical Design Document

——перевод——↓

Недавно я принимал решение о переходе с традиционной водопадной модели к Agile. Раньше я опасался Agile, особенно в части корпоративных продуктов, но когда я достиг лучшего понимания принципов Agile, он начал мне нравится больше. До сих пор сохраняются предостережения относительно использования Agile методов, и успех Agile процесса очень сильно зависит от того, кто управляет процессом, но я начинаю понимать, почему разработка по Agile столь привлекательна.

С точки зрения менеджера продукта, один из наиболее привлекательных аспектов Agile – то, как работает документирование требований. В течение многих лет я тратил значительное количество времени на создание документов с требованиями (в основном MRD, но также PRD и TDD). Причина этого в том, что MRD предназначен для широкой аудитории. Тот же MRD, который используется разработчиками и тестировщиками для написания функциональных требований, должен быть прочитан, понят и усвоен толпами Продавцов, Специалистов технической поддержки, консультантами и маркетологами.

 Это означает, что MRD должен быть битком набит информацией по некоторым или всем из следующих тем:

• бизнес-задача;
• модель монетизации (Revenue Model);
• анализ конкурентов;
• маркетинговый анализ;
• описание функций;
• проектирование функций (Feature Design);
• потребности в персонале;
• и прочую кухню (and the kitchen sink).

Вся эта информация приводит к большому и громоздкому документу, как для написания, так и для восприятия. Было много случаев, когда я должен был бегать за товарищами, которые настояли на получении копии MRD (и которые обещали сделать фидбек), только для того, чтобы узнать, что они даже его не прочитали за 3 недели, с тех пор, как я послал им документ (и множество напоминаний).

Уфф. Куча работы и мало или никакой выгоды.

Что мне нравится в разработке по Agile, это то что все «незначительные» (fluff) вещи выведены за рамки процесса работы с требованиями. Они по прежнему остаются в процессе релиза, но в другом месте, например в диалогах с директором, или на презентации менеджменту, объединенной еженедельной встрече продавцов и специалистов техподдержки или в беседе с вашим менеджером. Это люди, которые заботятся о «незначительных» частях документации с требованиями.

Когда вы работаете с командой разработчиков, в большинстве своем их не интересует модель монетизации, анализ конкурентов и другие вещи, которые не помогают им непосредственно писать код. Но нельзя сказать, что эти вещи их совсем не интересуют. Выручка должна быть интересна для ВСЕХ работников, но она лишь придает значимости их работе.

Итак, вместо 30-страничных MRD, я люблю 5-10-ти страничные спецификации релиза. Я фокусируюсь на том, что будет в новом релизе и что он должен делать. Я обычно добавляю еще немного о том, какую проблему он решает или как он будет полезен, чтобы команда разработчиков могла использовать эту информацию для лучшего понимания требований, но не более того.

Чтобы быть честным, скажу, что короткий и приятный документ не всегда работает так хорошо, как мне хотелось бы. Также остается необходимым проводить долгие дискуссии с разработчиками, чтобы уточнить отдельные вопросы, но мне это необходимо было делать и с большим MRD тоже, так почему же не сэкономить время и не писать его, а сфокусироваться на создании программного обеспечения и передачи его тестировщикам и пользователям?

Меньше работы для менеджера продукта, что означает больше работы «в поле», проведение времени с клиентами и партнерами и выслушивание товарищей, которые объясняют, как я могу помочь им с моим продуктом. Все в выигрыше!

Перевод статьи из блога carlknibbs.net.

Ссылка на статью: http://www.carlknibbs.net/blog/2009/3/4/communicating-your-product-vision.html

——перевод——↓

Невнятица с vision вашего продукта является самым большим препятствием для быстрого и успешного развития продукта.

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

Существует много техник, которые могут помочь вам сделать это. Marty Cagan ссылается на ряд техник быстрого прототипирования, позволяющих получить быстрое и приблизительное представление vision продукта, который вы создаете.

Это очень простая идея, но через несколько высокоуровневых представлений она дает вам четкую картину вашего vision продукта.

Почему создание хотя бы высокоуровневого визуального представления столь важно?

• люди в основном не очень впечатляются презентациями в Power Point и таблицами Excel. Несколько высокоуровневых визуальных представлений имеют больше шансов привлечь внимание и привести к заключению сделки;
• визуальные представления описывают функциональность в том виде, в котором это очень сложно сделать в спецификации требований (я все меньше и меньше верю в длинные списки требований, их кто-нибудь вообще читает?);
• вы должны предположить, что все, кому вы представляете ваш vision, не заинтересованы, запутаны или невежественны. Поэтому, если они не слушают, визуальное представление – хоть что-то, что сложно проигнорировать;
• визуальные представления действительно помогают делать оценки. Как вы можете оценивать, если не понимаете vision? Точное визуальное представление помогает людям понимать vision и, тем самым, анализировать его;
• что самое важное, чем быстрее вы визуализируете vision продукта, тем быстрее вы поймете, хорошая эта идея или нет!

* vision переводить не стал.  Product vision дословно – видение продукта.