СоХабр закрыт.
С 13.05.2019 изменения постов больше не отслеживаются, и новые посты не сохраняются.
| сохранено
H Аджайл в суете. Коллективный дизайн спасет мир в черновиках
Статья по мотивам выступления Евгения Романовского на конференции AgileDays.
Мы занимаемся дизайном сложных интерфейсов. Компания у нас небольшая, мы живем в условиях зашкаливающей неопределенности, а значит, просто обязаны быть гибкими. Казалось бы — аджайл в руки и вперед. Одна беда, любой формализованный способ организации совместной работы требует неспешности, размеренности и даже подобия стабильности в команде или компании. Что делать, когда всего этого нет?
И не только наша. Сверьте с вашей ситуацией. Похоже?
Раньше мы работали вот так.
Да, в статье про аджайл просто обязана быть диаграмма Ганта. Мы пользовались такой диаграммой и верили, что это хорошо. Угадайте, какие из наших ожиданий оправдались.
На всякий случай — мы рассказываем только про свой опыт.
Хороший инструмент для продажи — да. Диаграмма производит впечатление на заказчика, он сразу понимает, что мы готовились (и это правда), он может обсуждать отдельные пункты и задавать вопросы, он понимает, откуда взялась цена контракта.
Способ грубой оценки трудозатрат и сроков — еще раз да. План действий позволяет довольно точно предсказать задачи, объемы и количество ресурсов.
Хранение экспертизы внутри компании — скорее нет. Мы думали, что все будет работать так: мы определим, какие нужны этапы, чтобы сделать классный дизайн, пойдем по этим этапам, обнаружим, что нам чего-то не хватает, обновим свой план и следующий проект будем делать уже по обновленному плану. Но это работает только в простых линейных продукта вроде аудита. Все идет не по плану с первого дня, если мы создаем сложный интерфейс с высокой неопределенностью.
Быстрый и уверенный старт работы. И да, и нет. С одной стороны, с четким планом проще стартовать, с другой — попытки пошагово выполнять каждый пункт, да еще и вписываться в часы очень мешают.
Инструкция для менеджера — нет. Думали, новый менеджер взглянет на план и поймет, что делать. А где не поймет — спросит. На практике менеджер-новичок не понимает, какая именно работа скрывается за названием пункта, а спрашивать обо всем боится, потому что может не уложиться в календарные сроки и потратить на задачу больше времени.
Повышение предсказуемости хода работ — нет. Процесс меняется в процессе. План чаще всего отражает реальный объем и состав работ, но на вопрос «что делаем прямо сейчас» не отвечает. Тут надо отметить, что в целом-то Гант не виноват и крупноблочно планировать нужно. Но вот попытки жестко зафиксировать последовательность выполнения задач бесполезны. Задача нужна и важна, но выполнять прямо сейчас ее не надо. Или надо, но не до конца. Это тема для отдельной статьи, которая могла бы называться «жизненный цикл задачи в рамках проекта». Пока просто отметим, что проблема с последовательностью действий существует.
Несмотря на все недостатки Ганта, мы работали, и работали хорошо. Гибкости нам хватало. У нас были сравнительно небольшие проекты на несколько месяцев. У нас был какой-никакой канбан. У нас был дизайн-процесс, та методология, по которой работают дизайнеры интерфейсов. Наши менеджеры делали план-фактный анализ, мы пользовались Basecamp и, позднее, Teamwork.
Мы жили в таком состоянии довольно долго. Здесь у нас диаграмма Ганта, здесь — легкий бардак, здесь — отдельные аджайлоподобные приемчики. Все работало, мы выполняли сложные проекты вроде личного кабинета Альфастрахования, когда нужно было сотрудничать с командой разработки и на ходу менять дизайнеров.
Секрет прост. У нас в команде были менеджеры 80-го уровня. Эдакие крутаны с предпринимательским и дизайнерским бэкграундом, которые взваливали на плечи гору ответственности и тащили проект на себе, попутно обучая дизайнеров. Или наоборот, дизайнеры-крутаны, которые одной рукой делали проект, а другой обучали менеджера-новичка.
Ситуация поменялась. Конечно, не в один момент, но довольно быстро.
У нас появились новые менеджеры. Вроде бы неплохие, они действительно хотели расти и развиваться, но пока еще не были крутанами. И не желали глубоко погружаться в предметную область: «вот я менеджер, и я буду менеджерить, а как интерфейсы проектировать — пусть дизайнер думает».
У нас (и, подозреваем, не только у нас) появилось новое поколение дизайнеров. Они рвутся сразу делать что-то крутое, несмотря на недостаток опыта. Амбиции зашкаливают, они вписываются во что угодно. Это очень весело, но результат обычно плачевный. Особенно когда этим энтузиазмом некому управлять.
Не то чтобы мы оказались в такой ситуации первыми в мире. Если проблемы управляемости не решить в лоб, на помощь приходят гибкие методологии. Мы поняли, что выбора нет. Какую таблетку ни прими, нам нужно идти по проторенной дорожке в аджайл.
Нельзя просто так взять и внедрить аджайл. Мы были ограничены изучением теории, не могли позволить себе прокачать практику в учебно-тренинговом режиме, взять в штат коуча. У нас не было возможности остановиться и выдохнуть. Когда мы работаем, мы зарабатываем деньги, когда мы останавливаемся, мы не зарабатываем деньги. Мы не можем позволить себе, чтобы один человек трудился только над одним основным проектом. Предстояло действовать на ходу, перенимая отдельные практики и прощупывая, что работает в нашем случае, а что нет.
Так у нас появились фокусы интерфейса. Это наш вариант бэклога. Смысл в том, что весь интерфейс разбивается не на страницы, не на разделы, не на этапы, а на фокусы разного размера: поле ввода, форма регистрации, личный кабинет и т.д. Каждый фокус можно оценить в часах и днях, поставить в недельный план.
У нас появилось непрерывное планирование. Раз в неделю мы фиксировали реальное положение дел на проекте, прикидывали оставшееся время и задачи, детализировали план на ближайшее будущее.
Мы стали иначе распоряжаться временем. Если раньше время ровным слоем размазывалось на весь проект и на «допилки» выделялся сравнительно малый объем ресурсов, то сейчас мы стали нещадно экономить часы в самом начале. Если на какой-то большой кусок проекта было отведено 160 часов, старались сделать за половину времени, а лучше за треть. Зачем? Затем, что «тюнинг», работа с комментариями, прорисовка деталей и другие финализирующие действия требуют уйму времени.
Дирижировать всем этим должен был, собственно, менеджер. Загрузить задачей дизайнера, найти недостающие документы, ответить на вопросы, созвониться с заказчиком, принять промежуточные результаты.
Опытный управленец в начале работы задает себе простой вопрос: что пойдет не так? Ответить на него обычно нельзя, но можно хотя бы морально подготовиться к неизбежному кризису.
Наш кризис, к счастью, снаружи никто не заметил. Проекты в этот период мы сделали. Правда, некоторые из них в убыток. Если коротко (а подробно, простите, не хочется вспоминать), то все описанные выше проблемы накопились до критической массы. Смена производственного фреймворка не решила главной проблемы: помогают проекту только крутые менеджеры, а середняки в лучшем случае не вредят.
Мы пришли к парадоксальному выводу: чтобы улучшить управление проектом, надо отказаться от менеджеров.
Сначала было немного боязно. Но уже через пару недель мы поняли, что ничего страшного не произошло. Наш дизайнер даже выступил на UX-междусобойчике с докладом «Как мы работаем без менеджеров и у нас не отвалилась 0#@».
Сейчас мы работаем по методологии, которую называем «коллективный дизайн». Все начинается еще на этапе продажи. После первых переговоров на тему «а что, собственно, надо делать» мы собираем команду дизайнеров и предлагаем вместе с нами составить план проекта. Это проходит в формате брейншторма. Все высказывают свои идеи, какие работы реально нужны, делают оценку в часах.
Оценка дизайнеров обычно почти в два раза превышает оценку генерального директора. Как думаете, какое число уходит в коммерческое предложение? Ха, конечно же, то, которое меньше. Не нужно путать демократию и вседозволенность.
Если серьезно, это очень полезное упражнение. По такому плану легко определять, где команде не хватает компетенций. Например, если команда пишет, что для составления простого документа понадобится 10 часов, хотя там работы на 15 минут, значит, они плохо понимают суть этой задачи. И должны учиться. Не за счет заказчика и, желательно, не за счет компании. Прямо на старте мы определяем, каких знаний не хватает команде, и решаем, как закрыть этот пробел.
Да, это похоже на ту самую диаграмму Ганта. Напомним, в нашем случае она отлично подходит и для продажи, и для грубой оценки.
Если все хорошо, начинается работа. И она идет, конечно, не строго по намеченному плану. Он используется только как ориентир. Это знает и команда, и заказчик. Саму работу проще показать на нескольких примерах.
Вначале команда договаривается, что она будет делать. Или сама, или с участием «гуру».
Далее — нетиповой пример решения сложной задачи. Нужно было очень быстро и без раскачки сделать дизайн мобильного приложения. Подробностей не будет — NDA.
Было видение заказчика, описание матчасти, которая используется в продукте, результаты предварительных обсуждений. План на неделю выглядел так: нарисовать 100 картинок по этим документам. В первый день дизайнеры офигевали от такой постановки. На второй — сходили с ума. Ну как так можно сразу брать и рисовать? Надо же в задаче разобраться. На третий день вошли во вкус, на четвертый — нарисовали 90 картинок и опережали план.
На следующей неделе мы решили, что пора уже создавать структуру и определяться с функциональностью. Но тут дизайнеры ответили, что эта самая структура уже появилась в голове, пока они рисовали 100 картинок, осталось перенести на бумагу. И это отличная иллюстрация того, что коллективный дизайн позволяет экспериментировать с методами.
Сейчас мы используем более мягкий вариант. Команда встречается, обсуждает, что будет делать и сколько на это есть времени.
Здесь два важных момента. Во-первых, у проекта есть четкие рамки. Придумывать задачи и искать пути решения можно в строго отведенном на это временном промежутке. Во-вторых, эти же самые ограничения позволяют гибко менять степень погружения в ту или иную задачу. Если в списке есть пункт «проанализировать всё, что прислали», можно изучать две недели, а можно пробежать за час. Понятно, что при двухнедельном анализе мы узнаем больше. Но если времени нет (а его всегда нет), то мы можем «посмотреть» за час и выдать короткий полезный документ с результатами. Результатом может быть что угодно — от «тут вообще нечего анализировать» до «нам нужно еще неделю читать входящие документы».
Схема ведения проекта появилась естественным путем, когда мы пытались описать нашу новую реальность.
Диаграмма сделана в inShotr. Этот инструмент мы использовали только для прототипа системы планирования. В чистом виде он у нас «не взлетел», но позволил выявить требования к этой системе и адаптировать под эти требования уже Airtable.
Столбцы — потоки работ. Есть поток «управления проектом», и в нем больше всего задач на старте. Есть этап «постановка», когда мы определяем, что, собственно, делать. Дальше производственные потоки: «дизайн», «тексты» (на картинке его нет) и «контроль качества». Последний поток — «сдача-приемка». Поток, а не этап, потому что одновременно можно управлять проектом, планировать следующий кусок работ и сдавать предыдущий.
Мы используем Airtable. В отличие от, скажем, Trello, он позволяет смотреть на проект в двух разрезах. «Статусы» — это способ понять, что происходит с каждой отдельной задачей. Что-то ждем от заказчика, где-то собираем вводные, до чего-то еще руки не дошли. Похоже на канбан.
«Потоки» — это те же самые карточки-задачи, распределенные по потокам. Сейчас больше всего работы у аналитика, требуется что-то по управлению, а дизайнеры будут свободны. Все в динамике, и через неделю картина будет иной.
Часть менеджерских функций отдали чат-боту. Каждый будний день робот приходит к каждому сотруднику (включая директоров) в личку и долбит его сообщением, что нужно заполнить отчет о потраченном вчера времени.
Тот же самый бот ежедневно пишет в главном канале напоминание, что перед началом рабочего дня нужно отправить руководству короткий план на сегодня.
Проще некуда, в коридоре прямо на стене — список всех проектов и задействованных сотрудников.
Для визуализации оставшегося времени — лист А4 с распечатанными квадратиками. Количество квадратиков равно количеству часов в проекте. Раз в неделю мы маркером зачеркиваем отработанные часы по принципу календарика-пинарика.
У нас действительно нет менеджера в чистом виде. У нас есть фасилитатор, который помогает команде планировать работу и решать проблемы. «Что мы будем делать на этой неделе?», «Как мы будем это делать?», «Какие есть сложности?», «Как их разрешить?» и т.д. Довольно быстро опытные дизайнеры уже сами успешно фасилитируют команду и не нуждаются во внешней поддержке. Фасилитация — не самый сложный навык, и люди быстро его осваивают.
Изначальная табличка с микрозадачами на один-два часа схлопывается до этапов и ограничений. Дизайнеры делают то, что считают нужным, но строго в этих рамках.
В дизайне все еще сильна вера в некий универсальный процесс. Это тема отдельного разговора, а если коротко — нет такого процесса. Есть набор практик, которые нужно использовать в тот или иной момент. Если есть сомнения, то старшие товарищи придут на помощь и подскажут.
Конечно, есть дедлайн по договору. Конечно, есть дедлайны у заказчика — нужно успеть к выставке. Но у нас нет дедлайна по тем недельным задачкам, которые команда на себя взяла. Есть контрольная точка, на которой мы сверяемся, что было сделано, а что нет. Это снимает напряжение с команды.
Конечно, совсем без бюрократии нельзя, но ее можно свести к минимуму. Мы записываем всё, о чем договорились на внутренних обсуждениях, и всё, о чем договорились с заказчиком.
В папке проекта на GoogleDoc документы хранятся в папках по неделям. Не по формату, не по этапам, а просто в хронологическом порядке. Кстати, это здорово помогает собирать кейсы.
Те результаты, которые мы наблюдаем сейчас, — положительные. Наверняка будут подводные грабли. Да что лукавить, уже есть, но про них пока рано рассказывать. Поэтому закончим позитивно, как и положено в статье про аджайл. Мы получили такие выгоды.
Продолжение обязательно последует. А мы постараемся не забыть рассказать об этом вам.
Мы занимаемся дизайном сложных интерфейсов. Компания у нас небольшая, мы живем в условиях зашкаливающей неопределенности, а значит, просто обязаны быть гибкими. Казалось бы — аджайл в руки и вперед. Одна беда, любой формализованный способ организации совместной работы требует неспешности, размеренности и даже подобия стабильности в команде или компании. Что делать, когда всего этого нет?
Наша реальность
И не только наша. Сверьте с вашей ситуацией. Похоже?
- Сложные проекты с высокой неопределенностью. Не всегда известно, что же получится в конце.
- Неравномерная загрузка. Сегодня аврал, завтра все пропали и задач нет.
- Один и тот же дизайнер может работать на двух-трех проектах.
- Загрузка зависит от клиента. Клиент уходит в отпуск, берет паузу, чтобы презентовать идею совету директоров, а потом внезапно возвращается и просить сделать побыстрее.
- Крутаны не сидят на месте долго. В IT принято менять место работы каждые два-три года, а в нашем случае это еще и усугубляется сильным HR-брендом компании. «Собаку» используют, чтобы из «талантливых новичков» попасть в высшую лигу. Кадровики высшей лиги тоже про это знают.
Как мы жили раньше
Раньше мы работали вот так.
Да, в статье про аджайл просто обязана быть диаграмма Ганта. Мы пользовались такой диаграммой и верили, что это хорошо. Угадайте, какие из наших ожиданий оправдались.
- Хороший инструмент для продажи.
- Способ грубой оценки трудозатрат и сроков.
- Хранение экспертизы внутри компании.
- Быстрый и уверенный старт работы.
- Инструкция для менеджера.
- Повышение предсказуемости хода работ.
На всякий случай — мы рассказываем только про свой опыт.
Хороший инструмент для продажи — да. Диаграмма производит впечатление на заказчика, он сразу понимает, что мы готовились (и это правда), он может обсуждать отдельные пункты и задавать вопросы, он понимает, откуда взялась цена контракта.
Способ грубой оценки трудозатрат и сроков — еще раз да. План действий позволяет довольно точно предсказать задачи, объемы и количество ресурсов.
Хранение экспертизы внутри компании — скорее нет. Мы думали, что все будет работать так: мы определим, какие нужны этапы, чтобы сделать классный дизайн, пойдем по этим этапам, обнаружим, что нам чего-то не хватает, обновим свой план и следующий проект будем делать уже по обновленному плану. Но это работает только в простых линейных продукта вроде аудита. Все идет не по плану с первого дня, если мы создаем сложный интерфейс с высокой неопределенностью.
Быстрый и уверенный старт работы. И да, и нет. С одной стороны, с четким планом проще стартовать, с другой — попытки пошагово выполнять каждый пункт, да еще и вписываться в часы очень мешают.
Инструкция для менеджера — нет. Думали, новый менеджер взглянет на план и поймет, что делать. А где не поймет — спросит. На практике менеджер-новичок не понимает, какая именно работа скрывается за названием пункта, а спрашивать обо всем боится, потому что может не уложиться в календарные сроки и потратить на задачу больше времени.
Повышение предсказуемости хода работ — нет. Процесс меняется в процессе. План чаще всего отражает реальный объем и состав работ, но на вопрос «что делаем прямо сейчас» не отвечает. Тут надо отметить, что в целом-то Гант не виноват и крупноблочно планировать нужно. Но вот попытки жестко зафиксировать последовательность выполнения задач бесполезны. Задача нужна и важна, но выполнять прямо сейчас ее не надо. Или надо, но не до конца. Это тема для отдельной статьи, которая могла бы называться «жизненный цикл задачи в рамках проекта». Пока просто отметим, что проблема с последовательностью действий существует.
Какие были времена!
Несмотря на все недостатки Ганта, мы работали, и работали хорошо. Гибкости нам хватало. У нас были сравнительно небольшие проекты на несколько месяцев. У нас был какой-никакой канбан. У нас был дизайн-процесс, та методология, по которой работают дизайнеры интерфейсов. Наши менеджеры делали план-фактный анализ, мы пользовались Basecamp и, позднее, Teamwork.
Мы жили в таком состоянии довольно долго. Здесь у нас диаграмма Ганта, здесь — легкий бардак, здесь — отдельные аджайлоподобные приемчики. Все работало, мы выполняли сложные проекты вроде личного кабинета Альфастрахования, когда нужно было сотрудничать с командой разработки и на ходу менять дизайнеров.
Секрет прост. У нас в команде были менеджеры 80-го уровня. Эдакие крутаны с предпринимательским и дизайнерским бэкграундом, которые взваливали на плечи гору ответственности и тащили проект на себе, попутно обучая дизайнеров. Или наоборот, дизайнеры-крутаны, которые одной рукой делали проект, а другой обучали менеджера-новичка.
Все поменялось
Ситуация поменялась. Конечно, не в один момент, но довольно быстро.
У нас появились новые менеджеры. Вроде бы неплохие, они действительно хотели расти и развиваться, но пока еще не были крутанами. И не желали глубоко погружаться в предметную область: «вот я менеджер, и я буду менеджерить, а как интерфейсы проектировать — пусть дизайнер думает».
У нас (и, подозреваем, не только у нас) появилось новое поколение дизайнеров. Они рвутся сразу делать что-то крутое, несмотря на недостаток опыта. Амбиции зашкаливают, они вписываются во что угодно. Это очень весело, но результат обычно плачевный. Особенно когда этим энтузиазмом некому управлять.
Не то чтобы мы оказались в такой ситуации первыми в мире. Если проблемы управляемости не решить в лоб, на помощь приходят гибкие методологии. Мы поняли, что выбора нет. Какую таблетку ни прими, нам нужно идти по проторенной дорожке в аджайл.
Нельзя просто так взять и внедрить аджайл. Мы были ограничены изучением теории, не могли позволить себе прокачать практику в учебно-тренинговом режиме, взять в штат коуча. У нас не было возможности остановиться и выдохнуть. Когда мы работаем, мы зарабатываем деньги, когда мы останавливаемся, мы не зарабатываем деньги. Мы не можем позволить себе, чтобы один человек трудился только над одним основным проектом. Предстояло действовать на ходу, перенимая отдельные практики и прощупывая, что работает в нашем случае, а что нет.
Так у нас появились фокусы интерфейса. Это наш вариант бэклога. Смысл в том, что весь интерфейс разбивается не на страницы, не на разделы, не на этапы, а на фокусы разного размера: поле ввода, форма регистрации, личный кабинет и т.д. Каждый фокус можно оценить в часах и днях, поставить в недельный план.
У нас появилось непрерывное планирование. Раз в неделю мы фиксировали реальное положение дел на проекте, прикидывали оставшееся время и задачи, детализировали план на ближайшее будущее.
Мы стали иначе распоряжаться временем. Если раньше время ровным слоем размазывалось на весь проект и на «допилки» выделялся сравнительно малый объем ресурсов, то сейчас мы стали нещадно экономить часы в самом начале. Если на какой-то большой кусок проекта было отведено 160 часов, старались сделать за половину времени, а лучше за треть. Зачем? Затем, что «тюнинг», работа с комментариями, прорисовка деталей и другие финализирующие действия требуют уйму времени.
Дирижировать всем этим должен был, собственно, менеджер. Загрузить задачей дизайнера, найти недостающие документы, ответить на вопросы, созвониться с заказчиком, принять промежуточные результаты.
Кризис
Опытный управленец в начале работы задает себе простой вопрос: что пойдет не так? Ответить на него обычно нельзя, но можно хотя бы морально подготовиться к неизбежному кризису.
Наш кризис, к счастью, снаружи никто не заметил. Проекты в этот период мы сделали. Правда, некоторые из них в убыток. Если коротко (а подробно, простите, не хочется вспоминать), то все описанные выше проблемы накопились до критической массы. Смена производственного фреймворка не решила главной проблемы: помогают проекту только крутые менеджеры, а середняки в лучшем случае не вредят.
Мы пришли к парадоксальному выводу: чтобы улучшить управление проектом, надо отказаться от менеджеров.
Сначала было немного боязно. Но уже через пару недель мы поняли, что ничего страшного не произошло. Наш дизайнер даже выступил на UX-междусобойчике с докладом «Как мы работаем без менеджеров и у нас не отвалилась 0#@».
Рождение коллективного дизайна
Сейчас мы работаем по методологии, которую называем «коллективный дизайн». Все начинается еще на этапе продажи. После первых переговоров на тему «а что, собственно, надо делать» мы собираем команду дизайнеров и предлагаем вместе с нами составить план проекта. Это проходит в формате брейншторма. Все высказывают свои идеи, какие работы реально нужны, делают оценку в часах.
Оценка дизайнеров обычно почти в два раза превышает оценку генерального директора. Как думаете, какое число уходит в коммерческое предложение? Ха, конечно же, то, которое меньше. Не нужно путать демократию и вседозволенность.
Если серьезно, это очень полезное упражнение. По такому плану легко определять, где команде не хватает компетенций. Например, если команда пишет, что для составления простого документа понадобится 10 часов, хотя там работы на 15 минут, значит, они плохо понимают суть этой задачи. И должны учиться. Не за счет заказчика и, желательно, не за счет компании. Прямо на старте мы определяем, каких знаний не хватает команде, и решаем, как закрыть этот пробел.
Да, это похоже на ту самую диаграмму Ганта. Напомним, в нашем случае она отлично подходит и для продажи, и для грубой оценки.
Если все хорошо, начинается работа. И она идет, конечно, не строго по намеченному плану. Он используется только как ориентир. Это знает и команда, и заказчик. Саму работу проще показать на нескольких примерах.
Быстрый старт
Вначале команда договаривается, что она будет делать. Или сама, или с участием «гуру».
Далее — нетиповой пример решения сложной задачи. Нужно было очень быстро и без раскачки сделать дизайн мобильного приложения. Подробностей не будет — NDA.
Было видение заказчика, описание матчасти, которая используется в продукте, результаты предварительных обсуждений. План на неделю выглядел так: нарисовать 100 картинок по этим документам. В первый день дизайнеры офигевали от такой постановки. На второй — сходили с ума. Ну как так можно сразу брать и рисовать? Надо же в задаче разобраться. На третий день вошли во вкус, на четвертый — нарисовали 90 картинок и опережали план.
На следующей неделе мы решили, что пора уже создавать структуру и определяться с функциональностью. Но тут дизайнеры ответили, что эта самая структура уже появилась в голове, пока они рисовали 100 картинок, осталось перенести на бумагу. И это отличная иллюстрация того, что коллективный дизайн позволяет экспериментировать с методами.
Как обычно
Сейчас мы используем более мягкий вариант. Команда встречается, обсуждает, что будет делать и сколько на это есть времени.
Здесь два важных момента. Во-первых, у проекта есть четкие рамки. Придумывать задачи и искать пути решения можно в строго отведенном на это временном промежутке. Во-вторых, эти же самые ограничения позволяют гибко менять степень погружения в ту или иную задачу. Если в списке есть пункт «проанализировать всё, что прислали», можно изучать две недели, а можно пробежать за час. Понятно, что при двухнедельном анализе мы узнаем больше. Но если времени нет (а его всегда нет), то мы можем «посмотреть» за час и выдать короткий полезный документ с результатами. Результатом может быть что угодно — от «тут вообще нечего анализировать» до «нам нужно еще неделю читать входящие документы».
Формальности и инструменты
Схема проекта
Схема ведения проекта появилась естественным путем, когда мы пытались описать нашу новую реальность.
Диаграмма сделана в inShotr. Этот инструмент мы использовали только для прототипа системы планирования. В чистом виде он у нас «не взлетел», но позволил выявить требования к этой системе и адаптировать под эти требования уже Airtable.
Столбцы — потоки работ. Есть поток «управления проектом», и в нем больше всего задач на старте. Есть этап «постановка», когда мы определяем, что, собственно, делать. Дальше производственные потоки: «дизайн», «тексты» (на картинке его нет) и «контроль качества». Последний поток — «сдача-приемка». Поток, а не этап, потому что одновременно можно управлять проектом, планировать следующий кусок работ и сдавать предыдущий.
Инструменты
Мы используем Airtable. В отличие от, скажем, Trello, он позволяет смотреть на проект в двух разрезах. «Статусы» — это способ понять, что происходит с каждой отдельной задачей. Что-то ждем от заказчика, где-то собираем вводные, до чего-то еще руки не дошли. Похоже на канбан.
«Потоки» — это те же самые карточки-задачи, распределенные по потокам. Сейчас больше всего работы у аналитика, требуется что-то по управлению, а дизайнеры будут свободны. Все в динамике, и через неделю картина будет иной.
Слава роботам
Часть менеджерских функций отдали чат-боту. Каждый будний день робот приходит к каждому сотруднику (включая директоров) в личку и долбит его сообщением, что нужно заполнить отчет о потраченном вчера времени.
Тот же самый бот ежедневно пишет в главном канале напоминание, что перед началом рабочего дня нужно отправить руководству короткий план на сегодня.
Визуализация масштабов работы
Проще некуда, в коридоре прямо на стене — список всех проектов и задействованных сотрудников.
Для визуализации оставшегося времени — лист А4 с распечатанными квадратиками. Количество квадратиков равно количеству часов в проекте. Раз в неделю мы маркером зачеркиваем отработанные часы по принципу календарика-пинарика.
Что изменилось?
У нас действительно нет менеджера в чистом виде. У нас есть фасилитатор, который помогает команде планировать работу и решать проблемы. «Что мы будем делать на этой неделе?», «Как мы будем это делать?», «Какие есть сложности?», «Как их разрешить?» и т.д. Довольно быстро опытные дизайнеры уже сами успешно фасилитируют команду и не нуждаются во внешней поддержке. Фасилитация — не самый сложный навык, и люди быстро его осваивают.
Вместо пошагового плана — рамки проекта.
Изначальная табличка с микрозадачами на один-два часа схлопывается до этапов и ограничений. Дизайнеры делают то, что считают нужным, но строго в этих рамках.
Вместо методики — набор практик
В дизайне все еще сильна вера в некий универсальный процесс. Это тема отдельного разговора, а если коротко — нет такого процесса. Есть набор практик, которые нужно использовать в тот или иной момент. Если есть сомнения, то старшие товарищи придут на помощь и подскажут.
Вместо дедлайнов — контрольные точки
Конечно, есть дедлайн по договору. Конечно, есть дедлайны у заказчика — нужно успеть к выставке. Но у нас нет дедлайна по тем недельным задачкам, которые команда на себя взяла. Есть контрольная точка, на которой мы сверяемся, что было сделано, а что нет. Это снимает напряжение с команды.
Вместо отчетов — логирование проекта
Конечно, совсем без бюрократии нельзя, но ее можно свести к минимуму. Мы записываем всё, о чем договорились на внутренних обсуждениях, и всё, о чем договорились с заказчиком.
В папке проекта на GoogleDoc документы хранятся в папках по неделям. Не по формату, не по этапам, а просто в хронологическом порядке. Кстати, это здорово помогает собирать кейсы.
Профит
Те результаты, которые мы наблюдаем сейчас, — положительные. Наверняка будут подводные грабли. Да что лукавить, уже есть, но про них пока рано рассказывать. Поэтому закончим позитивно, как и положено в статье про аджайл. Мы получили такие выгоды.
- 100%-ная прозрачность. Не предсказуемость, не гарантия результата ни в коем случае. Но сейчас по любому проекту за 10 минут можно сказать, что происходит, какие есть потенциальные проблемы и что делать дальше.
- Дизайнеры стали общаться с заказчиком напрямую, и это улучшило качество результата.
- Повышение личной ответственности — прямо на глазах. Еще вчера дизайнер говорил тебе «я не знаю, что делать, дай мне задачу и принеси аналитику», а сегодня на предложение помочь отвечает «отойди и не мешай, у меня все под контролем».
- Дедлайн по отдельным задачам больше не давит.
- Быстрый старт. Если раньше у нас были проекты с долгой двухмесячной аналитикой, которую приходилось выбрасывать, потому что у заказчика «все поменялось», то теперь аналитика размазана по всему проекту и на погружение уходит одна-две недели.
- Никаких лишних документов. Все документы, которые появляются, используются в работе, потому что дизайнеры сами определяют, что им нужно.
Продолжение обязательно последует. А мы постараемся не забыть рассказать об этом вам.
–1
520
комментарии (1)