Успешные ИТ-проекты начинаются не со сбора урожая, а с нелегкого обсуждения того, что должно быть сделано
Пол Глен — руководитель компании C2 Consulting. С ним можно связаться по адресу: info@c2-consulting.com

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

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

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

Проблема со сбором требований, по существу, — это проблема сбора слов. Какой образ у вас возникает, когда вы слышите слово «сбор»? В моем воображении рождается картина сбора урожая: группа людей среди бесконечных рядов виноградной лозы срывает зрелые гроздья и аккуратно укладывает их в корзины. Другие могут представлять себе ребенка, собирающего раковины на берегу, или, скажем, людей, сливающихся в толпу на городском митинге. Что общего во всех этих представлениях? Есть объекты, которые собираются, — виноград, раковины или люди — и все они образуют нечто целостное и завершенное.

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

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

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

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

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

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

Успешные проекты начинаются не со сбора урожая, а с нелегкого обсуждения того, что должно быть сделано. Если вы перестанете пытаться собирать требования и начнете обсуждать их, ваш проект будет намного более продуктивным.