Software Product Management Russia

Перевод статьи из блога 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. Продукт. Код и тесты. Реализация.

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

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

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

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

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

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

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

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

Разработчик

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

Тестировщик

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

Заключение

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

Перевод статьи из блога Ask Good Product Manager.
Ссылка на статью: http://ask.goodproductmanager.com/2008/08/10/how-can-it-be-involved-in-product-management/

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

Вопрос: как разделять владение продуктом (product ownership) с компанией-разработчиком?

Я управляю продуктами портала по поиску работы и мой вопрос связан с владением продуктом.

Я нахожусь в компании, занимающейся управлением продуктами, и у нас есть компания-разработчик, которая ответственна за разработку в том направлении, которое было установлено менеджером продуктов. Сотрудники компании-разработчика по большей части молодые и креативные, и мы, конечно, хотим, чтобы они содействовали развитию продукта и проявляли инициативу для улучшения продукта.

Но как нам определить владение продуктом между продуктовой командой и командой разработчиков? Какие существуют лучшие практики для случая, когда менеджеры продукта и руководители разработки подчиняются разным руководителям?

Ответ Saeed Khan (On Product Management): Ключевой момент здесь – как наилучшим образом использовать креатвные таланты команды разработчиков в процессе разработки.

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

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

Я предполагаю, что креативные идеи крутятся вокруг пользовательского интерфейса и дизайна? Или они затрагивают средний уровень или back end портала?

В одной компании, в которой мне приходилось работать, у нас стояла главная задача – улучшать производительность серверной части нашего продукта на 25% каждый старший (major) релиз. Решение этой задачи включало, как правило, архитектурные  или внутренние изменения. Как именно это достигалось, не было определено менеджментом продукта, но мы поставили задачу архитекторам давать предложения по улучшению производительности и обсуждали совместно с архитекторами, что наиболее важно для конкретного релиза.

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

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

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

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