Как устроены дизайн-процессы в Facebook: понимание, моделирование, построение и запуск14.11.2016 20:22

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

Незнание порождает проблемы

Я привык думать, что разработка продукта происходит примерно так: кто-то что-то придумывает и просит меня подготовить несколько мок-объектов, я их делаю, потом мы пишем код, проводим пользовательское тестирование и настраиваем, а в финале запускаем продукт.

Моё изначальное видение типичного процесса разработки

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

Типичный процесс разработки в моём случае

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

В конце концов у всех появляется ощущение, что мы сделали что-то не то. Когда страсти немного утихнут, я произнесу нечто вроде: «Что происходит? Я думал, у вас есть какой-то план». И ребята ответят мне: «Да ты что, мы думали, это у тебя есть план!».

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

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

Сколько времени потребует проект

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

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

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

Организация процессов в Facebook

Я пришёл работать дизайнером в Facebook как раз тогда, когда в компании начался период особенно быстрых изменений. Продукты, которыми раньше занимался один-единственный дизайнер, вдруг обросли огромной инфраструктурой. Они стали приносить миллионы долларов и требовать поддержки сотен разработчиков.

Сейчас каждый дизайнер отвечает лишь за небольшой паззл целого продукта

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

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

Четыре этапа процесса разработки:

1. Понимание — определение проблемы, которую предстоит решить.
2. Моделирование — фокусировка видения и визуальное описание концепта.
3. Построение — проектирование и разработка продукта.
4. Запуск — тестирование и координация с маркетингом.

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

Я решил убедить их, что менее оптимистичный прогноз даст лучшие результаты.

Как я искал доказательства

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

Эти команды, в свою очередь, обновляли статус проекта и добавляли короткие заметки о ключевых событиях за прошедшую неделю (я просил их записывать только важные события, а не перечислять всё, что было сделано).

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

• Когда мы впервые привлекли к проекту разработчика или контент-стратега.
• Когда мы чётко договорились о том, что именно хотим создать.
• Когда мы все согласились с конкретным набором мок-объектов.
• Когда наши исследования принесли наибольшую пользу.
• Когда мы признали, что продукт готов (обычно это отмечается каким-то событием вроде Bug Bash, теста или альфа-запуска).
• Когда мы официально запустили продукт.

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

Реальные сроки отличались от запланированных, особенно для первых этапов проекта.

Поскольку обычно продуктовые менеджеры не делали различий между этапами понимания и моделирования, начальные планы по поводу разработки были очень неясными и часто формулировались просто как «сделать мок-объекты».

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

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

Это проклятое «почти готово»

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

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

Подобные разногласия возникали снова и снова, ведь команды верили, что мок-объекты «почти готовы» и можно спокойно обсуждать детали. Они не замечали, что на самом деле не могли договориться по принципиальным вопросам, связанным с разработкой. Я видел команды, которые настолько зацикливались на этом этапе, что вынуждены были прерывать проект.

Креативный цикл против «спирали смерти»

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

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

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

Как выйти из цикла

Я нашёл два основных способа избежать подобных циклов на мелких итерациях. Один из них — как можно тщательнее выяснить, что нужно разработчику, чтобы создать полезные мок-объекты. Обычно это достигается за счёт чёткого выделения этапа понимания: в это время вы должны выяснить, что именно хотите получить, создавая мок-объекты (на этапе моделирования).

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

Как бы это ни пугало, лучше сразу принять разницу в ожиданиях, чем обнаружить её позже

Когда кто-то знает, что он уже около финишной черты, он не очень-то рвётся её преодолеть.

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

Вот почему исследование и обсуждение процесса разработки стоит ваших усилий.