Обзор книги “Shape up” (Ryan Singer)

Про то, как ребята из Basecamp управляют продуктом “под капотом”.

Вытащил основные мысли из книги, чтобы вы сэкономили время.

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

Начнем с устройства спринтов и команд, а потом перейдем к процессу, по которому работает команда.

Шестинедельные спринты

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

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

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

Что делаем эти две недели:

• фиксим баги
• подводим итоги предыдущих спринтов
• прорабатываем новые идеи
• и конечно же планируем следующий шестинедельный спринт

Так мы разделяем фокусы и не выгораем.

Команда

Команда в Basecamp состоит из:

• 1 дизайнера
• 1-2 разработчиков
• 1 тестировщика

Работать в течение спринта такой отряд может над одним большим или несколькими маленькими проектами.

Теперь давайте подробнее про процесс работы поговорим

Процесс работы: структура

Наш процесс поставки изменений состоит из нескольких этапов:

• Шейпинг
• Ставки/планирование
• Разработка

Если соотнести с циклом разработки и спринтами, то получится так.

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

Шейпинг

Задача – провалидировать проблему и подготовить основные требования + набросок решения.

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

Для крупных проектов мы выделяем время лидов и скорим их небольшой группой (CEO/CPO, CTO, Design lead). У нас это называется shape или придание формы. На выходе этапа должен появится набросок грубого решения.

Подробнее разложим.

1.Устанавливаем границы

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

Мы используем такой параметр, как “аппетит”. Это штука вбирает в себя трудоемкость и ожидания от проекта. Если не устанавливать ограничения мы можем легко улететь в перфекционизм и выйти за пределы спринта.

Аппетит всегда отталкивается от ограничений (у нас есть 6 недель спринта) и заканчивается дизайном (решение, которое вписывается в ограничения). Так получается держать фокус на том, что действительно важно.

Как мы работаем с аппетитом:

• делим идеи на группы: маленькие (те, что можно затащить за неделю с дизайнером и парой разрабов) и большие (которые нужно пилить все 6 недель)
• убираем эмоции, даже если решение очень нравится, думаем про боль, которую нужно решить и минимальные ресурсы, которые потребуются

Если решение большое и не умещается в 6 недель, то стараемся сузить проблему. Урезаем требования.

Если совсем нереально урезать, то делим решение на крупные куски и раскидываем по 6 недельным спринтам.

Лучшее враг хорошего

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

Отношение к идеям

На старте любая идея для нас – что-то интересное что может случится. Мы не говорим “Да, надо брать!” или “Нет, в бэклог ее, пусть протухнет”. Пока еще идея не проработана, сырая. Вот, когда ее проанализируем, зашейпим, то поймем, чего она на самом деле стоит.

Копаем проблему

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

Сужаем требования

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

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

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

Итак, границы установлены: мы определили грубую идею, аппетит и вытащили задачу, теперь можно переходить к наброскам.

2.Готовим набросок

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

Чтобы процесс занимал оптимальное кол-во времени, нужно учитывать 2 правила:

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

Помимо правил мы используем чек-лист опорных вопросов, который помогает системно собирать наброски:

• Где в существующей системе будет новое решение?
• Как пользователь до него доберется?
• Когда решение само должно добраться до пользователя?
• Какие ключевые элементы взаимодействия будут?

Макетирование

Создавая набросок, мы раскладываем решение на 3 части:

1. Места и навигационные элементы: то, через что пользователь попадет на наше решение (точки входа).
2. Доступ: кнопки/поля/свичи, с которыми мы взаимодействуем внутри решения.
3. Линии связи: показывают путь пользователя, когда он на что-то нажал или ввел внутри решения (эта кнопка ведет сюда).

В итоге получается схема с основной логикой, типа такой.

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

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

3.Прикидываем слабые места

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

Ищем кроличьи норы и риски

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

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

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

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

Идем к тех. эксперту

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

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

4. Пишем речь

Теперь, когда большинство дыр и рисков закрыто, нам необходимо описать решение. Далее мы положим его в общий список с другими проектами и вынесем на планирование “Ставки” (чуть подробнее далее).

Описание проекта внутри Basecamp мы называем “Речью” – это некий формат документа, из которого любой поймет, какую задачу мы решаем и как примерно выглядит решение.

Для написания речи мы используем следующую структуру:

• Проблема. Сценарий пользователя, в котором отчетливо видно боль.
• Аппетит. Сколько времени мы рассчитываем потратить на решение в пределах 6 недель.
• Решение. Скетч блок схемы с логикой. Можно докрутить скринами существующего интерфейса, где маркером грубо нарисованы элементы поверх.
• Кроличьи норы. Детали, про которые надо не забыть, чтобы потом не влететь на кучу проблем. Риски сюда же.
• Куда не ходим. Функциональности, которые НЕ используем в решении, сценарии, которые НЕ покрываем, чтобы не выходить за рамки аппетита.

