В середине сентября профессоры стэнфордской d.School Perry Klebahn и Jeremy Utley провели для нашей компании тренинг “Design Thinking”. В ходе двух дней сверхплотной работы команды прошли по всем ключевым этапам этого процесса создания инновационных продуктов, а также опробовали на практике серию полезнейших методов и практик исследования, проектирования и тестирования. Хотя многое из этого мы применяли или давно собирались попробовать, в связке процесс оказался впечатляющим.

Design Thinking — появившийся в 80х и ставший особенно актуальным в последнее время подход к созданию новых продуктов. Одной из главных его особенностей является применение для нетривиальных и плохо описанных задач, а также хорошо поставленный итеративный процесс их решения и постоянного пересмотра изначальных установок. Нашей задачей на эти дни было улучшение и пересмотр “holiday experience” в самом широком смысле. Необходимо было понять, что нового и интересного мы можем предложить потенциальной аудитории. После чего создать и презентовать прототип такого продукта.

В целом предлагаемые d.School шаги процесса Design Thinking похожи на проектирование интерфейсов — предварительное исследование, проработка концепции, прототипирование и тестирование. Но отличаются нюансы и акценты, а также конкретный набор методов. В интерпретации d.School процесс выглядит так:

1. Empathize. Необходимо понять пользователя. Кто он, какие у него потребности, проблемы, желания, чувства, мысли, настроения?
2. Define. Мы ищем проблему, которую будет решать наш продукт. Точнее, пытаемся глубже и тоньше понять то видение проблемы, которое мы сформировали на старте проекта.
3. Ideate. Нам нужно понять пространство возможных решений проблемы. Важно предложить как можно больше вариантов, чтобы в дальнейшем выбрать или собрать из них лучшее.
4. Prototype. Мы начинаем заниматься реализацией продукта – делается его прототип. У всех уже есть его примерное видение и огромное желание наконец-то поработать руками.
5. Test. Тестирование получившегося продукта. Нужно понять, насколько хорошо он решает проблему пользователя и если нужно – подкрутить решение.

В презентации подробно описан каждый из этих этапов и другие детали тренинга:

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

Как я уже рассказывал в блоге, в июле этого года основная часть команды UI Modeling Company перешла в Mail.Ru, где усилила уже имевшийся отдел проектирования и дизайна интерфейсов. За прошедшее время мы успели сделать достаточно много в плане оптимизации рабочего процесса, автоматизации производства, построения инструментария, формирования базы знаний. И, естественно, основной работы над продуктами, которые находятся в нашем ведении — главная страница, общепортальные правила, Почта, Агент и их мобильные версии, новые сервисы компании.

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

• Команда. Какие продукты холдинга Mail.Ru Group имеют собственные интерфейсные группы, почему их несколько и кого включает именно наша.
• Процесс работы. Основные этапы проектирования и дизайна интерфейсов в компании, а также особенности и нюансы в отличие от других организаций.
• Инструменты и технологический процесс. Почему мы используем связку Adobe InDesign + Photoshop и как пытаемся сокращать рутинные операции для повышения производительности и освобождения времени для поиска интересных решений.
• Паттерны и гайдлайны. Лучший способ работы над интерфейсами пакета крупных продуктов, который мы постепенно распространяем на все продукты в нашей юрисдикции.
• Тестирование и исследования. Что нам нужно от юзабилити-лаборатории и как она помогает нам в создании более качественных продуктов.
• Творческие планы. Какие начатые дела мы хотим закончить в первую очередь и как это повлияет на качество, производительность и удовлетворенность от работы команды.

Саму презентацию можно посмотреть и скачать на SlideShare:

Также доступна видео-запись выступления. Другие материалы:

• Фотографии от Юрия Копылова — часть 1, часть 2 и часть 3;
• Видео-записи выступлений.

Организаторы собрали целую бригаду российских экспертов — я от UI Modeling Company, UI Design (Алексей Копылов и Иван Дегтяренко), UsabilityLab (Дмитрий Сатин и Андрей Сикорский), InterUX (Екатерина Сугак), Екатерина Умнова, Павел Коноплицкий. Мы должны были помочь спонсорам мероприятия — четырем украинским интернет-бизнесам — решить интерфейсные проблемы в их продуктах. Причем делать это не самостоятельно, а руководя подшефными группами специалистов, которые формировались из участников мероприятия.

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

Старт проекта

После этого началось формирование команд. Мне с Иваном Дегтяренко достался проект Prom.ua — ведущий украинский каталог компаний (работает также под брендами www.tiu.ru, www.deal.by, www.kazprom.net и в других странах СНГ). Необходимо было увеличить конверсию при регистрации новых компаний и решить сопутствующие задачи. В общем, после некоторой вводной и знакомства команд процесс стартовал.

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

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

Проектирование и презентация

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

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

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

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

P.S. Спасибо моей команде, было здорово работать вместе — Денису Горовому (заказчик), Юре Шиляеву (со-организатор команды), Юре Соколову, Свете Олишевской, Даше, Олесе, Косте и Саше.

Другие материалы:

• Отчет о работе команд и еще один;
• Фото от организаторов;
• Фото от Юрия Соколова;
• Фото от Александра Кулика;
• Фото от Анны Юрченко;
• Фото от Андрея Зайцева;
• Фото от Вадима Заковинко;
• Видео-репортаж;

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

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

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

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

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

Решением является работа с ожиданиями на различных этапах и уровнях проекта:

• Определение заинтересованных лиц и их интересов в проекте. Что ждет от него заказчик, команды разработки и поддержки, пользователи и сам проектировщик?
• Понимание условий успеха проекта. Важен ли срок выхода на рынок, потребительские качества продукта, учет сложных технических ограничений, вписывание в ограниченный бюджет или что-то еще?
• Донесение до клиента пользы проектирования в этом конкретном проекте. Будет ли это подробная спецификация, достижение определенных показателей потребительских качеств, экономия своих ресурсов или другие выгоды?
• Управление ожиданиями на всех этапах проекта — от предпродажных работ и сбора требований до детального проектирования и поддержки команды разработки.

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

Презентация состояла из двух частей. Во-первых, рассказ о самих организациях и их особенностях:

• процессе проектирования;
• распределении проектных ролей — их выбор, совмещение и возможные конфликты;
• составе команды и ее подразделений — проектирования, аналитики, менеджмента и разработки;
• возможностях и сложностях, стоящих перед проектировщиком;

Вторая часть выступления подытожила полученный опыт. Получились несколько ключевых тезисов:

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

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

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

Кстати, саму презентацию можно посмотреть и скачать на сайте SlideShare:

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

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

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

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

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

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

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

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

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

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

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

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

Почта

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

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

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

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

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

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

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

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

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

Браузер

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

• Del.icio.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. Вспомогательные инструменты