Shape Up рассказывает в деталях и по шагам, как налажен процесс работы над продуктом в Basecamp от идеи до реализации. Таким образом, чтобы делать действительно ту работу, которая имеет смысл и значение, и делать её вовремя. “Stop Running in Circles and Ship Work that Matters” — это и цель и суть подхода компании.

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

Phases of work

Ключевые идеи

  • Basecamp работают циклами: 6 недель активной работы, потом 2 недели cool-down
  • Работа разделена на два трека: Shaping (предварительная проработка) и Building (непосредственно дизайн в деталях и программирование до релиза)
  • Через Shaping обязательно проходит вся работа
  • Нет бэклога, каждый цикл с чистого листа
  • Устанавливается аппетит (сколько хотим потратить на это), а не сроки (сколько займет то, что хотим сделать)
  • На shaping детализация проработки очень выскоуровневая
  • Если проект не уложился в цикл, выделенное под него время не расширяется (circuit breaker)
  • Декомпозиция важна вокруг фич, а не слоёв (фронт/бэк)
  • Важна прозрачная коммуникация прогресса проекта
  • Не все фичи одинаково полезны, nice-to-have штуки можно и нужно выкидывать

Two tracks

Подробнее

Shaping

Levels of abstraction

  • Этот процесс ведет небольшая группа ключевых людей в компании
  • Проект формируется под срок (от 2 до 6 недель), а не дается оценка под проект
  • Время на проект будет фиксировано, но в деталях скоуп можно варьировать
  • Этап не подразумевает точных требований и прототипов, вместо этого описание + грубые наброски идей (breadboarding и fat marker sketches)
  • Упор на том, чтобы убрать основные риски
  • Детали дизайна оставлены на усмотрение дизайнера на этап активной работы в рамках цикла
  • Явно декларируется, что не входит в рамки проекта
  • На выходе — питч, который фиксирует проблему, аппетит (срок, который готовы потратить на проект), решение, возможные риски (rabbit holes) и то, что в рамки проекта не входит

Betting (выбор проектов на цикл)

We'll never get all this done

  • Бэклога нет, есть betting table, т.е. перед каждым циклом во время 2 недель cool-down узкая группа собирается, смотрит на все питчи и решает, на что сделать ставки (выбрать в работу на цикл)
  • Каждый цикл питчи новые. Если идея не прошла, то надо её пропатчить и делать заход еще раз
  • Состав обычной команды на проект: 1 дизайнер + 1-2 программиста
  • Команда не отвлекается на другие проекты во время цикла (совсем)
  • Если проекты с аппетитом меньше чем 6 недель, то на цикл команда берет несколько и только их
  • Если проект не успели сделать в рамках цикла, он стопается, время на доработку не дается. Нужно доработать питч в Shaping и сделать заход еще раз через цикл.
  • Баги фиксятся в cool-down, либо выносятся как питчи на betting table, если они большие. Еще есть запланированные недели для bug smash — массового убийства багов
  • Выбранные на цикл проекты анонсируются постом в Basecamp

Building

One slice at a time

  • Делегируются не задачи, а полностью ответственность за проект
  • Сделано = задеплоено на пользователей
  • Есть разница между задачами в рамках проекта, которые представляем на старте, и теми, которые обнаруживаются в течение работы (imagined vs. discovered tasks).

Tasks growing

  • Поэтому лучший способ выяснить, как решить задачу — начать ее выполнять.
  • Команда проекта сама разбивает его на scopes (цельные кусочки, которые можно выполнять отдельно) и задачи внутри них
  • Важно быстро сделать что-то, что можно показать и потыкать (get one piece done)
  • И дальше двигаться, выкатывая цельные части, а не отдельно фронт и бэк, например
  • Scopes — это язык проекта, коммуникации идут вокруг них

How's the project coming?

  • Прогресс надо показывать так, чтобы менеджерам не приходилось спрашивать самый тупой вопрос «че как с проектом?»
  • Используют Hill Charts: на каждый проект на рисованном холме отмечаются позиции разных scopes в данный момент времени
  • Если scope на первой половине (uphill — figuring out what to do), то есть еще нераскрытые риски и могут всплыть неприятные детали
  • Если scope на второй половине (downhill — getting it done), то все риски уже покрыты, просто надо дофигачить до прода
  • Важно протолкать все scopes от uphill до downhill как можно скорее

