При разработке каждого типа проекта, включая корпоративные информационные системы, коммерческие приложения, комплексные решения, интегрированные системы, встроенные системы, интернет приложения и ПО, конструируемые на заказ, необходимо привлечь с работе представителей пользователей, выражающих мнение большей части клиентов. Позаботьтесь, чтобы они участвовали во всех этапах, а не только в одном из начальных — формулировании требований. Ну и, конечно, должны быть представлены все классы пользователей.
Проще всего наладить контакт с пользователями, когда вы создаете внутрикорпоративные приложения. Если вы разрабатываете коммерческое ПО, можно расспросить тех, кто занимается бета-тестированием продукта или «обкаткой» сайта, чтобы выяснить у них требования на начальных этапах работы (подробнее — в разделе «Сторонники продукта, приглашенные со стороны» далее в этой главе). Иногда полезно создать фокус-группы из пользователей для анализа ваших продуктов или ПО конкурирующих компаний.
Некая компания предложила участникам фокус-группы протестировать различные цифровые фотоаппараты и компьютеры. Как показали результаты, ПО фотоаппаратов этой компании слишком долго выполняло самую обычную операцию из-за того, что в архитектуру были заложены наименее вероятные варианты использования. После внесения изменений в следующую версию фотоаппарата количество жалоб клиентов на малую скорость работы уменьшилось.
Убедитесь, что в фокус-группе представлены все классы пользователей, потребности которых должны определять возможности продукта, а также люди с различным опытом: и эксперты, и новички. Если в фокус-группу входят только приверженцы последних достижений и любители помечтать, вас захлестнет вал сложных и технически трудных требований, которые могут оказаться неинтересными большей части вашей целевой аудитории.
На рис. 6-2 показаны некоторые типичные пути распространения информации то есть, как голос пользователя достигает ушей разработчика. Как отмечалось в одном исследовании, в наиболее успешных проектах всегда больше каналов общения вообще и тех, что напрямую связывают разработчика и клиента, чем в менее успешных проектах (Keil и Carmel, 1995). Лучше всего, когда разработчики имеют возможность сами пообщаться с нужными пользователями; то есть выполняют роль аналитиков. Как и в детской игре «Испорченный телефон», дополнительные промежуточные звенья увеличивают вероятность непонимания. Например, требования, озвученные менеджером конечных пользователей, скорее всего, не совсем точно передают реальные потребности этих пользователей.
Тем не менее некоторые из этих промежуточных звеньев полезны, например, когда опытный аналитик требований работает с пользователями или другими участниками, собирая, оценивая, уточняя и организуя их информацию. Оцените возможные риски, используя в качестве представителей реального мнения клиента персонал отдела маркетинга, менеджеров продукта, профильных специалистов или каких-либо других лица. Несмотря на препятствия и затраты, связанные с поиском и выбором представителей пользователей, ваш продукт и клиенты пострадают, если вы пренебрежете общением с людьми, способными предоставить наиболее точную информацию.
Рис. 6-2 Некоторые возможные пути распространения информации от пользователей к разработчикам
Сторонники продукта
Много лет назад я работал в небольшой группе разработки программных продуктов, которая обеспечивала поддержку научных исследований в крупной корпорации. Во всех наших проектах принимали участие несколько наиболее активных представителей пользователей, которые помогали формулировать требования. Мы называли их сторонникамипродукта (product champion) (или приверженцами проекта, хотя этот термин относится скорее к тем, кто управляет финансовой стороной проекта) (Wiegers, 1996a). Привлечение искренне заинтересованных в продукте пользователей — это эффективный способ структурировать партнерство клиентов и разработчиков.
| Ловушка Опасайтесь менеджеров и разработчиков, считающих, что они и без общения с пользователями уже все знают о потребностях последних. |
Каждый сторонник продукта — это основной посредник между членами отдельного класса пользователей и аналитиком требований. В идеале сторонники должны быть реальными пользователями, а не псевдопользователями, как, например спонсоры, покупатели, специалисты по маркетингу, менеджеры или разработчики ПО, которые представляют себя на месте пользователя. Их задача — выяснить потребности остальных членов класса пользователей, который они представляют, и согласовать их. Таким образом, разработка требований — это общее дело аналитика и выбранных клиентов; хотя документацию составляет все-таки аналитик.
Лучшие из сторонников продукта имеют четкое представление о новой системе и в полной мере увлечены ее, так как понимают, какие преимущества она даст им и их коллегам. Сторонник продукта должен уметь отлично общаться и пользоваться авторитетом в компании. Кроме того, необходимо, чтобы он разбирался в предметной области и рабочей среде приложения. Такие сотрудники весьма заняты своей основной работой, поэтому вам необходимо продумать очень убедительные доводы, дабы обосновать крайнюю важность именно этих людей для успеха проекта. Моя команда и я убедились, что хорошие сторонники сделали очень много для успеха наших проектов, и мы с удовольствием выражаем им нашу признательность за их вклад.
Мы рады отметить и еще одно преимущество от сотрудничества со сторонниками продукта. В нескольких наших проектах участвовали отличные ребята, которые от нашего лица общались с коллегами и клиентами, когда те возмущались тем, что проект до сих пор не завершен. «Не волнуйтесь, — говорили они коллегам и начальству. — Мы понимаем и принимаем то, как команда разработчиков подходит к делу. Время, которое мы потратим сейчас на работу над требованиями, поможет нам получить именно ту систему, которую мы хотим, и сэкономит время в дальнейшем. Не беспокойтесь». Такое сотрудничество помогает устранить напряжение, зачастую возникающие между клиентами и командой разработчиков.
Наилучшие результаты отмечены, если каждый сторонник продукта обладает всеми полномочиями для принятия необходимых решений от имени класса пользователей, который он представляет. Если решения сторонника продукта регулярно отвергаются менеджерами или группой разработчиков, он попусту тратит свое время и добрую волю. Тем не менее горячим сторонникам продукта следует помнить, что они — не единственные клиенты. Проблемы возникают, если тот, кто играет такую важную роль посредника, общается с коллегами не должным образом и выражает только собственные пожелания и идеи.