Особенности проектирования интерфейсов командами, разделёнными океаном

У нас продолжается наработка сурового опыта разработки ПО и сервисов разделёнными между двумя континентами командами. И сейчас те давние проблемы всего лишь синхронизации программерского кода и разрешения конфликтов в SVN представляются цветочками Оказывается, наиболее весёлый аттракцион происходит в том случае, когда идёт этап проектирования нового сервиса, так же разделёнными командами. И вот начата работа над новым сервисом, пока всё больше на этапе исследований, при этом маркетологи исследуют рынок и составляют портрет ЦА, программеры – изучают техническую часть и пишут тестовые примеры различных потенциальных веток проекта. В целом исследовательская часть подходит к концу, и перед дизайнерами становится задача – нарисовать дизайн “общего” экрана сервиса, включающий стиль для формы, логотип, различные панели-кнопки-формы и содержательную часть, которые будут присутствовать на, скажем, среднем экране (середина работы с сервисом), причём наиболее насыщенном всяким хламом.

Когда цели проекта сформированы сколько-нибудь внятно, прикинуть первую версию такого “среднего” экрана довольно просто; и дизайн был нарисован, и принят заказчиком восторженно, и даже программеры, которые изрядно придирались к некоторым элементам дизайна, как к трудно реализуемым или малоадекватным, наконец-то сказали, что всё замечательно. Т.е. утверждён будущий стиль дизайна сервиса. Игрушки закончились, и теперь нужно бы приниматься за отрисовку уже реальных экранов. И тут у нас начинается ступор. Потому что этап проектирования сервиса в целом полностью на себя взяла канадская команда. Именно они там у себя в своих конференц-румах ежедневно с отделом маркетинга, руководством и прочими участниками процесса бурно, по нескольку часов ежедневно (по словам нашего канадского управляющего) обсуждают сценарии поведения пользователя при работе с сервисом, только… Ни одно из этих обсуждений не заканчивается присланными прототипами экранных форм. Что ж за беда-то такая?

Человечек специалист, который у них, там, должен был бы рисовать прототипы, группировать по сценариям и присылать сюда готовые шаблоны для рисующего дизайнера, то ли не справляется, то ли вообще не подходит для такой работы. Его первый вариант экранов, отрисованный в Visio, который мы получили больше недели назад, даже на тот период был недостоверный и не отвечающий никакой логике, не иллюстрирующий ни один из возможных сценариев. Так, набор каких-то страниц с формами, который мы покрутили-покрутили, и отложили, как пример показательно безграмотной работы. Тогда решили попробовать другой метод: устроили телефонную конференцию с включенным на компьютере одним общим монитором (через сервис logmein.com, давно используем его в работе и радуемся, что такое есть). Предварительно, до начала конференции, набросали наиболее вероятных 5-7 экранов; оказалось, что для того, чтобы диалог был конструктивным, канадским менеджерам действительно проще получить пусть и не оптимальныме (а никто и не говорил, что это последняя версия), но хоть какие-то экраны.

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

В процессе обсуждения, кстати, народ довольно часто повышал голос. Особенно конфликтные моменты возникали между программерами и кем-то другим: что делать, если на панели размещены два *горизонтальных бегунка* для изменения размеров просматриваемой области (zoom) и ограничителя времени (time) – они так красиво нарисованы рисующим дизайнером, так эффектно смотрятся, но как они будут меняться, когда изменится горизонтальный размер панели? Должны они тоже “ужиматься” и до какого минимума или должны “уезжать” за край рабочей области? Или имеет смысл сделать их вертикальными, но ведь тогда придётся передоговариться с “генеральным”, который уже официально сообщил, что эскиз того самого презентационного варианта интерфейса ему так понравился, что он ТРЕБУЕТ, что бы ничего не меняли ни по пожеланиям отдела маркетинга, ни по техническим требованиям программеров, а зум и таймер уж больно замечательно визуально вприсываются именно в горизонтальном состоянии… А с точки зрения привычности-удобства для пользователя вертикальные бегунки будут удобнее… и т.д.