Hill concept

  • Есть задачи must have, а есть nice to have. Последние можно выкидывать, если время цикла поджимает.
  • Scope hammering — чуваки прямо стараются отфигачить скоуп, чтобы он стал меньше, чище, понятнее и делабельнее.
  • Перефигачивать scopes и задачи — это норм.
  • Не надо бояться говорить «я не знаю»
  • QA проверяет только граничные кейсы, в остальном качество — ответственность команды
  • Сравнивать готовность надо не с выдуманным идеальным решением, а с baseline — тем, как пользователи решают задачу сейчас. Если наше решение уже лучше — можно релизить.

Compare to baseline

Мысли от книги

Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже 10 лет, если не больше. Разделяю многие их идеи и философию. При этом могу не соглашаться в каких-то деталях или понимать, что в реалиях конкретной компании или команды что-то работать не будет.

Если в прошлых книгах Basecamp можно найти достаточно количество воды и повторений, тут идеи раскрыты максимально лаконично, сжато и при этом точно.

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

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

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

Самые крутые цитаты

  • Instead of asking how much time it will take to do some work, we ask: How much time do we want to spend? How much is this idea worth?
  • Estimates start with a design and end with a number. Appetites start with a number and end with a design.
  • When teams are more autonomous, senior people can spend less time managing them. With less time spent on management, senior people can shape up better projects. When projects are better shaped, teams have clearer boundaries and so can work more autonomously.
  • At every step of the process we target a specific risk: the risk of not shipping on time.
  • default response to any idea that comes up should be: “Interesting. Maybe some day.” In other words, a very soft “no” that leaves all our options open.
  • When it comes to unclear ideas, the worst offenders are “redesigns” or “refactorings” that aren’t driven by a single problem or use case.
  • In terms of risk, well-shaped work looks like a thin-tailed probability distribution.
  • However, if there are any rabbit holes in the shaping—technical unknowns, unsolved design problems, or misunderstood interdependencies—the project could take multiple times the original appetite to complete.
  • Beware the simple question: “Is this possible?” In software, everything is possible but nothing is free. We want to find out if it’s possible within the appetite we’re shaping for. Instead of asking “is it possible to do X?” ask “is X possible in 6-weeks?” That’s a very different question.
  • Just because somebody thought some idea was important a quarter ago doesn’t mean we need to keep looking at it again and again.
  • Backlogs are big time wasters too. The time spent constantly reviewing, grooming and organizing old ideas prevents everyone from moving forward on the timely projects that really matter right now.
  • It’s easy to overvalue ideas. The truth is, ideas are cheap. They come up all the time and accumulate into big piles. Really important ideas will come back to you. When’s the last time you forgot a really great, inspiring idea?
  • We talk about “betting” instead of planning because it sets different expectations. First, bets have a payout. Second, bets are commitments. Third, a smart bet has a cap on the downside.
  • When people ask for “just a few hours” or “just one day,” don’t be fooled. Momentum and progress are second-order things, like growth or acceleration. You can’t describe them with one point. You need an uninterrupted curve of points. When you pull someone away for one day to fix a bug or help a different team, you don’t just lose a day. You lose the momentum they built up and the time it will take to gain it back. Losing the wrong hour can kill a day. Losing a day can kill a week.
  • The way to really figure out what needs to be done is to start doing real work.
  • We can think of projects in two layers: front-end and back-end, design and code. What we want instead is to pick off one slice of the project to integrate.
  • Organize by structure, not by person
  • Good-hearted managers don’t like asking for status. It’s awkward, feels like nagging, and gets even worse when they have to ask follow-up questions to get sufficiently clear about what’s going on.
  • From an outsider’s perspective, there’s no way to know whether the number of outstanding tasks will go down or up.
  • Pride in the work is important for quality and morale, but we need to direct it at the right target. If we aim for an ideal perfect design, we’ll never get there. At the same time, we don’t want to lower our standards. Instead of comparing up against the ideal, compare down to baseline—the current reality for customers.
  • If we don’t make trade-offs up front by shaping, the universe will force us to make trade-offs later in a mad rush when we’re confronted by deadlines, technical limitations, or resource constraints.

Shape Up доступна в открытом доступе на сайте Basecamp