Имея четкое представление о том, чего хотим мы сами и чего хотят наши пользователи, мы можем понять, как достичь этих стратегических целей. Стратегия превратится в возможности системы, когда вы преобразуете потребности пользователей и цели сайта в конкретные требования к контенту и функциональности веб-сайта – к тому, что он предлагает пользователям.
Определение набора возможностей
Есть вещи, которые мы делаем ради самого процесса – на пример, бегаем трусцой по утрам или разучиваем гаммы на фортепиано. Есть дела, которые мы выполняем, чтобы получить результат, – например, печем пирог с сыром или чиним автомобиль. Определение набора возможностей системы относится к обеим категориям сразу: это ценный процесс, который дает ценный результат.
Процесс ценен тем, что заставляет вас выявлять потенциальные противоречия и «шероховатости» конечного продукта на том этапе, когда сам результат существует лишь в вашей голове. Мы можем определить, за что следует взяться прямо сейчас, а что придется отложить на потом.
Результат представляет ценность, так как дает вашей команде точку отсчета для всей последующей работы над проектом и общий язык, на котором вы сможете обсуждать эту работу. Определение требований убирает из про есса разработки неоднозначность.
Однажды я работал над веб приложением, которое, казалось, навеки застряло в состоянии бета версии: почти (но не совсем) готово к передаче пользователям. Многое в нашей работе было неправильным: технология была ненадежной, мы ничего не знали о наших пользователях, а я был единственным человеком в компании, имевшим хоть какой-то опыт разработки для Всемирной паутины.
Однако ни один из этих фактов не объяснял, почему мы не можем закончить работу над продуктом. Главным камнем преткновения было наше нежелание документировать требования. В конце концов, какой смысл занудно протоколировать все и вся, если мы и так работаем в одной комнате? Да и нашему менеджеру необходимо было направить всю свою энергию на отслеживание новых технологических веяний…
Результатом был продукт, представлявший собой постоянно меняющуюся мешанину функциональных возможностей разной степени завершенности. Любая прочитанная кем-то из нас статья, любая мысль, пришедшая кому-нибудь в голову во время возни с продуктом, вдохновляла нас на обсуждение новой функциональности. Работа кипела, но без графика, без каких-либо контрольных точек – и этому не было ни конца, ни края. Если никто не знал четкого набора возможностей продукта, как можно было понять, что проект закончен?
Существуют две основных причины для документирования требований к продукту.
Причина №1: вы будете знать, что именно вы создаете
Эта идея кажется очевидной, но для команды разработчиков того веб приложения она была полной неожиданностью. Если вы точно опишете то, что собираетесь построить, каждый будет знать цели проекта – и когда они будут достигнуты, то все сразу поймут это. Конечный продукт перестанет быть смутной картиной в голове менеджера проекта и превратится в нечто осязаемое, с чем может иметь дело любой сотрудник компании – от руководителей высшего звена до рядовых инженеров.
Без документированных требований ваш проект, скорее всего, будет напоминать детскую игру в испорченный теле фон: каждый участник проекта будет судить о продукте со слов другого участника, и рано или поздно информация исказится. Либо, хуже того, какой то из важных частей проекта не будет заниматься никто, потому что каждый будет предполагать, что за нее отвечают другие.
Строго определенный набор требований позволит вам эффективнее распределять ответственность. Имея набор возможностей перед глазами, вы сможете разглядеть те связи между отдельными составляющими, которые иначе были бы неочевидными. Сопроводительная документация и спецификации могут показаться не связанными друг с другом на ранних этапах, но оформление их в виде требований к продукту ясно покажет, что их содержание сильно перекрывается и отвечать за них должна одна и та же рабочая группа.
Причина №2: вы будете знать, что вы не создаете
Многие функциональные возможности выглядят неплохо на уровне идей, однако они не обязательно согласуются со стратегическими целями проекта. Кроме того, когда проект идет полным ходом, то и дело возникают разнообразные поводы для создания новых функций. Документированные требования снабдят вас механизмом оценки идей, появляющихся при работе над проектом.
Когда вы знаете, что не будете делать, вы знаете также, что не нужно делать прямо сейчас. Сбор всех возникающих гениальных идей обретает реальную ценность, только когда вам удается учесть их в долгосрочных планах. Определив конкретный набор требований и отложив на будущее реализацию всех запросов, которые им не соответствуют, вы сможете управлять рабочим процессом осознанно и целенаправленно.
Без сознательного управления требованиями к продукту вы попадете в кошмарную «проектную лавину». Представьте себе снежный ком, который медленно скатывается с горы, а на него понемногу налипает снег – и в конце концов ком становится таким огромным, что остановить его движение просто невозможно. Точно так же каждое дополнительное требование, казалось бы, не прибавляет много работы. Но в сумме они превращают проект в снежный ком, который катится, сметая на своем пути все сроки и бюджетные планы, и в конце концов терпит неминуемое крушение.
Функциональность и контент
На уровне набора возможностей мы переходим от абстрактного вопроса «Зачем мы делаем этот сайт?», который задавали себе на уровне стратегии, к новому вопросу: «Что мы собираемся создать?».
На уровне набора возможностей проявляется разделение Всемирной паутины на программные интерфейсы и гипертекстовые информационные пространства. На «программ ной» половине мы занимаемся функциональностью – тем, что составляет «перечень функций» программного продукта. На «гипертекстовой» половине мы имеем дело с контентом – традиционной сферой издательских и маркетинговых компаний.
Казалось бы, контент и функциональность не имеют ничего общего, но когда мы начинаем определять набор возможностей системы, оказывается, что с ними можно обращаться почти одинаково. Далее в этой главе я буду употреблять термин «возможность» для обозначения как программных функций, так и характеристик содержимого, предоставляемого пользователю.
При разработке программного обеспечения набор возможностей определяется в документах, содержащих требования к функциональности, или в функциональных спецификациях. В некоторых организациях эти термины обозначают два разных понятия: функциональные требования формулируются в начале проекта для описания того, что система должна будет делать, а спецификации создаются на заключительном этапе и описывают, что она делает в реальности. В других случаях спецификации разрабатываются вскоре после формулирования требований для уточнения деталей реализации. Однако, как правило, эти термины взаимозаменяемы. Некоторые люди пользуются термином «спецификации функциональных требований», чтобы охватить оба варианта. Я буду называть функциональными спецификациями собственно документ, а требованиями – его содержимое.
Язык этой главы по большей части является языком разработчиков программного обеспечения. Однако изложенное здесь в той же степени применимо и к контенту. При разработке контента определение требований часто не включается в формальную процедуру, типичную для раз работки программ, однако основные принципы остаются теми же. Чтобы понять, какую информацию должен донести контент сайта, разработчику контента предстоит побеседовать с людьми или изучить исходные материалы, будь то база данных или коробка с газетными вырезками. Этот неформальный процесс сбора требований к контенту на самом деле не так уж радикально отличается от того, что де лают разработчики, проводя мозговой штурм с участием заинтересованных сторон и изучая имеющуюся документацию. Цели и подходы в обоих случаях одинаковы.
Требования к контенту часто имеют функциональный под текст. В наше время для работы с наполнением сайта обычно применяются системы управления контентом (CMS – content management system). Такие системы бывают самыми разными – от очень больших и сложных, способных автоматически генерировать страницы на основе десятков различных источников информации, до предельно облегченных узкоспециализированных инструментов, предназначенных для максимально эффективного управления контентом какого-либо конкретного вида. Вы сами решаете, купить ли вам коммерческую систему, воспользоваться одной из множества систем с открытым исходным кодом или разработать собственную с нуля. В любом случае вам придется подстроить систему под нужды вашей организации и под контент вашего будущего сайта.
Функциональность, которая вам потребуется от системы управления контентом, зависит от природы самого контента. Нужно ли вам поддерживать несколько языков и раз личные форматы данных? Системе управления контентом предстоит обрабатывать все эти элементы. Должен ли каждый пресс релиз визироваться шестью вице-президентами юристом? Система управления контентом обязана поддерживать цепочку сбора резолюций как часть рабочего процесса. Будут ли элементы содержимого сайта автоматически переупорядочиваться в соответствии с предпочтениями каждого пользователя? Система управления кон тентом должна уметь предоставлять данные в таком не простом режиме.
Функциональные требования со своей стороны влияют на контент. Потребуются ли инструкции на экране настроек? Как насчет сообщений об ошибках? Все это кто-то должен написать. Каждый раз, когда я вижу на веб сайте сообщение типа «Исключение: передана пустая строка», я пони маю, что в готовом продукте остался текст предупреждения, вставленный кем-то из программистов в качестве заглушки, и произошло это потому, что в требования к кон тенту никто не добавил сообщения об ошибках. Огромное количество якобы высокотехнологичных проектов могло бы стать радикально лучше, если бы кто-нибудь из их разработчиков взял на себя труд пристально посмотреть на контент приложения.
Сбор требований
Бывают требования, которые касаются сайта в целом. Од ним из распространенных примеров являются требования, связанные с брендингом. Другой пример – технические требования (например, поддерживаемые броузеры и операционные системы).
Есть требования, затрагивающие только какую-то отдельную возможность. В большинстве случаев разработчики, говоря о требованиях, подразумевают краткое описание определенной возможности, которой должен обладать конечный продукт.
Самым надежным источником требований всегда будут ваши пользователи. Лучший способ узнать, чего они хотят, – это просто спросить их. Приемы исследования пользовательской аудитории, упомянутые в главе 3, способны по мочь вам лучше понять, какие функциональные возможности нужны пользователям вашего сайта.
Независимо от того, получены ли требования к продукту от заинтересованных сторон, находящихся внутри вашей организации, или собраны непосредственно с помощью пользователей, все добытые вами сведения подразделяются на три категории. Первая и самая очевидная – явно вы сказанные пользователями пожелания. Бывает, что пользователи предлагают бесспорно удачные идеи, которые реализуются в конечном продукте.
Иногда пожелания пользователей сами по себе не являются хорошими идеями, но дают ключ к требованиям второго типа – тому, что пользователи хотят на самом деле. Нередко человек, испытывающий проблемы при обращении с каким-то товаром или при выполнении какого либо процесса, придумывает решение, позволяющее избавиться от этих проблем. Иногда такое решение невозможно реализовать; иногда оно касается скорее симптома, чем болезни. Тем не менее исследование этих предложений может при вести вас к совершенно иным требованиям, решающим реальную проблему.
Третий тип требований, получаемых в процессе сбора, – это те возможности, о необходимости которых пользователи не подозревали. Когда люди обсуждают с вами новые требования к продукту и стратегические цели, иногда им в голову приходят великолепные мысли, которые просто не возникали ни у кого при рутинном сопровождении сайта. Этому нередко способствуют мозговые штурмы, во время которых участники могут высказаться и всесторонне исследовать возможности, открываемые проектом.
По иронии судьбы люди, глубже других вовлеченные в создание сайта или работу с ним, подчас наименее способны к поиску новых направлений его развития. По этой причине сеансы мозгового штурма, в которых собираются вместе сотрудники разных отделов компании или представители разных групп пользователей, становятся очень эффективным инструментом, показывающим участникам возможности, о которых те прежде и не подозревали.
Если собрать в одной комнате инженера, сотрудника отдела по работе с клиентами и специалиста по маркетингу и предложить им обсудить веб сайт, эта дискуссия может стать откровением для каждого. Когда люди сталкиваются с точкой зрения на сайт, отличающейся от привычной для них, и имеют возможность реагировать на нее, они начинают шире смотреть и на связанные с разработкой сайта проблемы, и на способы их решения.
Выработка требований часто сводится к поиску способов устранения препятствий. Предположим, один из ваших пользователей уже решил сделать покупку, но не определился окончательно, покупать ли ему именно ваш товар. Как ваш сайт сможет упростить для него процессы выбора и последующего приобретения вашего товара?
В главе 3 мы рассмотрели технику создания вымышленных пользователей, называемых персонажами, которая позволяет лучше понять потребности пользовательской ауди тории. При выявлении требований к продукту мы можем снова прибегнуть к помощи персонажей, сочинив для наших героев маленькие рассказы, называемые сценариями. Сценарий – это короткое, простое описание того, как персонаж пытается удовлетворить какие-либо пользовательские потребности. Представив себе процедуру, через которую могли бы пройти наши пользователи, мы сможем вы работать требования, соответствующие их желаниям.
Источником вдохновения могут послужить и наши конку ренты. Кто-то другой, занимающийся тем же бизнесом, почти наверняка пытается удовлетворить те же потребности пользователей и реализовать те же цели сайта. Нашел ли конкурент особо эффективный способ достижения ка кой либо из стратегических целей? Как он разрешил противоречия, с которыми мы столкнулись?
Даже сайты, не являющиеся прямыми конкурентами, могут послужить плодотворным источником требований. На большинстве корпоративных сайтов, например, публикуется информация о вакансиях. Изучив, как оформляют такой контент компании за пределами нашей индустрии, мы, возможно, найдем подход, который даст нам преимущество перед прямым конкурентом.
Уровень детализации требований часто зависит от специфики набора возможностей проекта. Если цель проекта со стоит в реализации одной очень сложной подсистемы, может потребоваться весьма высокая степень детализации, даже если набор возможностей подсистемы невелик по отношения ко всему проекту. И наоборот, широкомасштабный тематический сайт может содержать однородный кон тент, так что будет достаточно сформулировать лишь самые общие требования к этому контенту.
Функциональные спецификации
В определенных кругах функциональные спецификации имеют плохую репутацию. Программисты ненавидят спецификации за их занудность и за то, что потраченное на их чтение время – это время, отнятое от написания программы. В результате спецификации остаются непрочитанными, а это лишь усиливает впечатление, что их создание – пустая трата времени.
Одна из претензий к функциональным спецификациям со стоит в том, что они не отражают реальный продукт. В процессе реализации многое меняется, и все отдают себе в этом отчет – такова природа работы над техническими продуктами. Иногда то, что должно было работать, не работает или, что вероятнее, работает не совсем так, как вы хотели. Однако это не повод объявлять спецификации за ведомо проигрышной затеей и отказываться от них. На оборот, этот факт лишь подчеркивает необходимость создания спецификаций и поддержания их в актуальном состоянии. Если по ходу работы над проектом что-то меняется, нельзя сдаваться и заявлять о тщетности написания спецификаций. Правильное решение – не лениться синхронизировать спецификации с ходом разработки.
Независимо от размера и сложности проекта при формулировании требований следует руководствоваться некоторыми общими правилами.
Будьте позитивны. Вместо описания плохого или неправильного поведения системы опишите ее действия, предотвращающие нежелательный поворот событий. Например, вместо
Система не позволит купить воздушный змей без веревки.
лучше написать
При попытке купить воздушный змей без веревки система направит пользователя на страницу, где он сможет приобрести веревку.
Будьте конкретны. Только оставив как можно меньше путей для неправильной интерпретации требований, мы сможем определить, выполнены ли эти требования.
Сравните эти примеры.
Сайт будет доступен людям с ограниченными физическими возможностями.
Сайт будет удовлетворять Разделу 508 Акта о людях с ограниченными возможностями.
Навскидку первый пример производит впечатление четко сформулированного требования, но даже без глубокого анализа видно, какие пробелы он содержит. Что значит «доступен»? Если все картинки на сайте сопровождаются текстовыми описаниями, этого достаточно? Кто считается человеком с ограниченными физическими возможностями? Если на сайте не воспроизводится звук, значит ли это, что сайт доступен для глухих?
К счастью, Конгресс США уже выработал эти определения. Второй пример отсылает нас к конкретному юридическому документу, подробно формулирующему наши цели. Убрав возможность различных интерпретаций, второй вариант требования исключает любые споры, которые могли бы возникнуть в течение или после работы над проектом.
Избегайте субъективных формулировок. Это просто еще один способ выражаться ясно и исключать из требований двусмысленность (а значит, возможность разночтений).
Вот очень субъективное утверждение:
Стиль сайта будет броским и ярким.
Требования обязаны быть проверяемыми, то есть должен существовать способ продемонстрировать, что требования нарушены. Явно показать, что сайту присущи такие субъективные качества, как «броский» и «яркий», – трудная задача. Мое представление о броскости может отличаться от вашего и почти наверняка не имеет ничего общего с мнением президента компании.
Сказанное не означает, что невозможно потребовать от сайта броскости. Вам просто нужно сформулировать критерии оценки:
Сайт должен быть броским с точки зрения Уэйна – клерка, разбирающего почту.
Уэйн никаким образом не участвует в проекте, но спонсор проекта полагается на его представления о том, что является броским. Будем надеяться, что эти представления не расходятся с мнением пользователей. Однако требования остаются довольно произвольными, поскольку мы полагаемся на суждение Уэйна, а не на объективно сформулированные критерии. Возможно, лучше всего будет такое требование:
Внешний вид сайта должен соответствовать доку менту, содержащему рекомендации о визуальном стиле бренда компании.
Понятие «броскость» попросту исчезло из требований. Вместо этого мы имеем ясную и однозначную ссылку на существующие рекомендации. Чтобы решить, насколько броским является корпоративный стиль компании, ответственный сотрудник отдела маркетинга может проконсультироваться с Уэйном, посоветоваться со своей дочерью подростком или даже поинтересоваться результатами исследования пользовательской аудитории. Это его дело. Зато мы теперь всегда уверенно скажем, выполнены ли наши требования.
Мы также можем устранить субъективность, сформулировав некоторые требования в количественных терминах. Подобно тому как метрики успешности делают измеримы ми стратегические цели, формулировка требований в количественных терминах поможет нам понять, удовлетворены ли эти требования. Например, вместо утверждения, что система должна иметь «высокую производительность», следует потребовать, чтобы она была в состоянии одновременно обслужить не менее 1000 пользователей. Если у конечного продукта поле со счетчиком пользователей будет трехзначным, мы скажем, что требование не выполнено.
Требования к контенту
Говоря о контенте, мы по большей части имеем в виду текст. Однако нельзя забывать, что изображения, звук и видео тоже являются контентом. Эти разные виды кон тента могут комбинироваться, чтобы удовлетворить какому то одному требованию. Например, контент, относящийся к спортивному событию, может состоять из статьи, сопровождаемой фотографиями и видеофрагментами. Конкретизация всех типов контента, связанных с данной возможностью системы, позволяет определить необходимые для создания этого контента ресурсы (или хотя бы понять, можно ли его создать в принципе).
Не следует путать формат элемента контента и его назначение. В ходе обсуждения с заинтересованными сторонамитребований к контенту одним из первых возникает пожелание: «На нашем сайте должны быть ответы на часто за даваемые вопросы». Однако термин «часто задаваемые вопросы» («ЧаВо», FAQ – Frequently Asked Questions) на самом деле относится к формату контента: это простая последовательность вопросов и ответов. Реальная ценность ЧаВо для пользователей состоит в организации непосредственного доступа к часто требующейся информации. Другие требования к контенту могут служить той же цели, но когда внимание сосредоточено на формате, о самой цели часто забывают. Нередко «частотная» составляющая в раз деле «ЧаВо» игнорируется, и в результате предлагаются ответы на те вопросы, которые смог придумать разработчик контента, чтобы выполнить требования к «ЧаВо».
Ожидаемый объем каждого элемента контента оказывает огромное влияние на принимаемые вами решения, касающиеся опыта взаимодействия. Ваши требования к контенту должны содержать приблизительные оценки объема каждого его элемента: количество слов текста, размеры изображений в пикселях, размеры отдельных скачиваемых файлов вроде PDF документов, а также аудио и видеофайлов. Эти количественные оценки не обязаны быть точны ми – достаточно приблизительных. Нам нужно лишь со брать существенную информацию, необходимую для проектирования сайта вокруг этого контента. Разработка сайта, предоставляющего доступ к мини изображениям, отличается от разработки сайта, на котором выставлены полноэкраннные фотографии. Если мы заранее знаем размеры эле ментов, которые будут размещены на сайте, мы сможем принимать разумные, обоснованные решения на протяжении всей работы над проектом.
Важно как можно раньше решить, кто за какой элемент отвечает. Любая идея относительно контента, прошедшая проверку на соответствие стратегическим целям, будет замечательной, особенно если за ее реализацию и сопровождение отвечает кто то другой. Если мы погрузимся в работу над проектом слишком глубоко, так и не определившись с ответственными за каждый конкретный элемент контента, мы, скорее всего, получим «белые пятна» на сайте, потому что элементы, которые всем нравились в проекте, оказались трудны в реализации, и в результате никто за них не взялся.
При разработке требований нередко забывают, что заниматься контентом сайта – тяжелый труд. Вы можете нанять специалиста на контрактной основе (или, что проще, найти кого-нибудь из отдела маркетинга) и поручить ему подготовку контента к моменту ввода сайта в строй. Но кто будет обновлять это содержимое? Контент, по крайней мере востребованный, требует постоянного сопровождения. Если вы считаете, что достаточно разместить материалы на сайте и забыть о них, то со временем ваш сайт будет все меньше и меньше соответствовать потребностям пользователей.
Вот почему для каждого элемента контента необходимо ре шить, как часто он будет обновляться. Частота обновления определяется стратегическими целями сайта. Отталкиваясь от целей сайта, подумайте, как часто пользователи должны возвращаться на сайт. Исходя из потребностей пользователей, решите, как часто, по их мнению, должна обновляться информация на сайте. Не забывайте, однако, что идеальная для пользователя частота обновления («Я хочу знать все новости немедленно и круглосуточно!») может оказаться неподъемной для вашей компании. Вам придется найти разумный компромисс между ожидания ми пользователей и возможностями вашей компании.
Если ваш сайт нацелен на несколько различных аудиторий, будет полезно определить, для какой из них предназначен тот или иной элемент контента. Такое понимание – особенно в тех случаях, когда потребности разных аудиторий вступают в противоречие, – поможет вам принять наилучшее решение о способе подачи этого элемента. Информация, обращенная к детям, требует иного подхода, нежели информация для их родителей, а содержимое, адресованное и тем, и другим, нуждается в каком-то третьем подходе.
В проектах, связанных с большим количеством уже существующего контента, значительная часть сведений о мате риалах хранится в реестре контента. Составление реестра контента действующего сайта кажется (да и является) скучным и утомительным процессом. Однако наличие такого реестра (обычно имеющего форму простой, хотя и про странной электронной таблицы) необходимо по той же при чине, что и наличие требований: каждый член команды будет точно знать, с каким материалом он работает при создании опыта взаимодействия.
Ранжирование требований
Собирать идеи относительно требований к продукту не так уж трудно. Почти у любого, кто сталкивается с продуктом, будь то сотрудники организации или внешние люди, есть хотя бы одно пожелание о том, какую возможность следует в него добавить. Сложность в том, чтобы определить, какие возможности действительно должны быть включены в набор возможностей проекта.
На практике довольно редко удается найти взаимно однозначное соответствие между стратегическими целями и требованиями к продукту. Иногда одно требование связано с несколькими целями, а иногда одна цель ассоциируется с несколькими различными требованиями.
Поскольку набор возможностей определяется на основе стратегии, нам придется оценить возможные требования с точки зрения их соответствия стратегическим целям (целям сайта и потребностям пользователей). В дополнение к этим соображениям при определении набора возможностей появляется еще одно: насколько трудоемким будет процесс реализации этих требований?
Некоторые возможности нельзя реализовать по технологическим причинам. Например, нет способа передавать по Сети запах продуктов, как бы сильно ни хотели этого пользователи. Другие возможности (особенно если речь идет
о контенте) не реализуемы, потому что потребуют больше ресурсов, людских или денежных, нежели мы имеем в своем распоряжении. В некоторых случаях это вопрос времени: на реализацию возможности уйдет три месяца, а мы должны открыть сайт через два.
В случае ограничений по времени вы можете отложить реализацию возможности до следующей версии или до очередного этапа проекта. Если же ограничения связаны с недостатком ресурсов, то технологические или организационные изменения иногда (но, что важно, не всегда) могут сделать ресурсы менее дефицитными и позволят вам реализовать требуемую функцию. (Однако совершенно не возможные вещи останутся невозможными, увы.)
Возможности системы существуют не в вакууме. Даже эле менты контента на веб сайте обычно предполагают наличие функций, поддерживающих пользователя и информирующих его о том, как обращаться с полученным содержимым. Это неизбежно приводит к конфликтам возможностей. Чтобы создать внутренне согласованный, целостный продукт, потребуются компромиссы. Например, некоторые пользователи захотят, чтобы процесс размещения заказа состоял из одного шага, но морально устаревшие базы данных, с которыми сайту приходится иметь дело, не в со стоянии принять всю информацию сразу. Следует ли оставить многошаговый процесс или все таки переработать базу данных? Ответ зависит от ваших стратегических целей.
Внимательно отслеживайте предлагаемые возможности, которые свидетельствуют о стратегических изменениях, не очевидных на стадии создания документа «Общее представление о сайте». Любое предложение, несогласующесся со стратегией проекта, по определению выходит за границы набора возможностей. Однако если предложение укладывается в вышеизложенные ограничения и при этом кажется неплохой идеей, пусть даже и не попадающей область возможностей, вы можете пересмотреть какие то стратегические цели. При этом возврат к рассмотрению стратегии означает, что вы, скорее всего, слишком рано перешли к формулированию требований.
Если ваш документ «Стратегия сайта» или «Общее представление о сайте» задает четкую приоритетность ваших стратегических целей, эти приоритеты должны стать решающими факторами при определении относительных приоритетов предлагаемых возможностей. Впрочем, иногда сравнительная важность двух стратегических целей не очень ясна. В таких случаях решение о том, попадут ли со ответствующие особенности системы в набор возможностей, слишком часто в конечном итоге определяется корпоративной политикой.
При обсуждении стратегии заинтересованные стороны обычно начинают разговор с идей, касающихся возможностей системы, а потом вынужденно возвращаются на более глубокий уровень стратегических факторов. Поскольку эти люди часто с трудом отделяют функциональность от стратегии, некоторые возможности оказываются «фаворитами» при формулировке требований к продукту. В результате сбор требований превращается в своего рода торговлю между заинтересованными сторонами.
Управлять такими переговорами бывает очень трудно. Лучшим способом разрешения конфликта заинтересованных сторон является апелляция к заданной на предыдущих этапах стратегии. Сосредоточьте внимание на стратегических целях, а не на предлагаемых способах их достижения. Если вы сумеете убедить менеджера, «зациклившегося» на какой то возможности, что стратегическая цель, которой эта функция соответствует, может быть достигну та другими средствами, он перестанет считать, что интересами его группы пренебрегли. Конечно, это легче сказать, чем сделать. Для разрешения конфликта важно демонстрировать заботу о потребностях заинтересованных сторон. Кто сказал, что «технарям» не требуется умение работать с людьми?
электронное учебное пособие 
Для отправки комментария необходимо войти на сайт.