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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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