В общем, конференция прошла успешно, я успела отрисовать изрядное количество черновиков экранов, и сегодня девочка-дизайнер уже рисует визуальные представления по этим черновикам. Они-то на самом деле, чуть причёсанные, и стали прототипами экранов для дизайнера. Формально, если бы было больше времени (и каждый занимался своим делом) по этим бумажным черновикам стоило бы сделать аккуратные схемы в каком-нибудь правильном редакторе, но сроки, сорванные канадским “проектировщиком” из-за того, что сначала он нарисовал не то, что надо потому что не понял, что же надо, потом в отпуске был, потом просто потерялся из-за интенсивных дискуссий с идеологами-генераторами идей по сервису. Отчасти его кст.говоря стопорил именно поток-объём идей: фантазёры-идеологи придумывали что-то совершенно не из реального мира, настолько оторванное от жестокой действительности, что он даже не знал, как это можно преобразовать в экранную форму и тем более в сценарий (набор экранных форм). И даже более того: часть нафантазированных идей тормозилась из-за того, что наиболее приближенные к технологиям, к реальной разработке менеджеры останавливали некоторые особо фантазийные идеи именно тем, что не были уверены, что разработчики, гм., смогут “такое” реализовать, а обсудить непосредственно с разработчиками техническую возможность невозможно (извиняюсь), потому, что разработчики спят, отделённые от дискуссии часовым поясом в +7 часов. Но проблема, должен ли проектировщик хотя бы в какой-то мере быть в курсе особенностей технологий разработки — это к вопросу о небольшой дискуссии по поводу одного из недавних постов “Дизайнерское: интерфейсы в исходниках” в трансляции на ya.ru, когда обсуждали требования к вакансии специалиста, то ли инфоарха, то ли проектировщика интерфейсов

Lisa:
1. Понимание особенностей разработки на .net для инфоарха точно будет обязательным входящим, или это можно рассказать при общей вменяемости человека?
2. Я видела, когда аналитика сочеталась с коммуникабельностью, но редко люди признают в себе оба этих качества одинаково сильными То есть аналитика тут важнее и ее человек должен самопризнавать, но я бы вторй пункт формулировала бы не как коммуникабельность, а как готовность и способность обсуждать и работать в команде. Оттенок чуть другой.
3. “Получение, обработка и синхронизация информации о текущих этапах разработки между разными подразделениями, работающими над проектом: отделом маркетинга, программистами, дизайнерами, интеграторами.” Это инфоарха задача или все-таки менеджера проекта? Я бы инфоарха не стала бы нагружать синхронизацией в процессе, в начале – да, деваться некуда, а в процессе это скорее для пм задача, отдавать инфоарху для внесения изменений уже согласованное.

Tatyana:
1. Конечно, это не обязательное входящее но у нас 99% проектов на дотнете, рано или поздно спецу придётся научиться считаться с особенностями разработки на .Net, не такие уж они сложные и недоступные для понимания. Для человека открытого информации (что закономерно для такого специалиста) проблем не будет.
2. Да, “коммуникабельность” — само слово неудачное. Именно готовность и способность обсуждать. Здесь вот какая проблема: каждое из подразделений (возьмём в качестве подразделений отдел маркетинга,дизайнеров и программеров) плохо умеет “общаться” на рабочие темы между собой. Во-первых снобизм у каждого из подразделений, во-вторых специализация – каждый видит своё и не видит чужое, из-за этого часто бывают конфликты. У инфоарха не должно быть проблемы с неумением договариваться с разными подразделениями при получении от них информации и при выдаче им.
3. Нет, нельзя сказать, что это “задача менеджера проекта”. Просто в задачи менеджера проекта тоже входит в какой-то мере получение, обработка и синхронизация информации о текущих этапах. Видимо, они получают, обрабатывают и синхронизируют немного разную информацию менеджер – командами и задачами между командами, инфоарх – архитектурой проекта.

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

В общем, описанным где-то там выше способом мы формируем первую группу наборов экранных форм, иллюстрирующих разные сценарии поведения пользователя в этой программе. Вплоть до того, что у файлов-иллюстраций каждого отдельно взятого сценария будут порядковые номера, чтобы канадские менеджеры не запутались при обсуждении первого, предложенного уже нами варианта; ведь следующий этап, всё ещё предваряющий уже реальную разработку, будет заключаться в том, что эти экраны (хоть и статическими картинками) будут тестироваться группой подопытных, которые будут изображать из себя представителей ЦА и создавать первую базу отзывов о работе будущей программы. А программеры уже в нетерпении подгоняют: их тестовые “учебные” скрипты готовы переростать в реальные, и, кажется им, затягивается процесс в бессмысленных совершенствованиях наименее важного для работающего сервиса этапа – проектирования интерфейсов и сценариев поведения.

Для нас же в общем-то понятно: канадское руководство просто пока прикрывает не особо одарённого чувака, который как бы “проектировщик интерфейсов”, понимает, что чувак не справляется, но, извиняясь перед нами, говорит о том, что “вот он ещё учится, пусть на этом проекте он ещё ошибается и делает неправильно, но если его не отшить, то на каком-то втором-третьем проекте у него начнёт получаться”. И ведь повлиять на ситуацию не возможно даже убеждениями в том, что на нашей стороне, в нашей команде этот этап – проектирования интерфейса – всё равно получается лучше, может сюда его и перенести? Ан нет. Почему? Потому что все те самые идеологи-фантазёры с генеральным в компании — они все там, за окияном, и проектировщик тоже им нужен на самом деле там, и это справедливо. Он должен их видеть, слышать, щупать общаться с ними, это должен быть диалог не только в процессе фантазирования, но и в процессе работы над прототипами, набросал черновики, показал, обсудили, перерисовал, показал, обсудили… а как удобно такие обсуждения иллюстрировать тут же зарисовками на доске с фломастерами! тут же стёр, дорисовал, показал, обвёл акцент… динамика! Мы оказались в менее динамичной среде: мои бумажные прототипы, дизайнерские эскизы, отрисованные в редакторе – это уже статика, на которую уходит больше времени; хорошо ещё, что почти всё, отправляемое от нас, почему-то утверждается почти без замечаний.

