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

Специалисты по исследованию пользовательских запросов занимаются двумя делами: они выбирают метод на основании тех вопросов, на которые должна ответить команда проектировщиков, и пользуются несколькими методами для нейтрализации ограничений и перекосов, возникающих при индивидуальных подходах. В табл. 3.2 показаны некоторые главные исследовательские методы и их основные достоинства и недостатки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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