Итак, вам по-прежнему нужно найти кого-то для выполнения проектирования взаимодействия. Стоит вам начать поиски, как вы увидите, что почти в каждой высокотехнологичной компании такие проектировщики есть и они преимущественно разочарованные: это технические писатели, к которым обращаются программисты с просьбой помочь прояснить некоторые вещи; менеджеры по продукту, книжные полки в кабинетах которых ломятся от книг по проектированию взаимодействия; юзабилити-тестировщики, упоминающие о том, что в процесс разработки следует вовлекаться на ранних стадиях; маркетологи, акцентирующие внимание на том, что им удалось приобрести стереосистему с наименьшим количеством кнопок; программисты, которые пишут совсем незначительное количество строк кода, но при этом другие программисты просят тех поработать с ними. На самом деле, когда сотрудникам компании становится известно, что проект начнется с этапа проектирования и случится это до этапа программирования, кто-то из них непременно вызовется, утверждая, что горит желанием быть именно тем человеком, который отвечает за качество продукта.
Когда вы станете подыскивать кандидата на полный рабочий день, хороший специалист может и не назваться проектировщиком взаимодействия. Вам следует обращать внимание на людей, в общих чертах понимающих технические детали, но обладающих страстью к дизайну и проектированию. Таких людей можно обнаружить в совершенно различных сферах деятельности и с совершенно разным опытом за плечами. Когда я нанимал людей для своей студии дизайна и проектирования, я просил их выполнить тестовое задание, связанное с решением проектировочной задачи, так как понимал, что в их резюме может не оказаться нужных сведений. Сейчас в моей студии в должности проектировщиков работают несколько человек, которые прежде были техническими писателями, руководителями разработки продуктов, специалистами технической поддержки или графическими дизайнерами. Многие из проектировщиков, работающих у меня, пришли из гуманитарной сферы, но есть и те, кто специализировался в физике, архитектуре, компьютерных дисциплинах и промышленном дизайне.
Специалисты с опытом работы в технической поддержке или в документировании спецификаций перспективны в отношении умения понять типичные потребности пользователя. Руководители, ответственные за разработку программного продукта, разбираются лишь в потребностях программистов, возникающих в процессе разработки. У графических и промышленных дизайнеров есть стремление к красоте и умение претворить ее в жизнь. Дизайнеры с гуманитарным образованием, имеющие опыт работы в высокотехнологичных отраслях, сочетают в себе понимание технологий и способность донести свою мысль.
Дискуссия о том, как разные специалисты подходят к созданию команд проектировщиков и управлению ими, могла бы занять отдельную книгу. Здесь же я касаюсь некоторых методов проектирования, чтобы вы лучше понимали, что я имею в виду, употребляя термин «проектирование», однако даже не делаю попытки изложить всю методологию целиком. Тем не менее, благодаря своему опыту управления командами проектировщиков в моей студии, я могу предложить вам некоторые ключевые принципы.
Формируйте команды небольшого размера. В целях преуспеть проектировщики должны обладать единым видением результата. В моих командах обычно бывает от двух до трех проектировщиков на каждый продукт, которым периодически могут оказывать помощь и содействие другие специалисты. Если проект сложный, проектирование может доходить до той стадии, когда у продукта возникает несколько разных интерфейсов – тогда задачу можно разделить на части и каждую из них отдать на откуп собственной команде. Однако до этого момента ситуация будет как в известной поговорке: «У семи нянек дитя без глазу».
Команду следует изолировать от руководства и программистов. На начальной стадии проекта проектировщики обязательно должны провести беседы с другими специалистами, задействованными в процессе, чтобы составить четкое представление о проблеме и определить персон. После этого им нужно дать пространство для проработки самых тупиковых вариантов, с тем чтобы они выработали собственное наиболее удачное решение, но сделать это эффективно они смогут только в уединении.
Назначьте специалиста, ответственного за составление документации по ходу работы команды. Каждый из членов команды внесет в эту документацию свой вклад, однако отвечать за нее должен лишь кто-то один – только тогда можно добиться эффективной работы.
Предоставьте команде время, чтобы привести мысли в порядок. Позднее, когда основные задачи решатся, будет вполне разумно, если вы обратитесь к команде проектировщиков за выяснением специфических деталей. На ранней стадии проекта команда должна самым тщательным образом обдумать все аспекты решения проблемы и представить свои измышления в виде целостной концепции. Когда моя студия предоставляет клиенту полную структуру продукта, мы формируем документацию и демонстрируем свои решения относительно проектирования с неофициальными контрольными точками там, где это требуется. В ходе первой презентации мы очерчиваем проблему, представляем набор персон и обговариваем задачи, которые требуется решить при помощи проектирования. На каждой последующей презентации мы описываем проект продукта во все более и более подробных деталях.
Организуя такой управляемый процесс, центром которого является проектирование, а не программирование, компании получают возможность избежать опасной игры с огнем. Им становится заранее известно, что требуется пользователям и каким образом им это предоставить. Им также станет известно, при каких условиях процесс разработки можно будет считать завершенным, а у специалистов различных направлений сформируется как общее, так и частное видение, которое позволит им сплотиться вокруг продукта.