По поводу трудностей, которые возникают в таких распределённых командах, хочу процитировать кусок из одной замечательной статьи, найденной уже давно на rsdn`е и не закрываемой в окне Оперы уже несколько месяцев, изумительно иллюстрирующей именно наши проблемы, которые наблюдаю ежедневно, статьи Алистэра Коуберна “Люди как нелинейные и наиболее важные компоненты в создании программного обеспечения”

Основным фактором в разработке программного обеспечения является возможность коммуникации. На рисунке 1 изображена некая кривая, с помощью которой я иллюстрирую свои методологические рассуждения. На этом рисунке видно, как падает эффективность коммуникации, если исчезает ее модальность и синхронизация. Этой теме посвящено несколько исследований (см. [Pl] и [Si]), кроме того, эту же зависимость подтверждает и Вайнберг, который описывал проекты около 30 лет назад [Wei].

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

• Физическая досягаемость. Я не знаю, как это объяснить, но физическая досягаемость собеседников влияет на их общение. Что бы ни лежало в основе этого влияния – трехмерность, синхронизация, запах или малозаметные визуальные сигналы – при коммуникации это имеет большое значение.
• Разнообразные модальности. Человек общается не только словами, но и при помощи жестов. Часто человек может высказать свое суждение жестикуляцией, например, поднимая бровь или указывая на что-то пальцем.
• Интонация и синхронизация речи. Чтобы подчеркнуть важность какого-либо высказывания или, к примеру, свое удивление, говорящий может ускорять или замедлять темп речи, делать паузы или изменять интонацию.
• Ведение диалога в реальном времени (вопрос-ответ). С помощью вопросов слушающий выясняет для себя то, что ему было неясно в речи собеседника, или же получает дополнительные сведения, которых ему не хватает для полного понимания предмета. Синхронизация вопросов и ответов является основополагающим определением типа коммуникации.

Итак, что же произойдет, если мы начнем убирать одно за другим все эти свойства?

• Убираем только физическую досягаемость. Поместим собеседников на противоположные концы видеосвязи. В принципе, при этом сохраняются все основные свойства физического присутствия, и тем не менее, эффект уже не тот. Когда мы испробовали этот способ в Норвегии, где одна часть команды разработчиков находилась в Осло, а другая – в Лиллехаммере, то оказалось, что команда находила верные проектные решения, только когда всем удавалось собраться вместе. Даже то время, которое люди тратили, чтобы вместе дойти до электрички, было более продуктивно для работы, нежели видеоконференция.
• Убираем жестикуляцию и визуальную синхронизацию, оставляем интонацию и вокальную синхронизацию (другими словами, используем для общения телефон). Большинство людей во время беседы по телефону рисуют. Если человек рисует линию, которая соединяет два прямоугольника, это значит, что он собирается сказать нечто важное, то, что нужно отметить особо. Визуально-слуховая синхронизация информации закрепляет в сознании человека ее суть. Когда люди говорят по телефону, эта синхронизация исчезает, а вместе с ней из коммуникации исчезают жестикуляция, выражение лица собеседника, и т.д.
• Теперь уберем голосовую синхронизацию и интонацию, оставим лишь возможность задавать вопросы (электронная почта). Без голосовой синхронизации мы не можем ни сделать эффектную паузу, ни подождать, не будет ли у собеседника возражений или вопросов, ни ускорить или замедлить темп речи, чтобы сделать высказывание. Лишив себя возможности использовать интонацию, человек не может выразить с ее помощью, насколько удивительна, скучна или очевидна выраженная в письме идея.
• Теперь уберем возможность задавать вопросы (но восстановим один из перечисленных выше факторов). Не имея возможности услышать вопросы собеседника, говорящий должен сам догадываться, что тот знает или не знает, какие вопросы мог бы задать, и включать в свою речь ответы на эти несуществующие вопросы. И все это он должен сделать, не имея обратной связи со своим слушателем. Этот вид коммуникации допускает наличие визуальной (видеокассета) или слуховой (аудиокассета) информации.
• И, наконец, убираем все свойства коммуникации – визуальные, слуховые, голосовые, синхронизацию общения, возможность задавать вопросы – что же мы получаем? Правильно, бумажную документацию. На приведенной выше модели вы видите, что документация является наименее эффективным способом коммуникации из всех возможных. Тот, кто пишет документацию, должен строить догадки относительно своей аудитории безо всякой обратной связи, у него нет возможности использовать ни синхронизацию и другие эмфатические сигналы, ни жестикуляцию и интонацию.