При разработке коммерческого ПО иногда трудно найти сторонников продукта вне компании. Если у вас налажены тесные деловые отношения с какими-либо крупными корпоративными клиентами, они могут благосклонно отнестись к возможности поучаствовать в формировании требований. Сторонников продукта, приглашенных со стороны, можно заинтересовать экономически, например предложить им скидку на продукт или оплатить их работу над требованиями. Тем не менее, здесь существует некоторая опасность: вам придется научиться слушать не только ярых приверженцев, чтобы не упустить мнения других клиентов. При наличии разнородной клиентской базы сначала нужно определить основные требования, общие для всех клиентов, затем дополнительные требования, важные для отдельных клиентов, сегментов рынка или классов пользователей.
В некоторых случаях компании-разработчики коммерческого ПО полагаются на собственных профильных специалистов или внешних консультантов, подменяющих реальных пользователей, о которых может быть ничего не известно или которых трудно привлечь к работе над, проектом. Другой вариант — нанять подходящего сторонника продукта с соответствующим опытом. Одна компания, создававшая систему с центральным сервером и клиентскими приложениями для точек розничной торговли, пригласила в качестве сторонников продукта на полный рабочий день трех менеджеров магазина. Вот еще один пример: Арт, мой давний семейный доктор, оставил врачебную практику и устроился в компанию, разрабатывающую медицинское ПО, где представлял мнение и интересы врачей. Работодатель Арта был уверен: штатный сотрудник, имеющий врачебный опыт, поможет компании разрабатывать ПО, которое придется по душе другим докторам. Другая компания пригласила на работу нескольких бывших сотрудников одного из своих основных клиентов. Эти люди поделились ценным опытом в предметной области и описали политику организации-клиента.
|
|
Если сторонник продукта — бывший пользователь или увлеченно играет роль пользователя, таковым не являясь, опасайтесь, что его восприятие проблем и потребности реальных пользователей могут различаться. Некоторые предметные области меняются очень быстро, другие относительно стабильны. Медицина развивается очень быстро, тогда как многие корпоративные бизнес-процессы остаются неизменными в течение лет. Основной вопрос в том, сможет ли сторонник продукта, независимо от его опыта и настоящей должности, точно отражать потребности реальных пользователей,
Чего следует ожидать от сторонника продукта
Чтобы сотрудничество со сторонниками продукта оказалось успешным, задокументируйте, что именно, по-вашему, они должны делать. Это поможет вам полнее выразить ваши ожидания от участия в проекте конкретного человека. В табл. 6-2 перечислены некоторые обязанности сторонника продукта. Не каждый станет выполнять их все; используйте эту таблицу как отправную точку для обсуждения с каждым сторонником продукта его обязанностей.
Таблица 6-2. Возможные обязанности сторонника продукта
| Категория | · Действия |
| Планирование | · Уточнение рамок и ограничение возможностей продукта · Определение интерфейсов для работы с другими системами · Оценка влияния новой системы на бизнес-операции · Разработка путей перехода со старых приложений на новые |
| Требования | · Сбор требований от других пользователей · Разработка сценариев и вариантов использования продукта · Разрешение конфликтов между высказанными требованиями · Определение приоритетов выполнения · Определение атрибутов качества и производительности · Оценка прототипов пользовательского интерфейса |
| Проверка и подтверждение | · Изучение документов с требованиями · Определение критериев приемлемости продукта для пользователей · Разработка вариантов тестирования на основе сценариев использования · Создание наборов тестовых данных · Бета-тестирование |
| Помощь пользователям | · Написание фрагментов руководств пользователя и справочных систем · Подготовка материалов для учебных пособий · Демонстрация продукта коллегам |
| Управление изменениями | · Оценка недостатков и определение порядка их устранения · Оценка предложений об усовершенствовании системы и определение порядка их реализации · Оценка того, как предполагаемые изменения требований повлияют на пользователей и на бизнес-процессы · Участие в принятии решений о внесении изменений |
|
|