Описали проект по этой структуре и сложили в список на планирование.

Примерно так выглядит готовая речь по одному проекту/решению.

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

На этом этап Шейпа закончен, и мы переходим к планированию или к Ставкам.

Напомню, что между 6 недельными спринтами у нас есть 2 недели на перерыв. Как раз в этот период мы планируем новые спринты.

Ставки

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

Как это работает:

• накануне шестинедельного спринта в период 2 недельного перерыва мы собираем стейкхолдеров (CEO, CTO, CPO) перед доской
• на доску вывешиваем описание проектов, которые появились за последние 6 недель в формате речей
• голосуем за претендентов на спринт исходя из ограниченмй спринта (6 недель)

Встреча длится 1-2 часа максимум. На ней ключевые люди компании определяют ход развития продукта и сверяют курс. Планирование происходит крайне быстро и эффективно.

Решения, за которые проголосовали и которые не влезают в спринт, идут в следующий.

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

Очень важно! У нас фиксированные спринты и мы не меняем наполнение внутри этого отрезка времени. Если что-то прилетает реально важное, откладываем до планирования. У нас есть обязательства, которые мы взяли на себя, и мы их не оспариваем. Потери от прерывания цикла на деле оказываются гораздо выше, нежели ценность от решения горящего запроса.

Распределенный список задач

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

Возвращение важных идей

Довольно часто мы переоцениваем свои идеи. На практике же, идея стоит немного: сегодня одна пришла, завтра еще три. Реально важные идеи не забываются и вы о них вспомните. А, если не вспомнили к очередному планированию, то точно ли было что-то важное?

Автоматический выключатель

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

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

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

Что с багами

Баги есть и будут всегда, но это не значит, что мы должны прерывать спринт и бежать тушить пожары. Понятно, что все зависит от критичности, если прилетит “подарок”, из-за которого теряются данные или страдает куча пользователей, то мы пофиксим. Но надо понимать, что остановка разработки – самое дорогое, что может быть, да и баги, которые не могут подождать 6 недель появляются очень редко.

У нас есть 3 стратегии, которые мы используем для работы с багами:

1. Две недели между спринтами отлично подходят под исправление багов. Выбираем с командой, что будем фиксить и в спокойном режиме делаем это.
2. Если баг крупный или речь про какой-нибудь рефакторинг, то тащим его на доску ставок перед очередным спринтом. Разрабы готовят речь и точно так же, как и другие задачи все вывешивается на доске.
3. Раз в год планируем “разгром багов”. Выбираем спринт с наибольшим кол-вом календарных праздников, когда пользователи уходят отдыхать и реже заходят в продукт. Фиксим все те штуки, которые постоянно откладывали.

Чистим списки

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

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

Что делать с задачами на 2 и более спринта?

Мы их режем на законченные куски пользовательского опыта и профита. То есть, за спринт нам надо получить эффект, а не кусок кода. Если вторая часть большой задачи победит на очередном планировании, то мы и ее возьмем в работу. А, если нет, то у нас будет возможность для маневра, потому как опять же, все может поменяться за 6 недель.

Образ результата

В зависимости от того, что именно мы делаем:

• допиливаем текущий продукт
• или делаем новый

…формируются ожидания от проекта и планируются работы.

Если допиливаем текущий продукт

То мы:

• скетчим решение
• планируем
• отдаем в команду

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

Если делаем новый

Мы выделяем три режима проработки решений, на каждом из которых, формируем разные ожидания:

• R&D режим – набрасываем вижн нового продукта
• Production режим – детально прорабатываем вижн
• Cleanup режим – вычищаем то, что могли забыть

Коротко про каждый.

R&D режим

1. Вместо ставок на конкретную идею во время планирования, мы ставим на время, которое нужно посветить новому продукту. Максимально верхнеуровневый скетчинг идеи, чтобы нащупать ключевую структуру.
2. Наш старший состав (CEO, CTO и Design Lead) собирается вместе и набрасывает основные части будущего продукта. Прикидывают реализуемость, профит, кроличьи норы.
3. На выходе R&D цикла мы не ожидаем получить готового решения. В лучшем случае это набросок UI скетча и кусок кода, который ляжет в основу работы в будущем.

В конце R&D цикла (6 недель) мы можем отказаться от идеи или же взять ее на очередном планировании в спринт. Сам режим включаем по-необходимости, если чувствуем, что нужно поработать над новым продуктом.

Production режим

После того, как из R&D режима выходит идея, в которую все верят, включается стандартный цикл производства:

• шейпим идею (набрасываем грубое решение + устанавливаем границы)
• пишем речь
• выносим на планирование
• берем в спринт

Но! Не катим на пользователей идею, а скорее мерджим код с основной частью, гоняем внутренние тесты на команде. Так как пользователь у нас ничего не видит, мы можем спокойно отпиливать какие-то фичи, если они нас не устраивают. Это позволяет нам быть гибкими.

Cleanup режим

Скорее всего при разработке идеи мы что-то не учли: баги, стоп сценарии и прочее. Оставляем спринт на чистку этого добра.

Берем снова лидов CEO, CTO, Design Lead и валидируем через них то, что получилось на выходе. Фиксим то, что всплывает на поверхность.

На этом этап ставок и планирования завершен, переходим к разработке.

Разработка

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

• как она будет выглядеть с точки зрения дизайна
• и кода

Туда же в спринт команда закладывает тестирование приоритетных сценариев.

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

Как устроен спринт

Задачи с планирования идут в выбранную команду. Мы закидываем речи с наброском решения в наш трекер Basecamp и цепляем туда назначенную команду.

Первые 3 дня спринта

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

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

Но! Если активность в пространстве команды не наступает спустя 3 дня: народ не переписывается, не закидывает вопросы и материалы по задаче, то стоит зайти внутрь и разобраться, в причинах.

После первых 3 дней

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

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

Поэтому в первые дни:

• дизайнер набрасывает грубый макет на html
• при этом разработчик параллельно готовит код на бэке, чтобы связать это с фронтом и выдать кликабельный прототип решения

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

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

После того как вектор решения утвержден

Команда постепенно детализирует требования:

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

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

Чтобы укрепить скоуп и снизить вероятность неожиданных доработок, мы скорим его через 3 пункта:

1. Смотря на решение/проект целиком, вы видите всю картину целиком. При этом, все штуки, которые могут вас волновать, отражены в тасках внутри.
2. Обсуждение решения проходит легко и непринужденно, потому что все понимают о чем идет речь.
3. Если появляется новая задача, вы с легкостью кладете ее в нужный скоуп.

Помимо того, как мы нарезаем задачи внутри спринта, у нас есть крутой инструмент для отслеживания прогресса – “Диаграмма Холма”.

Диаграмма Холма

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

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

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

Диаграмма Холма встроена в Basecamp, как один из основных элементов рабочего процесса. Трек движения проекта по холму напрямую связан с задачами, из которых он состоит.

В чем еще крутота Холма

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

Что делать с перфекционизмом в спринте

Учитывая, что спринт ограничен, мы понимаем, что выпустить все задачи в идеальном качестве не получится. На какие-то мы сделаем фокус, а какие-то будут в удобоваримом состоянии и это нормально.

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

• Как сейчас решает задачу пользователь без нашего решения?
• Какие еще боли закрывает наше решение?
• Сколько еще мы будем вытачивать решение, пока пользователь закрывает свою задачу костылями?

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

Тесты и кодревью

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

Основная ответственность за качество фич лежит на разработчике и дизайнере. Они в состоянии проверить базовые сценария решения, которые собрали.

Привлечение QA или кодревью это истории про то, что “хорошо бы иметь, но не обязательно”. Мы инвестируем в эти мероприятия время между спринтами. Как раз те 2 недели, когда команде надо выдохнуть и они могут позаниматься тюнингом и качеством.

Когда продлевается спринт

Мы стараемся выдерживать ограничения по времени в спринте, но бывают моменты, когда приходится его растягивать.

Когда мы так делаем:

• когда задача выдержала декомпозицию внутри спринта и осталась среди тех, которые “точно надо сделать”
• когда все основные таски спринта находятся на спуске диаграммы Холма, то есть все проблемы понятны, все проанализировано и нужно тупо доделать

Спринт растягивается на период передышки (2 недели между спринтами), а задачи дотягиваются до релиза.

Но мы всегда стараемся разобраться в причинах сдвига. Где было недоработанно? На этапе наброска решения или на преданализе (подъеме на Холм). В чем именно заключалась проблема и как ее избежать в будущем?

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

Заключение

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

Заключение (от автора блога)

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

Как чуваки разруливают вопросы с отложенным кодревью? Точно ли дизайнер с разработчиком могут сами нормально проверить функционал и не упустить что-то? Хз.

С другой стороны Basecamp довольно мощный продукт с хорошим пользовательским опытом и массового негатива про него я не слышал.

Ребята заточили процесс под себя, да еще и встроили его в свои сервисы, что само по себе является классикой создания продуктов. У нас что-то болит, мы пилим решение под себя, а потом открываем его наружу (привет Jira).

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

Книга понравилась, моя оценка 8/10, а автору респект, что написал про внутреннее мясо.

Алексей А.

---

Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.

---