Переход со связки “Visio+Photoshop” на “Fireworks+Fireworks”

Первая презентация — “Проектирование страниц интерфейса в Adobe Fireworks” от Александра Хмелевского — пройдет в эту пятницу, 31 октября, в рамках User Experience 2008 (начало в 12:30 в зале №2). Переход нашей компании с Visio на Fireworks — это отдельная тема, по которой скоро будет много интересного в моем блоге. Продукт Adobe имеет почти все лучшее из Visio, но делает это удобнее и быстрее. Не говоря уже о том, что он просто лучше заточен для работы с графикой и вебом.

Еще приятнее то, что Fireworks позволяет проектировщику, дизайнеру и верстальщику работать с одним единым инструментом. Со всеми вытекающими отсюда последствиями — повышением скорости и качества, уменьшением количества ненужных операций и ошибок, единой базой наработок и паттернов. Поэтому параллельно идет еще один переход — с Photoshop на Fireworks, хотя и без полного отказа от первого. Кстати, мастер-класс о том как строится совместная работа проектировщика и дизайнера проведут на “РИТ: Клиентские технологии” Александр Хмелевский и Лев Эйдинов. Точная программа еще неизвестна, но сама конференция будет проходить 8 и 9 декабря.

Опыт работы над проектами

Через пару недель состоится еще одна профессиональная конференция — World Usability Day 2008. На ней заявлен мой доклад “Опыт работы в различных форматах юзабилити-команд. Разности, сложности, возможности”. За последние несколько лет мне удалось поработать в различных компаниях. В каждой из них набор участвующих в проектировании ролей и поставленных перед ним задач здорово отличался, что давало в результате совершенно разные процессы и подходы к работе.

Очень часто все это было далеко от книжно-идеалистических представлений о правильном подходе к проектированию. Но в каждом процессе хватало инструментов для того чтобы повлиять на конечный продукт. Будет здорово, если рассказ поможет начинающим специалистам понять куда и зачем идти. Дата и программа конференции еще не определены, но стоит ориентироваться на празднование Всемирного Дня Юзабилити. Это 13 ноября, четверг (программа мероприятия — мое выступление в 14:20).

Вторая презентация пройдет в рамках “РИТ: Клиентские технологии” и тоже будет посвящена практическому опыту. Здесь я расскажу case study о том, как мы проектировали деловой портал BFM.ru. Сам процесс работы начался достаточно нетипично для нас — вместо предварительного сбора и формирования требований, мы сразу ринулись “в бой” и достаточно быстро получили интерактивный прототип портала.

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

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

 P.S. С User Experience ведется онлайн-трансляция, куда попадет и выступление Александра Хмелевского. Его можно увидеть 31 октября в 12:30 на сайте организаторов конференции.

Работы по проектированию делятся на 4 этапа — сбор и анализ требований, детальное проектирование страниц, визуальный дизайн, создание интерактивного прототипа. Первый этап имеет пару четко определенных вариантов, которые достаточно стандартны для всех проектов. А вот остальные три сильно зависят от планируемого набора функциональности и сложности бизнес-логики. Здорово, если у клиента уже есть хотя бы набросок технического задания. Если его нет, по крайней мере в черновом и кратком виде спецификации нужно набросать.

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

Для расчета по этому алгоритму используется набор метрик, собранных и отточенных на основе опыта работы. Это нормы выработки (например, сколько часов в среднем проектируется одна страница), принятые объемы работ (сколько часов занимает работа над дизайн-концептом или какой процент спроектированных страниц реализуется в интерактивном прототипе), коэффициенты рисков, фиксированные единицы (стоимость часа работы менеджера или курс доллара). Метрики могут корректироваться со временем, но их общий порядок сохраняется.

