Юрий Ветров. Управление проектами и проектирование интерфейсов

Одним из самых плотных по вовлечению и продолжительности проектов был для меня Project Management Center. Те полгода активных обсуждений, аналитики, проектирования и экспериментов помогли создать мощную базу наработок для всего процесса работы над интерфейсами. Все это в условиях двойного давления по времени — компании нужно было как можно скорее запустить новую версию системы, а мне — не затянуть давно запланированный переезд в Питер.

Задача

Project Management Center (PMC) — это одно из ключевых веб-приложений для крупного офшорного разработчика EPAM Systems. Система обеспечивает весь процесс работы над проектами. Работа с требованиями, планами, задачами, сборками, рисками, ошибками; учет бюджета и трудозатрат; отчетность по различным управленческим аспектам — и еще множество полезных вещей. Когда компания была не очень большой, большинство этих задач решалось с помощью MS Outlook. Но по мере роста пришло время делать уже пятую версию PMC.

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

Есть и сложности. Во-первых, проект все-таки внутренний. А это значит что не на все работы хватает ресурсов и внимания руководства, так что не все полезные изменения получается осуществить. В-третьих, помимо разработки пятой версии нужно вносить изменения и в текущую, на которой держится рабочий процесс. Третья проблема посерьезнее. Сотрудников (а значит и пользователей системы) в компании достаточно много, не всем она по душе. По делу этот негатив или нет — часть скепсиса переносится и на разрабатываемую новую версию.

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

В общем, нужно было сделать Project Management Center 5 более удобным и эффективным. Причем, возможно, переработать общую идеологию системы. Все четыре предыдущие версии базировались на интерфейсе корпоративного интранета и в основном добавляли функциональность, оставаясь похожими друг на друга. А родительский пользовательский интерфейс был не готов к такому масштабному развитию.

Проектирование

Процесс ведения проектов в компании по большей части водопадный. А значит общую концепцию системы, заточенную под RUP, менять не требовалось. Но вот концепцию интерфейса пора было пересмотреть. Улучшить общую информационную архитектуру, упростить навигацию по большому количеству функций и модулей, более тесно интегрировать функциональность друг с другом, обеспечить удобство работы с конкретными объектами — задачами, требованиями и т.п..

Ключевыми потребителями системы являются 4 группы людей:

1. Исполнители. Участники проектных команд, которым нужно выполнить поставленные задачи и отчитаться об отработанном времени. Реже — поставить задачу коллеге по проекту на основе дефекта (бага) или требования.
2. Менеджеры. Руководители проектов или команд разработчиков. Они ставят задачи и контролируют их выполнение, смотрят отчеты по ходу проектов и использованию ресурсов.
3. Высшее руководство. Начальники отделов и направлений, директоры. Этой группе важна высокоуровневая отчетность — как идут проекты в целом по компании, на каких этапах возникают “провисы”.
4. Клиенты. Представители заказчика и другие заинтересованные лица. Эту группу можно разбить на два подтипа — частные случаи 2) и 3). Первым важно видеть, как идет работа над конкретными задачами или требованиями, вторым — знать общий статус проекта, степень освоения ресурсов.

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

1. Переключение между множеством модулей и функций, отвечающих за общий процесс.
2. Просмотр списков объектов и поиск среди них нужных для текущей работы.
3. Просмотр и редактирование информации о конкретном объекте, просмотр дополнительных сведений о нем — каков его статус, с какими еще объектами связан.
4. Заполнение и контроль журнала отработанного времени.

Банальные задачи — меню, списки, страница объекта. Но только если не принимать во внимание масштаб системы.

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

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

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

Например, долгой и многословной была перепалка с программистами по поводу редактора фильтров для списков. Тех же багов в крупной системе могут быть десятки тысяч, так что нужен инструмент для быстрой выборки. В работающей версии системы это было монструозной махиной для создания максимально гибких фильтров с помощью деревьев любого уровня. Мало кто пользовался ей активно — принцип работы был понятен только после поллитры. Например, чтобы поменять оператор с “И” на “ИЛИ” нужно было как в квесте кликнуть по нескольким не предназначенным для этого контролам в нужном порядке.
 
Как сделать это удобным? Мы решили проанализировать задачи, которые можно выполнять с учетом этого фильтра. И не смогли придумать ни одной выборки, которая потребовала бы дерева глубже третьего уровня. А когда посмотрели статистику использования этой функции в существующей версии — увидели, что почти никто не создавал деревьев глубже второго. Редактор фильтров был здорово упрощен. Хотя по просьбам любителей подземных вертолетов создали возможность переключиться в advanced-версию, которая позволяла сделать и третий.

Основная работа по проектированию делалась в MS Visio. При этом активно использовались офлайновые инструменты — бумажные черновики, маркерные доски, стикеры Post-It. Последние, правда, были скорее забавой для разрядки обстановки. Они клеились на монитор в тех местах экрана, где предполагалось вставить новый элемент управления. Особенно здорово получалась динамика — сложенные “гармошкой” выпадающие меню.

Общий процесс

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

Еще одной важной частью проектной работы были мини-презентации внутренних процессов. Руководители команд тестировщиков, аналитиков, технической поддержки и других направлений в деталях рассказывали о том, как у них построен процесс, что важно и что мешает в текущей версии. Были и затяжные рабочие сессии с группой разработки, когда выяснялась реализуемость тех или иных задумок. Были и peer reviews, когда результаты работ с профессиональной точки зрения оценивали коллеги по отделу. В общем, как минимум половина времени работы над проектом проходила в обсуждениях — но оно того стоило. Опасно запустить нежизнеспособный продукт и парализовать работу полутора тысяч человек.

Большой кусок обсуждений приходился на работу с дизайнером. Здесь особенно серьезно встала проблема того, что при отрисовке схем страниц (wireframes) все масштабы относительны. А вот когда на их основе делается визуальный дизайн, начинается не только переделки некоторых вещей, но и настоящая война за пиксели. Классический случай — слишком высокая шапка. Оставить ее как есть — значит вынести много информации за пределы первого экрана. Уменьшить — не только разбить концепцию дизайна, но и чересчур уплотнить информационное наполнение. Иногда доходило и до ссор.

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

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

Wireframes, Пользовательские интерфейсы, Портфолио, Практика, Проектирование, Прототипы, Юзабилити