Психбольница в руках пациентов
Шрифт:
В предыдущей главе я писал, что проектирование необходимо излагать на бумаге, прежде чем начнется создание кода. Однако в кипящем котле разработки продукта программист по-прежнему имеет возможность игнорировать проектировочный документ, независимо от качества документа. Такое развитие событий весьма вероятно в пассивно-агрессивной культуре разработки программного обеспечения, где инженеры считают любые проектировочные вводные не более чем советом, которому можно следовать, если позволяет рабочая нагрузка и есть желание.
Следует четко и ясно дать понять всем участника проекта, что проект – это чертеж, которому
Есть только один способ эффективно передать эту мысль. Высшее руководство компании должно недвусмысленно заявить всем менеджерам по проектированию и разработке, что программисты освобождаются от ответственности. Оно должно дать понять, что за качество продукта отвечает теперь команда проектировщиков, и проектировщики наделяются полномочиями требовать, разумеется, под присмотром руководителей.
Программисты вольны импровизировать внутри программы, но любой аспект взаимодействия с пользователем, имеющий четкое определение, должен быть реализован строго по описанию. Описание можно подвергать сомнениям, но нельзя в одностороннем порядке игнорировать или переиначивать. Предписания проектировщиков не следует считать советом, который можно воспринимать частично или видоизменять.
На команду проектировщиков возлагается ответственность за все, с чем вступает в контакт пользователь. Не только за программное, но и за аппаратное обеспечение. Следует принимать во внимание и сопутствующие программные модули, такие как программы установки.
Это, вероятно, наиболее радикальное требование, выполнение которого необходимо для успешного проектирования, причем такое, которое требует наибольшей культурной адаптации. Позже в этой главе мы обсудим культурные вопросы более подробно. А сейчас рассмотрим пример компании, успешно включившей проектирование в процесс разработки.
Пример налаженного проекта
Моя студия проектирования недавно завершила работу над одним из самых успешных проектов. Клиент – небольшая компания Sun Healthcare Systems, Inc., создающая программное обеспечение для управления всевозможными аспектами работы учреждений системы здравоохранения.
На первых встречах я старательно объяснял заказчику важность персонажей и рассказывал о том, какую роль мы им отводим в процессе проектирования. К нашему большому удовольствию и удивлению, команда SHS восприняла эту концепцию очень благосклонно. На первое проектное совещание они принесли собственный набор из десятка уже определенных персонажей. Нам все же пришлось потратить время на изучение предметной области, чтобы проверить качество персонажей и доработать их, зато полностью исчезла необходимость убеждать разработчиков и маркетологов в применимости персонажей, как инструмента.
Бизнес SHS приводит эту компанию к тому, что Мишель Борк (Мiсhеl Воurque) из компании Clinidata, расположенной в Монреале, называет «Клиническим водоворотом». Кабинеты врачей попали в число первых объектов компьютеризации в малом бизнесе, однако преобразованию поддалась лишь финансовая часть. Та же сторона, где врач взаимодействует с пациентом, упрямо сопротивлялась
Усилия SHS в основном направлены на администрирование, но существенная часть задач оказывается прямо в этом водовороте. Мы участвовали в небольших проектах других компаний, работающих в этой области, но в самом центре водоворота мы еще не были. Возможность работать над столь серьезным и сложным проектом нас сильно воодушевила.
Воодушевились и в компании SHS, но для начала сообщили нам, что масштабы бизнеса настолько велики, что компания сомневается в нашей способности эти масштабы осилить. SHS считала, что ее бизнес просто слишком велик и сложен для понимания. Для нас это был вызов, и мы приняли его с готовностью.
Проект был большой. Мы выделили пять ключевых персонажей. Ни в одном из прошлых проектов не бывало больше трех. Поначалу мы с подозрением отнеслись к такому числу, однако, пересмотрев результаты, поняли, что SHS действительно пытается охватить огромный сегмент рынка здравоохранения. Разумеется, создание программного обеспечения сразу для пяти ключевых персонажей – слишком крупный проект. В SHS это поняли, поэтому продукт проектировался и создавался поэтапно, по одному персонажу на этап.
Дэвид Вест (David West), вице-президент по разработке и наш связной в SHS, помимо прочего снискал доверие и уважение других сотрудников этой растущей организации. Маркетологи знают, что он действует в их интересах. Знают это и программисты. Знают, что он суров, но справедлив. Он подобен камню в бурлящих водах разработки. Он верен процессу проектирования, и другие разработчики стали доверять нашей работе, воспринимать ее всерьез, как спецификацию.
Когда SHS вступила в контакт с Соорег Interaction Design, ее отдел разработки программ был организован в соответствии с уже имевшимся программным продуктом. А продукт имел два модуля – клинический и финансовый.
Проведя исследование и разработав персонажи, мы быстро поняли, почему существующая система не способна удовлетворить медиков. Если даже не учитывать серьезные проблемы взаимодействия, деление между информационными подсистемами (клинической и финансовой) было надуманным. Это порождало лишнюю бумажную работу, которую пользователь был вынужден выполнять, чтобы обойти недостатки системы обработки данных. Каждый пользователь обитал на собственном островке данных, поскольку два модуля системы не были взаимосвязаны.
Мы рекомендовали создать объединенную медицинскую карту пациента, содержащую как клиническую, так и финансовую информацию для консолидированной базы данных, а также модульный пользовательский интерфейс, позволяющий каждому персонажу получать доступ к информации, необходимой для решения ее задач. В результате SHS перепроектировала базу данных, лежащую в основе продукта. И что примечательно, реорганизовала сотрудников отдела разработки в соответствии с этой новой архитектурой! Разработчики сформировали две новые группы. Одна из них работала с архитектурой медицинской карты и базой данных, а вторая – с интерфейсами персонажей. Все дальнейшие программные спецификации и документы в SHS будут содержать имена персонажей для четкого определения функций.