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

При планировании создается большой объем информации и возникает непростая задача, как ее свести к простому плану действий. По большому счету, все взгляды, результаты исследований и стратегические основы синтезируются в единый концептуальный документ. Об этом особом документе мы поговорим в следующей главе. Но на более низком уровне простейшим инструментом становится набор требований.

Для многих проектов требования являются средством определения их направленности. Требования по определению означают, что команда (с ведома заказчика) к моменту завершения проекта должна их удовлетворить. В наипростейшем смысле определением требований является заказ пиццы с пепперони. Вы объявляете изготовителю пиццы, что вы, собственно, желаете получить. Он может уточнить требования, задавая вопросы («Не желаете ли вы вдобавок минеральной воды?»), или детально обговорить требования («У нас в данный момент нет пепперони, не подойдет ли взамен салями?»). В более сложном случае, при разработке программного продукта, получить качественно выработанные требования намного труднее. Существует множество различных способов интерпретации абстрактных идей, усложняющих процесс выработки требований («Сделайте более высокоскоростной или более отказоустойчивый продукт»).

Для выработки и документирования требований существует ряд устоявшихся методов, и я рекомендую ознакомиться с ними самостоятельно.[22] В зависимости от уровня имеющихся при выдвижении требований полномочий применяются различные способы решения этой задачи, позволяющие достичь хороших результатов. Особенности этих методов и способы их применения в данной книге не рассматриваются. Тем не менее один метод, отличающийся простотой, легкостью в применении и эффективностью, я могу вам предложить – это метод постановки задач.

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

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

• С домашней страницы затруднен поиск часто востребуемых разделов.

• Ведомственная информационная страница долго загружается, заставляя пользователя ждать.

• Страница запросов к базе данных сбоит при работе с большими таблицами, вынуждая пользователей начинать все заново.

• Веб-сайт не обеспечивает автоматического доступа к защищенным услугам, а ручной доступ отнимает много времени.

• Результаты поиска трудно просматривать в существующем формате.

• На странице регистрации не обеспечен контроль вводимой информации в обязательные поля, поэтому при вводе легко ошибиться.

• Страница состояния не включает информацию об электронной почте, и пользователи не могут узнать, почему их электронная почта не работает.

• Отсутствует способ сохранения предпочтений или вариантов появления домашней страницы.

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

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

Проблемы превращаются в сценарии

Поскольку постановка задач отражает текущее состояние дел, проект нуждается в чем-то другом, отражающем состояние, которое будет достигнуто по завершении работы. С этой целью нужно переработать постановку задач в нечто иное, называемое формулировкой характеристик или сценарием. Для этого существует масса различных способов. Одним из самых популярных считается метод сценариев использования (use-cases),[23] но существуют и другие методы.

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

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

Итак, возможные характеристики проекта X:

• Часто востребуемые разделы можно будет легко обнаружить на домашней странице.

• Результаты поиска будут представлены в доступном для большинства пользователей виде, допускающем беглый просмотр.

• Веб-сайт обеспечит простой автоматизированный доступ к защищенным услугам.

• Регистрационная страница позволит упростить безошибочный ввод информации.

• Ведомственная информационная страница будет загружаться, по крайней мере, так же быстро, как и домашняя страница.

• Интерфейс запросов к базе данных будет по надежности сопоставим с остальными компонентами системы.

• Пользователи получат возможность видеть состояние сервера электронной почты в простом и удобном формате.

• У пользователей будет удобный способ сохранять свои предпочтения при настройке системы.

Формулировка характеристик ни в коем случае не должна включать описание конкретной конструкции, в ней вместо этого должно быть объяснение влияния решений на потребителя. Проще, конечно, сказать, чем сделать. Большинство творческих личностей любят решать проблемы и сделают это автоматически. Загвоздка в том, что скоропалительные решения зачастую бывают поверхностными. Перед принятием решений нужно дать проблемам возможность как следует уложиться в сознании. Нужно просто попросить людей во время совещаний по планированию записать возникающие у них идеи по решениям и обсудить их чуть позже. Исключение можно сделать для тех идей, которые полностью вычеркивают проблему из списка или переводят ее в разряд несущественных.

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

Объединение деловых и технологических требований

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

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

22

Обратите внимание на замечательную книгу Дональда Гауса (Donald Gause) и Джералда Вейнберга (Gerald Weinberg) «Exploring Requirements: Quality Before Design» (Dorset House, 1989).

23

Этот метод описан в книге Алистера Кокборна (Alistair Cockburn) «Writing Eff ective Use Cases» (Addison Wesley, 2000).