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

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

Рис. 5.5. Правильно организованный процесс проектирования объединяет ориентацию на пользователя и практическое рассмотрение доступной технологии. Если изолировать один из компонентов, то другой неизменно от этого пострадает

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

Обдумывание подобных представлений, эскизов, первичных зарисовок или, в некоторых случаях, прототипов, станет первым шагом на пути осознания идеи. Если что-то не может быть выражено в виде рисунка или эскиза, то, скорее всего, оно не может быть и создано. Диаграммы, построенные в таких программах, как UML и Visio, не могут считаться проектными эскизами. Диаграммы – вещи абстрактные. В них не отображается то, что увидит пользователь, поэтому за ними могут скрываться всевозможные проблемы и детали, требующие осмысления.

Возьмем одну из простых проблем, перечисленных мною в главе 3: «Из домашней страницы затруднен поиск часто требующихся элементов». Давайте предположим, что после мозговой атаки были выявлены три вполне подходящие идеи:

1. Динамически выстраивать страницы по приоритетам на основе их востребованности.

2. Избавиться от материала, который никогда не вызывается по ссылкам.

3. Провести смысловую группировку материала домашней страницы с точки зрения пользователей.

Прежде чем какой-нибудь разработчик задумается над реализацией этих идей, кто-то должен взвесить их ценность с точки зрения пользовательского восприятия. Возможно, выяснится, что как бы привлекательно они не выглядели в абстрактном представлении, никто из присутствующих не в состоянии придумать приемлемую конструкцию,[34] объединяющую их таким образом, чтобы облегчить пользователям выполняемую ими работу. Поэтому в интересах команды лучше исходить из пользовательского восприятия – это самый легкий способ избавиться от лишней работы, выяснить, какая именно конструкция должна быть создана и зачем, а также уменьшить шансы последующих серьезных изменений. Управлять этим процессом нелегко, но лучше что-то, чем ничего.

Проектирование представляет собой серию переговоров

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