Книга: Искусство управления IT-проектами

Качественные требования и ошибки

Качественные требования и ошибки

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

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

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

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

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

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

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

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

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

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

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

Оглавление книги