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

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

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

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

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

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

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

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

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

Разработчик

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

Тестировщик

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

Заключение

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

Перевод статьи из блога 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 тоже, так почему же не сэкономить время и не писать его, а сфокусироваться на создании программного обеспечения и передачи его тестировщикам и пользователям?

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