Уже почти год назад я писал о ролях в разработке программного обеспечения. А именно о том, в чем состоят обязанности людей, играющих определённые роли и на чьей стороне (заказчика или разработчика) они играют.
Однако, необходимо помнить, что между ролями (на самом деле конечно между людьми, играющими эти роли) постоянно происходит взаимодействие. И от того насколько оно гладкое, налаженное, может зависеть успех проекта. Конечно все вышеизложенное сильно зависит от размеров компании и проекта. В маленьких компаниях больше неформального, дружеского взаимодействия, не требующего иногда никаких формальных документов (ну или требующее их очень малое количество). В больших же коллективах без "бумажки" иногда не обойтись никак. Связано это с тем, что чем больше коллектив, принимающий участие в проекте, тем больше времени тратится на обмен информацией между сотрудниками.
Хочу только сказать, что все о чем я здесь говорю - никакой не стандарт или правило. Каждая компания на самом деле сама определяет роли и необходимость наличия документов и что в этих документах должно быть написано. Я рассказываю о своём опыте и своём понимании этих процессов.
Я хочу сегодня рассказать про один из аспектов взаимодействия Product Manager (в терминах моей старой статьи) с разработчиками, заказчиками и высшим руководством.
Замечу, что под разработчиками здесь я понимаю не только программистов, но также и тестировщиков и технических писателей и работников технической поддержки и специалистов по внедрению. Соответственно "команда разработчиков" включает в себя (при необходимости конечно) всех этих людей.
Напомню, что Product Manager:
Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек,
представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:
- Исследование рынка
- Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
- Исследование конкурентов (иногда этим занимаются специально выделенные люди)
- Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
- Выработка списка "features" продукта
- Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
- Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
- План развития продукта (RoadMap)
- Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
- Взаимодействие с высшим руководством компании, если таковое необходимо
- Взаимодействие с отделом продаж и совместная выработка стратегии продаж
Взаимодействие с разработчиками происходит как формальное, так и неформальное. Основным формальным документом, который является результатом работы Product Manager и определяет продукт для разработчиков и является MRD - Marketing Requirements Document.
MRD описывает разрабатываемый продукт или новую версию продукта, с точки зрения заказчика. Заказчик - это будущий потребитель продукта и это может быть как человек, который купит коробку с программой в магазине, так и другой отдел той же компании. MRD нужен, чтобы разработчики получили представление о продукте, необходимой функциональности и могли начать разработку (здесь под разработкой понимается весь комплекс работ - дизайн, архитектура, кодирование, тестирование и все остальное, что разработчики считают нужным туда включить).
Ну то есть MRD - это документ при помощи которого Product Manager (человек представляющий заказчика и, в теории, знающий что тому нужно) пытается донести нужды заказчика до разработчиков.
Теперь попробуем описать какие разделы должен включать MRD. Для удобства я попытаюсь сразу после описания соответствующего раздела давать пример.
MRD представляет из себя документ, в общем, свободного формата. Основная аудитория MRD - это:
- Разработчики
Разработчикам MRD необходим для понимая того что же именно нужно написать.
- Высшее руководство
Ну, во-первых, начальство конечно должно быть в курсе что собственно делается ;-) Во-вторых, MRD - это документ, являющийся обоснованием для получения ресурсов (материальных и людских), если их не хватает.
- Заказчик
Заказчику MRD предоставляется в составе более широкого пакета документов, для утверждения. В случае возникновения споров по поводу наличия или отсутствия той или иной функциональности MRD является документом, который помогает их разрешению.
Помня о нашей аудитории и целях создания документа, опишем его составные части:
MRD для нового продукта "Феликс"- Цель создания продукта или выпуска очередной версии.
В данном разделе описывается проблема, существующая у потенциальных или реальных заказчиков и объясняется, как именно продукт или новая версия продукта эту проблему устранит. Это очень важный раздел, он должен сравнительно кратко объяснить что же именно предстоит сделать.
Пример: Не все люди достаточно хорошо могут считать "в уме". Особенно плохо это получается у людей, если числа являются не целыми и достаточно большими. Во многих магазинах существует проблема ошибок кассиров, которые, высчитывая цену покупок "на бумажке", часто ошибаются. Это приводит к недовольству покупателей (если кассир ошибается не в их пользу) или же к потерям самого магазина. Недовольные покупатели могут перестать приходить в этот магазин и, таким образом, также снизить доходы. Проблема очень велика и статистика показывает, что расходы магазинов связанные с потерями при арифметических подсчётах, увеличиваются с каждым годом:
| Год | Потери |
| 2004 | $200млн. |
| 2005 | $300млн. |
| 2006 | $400млн. |
Продукт "Феликс" предназначен для того, чтобы помочь магазинам справиться с описанной проблемой. Он будет представлять из себя небольшую программу, которая может быть запущена на мобильном телефоне кассира и поможет ему подсчитывать суммы, которые раньше ему приходилось считать на бумаге.
- Описание того, какой результат должен быть достигнут и в какие сроки.
Здесь необходимо описать что именно должно получиться (web-сервис, java-приложение, некоторый документ, который описывает что-то, некоторое устройство, обладающее определёнными характеристиками). Также в этом разделе обычно указывается желаемый (с точки зрения заказчика) срок получения продукта. Хочу специально отметить, что это не срок, за который продукт будет сделан. Это всего лишь желаемый срок. MRD проходит в своём развитии много итераций и реальные сроки исполнения в нем обычно не указываются. Заказчику сроки исполнения обычно предоставляются в других документах. Тем не менее указать желаемое время (например некоторое важное с маркетинговой точки зрения событие) здесь вполне возможно.
Пример: Поскольку по результатам исследований выяснилось, что большинство кассиров в магазинах пользуется мобильными смартфонами с установленной на них операционной системой компании Microsoft - Windows Mobile 6.0, то Феликс должен представлять собой программу работающую под управлением этой и последующих версий ОС Windows Mobile 6.0. В сентябре следующего года ожидается всемирная выставка Кассир-2008 в Лас-Вегасе и первую версию программы очень желательно иметь к этому времени, для того чтобы мы могли разрекламировать её во время выставки.
- Описание функциональных возможностей продукта.
Данный раздел собственно и составляет самую большую часть MRD - в нем описывается какие именно функции должен выполнять продукт. В зависимости от самих функций, квалификации Product Manager и принятых в компании правил, раздел может быть более или менее подробным. В частности, подробные сценарии использования (use cases) каждой из функциональных возможностей могут присутствовать, а могут и нет. Также MRD может включать или не включать в себя внешний вид пользовательского интерфейса. В любом случае, сценарии использования и внешний вид пользовательского интерфейса обычно появляются на той или иной стадии разработки и обычно являются дополнениями к MRD, поскольку дают более полное представление о продукте.
Описание каждой функциональной возможности обязательно должно включать в себя её приоритет - насколько важна эта возможность с точки зрения заказчика.
Приоритет важен, поскольку в какой-то момент, при разработке проекта часто появляется необходимость пожертвовать какими-то функциональными возможностями. Помочь решить какими именно и может знание важности каждой конкретной возможности для заказчика.
Пример: Феликс должен обладать следующими возможностями:
- Сложение действительных чисел, при помощи стандартных правил сложения, описанных в учебнике Г.М. Фихтенгольца
Приоритет: очень важно
- Вычитание действительных чисел, при помощи стандартных правил вычитания
Приоритет: очень важно
- Умножение действительных чисел
Приоритет: очень важно
- Деление действительных чисел
Приоритет: очень важно
- Скорость выполнения операций не должна быть больше 10 секунд на одну операцию
Приоритет: очень важно
- Программа установки, выполненная по стандартам Windows Mobile 6.0
Приоритет: очень важно
- Drag&Drop
Приоритет: очень важно
- Plug&Play
Приоритет: очень важно
- Возможность распечатывать результаты
Приоритет: очень важно - Наличие подробной документации по всем функциям программы
Приоритет: очень важно
Заметили ли вы некоторые странности в последнем примере? Что за удивительная функция Drag&Drop? А что такое Plug&Play? Какое отношение они имеют к программе "Феликс"? А может быть есть ещё какие-то странные требования? А почему собственно приоритет ВСЕХ функций поставлен как "очень важно"? Частенько Product Manager формулирует свои требования не достаточно чётко или само требование не кажется особенно осмысленным. Поэтому составление MRD часто требует нескольких итераций, так что каждая следующая делает этот документ более "внятным".
Для того чтобы уменьшить количество этих итераций, описание функциональных возможностей также иногда делят на части:
- Описание - эта часть у нас уже была
- Приоритет - эта часть также уже была
- Цель - какую задачу решает наличие данной функции. Обычно цель очевидна, а вот если она не очевидна, то может быть и сама функция не нужна.
- Откуда появилась идея - требование заказчиков, наличие такой функции у конкурентов, наличие проблем в существующей версии продукта
Такие функциональные возможности, которые предложил Product Manager для программы Феликс - Drag&Drop и Plug&Play возможно являются следствием того, что он бездумно пошёл на поводу у рекламы и просто включил в список пару "красивых" с его точки зрения фраз.
Составление MRD требует от Product Manager довольно большой работы, анализа конкурентов и ситуации на рынке, а также, иногда, понимания технической стороны вопроса.
Но, при наличии грамотно составленного MRD, взаимодействие заказчиков и разработчиков сильно улучшается и снимаются возможные проблемы, так что по крайней мере старая шутка по качели станет на один шаг короче:
blog: 
LinkedIn
Мой Круг
