→
Shape Up — гайд о продуктовой разработке от Basecamp
Публичный пост
15 мая 2022
783
Книга о подходах Basecamp к собственной продуктовой разработке. Необязательно читать полностью, ключевые идеи и техники описаны в этой главе.
Выписал пункты, которые показались мне наиболее любопытными:
- Для оценки будущих фичей в Basecamp используют понятие "аппетита": сначала договариваются, сколько усилий они готовы вложить в реализацию функционала, затем дизайнят решение, чтобы уложиться в оценку.
- Общий бэклог не нужен. Вместо него перед началом спринта проводят "питч-сессию" с участием заинтересованных команд и обсуждают качественно сформулированные актуальные задачи.
- Между спринтами нужны "кулдауны" на 1-2 недели, для спокойного переключения между контекстами, тестирования новых подходов, исправления срочных багов.
- Для улучшения коммуникации внутри команды по статусу отдельных задач используется метафора "холма". Предполагается, что все задачи имеют в себе некоторую неопределенность, которая анализируется и уточняется по мере работы над задачей - при этом мы "поднимаемся на холм". Когда же все неясности вскрыты и задача становится тривиальной - мы начинаем "спускаться с вершины":
Это всё хорошо, когда ты маленькая сверхприбыльная продуктовая компания. В этом случае можно придумать практически любой способ работы и получить высокую эффективность с продуктивностью, если харизматичный владелец обеспечил buy-in у толковой команды, хорошо замотивированной деньгами и другими нематериальными плюшками.
А если что-то из вышеперечисленного (а в реальности, как правило, сразу несколько факторов) отличается — то добро пожаловать в Джиру с нашим старым-добрым Скрамом (в маленьких проектах и компаниях) или SAFe (в больших), который позволяет хоть как-то ехать.
Кстати, эти 6-недельные циклы очень похожи на Product Increment в SAFe. В SAFe ведь команда разработки тоже не видит глобального беклога: доступный им беклог ограничен рамками текущего PI, во время которого стейкхолдеры бодаются за приоритеты своих требований на следующий PI.
"Кулдауны" между PI тоже вполне себе бывают: называются они как-нибудь типа "технический / инженерный спринт" (если посвящены исправлению технического долга) или "хакатон", если их цель — пилот новых технологий или создание некоего PoC.
А вот метафора "холма" вызывает больше всего вопросиков. Они там рисуют её в виде такого нормального распределения, но на деле какие-то задачи будут смещены сильно влево, где исследовательской части почти нет и можно брать и делать. Какие-то задачи будут смещены сильно вправо: у них будет медленное восхождение на холм, а потом сравнительно быстрый спуск. В этом смысле метафора фиксированных по времени спайков мне ближе.
Кстати, их подход с "аппетитом" — это ведь уже известные нам спайки. Когда мы в традиционном софтостроении не хотим убить целый спринт на дизайн решения, но мы и не можем заэстимировать трудозатраты, мы их таймбоксим: договариваемся, что сделаем лучшее из возможного за N дней и будем жить с ним, пока оно не начнём сильно мешать (ну или не взорвётся где-то).
перевод на русский: https://shapeup.vlad.studio/
PDF версия книги: https://basecamp.com/shapeup/shape-up.pdf
Неудобно что нет статусов у todo'шек типа: "in progress", "code review", ..., "done". Вот эти ползунки на холме ставятся "на глаз" и обычно народ забывает обновлять в принципе, на что жалуются манагеры) в кулдаунах как людей не пинай все обычно плюют в потолок) удобно что для каждого проекта есть свой space с доками, бордом и пр.