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

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

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

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

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

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

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

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

Устранение пробелов в технических условиях

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

Рис. 7.1. Устранение пробелов, оставшихся при проектированиии составлении технических условий

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

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

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

• Может ли эту проблему решить руководитель проекта или проектировщик? Выразится ли закрытие этой проблемы в появлении новых работ? (Например, может быть появится возможность действовать параллельно с программистом, который приступает к обдумыванию работ, в то время как руководитель проекта занимается решением открытых проблем.)

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

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

• Относится ли проблема к центральному или ключевому компоненту? Когда программист должен воплотить его в жизнь? Можно ли спроектировать компонент позже, в стадии разработки? Принадлежит ли проблема к чему-нибудь, от чего, по имеющимся прикидкам, зависит ряд других компонентов?

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

Устранение пробелов не всегда венчается успехом. Возможно, вы приложите массу усилий и сдвинете дело с мертвой точки, но обнаружите, что все еще далеки от победы. Даже в этом случае усилия по устранению проблем принесут пользу. Неопытные команды зачастую нуждаются в том, чтобы их принуждали к борьбе со всеми возникающими у них проблемам (как технического, так и иного плана), и руководители могут не понимать всей важности отложенных проблем, пока те себя в полной мере не проявят. Можно найти массу веских аргументов в пользу предупредительного, а не выжидательного метода устранения пробелов, подвергающего рабочий график существенному риску.

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

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

СОВЕТ

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