MRD: много ненужного
Перевод статьи из блога 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 тоже, так почему же не сэкономить время и не писать его, а сфокусироваться на создании программного обеспечения и передачи его тестировщикам и пользователям?
Меньше работы для менеджера продукта, что означает больше работы “в поле”, проведение времени с клиентами и партнерами и выслушивание товарищей, которые объясняют, как я могу помочь им с моим продуктом. Все в выигрыше!