Некоторые из метрик вызывают у многих удивление: “Как вы можете говорить, что проектирование любой страницы занимает ровно X часов?!”. Но практика работы показывает, что если взять общие трудозатраты на проектирование страниц и поделить их на количество страниц, получаются как раз эти самые X часов. Хотя цифры могут серьезно поменяться в случае заметных корректировок в самом процессе работы. Плюс метод не работает при очень малом количестве страниц в проекте.

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

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

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

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

Инфоканалом тут могут быть почта, телефон, личные встречи, браузер, мессенджеры. По ним передаются разные типы “сообщений”:

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

С телефоном, мессенджером и личными встречами справляется методика стикеров. А вот с почтой и браузером налажены свои способы работы.

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

Почта

Почта — один из главных источников задач. Какие-то из них можно сразу ставить в план работ, какие-то требуют предварительного уточнения, для многих решением задачи является просто ответ на само письмо.

Давно и с удовольствием пользуюсь MS Outlook. Это больше чем почтовик — отличнейшее средство продуктивности, связанное с не менее чудным календарем и адресной книгой. А вместе с плагином Xobni, собирающим всю корреспонденцию по контакту, полезность Аутлука еще выше. Ему пока не хватает нормального поиска, но хорошая система категоризации и хранение писем на Gmail (где можно найти сильно потерявшееся письмо) решает большую часть проблем.

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

Кстати, о категориях. Метод предполагает активное складывание всего и вся в архив. А значит нужна удобная система папок в почтовом ящике, чтобы знать куда положить ненужное письмо и где его потом найти, если оно вдруг понадобится. В моем Аутлуке три группы директорий — рабочая проектная и непроектная информация, а также личная переписка. В каждой из них из них — поддиректории, большинство из которых пронумеровано вдобавок к названиям, от более важных к реже используемым. Так легче ориентироваться в них, чтобы потом находить нужное “на ощупь”.

Предыстория вопроса

(Этот кусок можно пролистать)

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

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

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

Браузер

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

• Del.icio.us“>Del.icio.us для всех сайтов и материалов, к которые еще пригодятся позже;
• Vi.sualize.us“>Vi.sualize.us для полезных и интересных изображений;
• Plurk для скоропортящейся информации — забавной, но вряд ли понадобящейся потом;

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

Управляться с работой помогают и другие инструменты, но связка стикеры/ежедневник/таск-менеджер вместе с почтой и браузером — ключевые элементы методики. За год она здорово поменялась и развилась — появлялись новые обязанности, менялся формат работы. Будет интересно написать о ней еще через год — возможно, придется снова адаптировать ее к грядущим изменениям.

P.S. Кстати, все изменения методики за прошедший год сохранились на фото. Вот как менялся инструментарий:

Пробковая доска

первая версия	расширенная первая версия. заснято в момент, когда схема приказала долго жить — методика отстала от времени	текущая версия

Маркерная доска

первая версия	расширенная первая версия	вид “проекты” / “типы задач”
вид “проекты” / “горизонт планирования”	вид “проекты” / “горизонт планирования”	текущая версия

Все части материала:

• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 1. Проблема
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 2. Решение
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 3. Вспомогательные инструменты

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

Есть три инструмента, которые помогают управляться с задачами — цветные стикеры, ежедневник и онлайновый таск-менеджер Acunote. Каждый из на своем уровне детализации и со своей частотой использования помогают выстраивать рабочий процесс.

Цветные стикеры

Разноцветные клейкие стикеры минимального размера — основа текущего процесса. С этого, в общем-то, и начиналась прошлогодняя версия методологии. На листке писалось краткое описание действия, например, “проектирование каталога” или “написать КП” (коммерческое предложение), а сам он клеился в нужном пересечении матрицы “проект” (строка) / “день недели” (столбец) на пробковой доске. Если задачу не успевалось сделать в назначенный срок, она легко переклеивалась на другую “клетку”.

