Читать книгу "Искусство управления IT-проектами - Скотт Беркун"

Определите относительный приоритет каждого требования. Поскольку всем нам свойственно включать в список покупок все, что только нужно и не нужно, то по отношению к требованиям крайне необходимо определить важность каждого из них относительно всех остальных. После установки относительного приоритета становится значительно легче вести переговоры между специалистами, отвечающими за выработку требований, и специалистами, отвечающими за разработку конечного продукта (подробнее вопросы приоритетов рассмотрены в главе 12).

Постарайтесь уточнить или исключить все случайно вкравшиеся неоднозначные понятия. Такие слова, как быстрый, большой, маленький, хороший, красивый и удобный, понятны лишь в сравнении. Их неопределенность может устраивать только в том случае, когда все участники выработки требований (заказчики, руководители, программисты и т. д.) согласны отложить их уточнение до следующих переговоров. В противном случае каждый составитель требований не захочет вносить уточнения там, где это ему не выгодно. Зачастую простейшим способом устранения неоднозначности является установка определенных границ («Наша домашняя веб-страница должна загружаться в Firefox как минимум с такой же скоростью, как страница www.cnn.com, но лучше, если она будет загружаться так же быстро, как www.oreilly.com»). При этом должны быть легко различимы абсолютные (должно быть так) и желательные (было бы неплохо, но можно обойтись) требования.

Используя одну из постановок задач, рассматриваемых в главах 3 и 4, рассмотрим один из вариантов качественной формулировки отдельного требования:

Результаты поиска должны легко и быстро читаться большинством пользователей. Приоритет – 1. Наша цель состоит в том, чтобы постепенно сделать работу с системой поиска намного удобнее. Мы изменим внешний вид имеющейся на данный момент страницы результатов поиска за счет устранения пяти наиболее существенных пользовательских претензий и решения пяти наиболее важных проблем, которые будут выявлены в процессе предстоящей оценки эргономики существующего дизайна. Страница с обновленным дизайном станет единой страницей для отображения результатов поиска, появляющихся после ввода аргументов во все основные поисковые поля (в навигационной панели, в домашней странице, в покупательской корзине), а если это не повлечет за собой значительных затрат, то и для отображения результатов поиска с использованием всех имеющихся поисковых полей.

Естественно, возможна и более глубокая детализация, но даже столь краткое описание, состоящее всего из нескольких предложений, способно уберечь требование от множества просчетов, допускаемых при формулировке. Обратите внимание на то, что в требовании определены намерения, а не сами вопросы переработки дизайна страницы. Чем глубже детализация требования, тем выше риск, что оно станет накладывать на дизайн излишние ограничения. Насколько целесообразна глубокая детализация, зависит от распределения полномочий и мастерства разработчиков.

Исследование проекта

Теперь, после того как мы согласились (а ничего другого, собственно, и не оставалось) с тем, что требования играют весьма важную роль, можно обсудить, как исследовать основанные на этих требованиях идеи.

Поскольку требования уже изложены, проектировщики могут обследовать ограниченную ими область, представляющую собой довольно большое пространство потенциальных путей решения любой отдельно взятой задачи, которое называется пространством решения проблемы. В зависимости от требований это пространство может быть весьма обширным; например, существует несметное количество способов обустройства дома, приготовления еды, создания системы учета, веб-сайта или чего-нибудь еще, за что вам платят деньги. Итак, пока у вас не сложится некоторое представление об имеющихся возможностях (на основании предварительного исследования этой области), останавливаться на каких-нибудь ранее найденных решениях неразумно. Первые же пришедшие в голову идеи вряд ли будут удачными, поскольку вы все еще находитесь в процессе изучения путей подхода в пределах пространства решения проблем и выработки представления о своих возможностях.

На рис. 5.2 показано пространство решения проблем, определяемое на основе имеющихся требований. Как только проектировщик приступит к исследованию идей, удовлетворяющих требованиям, пространство решения проблем станет расширяться. Его расширение обусловлено тем, что в процессе ранней проработки какого-нибудь вопроса или эскиза вскрывается все больше и больше ранее не замеченных решений и возможностей. Например, требование может иметь следующую формулировку: «Веб-сайт должен обеспечивать полнотекстовый поиск на всех страницах», но при этом, скорее всего, ничего не будет сказано об используемой для этого поисковой машине, о способах настройки поиска или о способах встраивания пользовательского интерфейса поиска в структуру веб-сайта. То есть кто-то должен исследовать все многообразие существующих возможностей. (Несмотря на это, пространство решения проблем в конечном счете сужается, о чем мы поговорим в следующей главе.)

Рис. 5.2. Конструкторские замыслы возникают на основе формулировки задачи

В зависимости от характера требований границы пространства решения проблем могут различаться. Если на поиск альтернатив отпущена всего лишь неделя, а стоимость производства готового изделия должна составлять лишь 10 долларов, это пространство крайне ограничено. Проектировщик будет вынужден довольствоваться весьма скудным выбором альтернативных вариантов. Вообще-то можно ведь задать и абсолютно невыполнимые требования (например, создать вечный двигатель или решить задачу NP-заполнения в полиномиальном времени). Время, бюджет, компетентность и определенные проектные критерии – все это оказывает влияние на форму или размер пространства решения проблем. Этим частично объясняется то огромное влияние, которое оказывает выработка требований на процесс проектирования.

Также этим объясняется, почему должна быть обратная связь между проектированием и выработкой требований. Если выясняется, что некоторые требования, учитывая ограниченность пространства решения проблем, удовлетворить невозможно, они должны быть каким-то образом скорректированы. И наоборот, если проектировщику пришла в голову фантастическая идея, которая отвечает целям данного проекта и для реализации которой нужно внести изменения в требования, то обсуждение соответствующей корректировки будет уже в интересах клиента, заказчика или бизнеса.

Неудивительно, что работа чаще всего приобретает инновационный характер при условии, что ответственность за выработку требований и проектирование возложена на одного и того же человека (то есть кто-то в недавно созданной компании, в научно-исследовательской лаборатории или группе наделил его соответствующими полномочиями). При этом он может единолично регулировать любые изменения, как в требованиях, так и в вопросах проектирования.

Страх перед просчетами и размышления о прогрессе

Возможно, многие стараются уклониться от участия в проектировании, опасаясь проводить исследования под пристальным взглядом других людей. Когда мы исследуем собственную работу (например, пытаемся оптимизировать алгоритм или подправить документ), то делаем это без свидетелей. Мы можем свободно проверять самые сомнительные или странные идеи, самостоятельно оценивая собственные действия. А занимаясь проектированием в составе команды согласно графику общей работы, каждый проектировщик будет проводить исследования на виду у массы людей. Все создаваемые им эскизы или прототипы придется публично демонстрировать и открыто обсуждать. Если люди не верят в конструктивность высказываемых им критических замечаний, то не удивительно, что они боятся участвовать в процессе проектирования.[28]