14. Удовольствие и мощь

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

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

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

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

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

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

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

Пример успешного внедрения проектирования

Моя студия дизайна и проектирования не так давно закончила работать над одним из наших самых успешных проектов для небольшой компании в регионе Pacific Northwest. Компания называется Shared Healthcare Systems, Inc. (SHS), она занимается созданием программного обеспечения для управления всеми аспектами предоставления долговременных услуг здравоохранения.

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

Бизнес SHS вовлек компанию в ситуацию, которую Мишель Борк из компании Clinidata в Монреале характеризует как «клинический ураган». Процессу компьютеризации малого бизнеса первыми подверглись кабинеты врачей, но затронута оказалась только сторона работы, связанная с оплатой услуг. Тот участок работы, на котором врач взаимодействует с пациентом, непреклонно противился приходу цифровой эпохи и оставался одним из последних бастионов некомпьютеризированной части мира.

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

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

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

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

Когда SHS впервые обратилась в компанию Соорег Interaction Design, работа отдела разработки программного обеспечения была организована в соответствии с доставшимся ей программным продуктом, разделенным на два модуля – клинический и финансовый.

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

Нашей рекомендацией было создать единую запись о пациенте, содержащую одновременно и клиническую, и финансовую информацию в одной консолидированной базе данных, а поверх этого – модульный пользовательский интерфейс, который бы позволил каждой персоне получить доступ только к той информации, которая нужна для решения конкретных пользовательских задач. Результатом стала реструктурированная база данных, лежащая в основе программы. Более же примечательным стало то, что SHS произвела реорганизацию отдела разработки в соответствии с новой архитектурой программы! Разработчиков распределили на две новые группы: одни работали с архитектурой записи о пациенте и базой данных, другие – с интерфейсами для персон. В программные спецификации и документацию SHS по этому проекту теперь включали имена персон для более ясного определения их функционала.

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

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

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

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