Алан Купер - Психбольница в руках пациентов

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

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

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

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

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

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

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

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

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

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