Большинство руководителей проектов понимают, что список требований, выдвигаемых заказчиком в начальной стадии проекта по разработке системы, нуждается в расстановке приоритетов. В конце концов, в нынешние времена сжатых сроков и нехватки персонала обещать пользователю выполнить все его требования в срок попросту нереально.
Чего многие руководители проектов не осознают, так это необходимости постоянно осуществлять пересмотр первоначально установленных приоритетов, отсортировывать требования, с тем чтобы наиболее критичные из них оказались в конечном счете выполнены.
В рамках популярной когда-то стратегии между пользователем и разработчиком обычно заключается соглашение об обязательной реализации некоторых функций из оговоренного перечня в начальной версии системы. Черед других («дополнительных») функций должен был наступать в следующих версиях системы, которые выпускались бы, скажем, с интервалом в три месяца.
Подобное соглашение может заключаться из вполне достойных побуждений, однако же оно не принимает во внимание сегодняшних реалий крайне динамично меняющегося мира. Даже за те три — шесть месяцев, характерных для разработки систем в эпоху Internet, вполне могут произойти изменения на рынке или в законодательстве; кто-то из разработчиков вдруг может покинуть проект, а право принимать решения со стороны пользователя может перейти в другие руки.
Если еще учесть, что многие из нынешних проектов включают в себя использование технологий, относительно новых даже для разработчиков, то следует признать, что вероятность дать крайне неточные начальные оценки срокам и потребным ресурсам проекта довольно велика. Пример: проект с использованием Windows 2000 может изначально оцениваться как двухмесячный, но с учетом существующей кривой обучения и небольших несовместимостей Windows 2000 со старыми приложениями проект может потребовать четырех месяцев.
Из этой проблемы предлагается вот какой выход: в самом начале проекта следует упорядочить требования пользователей по важности и затем регулярно пересматривать их приоритеты: не реже, чем ежемесячно, а возможно, и раз в неделю — в зависимости от темпа проекта.
Здесь есть определенная аналогия с работой военного врача в полевом госпитале, так как требования нужно распределить по трем категориям. В первый список должны попасть те критические для системы функции, без которых она «не выживет», то есть не будет пригодна к употреблению или будет отвергнута конечным пользователем. Во вторую категорию попадут такие особенности, без которых система хотя и «выживет», но будет выглядеть «раненой» (то есть пользователям все время будет чего-то не хватать, но не настолько, чтобы отказаться от системы вообще). Наконец, в третью категорию попадут «украшения», доставляющие много радости пользователям, но без которых они не будут особо скучать.
Из-за отсутствия постоянной переоценки требований нередко рождаются проекты, не отвечающие реальности: обе стороны делают вид, что первоначальный перечень требований будет выполнен в срок, даже если каждый участник в отдельности (и разработчики, «выкладывающиеся» что есть сил, и пользователи, и руководитель проекта) понимает, что шансы на успех тают с каждым днем.
При таком развитии дел за несколько дней до официальной сдачи нередко происходит кризис, когда руководитель проекта вынужден заявить, что работа не может быть выполнена в том виде, в котором первоначально задумывалась. И тогда, если сроки сдачи отодвинуть невозможно и если добавить людей в команду разработчиков становится слишком поздно, остается только одно: урезать количество предусмотренных в системе возможностей, то есть осуществить переоценку требований. Однако делать это в конце проекта - и напряженная, и политически неприятная работа. Она чревата и потерями уже затраченных средств, так как от каких-то особенностей придется отказаться в то время, как они уже отчасти реализованы.
Из этого вытекает, что руководитель проекта должен быть в состоянии постоянно «перетасовывать» требования. И если речь не идет о совсем маленьком проекте, вполне вероятно, что помощь здесь окажут специальные средства автоматизации. Но правило остается одно, безотносительно к тому, будете ли вы это делать вручную или автоматизированно: проведите упорядочивание требований у нее в самом начале проекта и повторяйте это чаще.
Эд Йордон — редактор журнала Cutter IT Journal, выпускаемого Cutter Consortuim. Его координаты можно найти на сервере www.yourdon.com