Shape Up — гайд о продуктовой разработке от Basecamp

 Публичный пост

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

Выписал пункты, которые показались мне наиболее любопытными:

  1. Для оценки будущих фичей в Basecamp используют понятие "аппетита": сначала договариваются, сколько усилий они готовы вложить в реализацию функционала, затем дизайнят решение, чтобы уложиться в оценку.
  2. Общий бэклог не нужен. Вместо него перед началом спринта проводят "питч-сессию" с участием заинтересованных команд и обсуждают качественно сформулированные актуальные задачи.
  3. Между спринтами нужны "кулдауны" на 1-2 недели, для спокойного переключения между контекстами, тестирования новых подходов, исправления срочных багов.
  4. Для улучшения коммуникации внутри команды по статусу отдельных задач используется метафора "холма". Предполагается, что все задачи имеют в себе некоторую неопределенность, которая анализируется и уточняется по мере работы над задачей - при этом мы "поднимаемся на холм". Когда же все неясности вскрыты и задача становится тривиальной - мы начинаем "спускаться с вершины":

4 комментария 👇
Захар Кириллов , Амбассадор ЕРАМ в Клубе 15 мая в 13:04

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

А если что-то из вышеперечисленного (а в реальности, как правило, сразу несколько факторов) отличается — то добро пожаловать в Джиру с нашим старым-добрым Скрамом (в маленьких проектах и компаниях) или SAFe (в больших), который позволяет хоть как-то ехать.

Кстати, эти 6-недельные циклы очень похожи на Product Increment в SAFe. В SAFe ведь команда разработки тоже не видит глобального беклога: доступный им беклог ограничен рамками текущего PI, во время которого стейкхолдеры бодаются за приоритеты своих требований на следующий PI.

"Кулдауны" между PI тоже вполне себе бывают: называются они как-нибудь типа "технический / инженерный спринт" (если посвящены исправлению технического долга) или "хакатон", если их цель — пилот новых технологий или создание некоего PoC.

А вот метафора "холма" вызывает больше всего вопросиков. Они там рисуют её в виде такого нормального распределения, но на деле какие-то задачи будут смещены сильно влево, где исследовательской части почти нет и можно брать и делать. Какие-то задачи будут смещены сильно вправо: у них будет медленное восхождение на холм, а потом сравнительно быстрый спуск. В этом смысле метафора фиксированных по времени спайков мне ближе.

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

  Развернуть 1 комментарий
Denis Litovskikh , Head of IT service management team 17 мая в 10:04

перевод на русский: https://shapeup.vlad.studio/

  Развернуть 1 комментарий

PDF версия книги: https://basecamp.com/shapeup/shape-up.pdf

  Развернуть 1 комментарий

Неудобно что нет статусов у todo'шек типа: "in progress", "code review", ..., "done". Вот эти ползунки на холме ставятся "на глаз" и обычно народ забывает обновлять в принципе, на что жалуются манагеры) в кулдаунах как людей не пинай все обычно плюют в потолок) удобно что для каждого проекта есть свой space с доками, бордом и пр.

  Развернуть 1 комментарий

😎

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

Что вообще здесь происходит?


Войти  или  Вступить в Клуб