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

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

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

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

• Когда эта проблема должна быть решена? Кто больше всех подходит для ее решения?

• Нельзя ли как-то изолировать проблему, может быть с помощью специфического компонента или сценария? Влияет ли она на общую функциональность или на весь проект в целом?

• Чем может разрешиться проблема в случае выбора каждого из вариантов, которые еще находятся в стадии рассмотрения? (Например, если мы решим использовать технологию ASP или PHP вместо JSP.) Как выбор каждого из вариантов повлияет на технические условия?

• Нельзя ли вообще проигнорировать эту проблему? Как это реально повлияет на пользователя с точки зрения самого приоритетного сценария его работы?

• Можно ли разбить проблему на более мелкие, которые могут (или должны) быть поручены другим специалистам?

• Кто или что мешает решению проблемы и были ли предприняты усилия для устранения этой помехи? (Ответ может скрываться в технической или политической сфере.)

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

Если вы неплохо справляетесь с решением открытых проблем, то можно ликвидировать белые пятна в рабочем графике, проведя оценку времени разрешения этих проблем. Основную идею, часто называемую «усесться на переднем сидении», иллюстрирует рис. 7.1. При правильном воплощении этой идеи в жизнь технические условия могут считаться подготовленными и рассматриваться, даже если проектные проблемы остаются отчасти нерешенными. Этот прием представляет собой рискованную затею: вы прикидываете, насколько успешно командой будут решены оставшиеся проблемы, а не ждете их реального решения. Тем не менее подобные действия совсем не обязательно связаны с высокой степенью риска. Все зависит от того, насколько хорошо понятна суть этих проблем и насколько верны предположения относительно их решения. Рассмотрим для примера две команды. Команда А располагает длинным, но вполне понятным перечнем проблем, а команда Б – коротким, но малопонятным. Какая команда, по-вашему, скорее всего, уложится в назначенные сроки? Я бы отдал предпочтение команде А (в этом месте звучит гимн команды А ). Здоровый скепсис подсказывает, что короткий перечень команды Б свидетельствует о том, что ею еще не выявлены все проблемы, связанные с техническими условиями. Что касается команды А , она уделила больше времени на осознание всех имеющихся у нее открытых проблем и лучше подготовлена к тем испытаниям, которые уготовил ей проект.