Про то, как ребята из Basecamp управляют продуктом “под капотом”.
Вытащил основные мысли из книги, чтобы вы сэкономили время.
Пришлось немного пересобрать последовательность блоков, так как в оригинале автор часто возвращался к отдельным моментам, и логика немного рушилась. Повествование будет вестись от первого лица.
Начнем с устройства спринтов и команд, а потом перейдем к процессу, по которому работает команда.
Во многих компаниях живут двухнедельными спринтами, но мы в Basecamp понимаем, что за такой период времени вряд ли получится выпустить что-то значимое. Да и время, которое мы тратим на перепланирование очень затратно для нас. Вот сделали часть задачи в этом спринте, а часть надо запланировать снова, переприоретизация, обсуждения, – сжирается много времени.
Мы выбрали шестинедельные спринты, потому как они с одной стороны позволяют нам катить крупные штуки, с другой, держат нас в тонусе, потому как есть видимый дедлайн.
Спринты между собой разделены двухнедельными перерывами. Конец спринта – худшее время для планирования. Команда разогрета на максималках, чтобы завершить задачи, над которыми работала все время, нужно добить спринт, не растрачивая энергию. Именно поэтому после шестинедельного спринта мы берем две недели на вздох.
Что делаем эти две недели:
Так мы разделяем фокусы и не выгораем.
Команда в Basecamp состоит из:
Работать в течение спринта такой отряд может над одним большим или несколькими маленькими проектами.
Теперь давайте подробнее про процесс работы поговорим
Наш процесс поставки изменений состоит из нескольких этапов:
Если соотнести с циклом разработки и спринтами, то получится так.
Детально пройдемся по каждому шагу.
Задача – провалидировать проблему и подготовить основные требования + набросок решения.
Как и в любой другой компании, у нас постоянно появляются новые идеи. Какие-то тянут на крупный проект, какие-то валятся в бэклог мелочей.
Для крупных проектов мы выделяем время лидов и скорим их небольшой группой (CEO/CPO, CTO, Design lead). У нас это называется shape или придание формы. На выходе этапа должен появится набросок грубого решения.
Подробнее разложим.
Все начинается с того, что мы должны определить сколько потенциально времени может занять реализация и какую проблему надо решить.
Мы используем такой параметр, как “аппетит”. Это штука вбирает в себя трудоемкость и ожидания от проекта. Если не устанавливать ограничения мы можем легко улететь в перфекционизм и выйти за пределы спринта.
Аппетит всегда отталкивается от ограничений (у нас есть 6 недель спринта) и заканчивается дизайном (решение, которое вписывается в ограничения). Так получается держать фокус на том, что действительно важно.
Как мы работаем с аппетитом:
Если решение большое и не умещается в 6 недель, то стараемся сузить проблему. Урезаем требования.
Если совсем нереально урезать, то делим решение на крупные куски и раскидываем по 6 недельным спринтам.
Лучшее враг хорошего
С учетом аппетита и ограничений смотрим на решение через призму времени, которое можем на него потратить. Если эта форма для сбора имейлов нам так нужна, то мы выделим на неё больше времени, но все в тех же ограничениях спринта.
Отношение к идеям
На старте любая идея для нас – что-то интересное что может случится. Мы не говорим “Да, надо брать!” или “Нет, в бэклог ее, пусть протухнет”. Пока еще идея не проработана, сырая. Вот, когда ее проанализируем, зашейпим, то поймем, чего она на самом деле стоит.
Копаем проблему
Если от клиентов прилетает конкретный запрос, то мы не бросаемся сразу делать его. Надо погрузиться и вытащить проблему, которая требует решения, а не бежать сломя голову пилить тяжелое и дорогое решение. Часто, докопавшись до сути, можно легко и дешево решить запрос.
Сужаем требования
Если мы докопались до конкретной проблемы, то как должно выглядеть решение, если у нас есть всего 6 недель в спринте?
Друзья, я веду telegram канал, где публикую анонсы свежих материалов, плюс выкладываю интересные хаки и кейсы, которых нет на сайте. Подписывайтесь, буду рад видеть. Всё, не отвлекаю от чтения 😉
Как правило, пользователь не приходит с запросом, хочу новый Outlook. Скорее речь про то, что нужно закрыть задачу “написать сообщение/принять сообщение”, отсюда и скоуп работ можно сократить, не раздувая огромный сервис.
Итак, границы установлены: мы определили грубую идею, аппетит и вытащили задачу, теперь можно переходить к наброскам.
Обычно мы стараемся набросать блок схему с основной логикой, из которой команда поймет, что примерно надо будет делать и в каких границах. По сути, это крупные функциональные куски, связанные между собой пользовательским сценарием.
Чтобы процесс занимал оптимальное кол-во времени, нужно учитывать 2 правила:
Помимо правил мы используем чек-лист опорных вопросов, который помогает системно собирать наброски:
Макетирование
Создавая набросок, мы раскладываем решение на 3 части:
В итоге получается схема с основной логикой, типа такой.
Бывает так, что подобного уровня абстракции недостаточно и нужно более детально описать решение. В таком случае, берем в руки маркер и рисуем кнопки/формы с чуть лучшей детализацией, но не забываем про скорость. Можно брать скрины боевого интерфейса и поверх него прямо рисовать будущее решение.
После того, как скетч готов, в работу вступают дизайнеры. Их задача уже превратить набросок в макет решения.
Дабы усилить решение и не отдавать в команду что-то сырое, мы стараемся укрепить его. Шлифуем, убирая лишние куски или добавляем что-то, закрывая дыры. Держим фокус на том, чтобы при разработке команда тратила меньше времени на реализацию.
Ищем кроличьи норы и риски
Зависимости и риски, которые могут помешать решению выйти в срок, должны быть проработаны сразу. Это поможет команде быстрее двигаться в спринте.
Круто помогает прохождение сценариев пользователей в замедленном режиме. Представьте себя пользователем и идите прямо по новому решению (наброску с линиями). В процессе задавайте следующие вопросы:
Таким образом решение делится на ряд функций. Расставляем по ним приоритеты, выстривакм их в очередь и не забываем про аппетит.
Идем к тех. эксперту
После того, как набросок собран его нужно обстучать с тех.специалистом. Идем к разрабу, объясняем идею и спрашиваем реально ли уложиться за 6 недель.
На выходе решение может быть скорректировано. Например, отрежем часть неважных функций или упростим дизайн, чтобы вписаться в спринт.
Теперь, когда большинство дыр и рисков закрыто, нам необходимо описать решение. Далее мы положим его в общий список с другими проектами и вынесем на планирование “Ставки” (чуть подробнее далее).
Описание проекта внутри Basecamp мы называем “Речью” – это некий формат документа, из которого любой поймет, какую задачу мы решаем и как примерно выглядит решение.
Для написания речи мы используем следующую структуру:
Описали проект по этой структуре и сложили в список на планирование.
Примерно так выглядит готовая речь по одному проекту/решению.
По сути, речь можно легко упаковать в какой-нибудь notion, confluence или обычный док, лишь бы было откуда достать потом для планирования.
На этом этап Шейпа закончен, и мы переходим к планированию или к Ставкам.
Напомню, что между 6 недельными спринтами у нас есть 2 недели на перерыв. Как раз в этот период мы планируем новые спринты.
В Basecamp мы не любим бэклоги, потому что они с одной стороны заставляют нас чувствовать, что мы постоянно отстаем (много НЕ сделано), хотя это не так. С другой, задачи, которые были важны в прошлом квартале, не факт, что важны сегодня. Вместо бэклогов мы используем “Доску ставок”.
Как это работает:
Встреча длится 1-2 часа максимум. На ней ключевые люди компании определяют ход развития продукта и сверяют курс. Планирование происходит крайне быстро и эффективно.
Решения, за которые проголосовали и которые не влезают в спринт, идут в следующий.
В конце встречи назначаются дизы и разработчики под каждую выбранную задачу в спринт. Лиды понимают кого лучше всего аллоцировать на активность.
Очень важно! У нас фиксированные спринты и мы не меняем наполнение внутри этого отрезка времени. Если что-то прилетает реально важное, откладываем до планирования. У нас есть обязательства, которые мы взяли на себя, и мы их не оспариваем. Потери от прерывания цикла на деле оказываются гораздо выше, нежели ценность от решения горящего запроса.
Внутри спринта между разными департаментами может проходить кросс-опыление задач. Поддержка может прийти к продактам и обсудить баги, которые надо будет приоритезировать на планировании. То же самое продакты могут к разрабам зайти и обсудить очередную доработку.
Довольно часто мы переоцениваем свои идеи. На практике же, идея стоит немного: сегодня одна пришла, завтра еще три. Реально важные идеи не забываются и вы о них вспомните. А, если не вспомнили к очередному планированию, то точно ли было что-то важное?
Если задачу не успевают сделать за 6 недель, то мы не продолжаем разработку, а переключаемся на следующий проект. Это суровое, но справедливое правило, которое позволяет командам быть максимально сфокусированными и не выходить за рамки спринта.
Для нас важно разобраться в причинах факапа, и мы пытаемся понять, где была допущена ошибка. Возможно на преданализе что-то не учли или какая-то кроличья нора просочилась в решение.
Такой подход позволяет командам быть более ответственными за то, что они делают. Ребята могут решить от каких деталей отказаться в процессе разработки в пользу релиза всего проекта. Отсюда развивается навык принятия решений и растет уровень зрелости внутри команд.
Баги есть и будут всегда, но это не значит, что мы должны прерывать спринт и бежать тушить пожары. Понятно, что все зависит от критичности, если прилетит “подарок”, из-за которого теряются данные или страдает куча пользователей, то мы пофиксим. Но надо понимать, что остановка разработки – самое дорогое, что может быть, да и баги, которые не могут подождать 6 недель появляются очень редко.
У нас есть 3 стратегии, которые мы используем для работы с багами:
Для эффективного планирования спринтов крайне важно обновлять списки задач на доске со ставками. Если мы постоянно будем возвращаться к одному и тому же, значит велика вероятность, что продукт потеряет актуальность рынку.
Мы не знаем, что будет важно через 6 недель. Не догадываемся о том, какая гениальная идея может возникнуть и как изменится контекст. Поэтому мы всегда готовы представить на очередном планировании новую идею.
Мы их режем на законченные куски пользовательского опыта и профита. То есть, за спринт нам надо получить эффект, а не кусок кода. Если вторая часть большой задачи победит на очередном планировании, то мы и ее возьмем в работу. А, если нет, то у нас будет возможность для маневра, потому как опять же, все может поменяться за 6 недель.
В зависимости от того, что именно мы делаем:
…формируются ожидания от проекта и планируются работы.
Если допиливаем текущий продукт
То мы:
… и ожидаем, что в конце спринта нам выдадут версию заявленного решения.
Если делаем новый
Мы выделяем три режима проработки решений, на каждом из которых, формируем разные ожидания:
Коротко про каждый.
R&D режим
В конце R&D цикла (6 недель) мы можем отказаться от идеи или же взять ее на очередном планировании в спринт. Сам режим включаем по-необходимости, если чувствуем, что нужно поработать над новым продуктом.
Production режим
После того, как из R&D режима выходит идея, в которую все верят, включается стандартный цикл производства:
Но! Не катим на пользователей идею, а скорее мерджим код с основной частью, гоняем внутренние тесты на команде. Так как пользователь у нас ничего не видит, мы можем спокойно отпиливать какие-то фичи, если они нас не устраивают. Это позволяет нам быть гибкими.
Cleanup режим
Скорее всего при разработке идеи мы что-то не учли: баги, стоп сценарии и прочее. Оставляем спринт на чистку этого добра.
Берем снова лидов CEO, CTO, Design Lead и валидируем через них то, что получилось на выходе. Фиксим то, что всплывает на поверхность.
На этом этап ставок и планирования завершен, переходим к разработке.
После того, как ставки сделаны, и мы выбрали задачи для спринта, приходит время имплементации. На текущем шаге, мы полностью отдаем задачу в команду вместе с ответственностью за то:
Туда же в спринт команда закладывает тестирование приоритетных сценариев.
Важно! Мы не просим команду во время спринта документировать код, писать маркетинговые анонсы и прочее. Обычно мы оставляем это на период между спринтами, там как раз есть время на это, но не тогда, когда все должны концентрироваться на релизе.
Задачи с планирования идут в выбранную команду. Мы закидываем речи с наброском решения в наш трекер Basecamp и цепляем туда назначенную команду.
Первые 3 дня спринта
Мы отдаем на подумать. Разработчики уходят в код и прикидывают, как можно его затащить. Дизы планируют процесс проектирования.
Очень важно не давить на людей в это время, потому как основная их задача – организовать процесс своей работы. В противном случае все понесутся сломя голову пилить очередную фичу, а потом будут наступать на грабли, которых можно было избежать.
Но! Если активность в пространстве команды не наступает спустя 3 дня: народ не переписывается, не закидывает вопросы и материалы по задаче, то стоит зайти внутрь и разобраться, в причинах.
После первых 3 дней
Команды нарезают задачи, из которых будет собрано решение. Фокус делается на скорость поставки чего-то осязаемого без идеального дизайна.
Мы понимаем, что чем раньше дизайнер и менеджеры смогут “пощупать” решение, тем быстрее мы получим обратную связь и поймем туда ли мы двигаемся.
Поэтому в первые дни:
Далее дизайнер проводит демо для менеджеров/заказчиков и собирает обратную связь. Таким образом, те, кто заказывал решение, ровно как и команда, чувствуют прогресс и могут быстро доработать решение.
Еще круто то, что пока дизайнер показывает грубое решение, разработчик может работать на бэке и собирать целевую логику решения. Описанной речи и наброска вполне достаточно, чтобы работать “под капотом”.
После того как вектор решения утвержден
Команда постепенно детализирует требования:
Мы понимаем, что на старте спринта, команда вряд ли сможет учесть все зависимости. Скорее всего в процессе выполнения микрозадач обнаружатся связи и список по итогу разрастется.
Чтобы укрепить скоуп и снизить вероятность неожиданных доработок, мы скорим его через 3 пункта:
Помимо того, как мы нарезаем задачи внутри спринта, у нас есть крутой инструмент для отслеживания прогресса – “Диаграмма Холма”.
Представьте себе холм, у которого с одной стороны есть подъем, с другой спуск. Наша задача – подняться на него с одной стороны и спуститься с другой.
Когда мы поднимаемся, то не видим, что за ним находится и сколько времени займет спуск. Но, когда мы на вершине, становится понятно, как выглядит спуск, и мы можем прикинуть сколько осталось.
Точно также работает с проектами. Когда проект начинается, мы ничего не знаем про то, на сколько он сложный и сколько потребуется времени. Мы делаем преданализ, декомпозируем его на задачи и в конечном счете достигаем “вершины холма”, после которой остается только “спускаться”, то есть непосредственно делать проект.
Диаграмма Холма встроена в Basecamp, как один из основных элементов рабочего процесса. Трек движения проекта по холму напрямую связан с задачами, из которых он состоит.
В чем еще крутота Холма
Когда команда декомпозировала проект на задачи, она видит, что в начале все таски лежат у подножия Холма. Но, погрузившись чуть глубже, становится понятно, что в скоупе могут быть вещи, которые никто никогда не делал, а значит, есть риск не уложиться в спринт. Поэтому, вначале спринта фокус делается на самые сложные штуки, которые надо дотащить до вершины. Понятные/простые задачи идут после. Это позволяет снять львиную долю рисков и с большей вероятностью затащить проект вовремя.
Учитывая, что спринт ограничен, мы понимаем, что выпустить все задачи в идеальном качестве не получится. На какие-то мы сделаем фокус, а какие-то будут в удобоваримом состоянии и это нормально.
Чтобы не сваливаться в перфекционизм мы сравниваем решение не с идеалом, а с тем, что есть сейчас у пользователя:
Ответы на эти вопросы помогают командам не уходить в перфекционизм и держать баланс необходимого качества.
В нашем процессе тестирование и кодревью не является обязательными этапами спринта. Мы понимаем, что это важные части поставки, но не стоп факторы для выпуска задач.
Основная ответственность за качество фич лежит на разработчике и дизайнере. Они в состоянии проверить базовые сценария решения, которые собрали.
Привлечение QA или кодревью это истории про то, что “хорошо бы иметь, но не обязательно”. Мы инвестируем в эти мероприятия время между спринтами. Как раз те 2 недели, когда команде надо выдохнуть и они могут позаниматься тюнингом и качеством.
Мы стараемся выдерживать ограничения по времени в спринте, но бывают моменты, когда приходится его растягивать.
Когда мы так делаем:
Спринт растягивается на период передышки (2 недели между спринтами), а задачи дотягиваются до релиза.
Но мы всегда стараемся разобраться в причинах сдвига. Где было недоработанно? На этапе наброска решения или на преданализе (подъеме на Холм). В чем именно заключалась проблема и как ее избежать в будущем?
Подобной практики “продления” мы стараемся избегать, но реальность такова, что такое случается. Поэтому время между спринтами нас спасает.
На этом описание наших процессов заканчивается. Понятно, что Basecamp не идеален и мы постоянно что-то допиливаем, но те практики, которые описаны выше, помогают нам, а значит могут помочь и другим.
Пока я читал книгу мне было сложно натянуть процессы Basecamp на свои продукты. Длинные спринты, отсутствие тестировщика внутри команды и прочие штуки никак не укладывались в моей голове.
Как чуваки разруливают вопросы с отложенным кодревью? Точно ли дизайнер с разработчиком могут сами нормально проверить функционал и не упустить что-то? Хз.
С другой стороны Basecamp довольно мощный продукт с хорошим пользовательским опытом и массового негатива про него я не слышал.
Ребята заточили процесс под себя, да еще и встроили его в свои сервисы, что само по себе является классикой создания продуктов. У нас что-то болит, мы пилим решение под себя, а потом открываем его наружу (привет Jira).
Определенно часть процессных практик можно брать себе на вооружение, если откликается внутри. Для проектного управления так точно, а там уже все равно придется допиливать.
Книга понравилась, моя оценка 8/10, а автору респект, что написал про внутреннее мясо.
Алексей А.
Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.
Продуктовый подход в управлении IT продуктами: Как извлечь максимальную пользу и избежать распространенных ошибок. (далее…)
Что такое продуктовая команда? Зачем она нужна и какие задачи должна решать? (далее…)
Что такое культура компании? Зачем она нужна и какие задачи решает? Подготовил алгоритм сборки, поделюсь.…
На этой странице я собрал все семинары, которые когда-либо разрабатывал и проводил. Каждый из них,…
Какой должна быть оценка компетенций и как выстроить систему на примере продакт менеджеров. (далее…)
