Agile в суете. Коллективный дизайн спасет мир

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

Наша реальность

И не только наша. Сверьте с вашей ситуацией. Похоже?

• Сложные проекты с высокой неопределённостью. Не всегда известно, что же получится в конце.
• Неравномерная загрузка. Сегодня аврал, завтра все пропали и задач нет.
• Один и тот же дизайнер может работать на двух-трёх проектах.
• Загрузка зависит от клиента. Клиент уходит в отпуск, берёт паузу, чтобы презентовать идею совету директоров, а потом внезапно возвращается и просит сделать побыстрее.
• Крутаны долго не живут. В ИТ вообще принято менять место работы каждые два-три года, а в нашем случае это ещё и усугубляется сильным HR-брендом компании. «Собаку» используют как способ перейти из «талантливого новичка» в высшую лигу. Кадровики высшей лиги тоже про это знают.

Как мы жили раньше

Раньше мы работали вот так.

В статье про Agile просто обязана быть диаграмма Ганта. Мы пользовались такой диаграммой и верили в то, что это хорошо. Угадайте, что из этого оправдалось, а что нет?

1. Хороший инструмент для продажи.
2. Способ грубой оценки трудозатрат и сроков.
3. Хранение экспертизы внутри компании.
4. Быстрый и уверенный старт работы.
5. Инструкция для менеджера.
6. Повышение предсказуемости хода работ.

На всякий случай — мы рассказываем только про свой опыт.

Хороший инструмент для продажи — да. Она производит впечатление на заказчика, он сразу понимает, что мы готовились (и это правда), он может обсуждать отдельные пункты и задавать вопросы, он понимает, откуда взялась цена контракта.

Способ грубой оценки трудозатрат и сроков — еще раз да. Составление плана действий позволяет довольно точно предсказать работы, объемы и количество ресурсов, которое потребуется.

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

Быстрый и уверенный старт работы. И да, и нет. С одной стороны, когда есть четкий план, то проще стартовать, с другой — попытки пошагово выполнять каждый пункт, да еще и вписываться в часы, очень мешают.

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

Повышение предсказуемости хода работ — нет. Процесс меняется в процессе. По объему и составу работ план чаще всего отражает реальность, но на вопрос «что делаем прямо сейчас» не отвечает. Тут надо сделать сноску, что в целом-то Гант не виноват, и крупноблочно планировать нужно. Бесполезно пытаться последовательно проходить по всем задачам сверху вниз. Задача нужна и важна, но делать прямо сейчас ее не надо. Или надо, но не до конца. Это тема отдельной статьи, которая могла бы называться «жизненный цикл задачи в рамках проекта». Пока просто обозначим, что проблема с последовательностью действий существует.

Какие были времена!

Несмотря на все недостатки Ганта, мы работали, и работали хорошо. Мы были в достаточной степени гибкие. У нас сравнительно небольшие проекты на несколько месяцев. У нас был какой-никакой канбан. У нас был дизайн-процесс, та методология, по которой работают дизайнеры интерфейсов. Наши менеджеры делали план-фактный анализ, мы пользовались Basecamp и, позднее, Teamwork.

Мы жили в таком состоянии довольно долго. Здесь у нас диаграмма Ганта, здесь у нас легкий бардак, здесь отдельные аджайлоподобные приемчики. Все работало, мы делали сложные проекты вроде личного кабинета Альфастрахования, когда нужно было сотрудничать с командой разработки, когда нужно было «на ходу» менять заказчиков.

Секрет был прост. У нас в команде были менеджеры 80-го уровня. Эдакие крутаны с предпринимательским и дизайнерским бэкграундом, которые брали на себя гору ответственности и тащили проект на себе, попутно обучая дизайнеров. Или наоборот, дизайнеры-крутаны, которые одной рукой делали проект, а другой обучали менеджера-новичка.

Все поменялось

Ситуация поменялась. Конечно, не в один момент, но довольно быстро.

У нас появились новые менеджеры. Это были неплохие менеджеры, которые действительно хотели куда-то расти и развиваться, но они еще не были крутанами. Они не хотели глубоко погружаться в предметную область: «вот я менеджер, и я буду менеджерить, а как интерфейсы проектировать — пусть дизайнер думает».

У нас (и, подозреваем, не только у нас) появилось новое поколение дизайнеров. Они хотят сразу делать что-то крутое, несмотря на недостаток опыта. Амбиции зашкаливают, они вписываются во что угодно. Это очень весело, но результат обычно плачевный. Особенно, когда этим энтузиазмом некому управлять.

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

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

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

У нас появилось непрерывное планирование. Раз в неделю мы фиксировали реальное положение дел на проекте, прикидывали оставшееся время и задачи, детализировали план на ближайшее будущее.