Но делалось это при растущем потоке дел постоянно и такая постоянная перетасовка подрывала веру в победу. Да и сама доска хотя и находится на расстоянии вытянутой руки, в прямом поле зрения во время работы находится не она, а компьютер. В общем, методика не удовлетворяла описанным в первой части 2 и 3 обязательным пунктам, поэтому периодически приходила в заброшенное состояние.

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

Сам принцип записи на мини-листках почти не поменялся — разве что в углу сейчас пишется проект, к которому относится задача. А вот классификация теперь идет по 3 “слоям”:

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

Что дальше? Задачи с горизонтами “на этой неделе” и “в ближайшие месяцы” расклеиваются по матрице на пробковой доске, где строки — это срок, а столбцы — тип задания. Те, у которых горизонт “завтра” — лежат на столе рядом с ноутбуком. Если что-то делается сегодня — стикер приклеен между клавиатурой и экраном лэптопа. Тот листок, которым я занимаюсь сейчас, висит рядом с тачпадом — так, чтобы взгляд всегда падал на него. По ходу работы выполненные задачи складываются в стопку завершенных, а если у какой-то из них меняется срок — листок переклеивается в нужный “стек” задач.

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

Хотя я и стараюсь максимально отвязаться от конкретных дат, для запланированных на четкое время и число событий используется календарь в MS Outlook и таск-менеджер. Но об этом ниже.

Ежедневник

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

Проблему решил простой ежедневник. В нем записывается повестка дня — список проектов, которыми нужно заниматься, и общая суть дел по каждому из них. Отчасти это дублирует стикеры, но только в упрощенном виде, чтобы напомнить о них. Например, если на сегодня по проекту ACME^TM назначены задачи “проектирование каталога”, “проектирование личного кабинета”, “проектирование рассылок”, то в ежедневнике будет записано “ACME — проектирование”.

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

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

Таск-менеджер

Раньше мне на все про все вполне хватало работающего в браузере таск-менеджера — дополнительные уровни планирования появлялись только из-за роста потока задач. Сейчас дел на порядок больше, но это не повод совсем отказываться от автоматизированных сервисов. С начала года мы активно пользуемся веб-приложением Acunote. Его главные плюсы такие же как и у системы стикеров — гибкость и легкость. Сервис заточен под agile-подходы к ведению проектов, хотя ничто не мешает пользоваться им и для классических методов.

Свои задачи я в нем уже практически не веду. Не из-за лени — основной средой должна быть какая-то одна, и у меня это метод стикеров. А вот для постановки заданий коллегам по отделу Acunote в самый раз. Причем в последнее время мы переходим на самоконтроль — большую часть задач они выставляют себе сами. Я эти списки проверяю и пишу на их основе отчеты клиенту.

Сами работы ведутся по итерациям — из общего списка задач на проект выбираются первоочередные в том количестве, которое можно успеть за неделю (или две, в зависимости от договоренности с клиентом). Работа маленькими кусочками позволяет гораздо лучше понимать, как мы движемся по плану. Да и в целом процесс идет динамичнее, когда делается несколько мини-проектов вместо одного большого.

Acunote также используется как общий инструмент между нашим отделом и командой разработки. Это в основном задачи по поддержке и доработкам того что мы спроектировали ранее. При работе над прототипами используем Trac как баг-трекер, но это уже частные случаи.

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

Все части материала:

• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 1. Проблема
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 2. Решение
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 3. Вспомогательные инструменты

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

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

К той методике, которая бы работала и не ломалась, есть несколько требований:

1. Доступность в любой момент. Минимум специального ПО, все должно по возможности делаться подручными средствами. Записать что-то важное и срочное должно быть возможно без особых усилий и сложных инструментов.
2. Гибкость. Формат записи не должен накладывать особых ограничений. Важно, чтобы в спешке можно было за пару секунд в любой понятной форме пометить, что именно нужно не забыть. Как только появляются какие-то четкие правила классификации, время на запись каждой задачи увеличивается. Нагрузка на осознавательный аппарат при этом тоже растет, мешая всему остальному. Кроме того, быстро появляются исключения из классификации, что ломает стройную систему и вгоняет в еще большие ступоры.
3. Наглядность. Список задач должен быть всегда на виду, в любое время. Если он запрятан в какой-то программе, ее нужно постоянно запускать или переключаться к ней. Это лишнее действие, на которое во многих случаях просто нет времени, а значит появится желание сэкономить. Либо просто не будет возможности сделать его — компьютер не всегда под рукой и не всегда включен.
4. Минимальное количество списков задач. Важно, чтобы не нужно было мысленно склеивать несколько задачников — это лишняя нагрузка, на которую часто нет времени, и которая со временем заставит плюнуть на такую сложную методику. Основным лучше считать только один такой список, все остальные должны быть вспомогательными.

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

Исходя из количества и частоты уделяемого времени, мои задачи поделились на 4 типа. Список выстроился в порядке убывания необходимости держать руку на пульсе:

• Управление проектами и аккаунт-менеджмент. Сюда входят:
  • Первоначальное планирование работ по проекту;
  • Постановка задач коллегам и контроль их выполнения;
  • Отслеживание хода проекта и внесение изменений в планы, если это необходимо;
  • Общение с клиентом по возникающим в ходе работы вопросам;
  • Отчетность клиенту по завершению этапов работ;
• Проектирование интерфейсов. В рамках этих работ делаются:
  • Анализ предметной области, рынка и целевой аудитории;
  • Проектирование конкретных страниц и элементов интерфейса;
  • Написание спецификаций и других сопроводительных документов;
• Продажи. Это:
  • Предварительная оценка сроков и стоимости работ;
  • Подготовка коммерческих предложений и договоров;
  • Напоминание клиенту о необходимости подписания документов и оплаты счетов;
• Развитие отдела проектирования. Работа включает:
  • Стратегическое планирование развития отдела;
  • Планирование бюджета и контроль его исполнения;
  • Поиск сотрудников и работа с ними;
  • Маркетинг отдела;

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

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

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

Все части материала:

• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 1. Проблема
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 2. Решение
• Персональная продуктивность. Методика работы с большим потоком разнородных задач, часть 3. Вспомогательные инструменты

Про выстраивание процесса проектирования с учетом интересов команды разработки я недавно писал. В третьей части материала как раз говорится о том, как мы пытаемся решать проблему сроков. Эту же темы мы с коллегами поднимали в апрельском выступлении на конференции РИТ-2008.

Если вкратце, то вся работа разбивается на три части — концепция, интерактивный прототип и поддержка спецификации. Для каждой из них в идеале заключается свой договор, идущий по разным методикам. Концепцию удобнее прорабатывать по классической схеме с четким календарным планом. Интерактивный прототип бывает проще создавать в agile-процессе. Правда, такой подход годится не для всех проектов — в основном там, где важнее функциональные, а не потребительские качества продукта. Поддержку спецификации удобнее вести по чистому agile, но иногда удобнее иметь готовый пакет документации сразу, сделав все одним махом без всяких итераций.

Хочется расписать эту схему подробнее. Для начала важно понять, что вообще важно во всем этом деле заинтересованным лицам проекта — заказчику, разработчикам, проектировщикам:

1. Клиента интересует скорость выхода продукта на рынок. Важно узнать, когда и какие ключевые даты запланированы у него — официальный запуск самого продукта, отчетные точки для инвесторов, рекламные кампании и т.п. Это позволит гибче и лучше спланировать работы по проекту.
2. Крупные проекты обычно ведутся в условиях постоянного изменения требований. А значит разработчикам нужен такой процесс работы над проектом, который не заставит их отвечать за ошибочное планирование, съедающее нервы и внеурочные часы. Планы бывают чересчур оптимистичны не от недостатка квалификации — часто бывают нужны серьезные предварительные технологические исследования и испытания для того чтобы оценить трудоемкость функциональности. Которые здорово затягивают старт работ и, соответственно, выход на рынок.
3. Всех троих волнует качественная и глубокая проработка потребительских качеств продукта — в основном это касается интерфейса. Клиенту нужен успешный продукт; проектировщикам — интересный проект, за который потом не будет стыдно; разработчикам — стройная и целостная система, которая не расползется по швам с последующей тонной доделок.
4. Для обеспечения таких качеств важна полная и в то же время легко читаемая и поддерживаемая спецификация требований к продукту, своевременно обновляемая. Разработчикам она даст основу для планирования и уверенность в том, что они работают над тем, что нужно; проектировщикам — возможность проследить за качеством системы.
5. Проектную команду, не связанную непосредственно с разработкой, интересует равномерная загрузка. В первую очередь это касается проектировщиков. В идеале, конечно, они должны быть доступны по первому зову. Но если речь идет не о полностью посвятившей себя проекту компании, а о коммерческой организации, которая предоставляет услуги по проектированию, нужно планировать работу так чтобы и успевать все без авралов, и без дела не сидеть.

Определяющий здесь — первый пункт. Исходя из задач клиента мы определяем ключевые вехи, которые говорят что к “такому-то числу должно быть готовы такие-то вещи”. Под них строится и весь процесс работы. Он может отличаться в каждом конкретном случае, но в целом придерживается следующей схемы. Которая при этом удовлетворяет и остальным пунктам списка:

Этап 1. Pre-Sale

1-2 недели (хотя случается и полгода, и год)

Отдел проектирования

Предварительный анализ проекта, описание объема работ, оценка сроков и стоимости работ.

Документы

• коммерческое предложение;
• договор на проработку концепции.

Отдел разработки

Предварительная оценка сроков, трудозатрат и рисков проекта.

Документы

• нет формализованных документов.

Этап 2. Сбор требований и проработка концепции

2-4 недели

Отдел проектирования

Бизнес-анализ и сбор требований. Планирование работ по детальному проектированию.

Документы

• видение проекта;
• описание целевой аудитории;
• краткие сценарии взаимодействия;
• перечень функциональности;
• карта сайта;
• черновые структурные схемы страниц;
• договор на детальное проектирование бета-релиза;
• перечень функциональности бета-релиза;
• перечень функциональности финального релиза;
• устав проекта.

Отдел разработки

Выбор технологической платформы, планирование работ, сбор команды.

Документы

• план работ по разработке;
• оценка рисков;
• эксплуатационные требования;
• договор на разработку альфа-релиза.

Этап 3. Интерактивный и функциональный прототип (альфа-релиз)

1-2 месяца

Отдел проектирования

Детальное проектирование и дизайн интерфейса, создание интерактивного прототипа, сбор требований. Описывается функциональность, которая должна войти в бета-релиз.

Документы

• структурные схемы страниц;
• дизайн-макеты страниц;
• интерактивный прототип;
• атрибуты и методы сущностей;
• критерии приемки функциональности;
• договор на детальное проектирование финального релиза.

Отдел разработки

Разработка альфа-релиза продукта (ядро + модули без дизайна) по договору с фиксированной ценой и сроками.

Документы

• функциональный лист (backlog);
• отчетность о ходе проекта; 
• доработка существующих документов;
• договор на agile-разработку.

Этап 4. Бета-релиз

1,5-3 месяца

Отдел проектирования

Детальное проектирование и дизайн интерфейса, доработка интерактивного прототипа. Описывается функциональность, которая должна войти в финальный релиз. Также ведутся доработки документации по запросу команды разработки.

Документы

• структурные схемы страниц;
• дизайн-макеты страниц;
• интерактивный прототип;
• руководство по стилю интерфейса.

Отдел разработки

Разработка и отладка бета-релиза продукта по agile-договору.

Документы

• план тестирования; 
• отчетность о ходе проекта; 
• доработка существующих документов.

