Shape Up — Часть 2, Принципы шейпинга

От переводчика

Привет! Я Артем, а это мой любительский перевод книги Shape Up от основателей Basecamp. Первая глава тут. Найдете ошибки или опечатки — можете смело писать мне в телеграм. Ну и на телеграм-канал можете подписаться, там буду публиковать главы по ходу перевода. Enjoy 🤘

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

Прототипы слишком детальны

Когда дизайн-лиды начинают с прототипов или детализированных макетов, они слишком рано упарываются в мелкие детали. Они не оставляют дизайнерам пространства для креатива. Один друг описал это так:

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

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

Слова слишком расплывчаты

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

Мы решаем проблем без контекста. Ты должен быть телепатом. Это как: «мы поймем что это то, что нужно, когда увидим это».

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

Пример — Календарь с точками

Давайте посмотрим на пример того, как шейпить проект до нужного уровня детализации.

Мы запустили третью версию Basecamp без календаря. У нас было «Расписание», где списком были представлены события один за одним без возможности разбивки по месяцам, неделям или дням.

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

Вот примеры вещей, которые делают календарь сложным:

- Перетаскивание событий между ячейками

- Отображение многодневных событий

- Разные представления для месяца, недели, дня

- Возможность изменять длительность события, перетаскивая его границу

- Разные цвета для разных категорий событий

- Разные отображения на разных устройствах: ноутбуки, телефоны, и т.д.

В прошлых версиях Basecamp были календари, но только 10% пользователей использовали их. Вот почему у нас не было желания потратить 6 месяцев на календарь. С другой стороны, если бы мы могли решить задачу наших пользователей в течение одного 6-недельного цикла, то почему бы не попробовать?

За 6 недель мы могли сделать только 10% от того, что люди представляют, когда говорят «календарь». Осталось понять, какие именно 10% мы сделаем?

Мы провели исследование (обсудим это в следующей главе) и конкретизировали пользовательский запрос, который мы хотели решить. В итоге мы пришли к многообещающей концепции, вдохновленной календарями на телефонах. Мы могли разработать двух-месячную, нередактируемую календарную сетку. На каждое событие в дне ставилась точка. Список событий располагался под календарем, и клик по дню с точкой скроллил пользователя к событиям этого дня. Мы назвали это «Dot Grid».

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

Вот тот уровень детализации, который мы использовали для определения решения:

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

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

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

Этот небольшой пример подчеркивает несколько важных свойств шейпинга.

Свойство 1 — Это грубо

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

Свойство 2 — Это уже решение

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

Свойство 3 — У решения есть границы

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

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

Кто шейпит?

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

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

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

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

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

Два пути

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

Шаги для шейпинга

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

1. Установите границы. Для начала выясните, сколько времени займет реализация идеи в худшем случае и как решить проблему. Это позволит определить границы.

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

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

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

Часть 3 — Установите границы