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

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

Вот часть вопросов, относящихся к ранним образцам прототипов:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Все неопределенности, к которым рано или поздно придется вернуться, должны быть отражены в списке. Ни у кого, кроме руководителя проекта, не возникнет потребности заглянуть в этот список, и разумеется, не сразу. Но по прошествии времени список может послужить поводом для сбора команды или проведения обсуждений «на ходу». Цель не в том, чтобы испортить людям настроение, просто им нужно иногда напомнить о том, что осталось нерешенным, и помочь понять, какие проблемы нужно решить специалистам команды. Поскольку работа руководителя проекта касается всех, вывешивание списка на видном месте позволит людям сотрудничать в решении проблем: «А этот пункт и меня касается. Кто им займется, ты или я?» По этой причине я держу список проблем на доске в своем офисе или коридоре. (Может сработать и wiki-технология, но никто, кроме составителя, туда не заглядывает. Обычные невиртуальные и неформальные места срабатывают куда лучше.)

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