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