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

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

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

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

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

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

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