Мы стали иначе распоряжаться временем. Если раньше время ровным слоем размазывалось на весь проект, и на «допилки» выделялся сравнительно малый объем ресурсов, то сейчас мы стали нещадно экономить часы в самом начале. Прикидывали, что если отведено на какой-то большой кусок проекта 160 часов, то его нужно сделать за половину времени (а лучше за треть). Зачем? Затем, что «тюнинг», работа к комментариями, прорисовка деталей и другие как бы финализирующие действия требуют уйму времени.

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

Кризис

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

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

Получается парадоксальная ситуация: чтобы улучшить управление проектом, надо отказаться от менеджеров.

Сначала было несколько боязно. Но уже через пару недель мы поняли, что ничего страшного не произошло. Наш дизайнер даже выступил на UX-междусобойчике с говорящим докладом «Как мы работаем без менеджеров и у нас не отвалилась 0 #@».

Рождение коллективного дизайна

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

Оценка дизайнеров почти в два раза превышает оценку генерального директора. Как думаете, какое число уходит в коммерческое предложение? Ха, конечно же то, которое меньше. Не нужно путать демократию и вседозволенность.

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

Да, это похоже на ту самую диаграмму Ганта. Напомним, в нашем случае она отлично подходит и для продажи, и для грубой оценки.

Если все хорошо, начинается работа. И она идет, конечно, не строго по этому плану. Он используется только как ориентир. Это знает и команда, и заказчик. Саму работу проще показать на нескольких примерах.

Быстрый старт

В понедельник утром (или во вторник вечером, это не принципиально) команда договаривается, что она будет делать. Или сама, или с участием «гуру». Сейчас будет не типовой пример решения сложной задачи. Нужно было очень быстро и без раскачки сделать дизайн мобильного приложения. Подробностей не будет — NDA.

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

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

Как обычно

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

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

Формальности и инструменты

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

Схема ведения проекта появилась естественным путем, когда мы пытались описать вот эту нашу новую реальность.

Диаграмма сделана в inShotr. Этот инструмент мы использовали только для прототипа системы планирования. В чистом виде он у нас «не взлетел», но позволил выявить требования к этой системе и адаптировать под эти требования уже Airtable.

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

Инструменты

Мы используем Airtable. В отличие от, скажем, Trello, он позволяет смотреть на проект в двух разрезах. «Статусы» — это способ понять, что происходит с каждой отдельной задачей. Что-то ждем от заказчика, где-то собираем вводные, до чего-то еще руки не дошли. Похоже на Канбан.

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

Слава роботам

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

Тот же самый бот каждый день пишет в главном канале напоминание, что перед началом рабочего дня нужно отправить руководству короткий план на сегодня.

Визуализация масштабов работы

Проще некуда, в коридоре прямо на стене — список всех проектов и задействованных сотрудников.

Для визуализации оставшегося времени — лист А4 с распечатанными квадратиками. Количество квадратиков равно количеству часов в проекте. Раз в неделю мы маркером зачеркиваем отработанные часы по принципу календарика-пинарика.

Что изменилось?

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

Вместо пошагового плана — рамки проекта

Изначальная табличка с микрозадачами на 1−2 часа схлопывается до этапов и ограничений. Дизайнеры делают то, что считают нужным, но строго в этих рамках.

Вместо методики — набор практик

В дизайне все еще сильна вера в некий универсальный процесс. Это тема отдельного разговора, а если коротко — нет такого процесса. Есть набор практик, которые нужно использовать в тот или иной момент. Если есть сомнения, то старшие товарищи придут на помощь и подскажут.

Вместо дедлайнов — контрольные точки

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

Вместо отчетов — логирование проекта

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

В папке проекта на GoogleDoc документы хранятся в папках по неделям. Не по формату, не по этапам, а просто в хронологическом порядке. Кстати, это здорово помогает собирать кейсы.

Профит

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

• 100% прозрачность. Не предсказуемость, не гарантия результата ни в коем случае. Но сейчас по любому проекту за 10 минут можно сказать, что происходит, какие есть потенциальные проблемы и что делать дальше.
• Дизайнеры стали общаться непосредственно с заказчиком, и это улучшило качество результата.
• Повышение личной ответственности — прямо на глазах. Еще вчера дизайнер говорил тебе «я не знаю, что делать, дай мне задачу и принеси аналитику», а сегодня на предложение помочь отвечает «отойди и не мешай, у меня все под контролем».
• Дедлайн по отдельным задачам больше не давит.
• Быстрый старт. Если раньше у нас были проекты с долгой двухмесячной аналитикой, которую приходилось выбрасывать, потому что у заказчика «все поменялось», то теперь аналитика размазана по всему проекту, и на погружение уходит 1−2 недели.
• Никаких лишних документов. Все документы, которые появляются, используются в работе, потому что дизайнеры сами определяют, что им нужно.

Продолжение обязательно последует. А мы постараемся не забыть рассказать об этом вам.