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

• Каковы сильные и слабые стороны данного образца в отношении проблем, предположительно решаемых с его помощью? (Все за и против со всех точек зрения: потребителя, бизнесмена, разработчика.)

• Какими данными мы должны располагать при оценке этого образца? (Возможно, полученными в результате изучения потребительских запросов, неформального анализа возможностей реализации, проведенного программистами, анализа рыночной ситуации, мнений специалистов и т. д.)

• Что поучительного, пригодного для следующей версии прототипа содержал данный образец? Можно ли его уничтожить?

• Что нужно попробовать сделать в следующем образце, чтобы добиться лучшего результата?

• Есть ли в этой же группе или в других прототипах какая-нибудь другая идея, которой мы можем воспользоваться?

А вот ряд вопросов для более поздних прототипов:

• Какое решение с его помощью мы можем принять?

• Какие спорные вопросы он поможет нам закрыть?

• Подтверждается ли данным образцом существование проблемы, подлежащей исследованию? Решается ли эта проблема с его созданием?

• Что следует попробовать сделать в следующем образце, чтобы приблизиться к составлению технических условий?

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

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

Этот список можно начать с весьма приблизительного перечня вопросов, оставшихся без ответа, и дел, оставшихся не сделанными («Какую схему данных мы будем использовать, А или Б ?» или «Когда нужно забрать у Салли окончательный вариант дизайна пользовательского интерфейса»), но он должен наполняться подробностями по мере приближения дня сдачи технических условий. Рядом с каждым вопросом должна стоять фамилия человека, ответственного за его решение. А руководитель проекта должен оповестить всех ответственных за решение проблем и затем периодически напоминать им об этом и отслеживать результаты.

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

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