Будьте готовы встретить сопротивление, когда вы предложите привлечь к работе над проектом сторонников продукта. «Пользователи слишком заняты». «Менеджеры хотят сами принимать решения». «Они затормозят нашу работу». «Мы не можем себе этого позволить». «Я не знаю, что могу предложить в качестве сторонника продукта». Некоторые пользователи не хотят высказывать свои требования к системе, которая, как они думают, заставит их изменить методы работы или создаст угрозу увольнения. Иногда менеджеры неохотно делегируют обычным пользователям полномочия, касающиеся требований.
Отделив бизнес-требования от требований пользователей, вы смягчите эти препятствия. Будучи реальным пользователем, сторонник продукта принимает решения на уровне интересов пользователей в рамках, налагаемых бизнес-требованиями проекта. Финансовый менеджер сохраняет всю полноту власти, чтобы принимать решения, касающиеся вида продукта, его границ, графика работы и затрат. Документируя и обсуждая роль и обязанности апологета продукта, вы даете предполагаемым кандидатам на эту роль возможность уверенно отвечать на вопрос, чем же они занимаются.
Если же вы столкнетесь с сопротивлением, укажите, что недостаточное участие пользователей — общепризнанная основная причина провала проектов по разработке ПО (The Standish Group, 1995). Напомните оппонентам о проблемах предыдущих проектов, вызванных недостаточным вовлечением пользователей в работу. Каждая компания хранит свои страшилки о новых системах, которые не удовлетворили потребности пользователей, или оказались не столь полезны, или не оправдали ожидания. Вы не можете позволить себе переделывать системы или отказываться от них, если они не соответствуют необходимым требованиям, только потому, что никто не разобрался в требованиях. Привлечение сторонников продукта уменьшает такой риск.
В какие ловушки можно угодить, привлекая сторонников продукта
Модель привлечения сторонника продукта хорошо зарекомендовала себя во многих рабочих средах. Она имеет смысл, только если сторонник понимает и принимает свои обязанности, обладает полномочиями для принятия решений на уровне требований пользователей и имеет время для выполнения данной работы. Остерегайтесь следующих потенциальных проблем.
· Некоторые менеджеры изменяют решения, принятые квалифицированным и официально назначенным сторонником продукта. Возможно, у менеджера в последнюю минуту появилась новая безумная идея, он из прихоти захотел изменить направление работы или думает, что знает все потребности пользователей. Зачастую результат такого поведения — недовольные пользователи, срыв сроков сдачи проекта из-за того, что разработчики пытаются реализовать последние замечания менеджеров, а также расстроенные сторонники продукта, чувствующие, что руководство им не доверяет.
· Сторонник продукта, забыв, что он представляет других клиентов, озвучивает только собственные требования: конечно же, ему не удастся хорошо выполнять свои обязанности. Возможно, лично ему результат понравится, а вот остальным — вряд ли.
· Сторонник продукта, не имеющий четкого представления о новой системе, может уступить решение важных вопросов аналитику. Если все идеи аналитика вызывают одобрение сторонника, его трудно назвать полноценным помощником.
· Из-за нехватки времени опытный пользователь назначает сторонником продукта менее квалифицированного коллегу. Это может привести к давлению со стороны опытного пользователя, который по-прежнему желает направлять ход работы над проектом.
· Остерегайтесь пользователей, пытающихся выступить от имени класса, к которому они не относятся. В случае с системой контроля химикатов компании Contoso сторонник продукта от класса «Сотрудники склада химикатов настаивала, что может выразить требования класса пользователей «Химики». Ее было весьма трудно убедить, что это не его работа, однако аналитик не позволил ей оказывать давление. Менеджер проекта пригласил сторонника от класса «Химики», и тот проделал блестящую работу по сбору, оценке и передаче требований этих специалистов.
Кто принимает решения
Кто-то должен устранять конфликты между требованиями разных классов пользователей, сглаживать противоречия и решать возникающие вопросы относительно границ проекта. На ранних стадиях проекта необходимо определить тех, кто будет принимать решения, касающиеся требований. Если не ясно, кто за это отвечает, или уполномоченные лица отказываются брать на себя такую ответственность, обязанность принимать решения по умолчанию возлагается на разработчиков. Это — неудачный выход, поскольку у разработчиков обычно нет необходимых знаний, опыта и стратегического видения для принятия оптимальных бизнес-решений.
Не существует единственно верного ответа на вопрос о том, кто должен принимать решения по требованиям к программному проекту. Аналитики иногда прислушиваются к наиболее громогласному сотруднику или мнению начальства. Это понятный, но не лучший выбор. По возможности решения должны принимать сотрудники на низшем уровне организационной иерархии, которые непосредственно занимаются выпуском продукта и знают все о нем. Прежде чем приниматься за выработку первого решения, каждая группа должна определить соответствующее правило решения (decision rule) — согласованный метод принятия решения (Gottesdiener, 2001). Лично мне нравится совместное принятие решений или принятие решений в ходе совещания (когда собираются идеи и мнения множества заинтересованных лиц), а не принятие решений через достижение консенсуса всех заинтересованных лиц. Последний вариант - идеальный, однако вы не можете постоянно тормозить работу, ожидая, пока все заинтересованные лица согласуют каждый вопрос.
Ниже описаны некоторые конфликты, которые могут возникнуть в ходе работы над проектами, а также способы их устранения. Ведущим проект сотрудникам необходимо определить, кто будет принимать решения при возникновении подобных ситуаций, кто обладает правом голоса, если согласие не достигнуто, и кто будет в дальнейшем санкционировать решения по важнейшим вопросам.
· Если отдельные пользователи не могут прийти к согласию при определении требований, решение принимают сторонники продукта. Суть привлечения апологетов такова: они уполномочены и обязаны устранять конфликты требований, возникающие у тех, кого они представляют.
· Если требования различных классов пользователей или сегментов рынка несовместимы, сделайте выбор в пользу наиболее важного класса пользователей или сегмента, который окажет наибольшее влияние на успех продукта на рынке.
· Иногда все корпоративные клиенты одновременно требуют, чтобы архитектура проекта удовлетворяла именно их требования. В таком случае опять-таки на основе бизнес-целей проекта определите, кто из клиентов оказывает наиболее сильное влияние на успех или провал проекта,
· Иногда требования, высказываемые менеджером пользователей, не совпадают с интересами реальных пользователей. И хотя требования последних должны соответствовать бизнес-требованиям, менеджеры, которые не входят в конкретный класс пользователей, обязаны прислушаться к стороннику продукта, выражающему мнение соответствующего класса.
· Если представление разработчиков о создаваемом продукте не совпадает с пожеланиями клиентов, последнее слово за клиентами.
| Ловушка Не оправдывайте любые запросы клиента только потому, что «клиент всегда прав». Клиент прав не всегда. Однако у него есть своя точка зрения, и команда разработчиков должна понимать и уважать ее. |
· Аналогичная ситуация возникает, если требования маркетологов или менеджеров по продукту конфликтуют с представлением разработчиков о продукте. Мнение маркетологов, как представителей клиента, более весомо. Однако я знаю случаи, когда они потакали клиенту в его любых желаниях, как бы невыполнимы и дороги те ни были. Я также видел и обратные примеры, когда маркетологи предоставляли так мало информации, что разработчикам приходилось самим определять архитектуру продукта и формулировать требования.
Переговоры о требованиях не всегда проходят так, как они должны проходить по мнению аналитиков. Клиент может отвергать все предложения разумных альтернатив и другие точки зрения. Команде следует определить, кто будет принимать решения по требованиям к проекту, еще до начала подобных столкновений. В противном случае нерешительность и пересмотр уже принятых решений приведут к тому, что работа над проектом заглохнет в бесконечных спорах.
| Что теперь? Сравните схему на рис. 6-1 с тем способом, посредством которого вы узнаете мнение клиентов. Возникают ли у вас проблемы с распространением информации? Определите кратчайшие и наиболее подходящие пути распространения информации, которые пригодятся для сбора требований в будущем. Определите для своего проекта различные классы пользователей. Какие них привилегированные, а какие (если таковые имеются) — нет? Кто бы мог стать хорошим сторонником продукта для каждого из важных классов пользователей? Используя табл. 6-2 в качестве отправной точки, определите обязанности сторонника продукта. Обсудите конкретные пункты с каждым предполагаемым сторонником продукта и его менеджером. Определите, кто должен принимать решения по вопросам, связанным с требованиями к проекту. Насколько эффективен процесс принятия решений, используемый в настоящее время? Где он дает сбой? Правильно ли выбраны лица, принимающие решения? Если нет, кто должен принимать решения? Предложите лицам, принимающим решения, последовательность действий для достижения согласия по вопросам требований |