Одним из самых плотных по вовлечению и продолжительности проектов был для меня Project Management Center. Те полгода активных обсуждений, аналитики, проектирования и экспериментов помогли создать мощную базу наработок для всего процесса работы над интерфейсами. Все это в условиях двойного давления по времени — компании нужно было как можно скорее запустить новую версию системы, а мне — не затянуть давно запланированный переезд в Питер.
Задача
Project Management Center (PMC) — это одно из ключевых веб-приложений для крупного офшорного разработчика EPAM Systems. Система обеспечивает весь процесс работы над проектами. Работа с требованиями, планами, задачами, сборками, рисками, ошибками; учет бюджета и трудозатрат; отчетность по различным управленческим аспектам — и еще множество полезных вещей. Когда компания была не очень большой, большинство этих задач решалось с помощью MS Outlook. Но по мере роста пришло время делать уже пятую версию PMC.
Хотя система продается и как самостоятельный продукт, для компании он скорее важен как конкурентное преимущество — клиенты имеют доступ к большинству информации. Во-первых, это обеспечивает большую прозрачность процесса для существующих клиентов, которая и доверие поднимает, и коммуникацию улучшает, и команду подстегивает работать лучше. Во-вторых, наличие такого мощного инструмента говорит о том что внутренний процесс отлажен и предсказуем. А это уже помогает при общении с потенциальными заказчиками.
Есть и сложности. Во-первых, проект все-таки внутренний. А это значит что не на все работы хватает ресурсов и внимания руководства, так что не все полезные изменения получается осуществить. В-третьих, помимо разработки пятой версии нужно вносить изменения и в текущую, на которой держится рабочий процесс. Третья проблема посерьезнее. Сотрудников (а значит и пользователей системы) в компании достаточно много, не всем она по душе. По делу этот негатив или нет — часть скепсиса переносится и на разрабатываемую новую версию.
С другой стороны, свежая инкарнация несет много приятного. Дизайн меняется от тяжеловесного и устаревшего в сторону приятного и гибкого к изменениям. Новая схема навигации должна упростить работу с системой, сделать ее более понятной. Да и в целом интерфейс должен стать более простым и целостным. Кстати, по итогу оказалось, что прибавил очков и показ промежуточных результатов неформальным лидерам мнений. Эти консультации поднимали настроение не только им, но и их коллегам — до них показанное доходило как интересные слухи.
В общем, нужно было сделать Project Management Center 5 более удобным и эффективным. Причем, возможно, переработать общую идеологию системы. Все четыре предыдущие версии базировались на интерфейсе корпоративного интранета и в основном добавляли функциональность, оставаясь похожими друг на друга. А родительский пользовательский интерфейс был не готов к такому масштабному развитию.
Проектирование
Процесс ведения проектов в компании по большей части водопадный. А значит общую концепцию системы, заточенную под RUP, менять не требовалось. Но вот концепцию интерфейса пора было пересмотреть. Улучшить общую информационную архитектуру, упростить навигацию по большому количеству функций и модулей, более тесно интегрировать функциональность друг с другом, обеспечить удобство работы с конкретными объектами — задачами, требованиями и т.п..
Ключевыми потребителями системы являются 4 группы людей:
- Исполнители. Участники проектных команд, которым нужно выполнить поставленные задачи и отчитаться об отработанном времени. Реже — поставить задачу коллеге по проекту на основе дефекта (бага) или требования.
- Менеджеры. Руководители проектов или команд разработчиков. Они ставят задачи и контролируют их выполнение, смотрят отчеты по ходу проектов и использованию ресурсов.
- Высшее руководство. Начальники отделов и направлений, директоры. Этой группе важна высокоуровневая отчетность — как идут проекты в целом по компании, на каких этапах возникают “провисы”.
- Клиенты. Представители заказчика и другие заинтересованные лица. Эту группу можно разбить на два подтипа — частные случаи 2) и 3). Первым важно видеть, как идет работа над конкретными задачами или требованиями, вторым — знать общий статус проекта, степень освоения ресурсов.
На первой фазе проекта мы решили сконцентрироваться на первых двух. Именно они больше всего работают с системой — вся их работа проводится через PMC. И именно они чаще всего просят улучшений. Да и ругаются на нее тоже куда больше остальных. Так что упрощение работы над их повседневными задачами даст общему процессу в компании наибольший эффект. Если прикинуть грубо, основное время менеджеров и исполнителей тратится на:
- Переключение между множеством модулей и функций, отвечающих за общий процесс.
- Просмотр списков объектов и поиск среди них нужных для текущей работы.
- Просмотр и редактирование информации о конкретном объекте, просмотр дополнительных сведений о нем — каков его статус, с какими еще объектами связан.
- Заполнение и контроль журнала отработанного времени.
Банальные задачи — меню, списки, страница объекта. Но только если не принимать во внимание масштаб системы.
Начинаем с разработки информационной архитектуры и общего лейаута. После нескольких вариантов и пары километров пробега маркера по whiteboard вырисовалась отличная схема. В целом ничего принципиально нового, но вот общая сумма проверенных решений дала отличный результат. Двухуровневое верхнее меню, дерево папок, список элементов, переключатель проектов, поисковая форма и статус пользователя — все снова достаточно банально. Но почти каждый из этих блоков был вылизан до блеска.
Особенно удался список объектов — это решение в том же или упрощенном виде я использую везде и теперь. Да и в целом такой подход — наличие типовых элементов, которые переходят из проекта в проект — дает много плюсов. И время экономится, и сами элементы развиваются. Конечно, они применимы не всегда, но большинство проектов хотя и достаточно разные, часто решают набор одних и тех же задач. Так что новый велосипед не всегда полезен.
После проработки концепции интерфейса взялись за детали. Диалоги, собственные элементы управления, отрисовка конкретных форм и списков, уведомления и множество других приятных мелочей. Не забываем и про сервисные страницы вроде настроек всей системы или конкретного модуля. Прорабатываем AJAX-взаимодействия и другую динамику. Очень помогало в работе наличие статистики по использованию текущей версии системы. Так было проще не только принимать решения, как спроектировать ту или иную функциональность, но и разрешать споры.
Например, долгой и многословной была перепалка с программистами по поводу редактора фильтров для списков. Тех же багов в крупной системе могут быть десятки тысяч, так что нужен инструмент для быстрой выборки. В работающей версии системы это было монструозной махиной для создания максимально гибких фильтров с помощью деревьев любого уровня. Мало кто пользовался ей активно — принцип работы был понятен только после поллитры. Например, чтобы поменять оператор с “И” на “ИЛИ” нужно было как в квесте кликнуть по нескольким не предназначенным для этого контролам в нужном порядке.
Как сделать это удобным? Мы решили проанализировать задачи, которые можно выполнять с учетом этого фильтра. И не смогли придумать ни одной выборки, которая потребовала бы дерева глубже третьего уровня. А когда посмотрели статистику использования этой функции в существующей версии — увидели, что почти никто не создавал деревьев глубже второго. Редактор фильтров был здорово упрощен. Хотя по просьбам любителей подземных вертолетов создали возможность переключиться в advanced-версию, которая позволяла сделать и третий.
Основная работа по проектированию делалась в MS Visio. При этом активно использовались офлайновые инструменты — бумажные черновики, маркерные доски, стикеры Post-It. Последние, правда, были скорее забавой для разрядки обстановки. Они клеились на монитор в тех местах экрана, где предполагалось вставить новый элемент управления. Особенно здорово получалась динамика — сложенные “гармошкой” выпадающие меню.
Общий процесс
Все результаты постоянно обсуждались не только с командой проекта, но и просто с коллегами по работе. Это особенно удобно, когда потребителем продукта является практически каждый первый из них. Узнать о неудобностях и приятностях текущей и разрабатываемой версий можно в любой момент. Так что опросы, беседы и интервью начались еще до непосредственного проектирования и не останавливались на всем протяжении проекта.
Еще одной важной частью проектной работы были мини-презентации внутренних процессов. Руководители команд тестировщиков, аналитиков, технической поддержки и других направлений в деталях рассказывали о том, как у них построен процесс, что важно и что мешает в текущей версии. Были и затяжные рабочие сессии с группой разработки, когда выяснялась реализуемость тех или иных задумок. Были и peer reviews, когда результаты работ с профессиональной точки зрения оценивали коллеги по отделу. В общем, как минимум половина времени работы над проектом проходила в обсуждениях — но оно того стоило. Опасно запустить нежизнеспособный продукт и парализовать работу полутора тысяч человек.
Большой кусок обсуждений приходился на работу с дизайнером. Здесь особенно серьезно встала проблема того, что при отрисовке схем страниц (wireframes) все масштабы относительны. А вот когда на их основе делается визуальный дизайн, начинается не только переделки некоторых вещей, но и настоящая война за пиксели. Классический случай — слишком высокая шапка. Оставить ее как есть — значит вынести много информации за пределы первого экрана. Уменьшить — не только разбить концепцию дизайна, но и чересчур уплотнить информационное наполнение. Иногда доходило и до ссор.
Удался на славу интерактивный прототип. Именно на его основе строилась большая часть обсуждений и презентаций системы. Не на всех проектах имеет смысл поддерживать его в актуальном виде в ходе всей разработки. Но для нас это было критично, поэтому он не только постоянно был свежим и отражал большую часть экспериментов с дизайном, но и имитировал огромную кучу JavaScript-взаимодействий.
Ближе к концу разработки новая версия была запущена параллельно со старой. С самого начала предполагалось, что база данных будет общей, так что пользователи могли начинать переход поэтапно. Были и недовольные — не все мы успели отшлифовать, не все проблемы предыдущей версии решились в первой фазе, не все готовы менять привычки. Но в целом отзывы говорили о том что работать стало приятнее и удобнее.
62 comments
Очень интересная статья, спасибо. Особенно любопытно в свете того, что я уже многое слышал о PMC как от пользователей, так и от разработчиков.
Вопросик из сферы юзабилити. Чем отличаются по функциям два чекбокса под формой отправки комментария в этом блоге? Цитирую:
1. Receive an email if someone else comments on this post?
2. Notify me of followup comments via e-mail
Если честно, я разобраться не смог, но на всякий случай поставил галочку в первом пункте.
Спасиб! А отзывы были в хорошую или плохую сторону? 🙂
А по поводу чекбоксов в форме — он пока сделан из типовых движка и плагинов, так что я еще не успел заняться деталями. Но планирую в ближайший месяц-два запуск новой версии сайта — ближе к персональному сайту, а не блогу. Так что там все будет проще и понятнее 🙂
Крайне интересно. Спасибо за скриншоты 😉
Колллега, не хочется вас расстраивать, но с точки зрения эффективности взаимодействия интерфейс этой “программы” если проводить аналогию с автомобилями соответствует примерно первым бензиновым повозкам.
Подсказка для направления работы: интерфейса должно быть меньше, а не больше.
2 Юзабилист
Что, вы действительно способны спроектировать Феррари? 🙂
Что, задело? Значит есть за что.
Да неужели? 🙂
У нас, кажется, большинство способно еще только паровозы собирать.
[удалено как провокационное и оскорбительное — Юрий Ветров]
У Юзабилистов.
Это гопники – они мешают нам жить.
Юра,
Твою работу на этом проекте до сих пор ставят в пример. Если кому-то надо показать, как на самом деле можно сделать в Visio – смотрят на те PMC wireframes.
Жаль что бедные пользователи этой системы этого не оценят 🙁
Вы же не видели предыдущих версий…
Во сколько экранов оцениваете сложность системы?
То, что сделал Юра – очень и очень достойно.
Ах вы ещё экранами меряете? Пожалуй моя первая оценка была завышена
А чем мерять надо?
Вообще хотелось бы услышать пару имен Феррари среди интерфейсов и имен их проектировщиков.
Кирилл,
Спасиб! Делал бы больше скриншотов для рассказов о текущих проектах, да до запуска не могу. Но скоро будет сразу два интересных рассказа о свежем 🙂
Юзабилист,
Это понятно, что его должно быть меньше. Но вы, похоже, не очень знакомы с задачей. Количество интерфейса зависит не только от желания проектировщика, но и от объема требуемой функциональности. В PMC функционала не просто много — его нереально много. Да и масштабы ведущихся в нем проектов не меньше.
Я писал, что это была первая фаза работы над продуктом. Для уменьшения тяжеловесности планировались персонализированные обзорные страницы, которые показывали бы только важное — я, например, не привел пример dashboard, но это был один из первых шагов. Но инструменты для работы со списками в 10 000 записей в любом случае должны быть. Эти базовые возможности и были сделаны в первой фазе. Скриншоты в публикации двухлетней давности — сейчас сделано многое из запланированного тогда. Например, работать с документами можно через обычный проводник операционной системы — реализована система версионного контроля, которая позволяет выгружать их.
RUP сам по себе процесс достаточно забюрократизированный, поэтому аскетизма какого-нибудь BaseCamp там будет крайне мало. Несмотря на всю любовь к 37 Signals, для водопадных проектов с километрами документации их продукты ни разу не подойдут. Почему системы на SAP до сих пор выглядят страшновато? Они идут в сторону упрощения, но очень непросто представить приборную панель самолета в виде калькулятора. Учитывайте не только вид системы, но и ее назначение и условия использования.
Гена,
Спасибо за поддержку! Тебе, как человеку каждый день работающему с PMC, лучше знать, удалась система или нет 🙂
Юра,
Просто как проектировщик, я представляю, каких усилий требует работа над системой такой сложности и как сложно найти баланс между требуемой функциональностью и простотой в использовании.
Гена,
Тем более приятно, что есть понимание 🙂 Я чуть выше в комментарии описал, что были планы сделать представления для конкретных ролей — тестировщиков, разработчиков, аналитиков, менеджеров и других. Поэтому много времени провел общаясь с руководителями таких команд. Это здорово упростило бы и вид, и процесс работы с системой. Жалко, я не доработал до этого времени, а в питерском офисе вакансию проектировщика открыть не захотели 🙂
Юрий,
к сожалению я наоборот слишком знаком с задачей ибо руководство проектом – это моя работа. Текущая среда – большой распределённый проект просто с огромным количеством функций. Больно видеть как колеги пытаются в MS Project или в других “программах” добиться хоть какого-то планирования и контроля, плюются и перестают пользоваться этими системами. В небольшом проекте с ними можно ещё как то работать, но небольшой можно спланировать и на салфетке.
Как раз для сложных проектов просто необходим простота интерфейса. Инструмент руководителя проекта должен уметь при минимальном количества входных данных дать своему пользователю _чувство_ правильности плана и текущего состояния проекта. Всё, больше ничего не надо. Что мы наблюдаем во всех без исключения системах это принуждения пользователя постоянно вводить сотни цифр с точностью до третьего знака после запятой (ну невозможно планировать работу разработчика в часах!) и получать за это какие-то графики, далёкие от реальности. Интерфейс для списков в 10000 значений – это интерфейс для робота, не человека.
В моей части проекта в данных момент несколько тысяч требований. После безуспешных попыток использования программных средств я тупо повесил на стенку специализированную магнитную доску с календарём и с помощью магнитных полосок распланировал рабочие пакеты. Люди, по сравнению с _таким_ интерфейсом все современные программные средства нервно кашляют с сторонке. В этом направлении и надо идти.
Юзабилист,
Вы говорите о гибких подходах к разработке. Это как раз то, к чему мы стремимся в той компании, где я работаю сейчас — agile-процесс отлаживается на двух крупных проектах, находящихся в разработке.
Но agile применим не во всех компаниях и не во всех проектах. И дело даже не в том, что его не так просто масштабировать и не в том, что с ним сложно работать распределенным командам — выходы из этих ситуаций есть. Часто и заказчикам, и исполнителям сложных и долгих проектов проще работать по RUP.
Поэтому не забывайте о задаче — инструмент предназначается для компании с водопадным процессом разработки. С планированием в MS Project и тоннами документации. Хорошо это или плохо — можно судить только взвесив альтернативные подходы. И учтя все особенности работы компании, не только технические, но и окруженческие — сертификации, кадры и т.п.. Для того чтобы простым был интерфейс системы проект-менеджмента, простым должен быть процесс работы над проектами.
Календари на досках — это один из способов степень визуализации всех тех 10 000 записей. Я использую такие вещи в работе и в ближайший месяц напишу о развитии этого решения — проектных досках задач (taskboards). Их мы хотим воплотить в новой версии нашей системы управления проектами. Но эти календари — только один из способов работы с тонной объектов, который не заменяет обычного списка. И они имеют смысл только если сам процесс построен гибко. А это уже тема для отдельного обсуждения.
Этот интерфейс не выглядит здорово. Я, конечно не в курсе конкретных сценариев использования и трудно оценить конкретные решения.
Однако. Интерфейс малоконтрастный, в нем много визуального шума.
(Сруз видно — вы не графический дизайнер)
Собственно все что видно — матроска из сеток, линий и плашек, которые можно смело убрать и соотношение сигнал/шум тут же увеличится. (Очевидно, вы не информационный дизайнер)
Такое большое количество форм, в которых практически не видно работы над текстом, что в таком интерфейсе принципиально. Я согласен с мыслью, что форма должна читаться как предложение (предложение — единица смысла), а элементы управления имеют свою синтаксическую роль в предложении.
Может быть вы пробовали написать текст, но вышло вот что:
Filter Editor for Task. Filter: My tasks. Add Filter, Copy Selected Filter (куда?).
File Name (* = Кхм), File type User defined.
Selected Simple. Select Advanced.
Rule. Rule: Open Task. Add Rule, Copy Selected Rule. (куда?)
(http://jvetrau.com/wp-content/uploads/2007/11/05-epam-pmc-htmlprototype-listtask-filtereditor.png)
+ куча ненужных линий создающих паузу.
Я постарался передать то как прочитают вашу форму, естественно я немного утрирую, однако понять что вы хотите сказать пользователю сложно, можно лишь догадаться по ключевым словам. Вы не использовали предложения, поэтому потеряли смысл.
Собственно я уверен, что все ваши формы можно переписать на человеческом языке и интерфейс станет незаметным и информативным. А пока доля смысла на количество элементов мала. (Тут может помочь Тафти)
Второе, что хочется подсказать. Попробуйте применить бритву Оккама ко всем элементам интерфейса. То есть попробуйте убрать линию. Потеряется ли смысл? А если другую? И так ко всем элементам. Вы обратите внимание, что без потери смысла можно убрать половину элементов оформления или больше. Вероятно вы скажите что интерфейс стал беднее, однако после этого, можно будет применить нормальную цветовую схему для выделения мыслей (потому что вы определитесь, что хотели сказать), можно будет обосновать какие цвета тут нужны. Определиться со шрифтами, определиться с модульной сеткой, со стилем. Правильно выделить ключевые слова полужирным и курсивом, наконец.
Таким образом что бы я сделал после разработки и изучения сценариев использования.
Определился бы и написал (!) что я хочу сказать пользователю.
Сверстал бы этот текст без всяких линий и ненужных плашек.
(если не очень с типографикой, перечитал бы Брингхерста и Чихольда) Подумал над типографикой и стилем. Придумал бы модуль для всех страниц. Выделил главные мысли, комментарии.
А элементы управления добавлял в соответствии с их синтаксической ролью (см. кажется у Горбунова в советах).
Мне кажется, стало бы лучше.
Сюдя по скриншотам статья более чем двух летней давности.
Gihar,
Двухлетней давности не статья, а описываемые в ней события. Соответственно, и скриншоты из первых рук — со стадии проектирования. В них тестовые данные и шаблонные названия. Внедренная версия и изменения за два года после запуска обновленной версии не показаны.
Илья,
Во-первых, спасибо за развернутый ответ 🙂 Но сразу оговорюсь — я не являлся визуальным дизайнером проекта. Моя роль в нем — проектирование интерфейса, то есть отрисовка wireframes и тесная работа с дизайнером, верстальщиком прототипа и разработчиками для того чтобы спроектированное превратилось в готовую картинку.
Насчет общего визуального шума. И соглашусь, и не соглашусь. Соглашусь, потому что многое действительно можно сократить. Не соглашусь, во-первых, потому что приведенный интерфейс — это гигантский скачок по сравнению с предыдущей версией. На полную переделку ушло бы слишком много времени, поэтому в первую очередь сменился концепт интерфейса. Я ищу ее скришоты и сегодня опубликую как апдейт к посту — сможете сравнить скачок.
Не соглашусь во-вторых, поскольку люди были не готовы к кардинальному изменению системы. Даже то что мы сделали уже было достаточно непривычно.
С новым концептом (я имею в виду обновленную структуру системы и отдельных страниц) дизайн можно менять поэтапно. Что мы и делали по ходу разработки — я специально привел последним скриншотом одну из рабочих версий. Еще раз повторюсь, как уже описал Юзабилисту — для того чтобы запустить такую масштабную систему сразу в идеальном виде, нужно потратить слишком много времени. За которое и требования могут успеть поменяться, и бюджет может уйти. Поэтому имеет смысл запускать такие проекты итерационно — сперва базовую версию, в которой реализован основной концепт и важнейший функционал. Затем работать напильником чтобы срезать углы. И еще — над новыми представлениями, чтобы упрощать доступ к информации и ее восприятие.
Насчет названий полей — на скриншотах тестовые данные и типовые страницы, над названиями в конкретных формах и списках шла отдельная работа.
На первом этапе важнее целостность системы и возможность развивать ее. А бритву Оккама лучше применять на последующих. В такой системе тысячи моментов, которые нужно предусмотреть. Небольшой команде стоит такую задачу разбить на несколько этапов — от ключевых проблем к локальным. Что мы и сдедали в работе.
Раздел I. Цели.
У меня сложилось странное впечатление, что предназначение инструмента – это мешать работе проектной команды. Ощущение это возникло после анализа и “основных” видов деятельности. Смотрите:
— Цитата ———————————————
1. Исполнители. Участники проектных команд, которым нужно выполнить поставленные задачи и отчитаться об отработанном времени. Реже — поставить задачу коллеге по проекту на основе дефекта (бага) или требования.
———————————————–
Я всегда полагал, что основное назначение подобного инструментария по проекту – это получение оперативной и постоянной информации инженерами проектной группы. К ним, в частности, относятся:
* концепция проекта
* прецеденты
* дефекты
Часто подобные системы создаются для упрощения прослеживаемости между элементами разных артефактов. Иногда (как бактрекер) для упрощения работы с элементами одного артефакта.
У вас же получается, что основная задача этих инженеров – написание отчетов о проделанной работе. Если это так, то сама идея создания инструмента для эффективной работы уже убита напрочь.
— Цитата ———————————————
2. Менеджеры. Руководители проектов или команд разработчиков. Они ставят задачи и контролируют их выполнение, смотрят отчеты по ходу проектов и использованию ресурсов.
———————————————–
Странно. А я вот думал, что по настоящему хороший руководитель по определению должен знать состояние дел. И получает он эту информацию отнюдь не из отчетов. Если конечно он хороший руководитель. Кстати, основная задача руководителя не в “постановке задач и контроле их выполнение” и уж тем более не в “просмотре отчетов по ходу проектов”. Кстати, так думаю не только я, но и Демарко, Листер, Коберн, Йордан. Или, если хотите наших профи то, Ашманов, Мусаев, …
— Цитата ———————————————
3. Высшее руководство. Начальники отделов и направлений, директоры. Этой группе важна высокоуровневая отчетность — как идут проекты в целом по компании, на каких этапах возникают “провисы”.
———————————————–
И это бессмысленная работа.
А где, простите, управление портфелем проектов, рисками, персоналом наконец? Если уж подключать топ менеджмент к этой системе, то эти функции нужно реализовывать.
Раздел II. Платформа.
Выбор AJAX мне кажется, как минимум, сомнительным. Сравнение стоимости реализации проекта на разных платформах проводилось?
Раздел III. Функционал и атрибутивные наборы.
Ничего не скажу, тут работать надо.
==================================
С уважением,
Сергей Мартыненко aka SALar
Сергей,
Отвечу по пунктам:
Раздел I. Цели
В компании, которая использует PMC, построен сильно формализованный RUP-процесс (можно его и бюрократическим назвать отчасти). Компания, как и многие другие крупные офшоры, предполагает взаимозаменяемость ресурсов. Поэтому разработчикам не всегда важно болеть душой за проект — работа часто разбита на небольшие конвейерные участки и исполнителю не особо важна концепция. Это не хорошо и не плохо — такая у компании модель. Поэтому исполнителю и вправду нужно в основном отчитываться об отработанном времени, а руководителю проекта — об освоенном бюджете. В случе выхода за рамки бюджета — расширять его. Хотя обычно он и так имеет хороший запас. И это тоже вполне жизненная бизнес-модель. Поэтому здесь эффективностью работы конкретных участников проктных команд — далеко не главный для успешности компании.
Да и в целом вы не совсем так поняли посыл абзаца — это не цели, а задачи пользователей при работе в системе. Которые как раз помогают в достижении целей. Эффективным или нет образом — это уже другой вопрос. Опять же повторюсь о специфике конкретной компании, под которую заточена система. А топ-менеджмент использует другие корпоративные веб-приложения — в EPAM их наберется с десяток.
Раздел II. Платформа
AJAX используется в системе точечно, поэтому сложно говорить о его выборе. Просто помогает в отдельных моментах. Сама система работает на BEA WebLogic и Oracle.
Раздел III. Функционал и атрибутивные наборы
Не совсем понял посыла 🙂
>Красинский Илья
Коллега, от части согласен с вашим комментом в отношении лишних деталей и недостаточного контраста, но это “заслуга” самой компании, как заказчика. Непонятно мне только, зачем разбрасываться такими умными (порой неуместными) терминами, когда можно все на котиках доступно объяснить. Кроме того, непонятно, зачем необдуманно, в данном случае, пудрить человеку мозги книгами по “книжной” типографике. Насколько я помню, заслуги тот же Чихольда были исключительно в книжной верстке, да и помер он так и не увидев ЭВМ в своей жизни. Дело даже не в ЭВМ и не в Чихольде, а в том что прочти сейчас Юра эти книги, мало что тут исправит. Типографика типографикой, но это как печнику советовать читать книги по отделке фасадов зданий.
2Juras Vetrau: Если еще актуально отвечать на Ваш вопрос 🙂 – то слышал в основном положительные отзывы. Сам являясь руководителем проектов скорее слегка завидовал пользователям PMC, поскольку всегда тяготел к системам, которые учитывают все – от выписки больничных до ведения договоров и управления требованиями, предоставляя при этом средства контроля ведения проекта для руководителей от заказчика.
Отличные комментарии (несмотря на негативную окраску) – тот случай, когда комменты не менее полезны, чем сам материал. О многом захотелось задуматься.
По поводу интерфейса этого блога. Выходит, галочка, которую я в прошлый раз поставил, не работает. Щас поставлю вторую галочку. Будем надеяться, после этого я начну получать комментарии на E-Mail.
Хотел написать длинный-предлинный пост, но время не позволяет.
Скажу так:
1. PMC ужасен, интерфейс плох.
2. Юра и другие замечательные люди сделали все, что могли, чтобы PMC стал лучше, у них это получилось.
3. При оценке тех или иных вещей надо учитывать окружение и требования, в рамки которых были поставлены разработчики и дизайнеры. Так сказать, есть такая фраза у дизайнеров: “не пизди своим ребятам”.
Всем, кто обсирает интерфейс, просьба: пришлите варианты своих работ, так сказать тех, за которые вам не стыдно. Я напишу рецензию.
Максим,
Соглашусь со всем, кроме первого пункта. Плох не PMC, а внутренний процесс EPAM. Точнее, не то чтобы плох, просто построен на количестве проданных часов имеющихся ресурсов. Причем старается поднимать не эффективность использования текущих ресурсов, а тираж человекочасов. А это не всегда приятно для сотрудников. И это очень даже работающая бизнес-модель, которая хороша для многих ее участников.
PMC — отражение процесса EPAM. Невозможно поменять внутреннюю структуру компании. Но здорово упростить жизнь ее сотрудникам можно. Это замечание даже не тебе, а посторонним читателям — ты и так все видишь 🙂 Так что за второй пункт отдельное огромное спасибо 🙂
Lamer,
Отвечать никогда не поздно 🙂 Здорово, что есть интерес к системе — она и вправду мощная и перспективная, пусть и имеет шероховатости постоянного развития. К этому постингу обещал отписаться продукт-менеджер PMC Энвер Эмди — он лучше всех расскажет о системе и процессе ее разработки.
А комментарии и вправду вышли на славу 🙂 Система местами спорная, но при такой трудоемкости задачи альтернативных путей решения всегда огромное множество. Да и то ли я описал недостаточно понятно, то ли сами комментаторы не вчитывались в текст, но многие не учли специфики компании-заказчика, процесса под который заточен PMC и других деталей. Система делалась для вполне конкретных сотрудников конкретной компании и здорово облегчила жизнь им.
P.S. Над механизами работы блога предстоит серьезная работа — пока что основные усилия вкладываются в контент 🙂
«…я не являлся визуальным дизайнером проекта…»
В том то и беда, что человек проектирующий не владеет графическим и информационным дизайном. А дизайнер работает маляром. Это крайний случай порочной болезни роста, надеюсь скоро это закончится. Специализация и конвейер (детище Форда и наследник постройки суэцкого канала) работают в простых, детерминированных областях.
Можно предполагать, что в одной команде универсалов, есть люди у которых получается что-то лучше.
Очевидно автор — юзабилити специалист. Не хочу разжигать холиваров. Наверное вы видели развернутый комментарий Артема Горбунова http://www.artgorbunov.ru/bb/soviet/20071108/. Лучше я не скажу. Особое внимание заслуживает список книг в конце.
>S-Sanytch
Вы напрасно считаете, что с появлением компьютеров, типографика перестала существовать, потому как принципы чтения не изменились.
Боюсь вы превратно понимаете типографику как украшательство текста, когда ее задача упростить передачу смысла, сделать работу более информативной. Язык типографики крайне богат для предачи нюансов, акцентов, а методы тоньше, чем линии, плашки. Не видел еще ни одного интерфейса который бы проиграл от осознаной работы с текстом, предложениями, словами.
Тех кто особо не согласен, прошу не засорять комментарии и писать на почту, особенно если хочется перейти на личности.
Илья,
Еще раз поблагодарю за развернутый комментарий. Но вот что плохо — вы делаете основную ставку на визуальный дизайн, а он в таком проекте не самый важный критерий успеха. Как бы это не было обидно визуальному дизайнеру. Я не стараюсь задеть, подчеркивая слово “визуальный”, но вы говорите практически только об этих качествах.
Статью Горбунова я как раз недавно видел, но это все опять терминологические споры. А поскольку все профессии постоянно развиваются, эти споры не закончатся никогда, так что я постою в стороне. Горбунову удобнее называть дизайном весь процесс, я для себя разделяю его на архитектуру всей системы, проектирование (структуры и взаимодействия) отдельных функций и их визуальный дизайн.
Есть конкретные потребители продукта — будь то визитка, веб-почта или мотоцикл. И их мало интересует, сделан продукт с помощью дизайна, юзабилити или векторного анализа. Удовлетворяет потребности — практические, эстетические и все остальные, которые потребителю важны — и хватит. Поэтому я скорее менеджер проектов, стремящийся обеспечить хорошие пользовательские, технические, маркетинговые и другие качества продукта, а не юзабилист. Юзабилити — это одно из качеств продукта. Важное, но не ключевое, да и плюс пересекающееся то тут, то там с другими дисциплинами.
Я не зря расписал в материале о тех людях и их задачах, на улучшение эффективности работы которых был сделан упор в первой фазе проекта. Попробую описать те задачи (и качества), от которых зависел успех проекта (в порядке убывания важности):
Для успеха первых двух задач основная работа идет над информационной и системной архитектурой. Проектирование и визуальный дизайн подключаются при работе над 3, 4 и 5 задачами. Причем визуальный дизайн имеет основное значение только на пятом, а на остальных — дает к хорошему результату процентов 30. Мало того, поскольку система используется повседневно, пользователи привыкают к ней. И даже если она будет черно-белой с парой оттенков — к ней привыкнут. Но если для добавления объекта нужно пройти пять страниц вместо одной — это будет замедлять работу каждый раз. Я не говорю, что нужно плюнуть на оформление. Но важно знать, что нужно делать в первую очередь, а что может подождать.
Замечание насчет работы дизайнера маляром неверное. Да, он не занимался основным проектированием системы. Но если у него были предложения по переделке тех или иных вещей — они принимались. И такие предложения шли постоянно — и внедрялись не менее часто. У нас не конвейер — каждый специалист владеет смежными знаниями. И хотя может и должен влиять на работу соседних задач, отвечает все-таки за свой участок. Давайте я расскажу вам о структуре команды, а вы расскажете, каким образом все могут делать все и что из этого получится? Итак, дано:
Задача: начав в августе, к апрелю следующего года запустить новую версию системы в эксплуатацию. Общие требования к системе в начале моего комментария. Не забываем про контекст использования системы — в компании водопадный процесс управления проектами. Типовая команда включает группы управления (менеджер и координатор проекта, 2-3 тим-лидера), аналитики и дизайна (2-4 бизнес-аналитика, дизайнер), разработки (10-50 программистов, 1-2 верстальщика), тестирования (5-15 тестировщиков) и вспомогательную (поддержка, консультанты по нагрузке, безопасности и т.п.).
Максим Гулевич не зря так нервно ответил — он уже много лет руководит отделом в EPAM и как никто знаком со спецификой работы компании. Поэтому странно слышать оторванные от контекста замечания. А ведь основная задача и дизайнера, и проектировщика — сделать продукт для конкретных потребителей в конкретных контекстах работы.
P.S. Скриншот предыдущей версии пока не обнаружился, но мы работаем над этим 🙂
Юра,
интересная статья, отменное обсуждение в комментах.
Так держать 🙂
/Костя
Костя,
Спасибо за отзыв! Когда есть много способов решения проблемы, те кто их увидел обязательно расскажут об этом 🙂
Юра,
не плохая статься, чтобы показать над какими проектами тебе приходилось работать на ЕПАМе. Я свалил до выхода 5-й версии, но поработал на предыдущей версии. Могу всех сомневающихся заверить, что работа по усовершенствованию PMC может быть только титаническая. Судя по скриншотам, вы многого добились!
P.S. (на некоторых screenshots) – warning: this document contains confidential information which is epam systems property. content can not be used or disclosed without prior written consent of the owner 😉
Женя,
Спасиб! Я знаю, что те кто ощутил разницу между 4 и 5 версией оценят сделанное 🙂
Ну а насчет NDA — я несколько раз пообщался с Энвером перед публикацией — так что вроде как ничего не нарушаю 🙂 Хотел бы рассказать еще и про Cost Tracking Center, сделанный на базе PMC 5, но там уж точно меня побьют 🙂
Юра, респект 🙂
Объем проекта конечно завораживает, но хотелось бы больше конкретики – где и какие солюшны ты и другие проектировщики придумали на основе анализа деятельности разных ролей (отделов).
Понимаю, что много воды утекло, но ведь что-то в памяти должны было остаться 🙂
Саша,
И тебе спасиб за хорошие слова! В памяти осталось все, да только мы на том этапе занимались скорее общим концептом новой версии, а конкретными функциями — во вторую очередь. Так что вот даже не знаю, о чем рассказать 🙂 В самом материале есть пример про редактор фильтров — это то что нужно? Если да — распишу еще про несколько функций 🙂
Статья интересная, но я так и не понял, почему и в ней и в комментах походя ставится знак соответствия между RUP и водопадом.
Это серьёзно подрывает доверие к автору.
2Денис: Возможно это оговорка по фрейду 🙂 И на самом деле в Epam – водопадная Методология, а не RUP 🙂
Денис,
Да, есть момент путаницы с понятиями, но без злого умысла. Дам немного пояснений, чтобы вернуть доверие 🙂 Проект заточен под специфику компании, которая на тот момент имела CMMI 4го уровня и готовилась сертифицироваться по 5му. Внутренний процесс формализован в соответствии с RUP. Большинство проектов идет либо одним большим водопадом, либо разбиваются на несколько крупных фаз (от нескольких месяцев), каждая из которых идет своим маленьким водопадом. Поэтому для этой конкретной организации можно поставить знак “почти равенства” 🙂
Я ушел из EPAM почти два года назад, так что процессы могли поменяться. В принципе, слова про водопад из статьи можно было вообще опустить — важнее помнить о привязке к RUP для того чтобы охватить в системе все нужные этапы. И то что проекты планируются и управляются централизованно — поэтому акцент в PMC сделан на то чтобы ничего не забыть, а не на обеспечения гибкости.
Ну и в целом я попытался описать и систему, и процесс работы над ней с как можно большего количества сторон. А в этом случае приходится обобщать и идти по верхам. Если, конечно, не бояться утомить читателя многотомным трудом 🙂 Поэтому здорово что в комментариях спрашивают про конкретику — так материал получится более полным.
Наконец-то ты опубликовал скриншоты. Система, конечно, сделана программистами для программистов, но в общем свои задачи решает и хорошо.
Еще раз повторюсь, всем, кто хочет попробовать себя в качестве проектировщика в ЭПАМЕ – предлагаю работу.
Саша,
Наконец-то появился повод для их публикации 🙂 Система да, для программистов — но как иначе, если процентов 80 сотрудников компании — программисты и тестировщики? Они и правят бал 🙂 И официально, и неформально. Потому и в задачах акцент — не гибче, а четче 🙂
Спаси нас от 26-летних проджект менеджеров.
Den,
Хотелось бы в таком случае узнать, что вы понимаете под проект-менеджментом. Также не очень понятно, почему определяющим для специалиста является возраст, а не профессиональный опыт и человеческие качества.
Ну и не стоит свой негативный опыт распространять на всех.
Спаси нас от людей, которые судят о знаниях специалиста по его возрасту.
“Внутренний процесс формализован в соответствии с RUP. Большинство проектов идет либо одним большим водопадом, либо разбиваются на несколько крупных фаз (от нескольких месяцев), каждая из которых идет своим маленьким водопадом.”
Юра, итерационная демонстрация результатов работ, которая достигается за счёт применения итераций фиксированной длительности – это один из 6 ключевых принципов RUP:
http://en.wikipedia.org/wiki/Rational_Unified_Process#Six_Key_Principles_of_Business-Driven_Development
Если нет итераций – то какой же это RUP?
Ещё раз – если есть итерации – то это уже НЕ водопадный процесс.
Если итераций нет – то это уже НЕ RUP совершенно точно.
См. http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Iterative_and_incremental_development
Денис,
Я, кажется, понял в чем проблема — терминологическая. Точнее, в самом термине “итерационный”. Сейчас мы в компании внедряем agile-методики, поэтому понятие итерационности я сейчас воспринимаю именно в ключе гибких процессов ведения проектов. RUP — вещь достаточно гибкая, которая и для водопадной, и для итерационной разработки подойдет. Есть отличная статья по этому поводу на сайте самого IBM — в самую точку этого терминологического спора. Но суть итераций в agile и RUP разная, поэтому и непонимание из-за разницы терминологий.
Если пойти дальше — можно изловчиться и agile-методики вести, используя RUP. RUP скорее всего будет развиваться и дальше, включать в себя практики гибких методик. Но что тогда понимать под RUP? Я для себя выбрал определение как водопад или много водопадов. Из статьи это не очень понятно, так что за это прошу прощения.
Честно скажу. Хуже PMC может быть только CTC. Очень бы хотелось, чтоб этот кошмарный ужас все же когда-нибудь рухнул под собственной тяжестью.
Валерий,
Большой организации — большая и сложная система. Хотя ее здорово перегрузили функциональностью в процессе развития.
Система впалне организации рабочего места – то есть управление процессом разработки (проставление времени и тд) для обычного разработчика действительно очень хорошая (работал на епаме и пользовался). Сейчас пытаюсь на текущем месте работы проектировать чтото подобное, некоторые элементы уже “позаимствовал”. Но в силу того, что сам процесс отличается, то и система будет принимать другой вид. Но PMC – для епама достаточно хорошая и продуманная система.
Павел,
Спасибо! Система получилась интересной, хотя ее нужно с оглядкой переносить на другие компании — PMC заточена под большие организации с достаточно жестко заданным процессом, для средних и небольших команд стоит делать продукты полегче.