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

Провидцам от технологии не дано осознать различие между выполнимым и желаемым.

Эдвард Мендельсон (Edward Mendelson)

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

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

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

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

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

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

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

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

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

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