Этап 5. Финальный релиз

2-6 месяцев

Отдел проектирования

Доработки документации по запросу команды разработки.

Документы

• доработка существующих документов.

Отдел разработки

Разработка и отладка финального релиза продукта по agile-договору.

Документы

• сопроводительная документация к проекту; 
• доработка существующих документов.

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

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

P.S. Общий вид диаграммы Ганта на основе описанного выше графика. Так он смотрится куда нагляднее.

P.P.S. Отмечу соавторство Юры Шиляева — он руководит минским офисом разработки нашей компании и именно с ним мы доводим эту схему до ума в ходе работы над проектами.

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

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

И все-таки есть характеристика, с которой можно выйти из тупика — это глубина проработки интерфейса. Со временем мы нашли хороший баланс, разбив работы над проектом на три фазы:

1. Концепция

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

Для этого мы анализируем проект и предметную область, описывая результаты аналитики в виде серии документов: видения проекта, описания целевой аудитории (персонажей), сценариев взаимодействия (use cases) и перечня функциональности (user stories). Они дают общее представление о проекте, достаточное для того чтобы и клиент, и аналитики, и разработчики могли общаться предметно. Еще лучше расширить пакет спецификации за счет предварительного проектирования. Важно получить уже на этапе концепции точную структуру системы и черновые наброски структурных схем ключевых страниц. Переход от текстовых описаний к наглядным образам здорово облегчает понимание. Да и для раннего начала разработки они как нельзя кстати.

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

2. Прототип

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

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

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

3. Детальная спецификация

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

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

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

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

Хотя в целом выбор процесса зависит от тех характеристик, которые клиенту хочется достичь в итоге. Судя по нашему опыту, это график по осям “скорость” и “качество”, значения по которым растут обратнопропорционально. Причем “качество” здесь выступает как совокупный показатель, в который входит и набор функциональности, и прозрачность процесса, и само качество проработки и исполнения. Важно, чтобы приоритетность каждой из этих осей одинаково понимали все участники процесса.

Все части материала:

• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 1. Четыре слоя проектирования
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 2. Спираль повышения качества
• Процесс и продукт проектирования. Жизненный цикл интерфейса, часть 3. Ранние результаты

1. Бизнес-анализ

Мы анализируем задачи клиента и пользователей и определяем общие подходы к решению этих задач. Здесь обрисовываются контуры будущей системы, задаются общие направления движения. Тот бэкграунд, который позволяет в ходе дальнейших работ не забывать о целях и задачах проекта. Мы также находим существующие примеры того, как примерно должно получиться в итоге. Уже точно известно, что должна уметь делать система. А в голове и на бумаге возникают первые грубые наброски ключевых страниц. Как итог — описание продукта с примерно 5% точности.

2. Проектирование интерфейса

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

В результате вместо общей фразы “пользователь оформляет заказ”, полученной в ходе бизнес-анализа, получается набор конкретных страниц. Каждая из которых содержит всю необходимую информацию для выполнения этой задачи. А также элементы управления, позволяющие выполнять частные подзадачи общего процесса и связывающие эти подзадачи между собой. Итоговый набор страниц должен выглядеть аккуратно, но без фанатизма. Ведь на этом этапе стоит задача именно распределения, а не оформления функциональности. Все это повысит точность описания до 40%.

3. Дизайн

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

Дизайнер, как человек со свежим взглядом на проблему, может предлагать свои решения. И если они окажутся лучше предварительно спроектированных — почему бы не воспользоваться ими? Еще более важно то, что он может заметить ошибки и нестыковки. Дизайнеру также может понадобиться объяснить те вещи, которые проектировщик забыл описать. И этот очередной уровень проверки интерфейсных решений дает 60% точности.

4. Интерактивный прототип

Мы делаем так, чтобы интерфейс будущей системы можно было “покликать”, поработав с ним в приближенном к реальному режиме. Нес