Формирование команд проектировщиков

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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