# Книга Shape Up — как доводить продуктовые проекты до выпуска

Канонический адрес: https://producthub.live/shape-up
Автор публикации: Product Hub (https://producthub.ru). Опубликовано: 2026-10-13. Обновлено: 2026-10-13.
Книга: Ryan Singer (Райан Сингер), «Shape Up: Stop Running in Circles and Ship Work that Matters», Basecamp, 2019. Оригинал: https://basecamp.com/shapeup

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

В книге Райан Сингер описывает работу Basecamp шестинедельными циклами: как прорабатывать идеи до запуска, превращать их в работающий результат и вовремя останавливаться. Здесь выбранные главы собраны в три части. Читайте подряд или открывайте нужный раздел в оглавлении.

## Оглавление

**Часть 1. Подготовить выполнимый проект**
- [Глава 1. Определить глубину проработки](https://producthub.live/shape-up/1-opredelit-glubinu-prorabotki)
  - [Каркасы интерфейса слишком конкретны](https://producthub.live/shape-up/karkasy-interfeysa-slishkom-konkretny)
  - [Слова слишком абстрактны](https://producthub.live/shape-up/slova-slishkom-abstraktny)
  - [Пример: календарь с сеткой точек](https://producthub.live/shape-up/primer-kalendar-s-setkoy-tochek)
  - [Свойство 1: черновой вид](https://producthub.live/shape-up/svoystvo-1-chernovoy-vid)
  - [Свойство 2: решение продумано](https://producthub.live/shape-up/svoystvo-2-reshenie-produmano)
  - [Свойство 3: границы определены](https://producthub.live/shape-up/svoystvo-3-granitsy-opredeleny)
  - [Кто занимается проработкой](https://producthub.live/shape-up/kto-zanimaetsya-prorabotkoy)
  - [Два потока](https://producthub.live/shape-up/dva-potoka)
  - [Этапы проработки](https://producthub.live/shape-up/etapy-prorabotki)
- [Глава 2. Задать границы](https://producthub.live/shape-up/2-zadat-granitsy)
  - [Определите аппетит](https://producthub.live/shape-up/opredelite-appetit)
  - [Фиксированное время, переменный объём](https://producthub.live/shape-up/fiksirovannoe-vremya-peremennyy-obem)
  - [«Хорошо» — понятие относительное](https://producthub.live/shape-up/khorosho-ponyatie-otnositelnoe)
  - [Как отвечать на сырые идеи](https://producthub.live/shape-up/kak-otvechat-na-syrye-idei)
  - [Сузьте проблему](https://producthub.live/shape-up/suzte-problemu)
  - [Пример: что подразумевается под «календарём»](https://producthub.live/shape-up/primer-chto-podrazumevaetsya-pod-kalendarem)
  - [Остерегайтесь сборных мешков](https://producthub.live/shape-up/osteregaytes-sbornykh-meshkov)
  - [Границы заданы](https://producthub.live/shape-up/granitsy-zadany)
- [Глава 3. Найти устройство решения](https://producthub.live/shape-up/3-nayti-ustroystvo-resheniya)
  - [Двигайтесь с подходящей скоростью](https://producthub.live/shape-up/dvigaytes-s-podkhodyashchey-skorostyu)
  - [Схемы взаимодействия](https://producthub.live/shape-up/skhemy-vzaimodeystviya)
  - [Пример](https://producthub.live/shape-up/primer)
  - [Эскизы толстым маркером](https://producthub.live/shape-up/eskizy-tolstym-markerom)
  - [Результат — это элементы](https://producthub.live/shape-up/rezultat-eto-elementy)
  - [Пространство для дизайнеров](https://producthub.live/shape-up/prostranstvo-dlya-dizaynerov)
  - [Пока не готово к передаче](https://producthub.live/shape-up/poka-ne-gotovo-k-peredache)
  - [Никакого конвейера](https://producthub.live/shape-up/nikakogo-konveyera)
- [Глава 4. Проверить риски](https://producthub.live/shape-up/4-proverit-riski)
  - [Разные категории риска](https://producthub.live/shape-up/raznye-kategorii-riska)
  - [Ищите кроличьи норы](https://producthub.live/shape-up/ishchite-krolichi-nory)
  - [Пример: закрываем пробел](https://producthub.live/shape-up/primer-zakryvaem-probel)
  - [Обозначьте, что остаётся за рамками](https://producthub.live/shape-up/oboznachte-chto-ostaetsya-za-ramkami)
  - [Сокращайте](https://producthub.live/shape-up/sokrashchayte)
  - [Покажите техническим экспертам](https://producthub.live/shape-up/pokazhite-tekhnicheskim-ekspertam)
  - [Риски снижены — можно описывать](https://producthub.live/shape-up/riski-snizheny-mozhno-opisyvat)

**Часть 2. Получить работающий результат**
- [Глава 5. Собрать первый рабочий фрагмент](https://producthub.live/shape-up/5-sobrat-pervyy-rabochiy-fragment)
  - [Соедините слои в одном фрагменте](https://producthub.live/shape-up/soedinite-sloi-v-odnom-fragmente)
  - [Пример: клиенты в проектах](https://producthub.live/shape-up/primer-klienty-v-proektakh)
  - [Программистам не нужно ждать](https://producthub.live/shape-up/programmistam-ne-nuzhno-zhdat)
  - [Сначала возможности действия, затем экраны, выверенные до пикселя](https://producthub.live/shape-up/snachala-vozmozhnosti-deystviya-zatem-ekrany-vyverennye)
  - [Пишите ровно столько кода, сколько нужно для следующего шага](https://producthub.live/shape-up/pishite-rovno-stolko-koda-skolko-nuzhno)
  - [Начинайте с середины](https://producthub.live/shape-up/nachinayte-s-serediny)
- [Глава 6. Разделить проект на участки работы](https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty)
  - [Организуйте работу по структуре, а не по людям](https://producthub.live/shape-up/organizuyte-rabotu-po-strukture-a-ne)
  - [Карта участков работы](https://producthub.live/shape-up/karta-uchastkov-raboty)
  - [Язык проекта](https://producthub.live/shape-up/yazyk-proekta)
  - [Пример: черновики сообщений](https://producthub.live/shape-up/primer-chernoviki-soobshcheniy)
  - [Обнаружение участков работы](https://producthub.live/shape-up/obnaruzhenie-uchastkov-raboty)
  - [Как понять, что участки определены правильно](https://producthub.live/shape-up/kak-ponyat-chto-uchastki-opredeleny-pravilno)
  - [Слоёные пироги](https://producthub.live/shape-up/sloenye-pirogi)
  - [Айсберги](https://producthub.live/shape-up/aysbergi)
  - [Похлёбка](https://producthub.live/shape-up/pokhlebka)
  - [Помечайте желательные задачи знаком ~](https://producthub.live/shape-up/pomechayte-zhelatelnye-zadachi-znakom)
- [Глава 7. Отслеживать неопределённость и прогресс](https://producthub.live/shape-up/7-otslezhivat-neopredelennost-i-progress)
  - [Задачи, которых нет](https://producthub.live/shape-up/zadachi-kotorykh-net)
  - [Оценки не показывают неопределённость](https://producthub.live/shape-up/otsenki-ne-pokazyvayut-neopredelennost)
  - [Работа похожа на холм](https://producthub.live/shape-up/rabota-pokhozha-na-kholm)
  - [Участки работы на холме](https://producthub.live/shape-up/uchastki-raboty-na-kholme)
  - [Состояние работы без вопросов](https://producthub.live/shape-up/sostoyanie-raboty-bez-voprosov)
  - [Никто не говорит «Я не знаю»](https://producthub.live/shape-up/nikto-ne-govorit-ya-ne-znayu)
  - [Повод пересмотреть участки работы](https://producthub.live/shape-up/povod-peresmotret-uchastki-raboty)
  - [Поднимайтесь по холму, создавая работающий результат](https://producthub.live/shape-up/podnimaytes-po-kholmu-sozdavaya-rabotayushchiy-rezultat)
  - [Решайте проблемы в правильной последовательности](https://producthub.live/shape-up/reshayte-problemy-v-pravilnoy-posledovatelnosti)

**Часть 3. Завершить вовремя и двигаться дальше**
- [Глава 8. Определить достаточный результат](https://producthub.live/shape-up/8-opredelit-dostatochnyy-rezultat)
  - [Сравнивайте с исходным положением](https://producthub.live/shape-up/sravnivayte-s-iskhodnym-polozheniem)
  - [Ограничения побуждают выбирать компромиссы](https://producthub.live/shape-up/ogranicheniya-pobuzhdayut-vybirat-kompromissy)
  - [Объём работы растёт, как трава](https://producthub.live/shape-up/obem-raboty-rastet-kak-trava)
  - [Сокращать объём — не значит снижать качество](https://producthub.live/shape-up/sokrashchat-obem-ne-znachit-snizhat-kachestvo)
  - [Жёстко сокращайте объём](https://producthub.live/shape-up/zhestko-sokrashchayte-obem)
  - [QA — для пограничных случаев](https://producthub.live/shape-up/qa-dlya-pogranichnykh-sluchaev)
  - [Когда продлевать проект](https://producthub.live/shape-up/kogda-prodlevat-proekt)
- [Глава 9. Работать с обратной связью после выпуска](https://producthub.live/shape-up/dayte-bure-utikhnut)
  - [Дайте буре утихнуть](https://producthub.live/shape-up/dayte-bure-utikhnut)
  - [Не набирайте долгов](https://producthub.live/shape-up/ne-nabirayte-dolgov)
  - [Обратную связь тоже нужно проработать](https://producthub.live/shape-up/obratnuyu-svyaz-tozhe-nuzhno-prorabotat)

## Часть 1. Подготовить выполнимый проект

### Глава 1. Определить глубину проработки

Адрес: https://producthub.live/shape-up/1-opredelit-glubinu-prorabotki

![Проработанное решение находится между абстрактным и конкретным](https://producthub.live/assets/books/shape-up/light/p015-01.webp)

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

#### Каркасы интерфейса слишком конкретны

Адрес: https://producthub.live/shape-up/karkasy-interfeysa-slishkom-konkretny

Когда руководители дизайна сразу переходят к каркасам интерфейса — вайрфреймам — или детальным макетам, они слишком рано определяют слишком много деталей. Дизайнерам не остаётся пространства для творчества. Один мой знакомый описал это так:

> Я даю дизайнеру вайрфрейм, а потом говорю ей: «Я знаю, что ты на него смотришь, но я не хочу, чтобы ты спроектировала именно это. Я хочу, чтобы ты переосмыслила решение!» Трудно добиться этого, когда ты даёшь человеку такую конкретную вещь.

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

#### Слова слишком абстрактны

Адрес: https://producthub.live/shape-up/slova-slishkom-abstraktny

Другая крайность — слишком расплывчатые проекты — тоже не работает. Когда проект определён несколькими словами, никто не знает, что они означают. «Сделать календарный вид» или «добавить групповые уведомления» звучит разумно, но что именно за этим стоит? У участников команды недостаточно информации, чтобы выбирать компромиссы. Они не знают, что включить, а что исключить. Программист, работавший в таких условиях, сказал:

> Ты решаешь проблему без контекста. Нужно уметь читать мысли. Примерно так: «Когда увидим, тогда и поймём, что нам нужно».

Что касается оценок, недостаточно определённые проекты закономерно разрастаются и выходят из-под контроля: нет границы, которая показывает, что остаётся за рамками проекта.

#### Пример: календарь с сеткой точек

Адрес: https://producthub.live/shape-up/primer-kalendar-s-setkoy-tochek

Посмотрим на пример проработки проекта с правильным уровнем детализации.

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

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

Вот что делает календарь сложным:

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

В предыдущих версиях Basecamp календари были, и ими пользовалось лишь около 10% клиентов. Поэтому у нас не было аппетита потратить на календарь шесть месяцев. С другой стороны, мы были готовы что-то сделать, если смогли бы удовлетворить клиентов, которые нам писали, за один шестинедельный цикл.

> **Редакторское пояснение.** «Аппетит» — время, которое мы готовы выделить проекту, а не прогноз того, сколько он займёт. Цикл — период реализации; в Basecamp он длится шесть недель. За него команда выпускает один проработанный проект или несколько небольших. Ей выделяют этот срок без отвлечений на другую работу, кроме настоящих кризисов.

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

Мы провели исследование — о нём в [главе 2 «Задать границы»](https://producthub.live/shape-up/2-zadat-granitsy) — и выделили конкретный сценарий, для которого хотели найти решение. В итоге мы пришли к многообещающей концепции, вдохновлённой календарями в телефонах. Можно сделать сетку на два месяца, доступную только для просмотра. В дни с событиями каждое событие отмечалось бы точкой. Под календарём располагался бы список событий; нажатие на день с точкой прокручивало бы список до событий этого дня. Мы назвали это «сеткой точек» — Dot Grid.

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

Вот с каким уровнем детализации мы определили решение:

![Грубый эскиз концепции сетки точек](https://producthub.live/assets/books/shape-up/light/p017-01.webp)

*Грубый эскиз концепции сетки точек.*

Обратите внимание, насколько эскиз грубый и сколько деталей опущено. У дизайнера оставалось много свободы решить, как всё это должно выглядеть и ощущаться при использовании.

В то же время обратите внимание, насколько конкретна сама идея. Совершенно ясно, как она работает, что нужно сделать, что входит в проект, а что нет.

К концу проекта результат работы дизайнеров и программистов выглядел так:

![Снимок экрана с сеткой точек на момент выпуска](https://producthub.live/assets/books/shape-up/light/p018-01.webp)

*Снимок экрана с сеткой точек на момент выпуска.*

Этот небольшой пример показывает несколько свойств проработанной работы.

#### Свойство 1: черновой вид

Адрес: https://producthub.live/shape-up/svoystvo-1-chernovoy-vid

На этапе проработки работа выглядит черновой. Любой сразу видит, что она не закончена. Видны свободные места, куда предстоит внести свой вклад. Слишком тщательно выполненная работа на слишком раннем этапе привязывает всех к не тем деталям. Дизайнерам и программистам нужно пространство, чтобы применить собственные суждения и опыт, когда они засучат рукава и обнаружат все реальные компромиссы, которые возникнут по ходу дела.

#### Свойство 2: решение продумано

Адрес: https://producthub.live/shape-up/svoystvo-2-reshenie-produmano

Хотя проработанная работа выглядит грубо и незавершённо, она продумана. Все основные элементы решения определены на общем уровне и связаны друг с другом. Работа не расписана до отдельных задач, но решение в целом изложено. Неожиданности ещё могут случиться, и айсберги ещё могут всплыть, однако есть ясное направление, указывающее, что делать. Все открытые вопросы и кроличьи норы, которые мы смогли заметить заранее, устранены, чтобы снизить риск проекта.

> **Редакторское пояснение.** Кроличья нора — неизвестная, слишком сложная или неограниченная часть проекта, в которой можно увязнуть. Айсберг — несоразмерность видимой и скрытой работы: например, небольшое изменение интерфейса требует большого объёма серверной логики. Подробные примеры айсбергов разобраны в [главе 6](https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty).

#### Свойство 3: границы определены

Адрес: https://producthub.live/shape-up/svoystvo-3-granitsy-opredeleny

Наконец, проработанная работа указывает, чего делать не нужно. Она говорит команде, где остановиться. Есть конкретный аппетит — количество времени, которое команда вправе потратить на проект. Чтобы завершить его за этот фиксированный срок, приходится ограничить объём работы и исключить конкретные вещи.

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

#### Кто занимается проработкой

Адрес: https://producthub.live/shape-up/kto-zanimaetsya-prorabotkoy

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

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

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

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

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

#### Два потока

Адрес: https://producthub.live/shape-up/dva-potoka

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

> **Редакторское пояснение.** «Сделать ставку» означает решить, что проект заслуживает выделенного времени, и предоставить команде согласованный срок в рамках цикла с ожиданием выпуска. Небольшому проекту может хватить одной-двух недель; весь цикл тогда включает несколько таких проектов. Это обязательство обеспечить время для работы, а не требование реализовать весь первоначальный объём любой ценой.

#### Этапы проработки

Адрес: https://producthub.live/shape-up/etapy-prorabotki

В проработке четыре основных шага.

1. **Задать границы.** Сначала мы выясняем, сколько времени стоит сырая идея и как определить проблему. Это задаёт основные границы, в которые нужно уложить решение при проработке.
2. **Наметить элементы.** Затем начинается творческая работа: мы набрасываем решение. Мы делаем это на более высоком уровне абстракции, чем вайрфреймы, чтобы двигаться быстро и рассмотреть достаточно широкий набор возможностей. Результат этого шага — идея, которая решает проблему в пределах аппетита, но ещё не проработана до мельчайших деталей.
3. **Разобраться с рисками и кроличьими норами.** Когда нам кажется, что решение найдено, мы пристально изучаем его, чтобы найти пробелы и вопросы без ответа, на которых команда может споткнуться. Мы дополняем решение, убираем из него лишнее или уточняем детали в отдельных трудных местах, чтобы команда не застряла и не потеряла время.
4. **Зафиксировать решение.** Когда проект достаточно проработан, чтобы рассматривать выделение ресурсов, мы оформляем его в документ — питч. Это краткое описание проблемы, ограничений, решения, кроличьих нор и того, что остаётся за рамками проекта. По нему можно оценить проект, а после выбора — объяснить замысел команде на стартовой встрече.

### Глава 2. Задать границы

Адрес: https://producthub.live/shape-up/2-zadat-granitsy

![Прежде чем обсуждать решение, нужно договориться о границах](https://producthub.live/assets/books/shape-up/light/p021-01.webp)

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

Разговор о создании функции всегда начинается с сырой идеи, например: «Клиенты просят групповые уведомления». Прежде чем мы все полезем в кроличью нору, обсуждая способы решить задачу, нужно задать общие рамки разговора, чтобы он был продуктивным.

#### Определите аппетит

Адрес: https://producthub.live/shape-up/opredelite-appetit

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

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

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

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

- **Малый пакет:** проект, который команда из одного дизайнера и одного-двух программистов может создать за одну-две недели. Мы объединяем такие проекты в шестинедельный цикл: команда сама определяет порядок работы и выпускает их к его окончанию.
- **Большой пакет:** проект, на который команда того же размера тратит полные шесть недель.

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

#### Фиксированное время, переменный объём

Адрес: https://producthub.live/shape-up/fiksirovannoe-vremya-peremennyy-obem

Аппетит принципиально отличается от оценки. Оценка начинается с проекта решения и заканчивается числом. Аппетит начинается с числа и заканчивается проектом решения. Мы используем аппетит как творческое ограничение в процессе проектирования.

Этот принцип — «фиксированное время, переменный объём» — ключ к тому, чтобы успешно определять и выпускать проекты. Возьмём эту книгу. Её трудно выпустить, если всегда можно что-то добавить, подробнее объяснить или улучшить уже написанное. Когда появляется дедлайн, внезапно приходится принимать решения. Если осталась неделя, я могу выбирать: исправить опечатки или добавить в главу новый раздел. В этом проявляется напряжение между временем, качеством и объёмом. Я не хочу выпускать книгу с позорными опечатками, поэтому выберу сокращение объёма и откажусь от дополнительного раздела. Без давления фиксированного срока я не пошёл бы на этот компромисс. Если бы объём нельзя было менять, мне пришлось бы включить дополнительный раздел. Тогда не осталось бы времени исправить проблемы с качеством.

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

#### «Хорошо» — понятие относительное

Адрес: https://producthub.live/shape-up/khorosho-ponyatie-otnositelnoe

Абсолютного определения «лучшего» решения не существует. Лучшее определяется вашими ограничениями. Если время не ограничено, всегда найдётся версия лучше. Идеальным приёмом пищи может быть ужин из десяти блюд. Но когда вы голодны и торопитесь, хот-дог — в самый раз.

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

#### Как отвечать на сырые идеи

Адрес: https://producthub.live/shape-up/kak-otvechat-na-syrye-idei

По умолчанию на любую новую идею стоит отвечать: «Интересно. Возможно, когда-нибудь». Иными словами, очень мягкое «нет», которое сохраняет все варианты открытыми. Мы не кладём идею в бэклог. Мы оставляем ей пространство, чтобы понять, действительно ли она важна и что может за собой повлечь.

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

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

#### Сузьте проблему

Адрес: https://producthub.live/shape-up/suzte-problemu

Помимо определения аппетита, обычно нужно сузить наше понимание проблемы.

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

Другой пример — календарный вид из [главы 1](https://producthub.live/shape-up/1-opredelit-glubinu-prorabotki). Все знают, что такое календарный вид. Но стоило разобрать запрос, как обнаружилось множество неизвестных и решений, которые радикально влияли бы на объём работы. Если мы хотим потратить лишь шесть недель вместо шести месяцев на огромный календарь, как сузить задачу?

В таком случае мы переключаемся с вопроса «Что мы могли бы создать?» на вопрос «Что на самом деле идёт не так?». Конечно, календарь звучит заманчиво. Но что стоит за запросом? В какой именно момент привычный рабочий процесс человека перестаёт работать без того, о чём он просит?

#### Пример: что подразумевается под «календарём»

Адрес: https://producthub.live/shape-up/primer-chto-podrazumevaetsya-pod-kalendarem

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

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

Вывод был не в том, чтобы «перенести календарь в компьютер» — это очевидно. Мы поняли другое: в этом сценарии важно «видеть свободные интервалы», а не «делать всё, что умеет календарь».

Эта и похожие истории дали нам конкретное исходное положение, с которым можно было сравнивать решение. В Basecamp уже был список событий по датам. Он подходил для отображения основных сроков и ключевых этапов, но плохо справлялся с планированием ресурсов: свободных промежутков в нём не было видно. Мы сузили потребность с «делать всё, что умеет календарь» до «помогите мне увидеть свободные интервалы, чтобы понять, на какое время что-то назначить».

Решения у нас ещё не было. Но теперь мы чувствовали, что проблема достаточно конкретна, чтобы подсказать идею, которая уложится в наш аппетит. Так мы пришли к более простой концепции сетки точек из [главы 1](https://producthub.live/shape-up/1-opredelit-glubinu-prorabotki).

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

#### Остерегайтесь сборных мешков

Адрес: https://producthub.live/shape-up/osteregaytes-sbornykh-meshkov

Среди неясных идей хуже всего «редизайны» и «рефакторинги», которые не опираются на одну конкретную проблему или сценарий. Когда кто-то предлагает «переделать раздел Files», это сборный мешок, а не проект. Будет очень трудно понять, что за этим стоит, где работа начинается и где заканчивается. Вот более продуктивная отправная точка: «Нам нужно переосмыслить раздел Files, потому что, чтобы поделиться несколькими файлами, требуется слишком много шагов». Теперь можно спрашивать: что не работает? В какой ситуации шагов слишком много? Какие части существующего дизайна могут остаться прежними, а какие нужно изменить?

Верный признак такого сборного мешка — обозначение «2.0». В прошлом мы ошиблись, начав проект «Files 2.0» и толком не задумавшись, что это означает. Энтузиазм по поводу улучшения огромной части приложения взял над нами верх. Мы знали, что в нашей функции работы с файлами много проблем, но не спросили себя, что именно собираемся сделать. Проект превратился в беспорядок: мы не знали, как выглядит «готово». Мы выправили ситуацию, разделив его на более мелкие проекты, например «Улучшенный предпросмотр файлов» и «Собственные цвета папок». Для каждого проекта задали аппетит и ясные ожидания, после чего успешно их выпустили.

#### Границы заданы

Адрес: https://producthub.live/shape-up/granitsy-zadany

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

### Глава 3. Найти устройство решения

Адрес: https://producthub.live/shape-up/3-nayti-ustroystvo-resheniya

![Совместный поиск элементов решения у доски](https://producthub.live/assets/books/shape-up/light/p026-01.webp)

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

#### Двигайтесь с подходящей скоростью

Адрес: https://producthub.live/shape-up/dvigaytes-s-podkhodyashchey-skorostyu

На этом этапе двигаться с подходящей скоростью нам помогают две вещи.

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

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

Задача — добиться достаточной конкретности, чтобы продвинуться в определённом решении, но не погрузиться в мелкие детали. Мы пытаемся ответить на такие вопросы:

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

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

#### Схемы взаимодействия

Адрес: https://producthub.live/shape-up/skhemy-vzaimodeystviya

Чтобы проектировать на нужном уровне абстракции, мы заимствуем понятие из электротехники. Макетная плата — *breadboard* — это электротехнический прототип, в котором есть все компоненты и соединения настоящего устройства, но нет промышленного дизайна.

![Макетная плата с компонентами и готовое устройство с корпусом](https://producthub.live/assets/books/shape-up/light/p027-01.webp)

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

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

1. **Места.** То, куда можно перейти: экраны, диалоги или всплывающие меню.
2. **Возможности действия.** То, с чем пользователь может взаимодействовать: кнопки и поля. Текст интерфейса мы тоже считаем возможностью действия. Его чтение — действие, которое даёт пользователю информацию для последующих действий.
3. **Соединительные линии.** Они показывают, как возможности действия переводят пользователя из одного места в другое.

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

#### Пример

Адрес: https://producthub.live/shape-up/primer

Предположим, наш продукт — инструмент для выставления счетов. Мы рассматриваем новую функцию Autopay — автоплатёж, — чтобы клиенты наших клиентов могли автоматически оплачивать будущие счета.

Как включить автоплатёж? Что для этого требуется? Можно выбрать начальную точку: клиент открыл счёт. Это наше первое место. Рисуем его: пишем название и подчёркиваем.

![Первое место: счёт](https://producthub.live/assets/books/shape-up/light/p028-01.webp)

Мы думаем, что на счёт можно добавить новую кнопку Turn on Autopay — «Включить автоплатёж». Это возможность действия. Возможности действия располагаются под чертой: так мы показываем, что они доступны в этом месте.

![Кнопка включения автоплатежа под названием места «Счёт»](https://producthub.live/assets/books/shape-up/light/p028-02.webp)

Куда ведёт эта кнопка? В какое-то место настройки автоплатежа. Нам не нужно уточнять, отдельный это экран, всплывающее модальное окно или что-то ещё. С точки зрения того, что с чем связано, — топологии — это одно и то же. Проведём соединительную линию от кнопки к экрану Set up Autopay — «Настроить автоплатёж».

![Связь от кнопки на счёте к настройке автоплатежа](https://producthub.live/assets/books/shape-up/light/p028-03.webp)

Теперь можно обсудить, что должно быть на этом экране. Запрашиваем ли мы здесь данные кредитной карты? Может быть, карта уже сохранена? А как насчёт ACH или других способов оплаты?

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

Обдумав всё, мы решаем запросить здесь данные кредитной карты и показать логотип финансовой организации — это особенность предметной области именно этого продукта.

![Настройка автоплатежа: данные карты, логотип финансовой организации и переход к подтверждению](https://producthub.live/assets/books/shape-up/light/p029-01.webp)

Всё достаточно просто. Но постойте: исходный счёт мы оплатили или нет? Хм. Теперь у нас появились вопросы и к функциональности, и к интерфейсу. Что на самом деле делает включение автоплатежа? Оно относится только к будущим счетам или первый платёж через Autopay оплачивает и текущий счёт? И где мы объясняем это поведение? Всего несколько слов и стрелок на схеме взаимодействия вызывают всё более глубокие вопросы и обсуждения.

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

Можно добавить опцию на экран настройки…

![Вариант с дополнительным вопросом об оплате текущей задолженности](https://producthub.live/assets/books/shape-up/light/p029-02.webp)

Но теперь мы усложняем обязанности экрана подтверждения. Если пользователь оплачивает задолженность сейчас, нужно будет показать квитанцию. Должен ли экран подтверждения содержать условие, при котором он иногда показывает квитанцию с суммой только что совершённого платежа?

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

![Автоплатёж как опция на существующем экране оплаты счёта](https://producthub.live/assets/books/shape-up/light/p030-01.webp)

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

А что происходит после включения автоплатежа? Как клиент его выключает? До сих пор у многих клиентов в системе не было имён пользователей и паролей. Для оплаты каждого отдельного счёта они переходили по ссылкам с токенами доступа. Можно было бы естественным образом предположить: раз у клиента появляется что-то вроде автоплатежа, теперь ему нужны имя пользователя, пароль и отдельное место, где всем этим можно управлять.

Но команда в этом случае решила, что сценарии с именем пользователя и паролем добавят слишком много работы для её тогдашнего аппетита. Стратегически осмыслив то, что они знали о своих клиентах, участники сочли вполне приемлемым, чтобы клиенты того, кто выставляет счета, обращались к нему с просьбой отключить автоплатёж. В таком случае можно добавить всего одну опцию отключения на страницу с данными клиента, которую мы уже предоставляли тем, кто выставляет счета. Мы нарисовали такой сценарий:

![Отключение автоплатежа на странице клиента со стороны того, кто выставляет счета](https://producthub.live/assets/books/shape-up/light/p030-02.webp)

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

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

#### Эскизы толстым маркером

Адрес: https://producthub.live/shape-up/eskizy-tolstym-markerom

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

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

Вот пример. Мы часто создавали фиктивные задачи в списках задач Basecamp, чтобы использовать их как разделители. Добавляли пункт вроде «––– Нужно протестировать –––» и размещали задачи под ним. Нам пришла идея добавить полноценную функцию разделителей в инструмент работы с задачами: превратить обходной приём в штатную возможность списков.

Нужно было понять, к чему приведёт добавление разделителя. Мы пришли к предварительной идее: разделитель делит список на «негруппированные» задачи над ним и «сгруппированные» задачи под ним. Каждый следующий разделитель добавляет новую группу ниже негруппированных задач вверху.

![Разделение списка на негруппированные и сгруппированные задачи](https://producthub.live/assets/books/shape-up/light/p032-01.webp)

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

![Возможность добавлять задачи отдельно в каждую часть списка](https://producthub.live/assets/books/shape-up/light/p032-02.webp)

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

![Добавление задачи через существующее меню действий](https://producthub.live/assets/books/shape-up/light/p033-01.webp)

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

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

#### Результат — это элементы

Адрес: https://producthub.live/shape-up/rezultat-eto-elementy

В примере с автоплатежом у нас получились чёткие элементы:

- Новый флажок «Использовать это для автоплатежа?» на существующем экране Pay an invoice — «Оплата счёта».
- Опция Disable Autopay — «Отключить автоплатёж» — на стороне того, кто выставляет счета.

Для проекта групп задач — To-Do Groups — элементы были такими:

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

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

![Эскиз толстым маркером: сетка двух месяцев, точки событий и список под ней](https://producthub.live/assets/books/shape-up/light/p034-01.webp)

Это помогло определить основные элементы решения:

- Сетка календаря с двумя месяцами рядом.
- Точки для событий, без протяжённых плашек.
- Список событий по датам внизу; нажатие на точку прокручивает список до соответствующего события.

По сравнению с «календарём на месяц» этот набор элементов чрезвычайно узок и конкретен. Именно к такому сужению мы и стремимся при проработке.

#### Пространство для дизайнеров

Адрес: https://producthub.live/shape-up/prostranstvo-dlya-dizaynerov

Позже, когда придёт время подключить дизайнера, вам не захочется говорить: «Я знаю, что нарисовал это так, но не обращай внимания…» Что бы вы ни сказали, любой конкретный макет повлияет на решения людей, которые будут работать после вас, — особенно если вы занимаете более высокую должность. Они воспримут каждую деталь первоначального макета как указание, даже если вы не это имели в виду.

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

Оставляя детали за рамками, схемы взаимодействия и эскизы толстым маркером дают дизайнерам свободу на последующих этапах проекта.

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

#### Пока не готово к передаче

Адрес: https://producthub.live/shape-up/poka-ne-gotovo-k-peredache

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

Мы перешли от туманной идеи вроде «автоплатежа» или «групп задач» к конкретному подходу и нескольким определённым элементам. Но форма результата всё ещё очень грубая: в основном это лишь контуры.

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

Следующий шаг — проверить решение на прочность и снизить риски. Мы хотим найти пробелы и трудности, которые способны помешать выпустить проект в пределах фиксированного аппетита времени, который мы для него определили.

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

#### Никакого конвейера

Адрес: https://producthub.live/shape-up/nikakogo-konveyera

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

### Глава 4. Проверить риски

Адрес: https://producthub.live/shape-up/4-proverit-riski

![Обсуждение рисков: «Да, но это работает не совсем так…»](https://producthub.live/assets/books/shape-up/light/p036-01.webp)

Помните: мы прорабатываем проект под фиксированный срок. Опыт может подсказывать нам, что элементы решения, которые мы конкретизировали в [главе 3](https://producthub.live/shape-up/3-nayti-ustroystvo-resheniya), можно реализовать в рамках аппетита — за шесть недель. Но нужно присмотреться внимательнее: достаточно одного пробела в концепции, чтобы этот план сорвался. Допустим, мы сделали ставку на проект и команда за него взялась. Если она столкнётся с непредвиденной проблемой, на решение которой уйдут две недели, треть бюджета уже потрачена!

Бывает и хуже: некоторые проблемы не просто задерживают проект — у них вообще нет очевидного решения. Однажды мы сделали ставку на проект по изменению того, как на главном экране Basecamp показываются проекты с участием клиентов. Мы предположили, что дизайнер разберётся; на этапе проработки не проверили, существует ли вообще жизнеспособный подход. Когда проект начался, выяснилось, что проблема гораздо сложнее, чем мы ожидали. За выделенные шесть недель ни один из нас не смог найти подходящее дизайнерское решение. В итоге мы отказались от проекта и вернулись к его переосмыслению позже.

Конечно, неизвестные всегда останутся. Именно поэтому мы используем практики следующих глав: выделение участков работы, отслеживание неизвестного и пересмотр объёма. Они помогают командам решать нужные проблемы в нужном порядке и оставлять место для неожиданностей. Но это не значит, что не стоит заранее искать и устранять те ловушки, которые мы способны обнаружить, прежде чем делать ставку на проект. Прежде чем считать ставку достаточно безопасной, нужно по возможности избавиться от пробелов в проработанном проекте.

#### Разные категории риска

Адрес: https://producthub.live/shape-up/raznye-kategorii-riska

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

![Распределение с тонким хвостом: основная вероятность сосредоточена около шести недель](https://producthub.live/assets/books/shape-up/light/p037-01.webp)

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

![Распределение с длинным правым хвостом: проект может занять втрое больше времени](https://producthub.live/assets/books/shape-up/light/p037-02.webp)

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

#### Ищите кроличьи норы

Адрес: https://producthub.live/shape-up/ishchite-krolichi-nory

Когда мы конкретизировали элементы решения, процесс шёл быстро: мы исследовали возможности. Мы двигались скорее вширь, чем вглубь. На этом шаге мы замедляемся и критически смотрим на то, что придумали. Не упустили ли мы чего-нибудь? Не делаем ли необоснованных технических допущений?

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

Затем стоит проверить жизнеспособность каждой части, которую мы считаем решённой. Мы задаём себе такие вопросы:

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

#### Пример: закрываем пробел

Адрес: https://producthub.live/shape-up/primer-zakryvaem-probel

Например, когда мы определяли проект «Группы задач» (To-Do Groups), мы предложили разделители в списке задач:

![Разделители в списке: отдельные задачи и задачи, собранные в группы](https://producthub.live/assets/books/shape-up/light/p038-01.webp)

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

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

Мы знали по опыту, что изменение способа отображения выполненных задач влечёт множество сложных последствий для пользовательского опыта, навигации и производительности. Чтобы убрать неопределённость, мы решили жёстко задать решение в проработанной концепции. Выполненные задачи должны были остаться ровно такими, как прежде. Вместо того чтобы группировать их или разбивать на секции, мы просто добавили бы название группы к каждой выполненной задаче. Получалось немного неаккуратно, но мы обосновали этот компромисс: он радикально упрощал проблему, а выполненные задачи группы мы по-прежнему могли показывать на странице самой группы.

![Группируются только невыполненные задачи; к выполненным добавляются названия групп](https://producthub.live/assets/books/shape-up/light/p039-01.webp)

Такой компромисс трудно принять, работая внутри цикла под давлением. Есть множество причин, по которым иной дизайн или более глубокое переосмысление выполненных задач было бы объективно лучше. Почему бы не попробовать показывать их внутри каждой группы? Дизайнер вполне может подумать: «Может, если я ещё немного поэкспериментирую с оформлением, они будут лучше вписываться». Так можно легко потратить несколько дней из и без того немногочисленных недель на тупиковый путь.

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

При оформлении описания проекта мы отдельно укажем эту «заплатку» как часть концепции. Тогда на следующих этапах никто на ней не споткнётся.

#### Обозначьте, что остаётся за рамками

Адрес: https://producthub.live/shape-up/oboznachte-chto-ostaetsya-za-ramkami

Поскольку каждый в команде хочет сделать работу как можно лучше, люди, конечно, будут искать все возможные сценарии использования и считать необходимым их поддержать. По мере того как команда осваивает жёсткое сокращение объёма работы — словно отсекает лишнее молотком (см. [главу 8 «Определить достаточный результат»](https://producthub.live/shape-up/8-opredelit-dostatochnyy-rezultat)), — ситуация улучшается. Но всё равно полезно явно назвать сценарии, которые вы намеренно не поддерживаете, чтобы проект уверенно укладывался в аппетит.

Например, мы работали над идеей уведомлять группы людей в Basecamp. Вместо того чтобы по одному отмечать пятерых программистов, можно было бы нажать «Программисты», и они все были бы выбраны для уведомления. Изучая продукт, мы увидели множество мест, где такое поведение могло бы иметь смысл. Если при публикации сообщения можно выбрать группу, почему не сделать это при назначении задачи или при упоминании людей в чате?

Для этого проекта мы решили, что основная ценность — быстрее выбрать тех, кого нужно уведомить о сообщении. Мы прямо обозначили остальные сценарии как находящиеся «за рамками» проекта и сосредоточились на нужном нам результате: ускорении публикации сообщений.

#### Сокращайте

Адрес: https://producthub.live/shape-up/sokrashchayte

Некоторые части решения, которые увлекли нас во время набросков, могут оказаться необязательными. Когда мы проектировали функцию «Группы задач», нам казалось, что было бы здорово различать группы по цвету. Безусловно, с цветными метками групп страница выглядела бы интереснее, а функция, возможно, стала бы полезнее. Но мы решили отметить это как необязательное и убрать из основы проекта. Команде можно упомянуть это как желательное дополнение, но все должны исходить из того, что функция ценна и без него.

#### Покажите техническим экспертам

Адрес: https://producthub.live/shape-up/pokazhite-tekhnicheskim-ekspertam

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

Сейчас самое время пригласить технических экспертов и познакомить их с идеей. Объясните, что это пока лишь идея. Вы прорабатываете её как возможную ставку, а не как проект, который уже собираются запускать. Настрой — дружеский, чуть заговорщический: «Вот над чем я сейчас думаю… но ещё не готов никому показывать… что скажешь?»

Остерегайтесь простого вопроса: «Это возможно?» В программном обеспечении возможно всё, но ничто не даётся бесплатно. Нам нужно выяснить, возможно ли это в рамках аппетита, под который мы прорабатываем проект. Вместо «Можно ли сделать X?» спросите: «Можно ли сделать X за шесть недель?» Это совсем другой вопрос.

Обсудите ограничения и объясните, почему решение хорошо именно с учётом аппетита. Тогда эксперты станут вашими партнёрами в сохранении намеченного размера проекта. И подчеркните, что вы ищете риски, способные взорвать проект. Это не просто беседа «Что думаешь?» — мы действительно ищем бомбы замедленного действия, которые могут сработать после передачи проекта команде.

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

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

#### Риски снижены — можно описывать

Адрес: https://producthub.live/shape-up/riski-snizheny-mozhno-opisyvat

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

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

## Часть 2. Получить работающий результат

### Глава 5. Собрать первый рабочий фрагмент

Адрес: https://producthub.live/shape-up/5-sobrat-pervyy-rabochiy-fragment

![Много задач выполнено, но объяснить, как продвигается проект, всё ещё трудно](https://producthub.live/assets/books/shape-up/light/p073-01.webp)

> **Редакторское пояснение.** К этому моменту команда получает целый проработанный проект с проблемой, решением и границами; задачи и порядок работы она определяет сама. В первые дни ей нужно изучить существующий код и найти отправную точку, поэтому отсутствие закрытых задач ещё не означает отсутствия работы. Для проекта в целом «готово» означает, что результат к концу цикла доступен пользователям в рабочей среде; тестирование также входит в выделенный срок. Первый рабочий фрагмент можно проверять и показывать на тестовом сервере, пока остальной проект ещё не завершён.

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

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

#### Соедините слои в одном фрагменте

Адрес: https://producthub.live/shape-up/soedinite-sloi-v-odnom-fragmente

Можно представить проект состоящим из двух слоёв: пользовательской части — фронтенда — и серверной части — бэкенда, дизайна и кода. Хотя с технической точки зрения слоёв больше, именно соединение этих двух слоёв — главная трудность интеграции в большинстве проектов.

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

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

![Выполнены отдельные части фронтенда, но ничего не работает](https://producthub.live/assets/books/shape-up/light/p074-01.webp)

![Выполнены разрозненные части фронтенда и бэкенда, но ничего не работает](https://producthub.live/assets/books/shape-up/light/p074-02.webp)

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

![Соединён один вертикальный фрагмент — что-то уже работает](https://producthub.live/assets/books/shape-up/light/p074-03.webp)

#### Пример: клиенты в проектах

Адрес: https://producthub.live/shape-up/primer-klienty-v-proektakh

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

- **Доступ клиентов.** До появления этой функции модель доступа Basecamp работала по принципу «всё или ничего». Нам нужен был способ приглашать людей так, чтобы они видели лишь некоторые части проекта. Это существенно влияло на бэкенд и кеширование.
- **Управление клиентами.** Нам нужен был способ добавлять клиентов в проекты и возможность управлять ими отдельно от участников команды.

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

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

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

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

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

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

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

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

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

#### Программистам не нужно ждать

Адрес: https://producthub.live/shape-up/programmistam-ne-nuzhno-zhdat

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

#### Сначала возможности действия, затем экраны, выверенные до пикселя

Адрес: https://producthub.live/shape-up/snachala-vozmozhnosti-deystviya-zatem-ekrany-vyverennye

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

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

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

![Простой HTML-интерфейс регистрации на многодневные курсы](https://producthub.live/assets/books/shape-up/light/p076-01.webp)

Это скриншот приложения для регистрации на многодневные курсы. Дизайнер вручную написала для него HTML. Оформления почти нет — лишь визуальная иерархия, достаточная, чтобы убедиться: компоновка удобна и поверх неё можно будет добавить оформление.

Хотя дизайн выглядит простым, в нём отражено множество решений.

- Решение спрашивать время прибытия, но не время отъезда возникло из подробных обсуждений бизнес-логики и модели ценообразования.
- Конкретные варианты в выпадающем списке времени прибытия соответствуют правилам оплаты питания и ночёвок, которые пришлось выработать.
- В первых эскизах дизайнер использовала календарный элемент выбора дат прибытия и отъезда. Но это создало проблемы с удобством использования. Некоторые курсы были длинными — по несколько недель — и состояли из разных этапов. В стандартном календаре выбора даты не хватало места в ячейках дней для подписей этапов. В выпадающем списке она могла при необходимости группировать даты и подписывать группы. Так пользователям не нужно было сверяться с расписанием где-то ещё, чтобы убедиться, что они выбирают нужные даты.

Вот ещё один пример. Это первая работающая часть приложения для записи данных клиентских интервью.

![Первый рабочий интерфейс приложения для записи данных интервью](https://producthub.live/assets/books/shape-up/light/p077-01.webp)

На этом раннем этапе название проекта (Basecamp) и имя участника интервью (Jan) были жёстко заданы в коде, а большинство ссылок никуда не вели.

Посмотрите, насколько черновой этот дизайн. Действия представлены обычными текстовыми ссылками стандартных для браузера синего и фиолетового цветов. Блоки с данными почти не оформлены — у них лишь простые чёрные границы. При всей своей грубости этот дизайн позволяет проверить важные компромиссы. Дизайнер решила показать как можно больше данных в пределах первого экрана, чтобы интервью было легко просматривать. Из-за этого в каждом разделе не осталось достаточно места для элементов добавления, редактирования и удаления данных. Поэтому дизайнер создала отдельные экраны для добавления и редактирования данных в каждом разделе.

![Черновой экран добавления и редактирования притягивающих факторов](https://producthub.live/assets/books/shape-up/light/p078-01.webp)

Это первый дизайн для добавления и редактирования *pulls* — притягивающих факторов, одного из типов данных в этой технике интервью. Снова обратите внимание, насколько он черновой. Дизайна ровно столько, чтобы быстро подключить код и проверить решение. Команда может пройти по экранам и оценить, приемлем ли переход на отдельный экран для записи данных. Если всё работает, дополнительное оформление можно добавить позже. Если нет, команда не потратила много времени на реализацию дизайна, выверенного до пикселя.

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

#### Пишите ровно столько кода, сколько нужно для следующего шага

Адрес: https://producthub.live/shape-up/pishite-rovno-stolko-koda-skolko-nuzhno

То же верно и для бэкенда. Здесь не обязательно действовать по принципу «всё или ничего». Иногда дизайнеру нужен лишь каркас — пара полей, сохраняющих данные, или код для перехода с одного экрана-заготовки на другой. В других случаях ей нужно заполнить переменную в шаблоне набором реальных данных, чтобы пробовать разные способы отображения — строки, столбцы, блоки с медиаматериалами и так далее — и найти лучший дизайн.

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

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

![Диалог браузера для HTTP-аутентификации](https://producthub.live/assets/books/shape-up/light/p079-01.webp)

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

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

#### Начинайте с середины

Адрес: https://producthub.live/shape-up/nachinayte-s-serediny

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

Развивая эту мысль, вот три критерия, о которых стоит подумать, выбирая, что реализовать первым.

Во-первых, это должно быть что-то центральное. Переключатель видимости был центральным элементом концепции «Клиенты в проектах». Без него остальная работа не имела бы смысла. Сравните его с более периферийной частью проекта, например возможностью переименовать клиента. Обе были «необходимы», но одну было важнее проверить в начале цикла. В приложении для интервью запись данных была более центральной задачей — находилась ближе к середине, — чем создание нового исследовательского проекта.

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

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

### Глава 6. Разделить проект на участки работы

Адрес: https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty

![Карта участков позволяет объяснить состояние проекта](https://producthub.live/assets/books/shape-up/light/p081-01.webp)

В [главе 5](https://producthub.live/shape-up/5-sobrat-pervyy-rabochiy-fragment) мы начали проект с того, что на раннем этапе завершили один фрагмент, соединив в нём все слои. Эта практика — часть более общего приёма, который команда может использовать на протяжении всего проекта.

#### Организуйте работу по структуре, а не по людям

Адрес: https://producthub.live/shape-up/organizuyte-rabotu-po-strukture-a-ne

Когда людей просят организовать задачи проекта, они часто делят работу по людям или ролям: создают список для дизайнеров и список для программистов. Это приводит к проблеме, о которой мы говорили в [главе 5](https://producthub.live/shape-up/5-sobrat-pervyy-rabochiy-fragment): участники выполняют задачи, но эти задачи не складываются в готовую часть проекта достаточно рано.

Возьмём пример вне разработки ПО: человек организует мероприятие по сбору средств. Он мог бы создать список задач для каждого из трёх волонтёров и отслеживать работу таким образом. Но тогда не было бы видно общей картины подготовки мероприятия — что на крупном уровне готово, а что ещё нет. Вместо этого ему стоит создавать списки по структуре проекта: по частям, над которыми можно работать и которые можно завершать независимо друг от друга. Для этого он создаст списки «Меню», «Подготовка площадки» и «Свет и звук». Тогда организатору будет легко увидеть, какие направления завершены, а в каких ещё осталась работа.

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

Как мы видели в [главе 5](https://producthub.live/shape-up/5-sobrat-pervyy-rabochiy-fragment), такие фрагменты работы объединяют задачи фронтенда и бэкенда. Это позволяет завершить одну часть настоящего проекта и уверенно перейти дальше. Так лучше, чем получить множество частей, которые — скрестим пальцы — должны соединиться к концу цикла.

Такие объединённые фрагменты проекта мы называем участками работы (*scopes*). Мы разбиваем общий объём работы проекта (*scope*, в единственном числе) на отдельные участки (*scopes*, во множественном числе), которые можно завершать независимо друг от друга. В этой главе мы рассмотрим, как команда составляет карту участков проекта и поочерёдно над ними работает.

#### Карта участков работы

Адрес: https://producthub.live/shape-up/karta-uchastkov-raboty

Представьте проект с высоты птичьего полёта. В начале есть только контур, заданный проработкой до старта проекта. Ни задач, ни участков работы пока нет.

![Контур проекта до обнаружения задач и участков работы](https://producthub.live/assets/books/shape-up/light/p082-01.webp)

Когда участники команды принимают проект, они начинают обнаруживать задачи. Задачи — естественная отправная точка, потому что они конкретные и мелкие. Ещё слишком рано организовывать их в категории более высокого уровня. Попытка произвольно сгруппировать их была бы искусственной. Для начала достаточно просто записать разные вещи, которые нужно сделать.

![Отдельные обнаруженные задачи внутри контура проекта](https://producthub.live/assets/books/shape-up/light/p083-01.webp)

Но надолго оставаться с такой картиной мы не хотим. Она слишком подробная. С большой высоты ничего не видно.

Когда команда начинает настоящую работу над проектом, она узнаёт, как связаны задачи и как на самом деле устроен проект. Тогда она получает возможность разделить его на участки работы. Это похоже на разделение карты проекта на отдельные территории.

![Проект разделён на участки работы](https://producthub.live/assets/books/shape-up/light/p083-02.webp)

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

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

![Участки проекта представлены отдельными списками задач в Basecamp](https://producthub.live/assets/books/shape-up/light/p084-01.webp)

#### Язык проекта

Адрес: https://producthub.live/shape-up/yazyk-proekta

Участки — это не просто фрагменты. Они становятся языком проекта на крупном уровне. Когда мы создавали функцию «Клиенты в проектах», команда использовала названия участков так: «Когда закончим “Доступ к контейнеру”, сможем реализовать “Приглашение клиентов”. Затем будем “Обновлять видимость записей”, когда сотрудники компании меняют “Переключатель видимости”».

Когда приходит время рассказать о состоянии работы, команда использует язык участков, чтобы объяснить, что готово, а что нет. Намного приятнее обсуждать проект на общем уровне и показывать готовые части ПО, чем погружаться в мелочи и обосновывать назначение и состояние отдельных незавершённых задач. (В следующей главе подробнее рассмотрим, как рассказывать о состоянии участков с помощью диаграммы-холма.)

#### Пример: черновики сообщений

Адрес: https://producthub.live/shape-up/primer-chernoviki-soobshcheniy

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

![Исходный набор задач ещё не распределён по участкам](https://producthub.live/assets/books/shape-up/light/p085-01.webp)

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

Они назвали новый участок «Создать новый» (*Start New*), завели для него список задач и перенесли туда соответствующие пункты. Чтобы считать этот участок завершённым, им оставалось выполнить только одну дизайнерскую задачу.

![Из общего списка выделен участок «Создать новый»](https://producthub.live/assets/books/shape-up/light/p085-02.webp)

После выполнения этой дизайнерской задачи участок был завершён.

![Участок создания нового черновика завершён, остальные задачи ещё не распределены](https://producthub.live/assets/books/shape-up/light/p086-01.webp)

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

Посмотрев на оставшиеся задачи, участники решили выделить задачи поиска черновиков в новый участок «Найти» (*Locate*), а задачу удаления — в участок «Удалить» (*Trash*). Вся остальная работа, казалось, относилась к сохранению и редактированию черновика, поэтому её назвали «Сохранить/Редактировать» (*Save/Edit*).

![Выделены участки «Найти», «Удалить» и «Сохранить/Редактировать»](https://producthub.live/assets/books/shape-up/light/p086-02.webp)

Посмотрите на участок «Найти». Сейчас там только одна задача. Но наверняка работы будет больше, чем просто спроектировать список. Когда появятся задачи реализации, они попадут именно сюда.

Дизайнер начала работать над участком «Найти», а программист сосредоточилась на «Сохранить/Редактировать». Погрузившись в работу, она заметила, что может отделить несколько частей, чтобы сделать прогресс более видимым. На самом деле здесь было три участка.

Сначала она выделила работу, связанную с отправкой подготовленного сообщения. Этот участок она назвала «Отправить» (*Send*).

![Из «Сохранить/Редактировать» выделен участок «Отправить»](https://producthub.live/assets/books/shape-up/light/p087-01.webp)

Наконец, часть оставшихся задач «Сохранить/Редактировать» касалась хранения информации, а ещё одна задача вообще относилась к другому: это был особый случай работы с черновиками при ответе на другое сообщение. Она выделила их в два новых участка: «Хранить» (*Store*) и «Ответить» (*Reply*).

![Оставшаяся работа разделена на «Хранить» и «Ответить»](https://producthub.live/assets/books/shape-up/light/p088-01.webp)

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

Тем временем дизайнер продвинулась с участком «Найти». После небольшого подключения кода его удалось отметить завершённым. Выполнялись задачи и на участках «Отправить» и «Хранить».

![«Найти» завершён, работа над «Отправить» и «Хранить» продолжается](https://producthub.live/assets/books/shape-up/light/p088-02.webp)

Когда «Отправить» и «Хранить» были закончены, на участках «Удалить» и «Ответить» осталось лишь несколько задач.

![Остались отдельные задачи на участках «Ответить» и «Удалить»](https://producthub.live/assets/books/shape-up/light/p089-01.webp)

А затем проект был готов.

![Все участки проекта завершены](https://producthub.live/assets/books/shape-up/light/p089-02.webp)

#### Обнаружение участков работы

Адрес: https://producthub.live/shape-up/obnaruzhenie-uchastkov-raboty

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

Участки возникают из взаимозависимостей. То, как части зависят друг от друга, определяет, когда можно назвать конкретный фрагмент работы готовым. Вы не знаете заранее, каковы на самом деле работа и взаимозависимости. Предполагаемые задачи — то, что мы считаем необходимым, пока только размышляем о проекте. Обнаруженные задачи — то, необходимость чего выясняется в ходе реальной работы. Тот же принцип относится и к участкам. Их нужно обнаруживать, выполняя настоящую работу и наблюдая, что связано между собой, а что нет.

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

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

#### Как понять, что участки определены правильно

Адрес: https://producthub.live/shape-up/kak-ponyat-chto-uchastki-opredeleny-pravilno

Хорошо выделенные участки показывают анатомию проекта. Когда у вас что-то болит, вам не приходится гадать, рука это, нога или голова. Вы знаете части тела и их названия, поэтому можете объяснить, где болит. Так же и у каждого проекта есть естественная анатомия: она возникает из желаемого дизайна, системы, в которой вы работаете, и взаимозависимостей между проблемами, которые нужно решить.

Три признака того, что участки определены правильно:

1. У вас есть ощущение, что вы видите весь проект, и ничто важное, вызывающее беспокойство, не спрятано в деталях.
2. Обсуждать проект становится легче, потому что участки дают вам подходящий язык.
3. Когда возникают новые задачи, вы знаете, куда их положить. Участки служат корзинами, в которые легко забрасывать новые задачи.

А эти три признака, напротив, говорят о том, что границы участков нужно пересмотреть:

1. Трудно сказать, насколько участок готов. Часто это происходит, когда задачи внутри него не связаны. Если проблемы внутри участка не связаны, решение одной не приближает вас к решению другой. В таком случае полезно поискать то, что можно выделить отдельно, как в примере с черновиками.
2. Название не связано с особенностями этого проекта: например, «Фронтенд» или «Ошибки». Мы называем такие участки «сборными мешками» и «ящиками для всякой всячины». Это признак того, что вы недостаточно соединяете слои работы и потому никогда не сможете отметить такой участок готовым независимо от остальных. Например, ошибки лучше относить к конкретным участкам, чтобы понимать: «Отправить» уже готов или сначала нужно исправить пару ошибок, прежде чем о нём можно будет забыть.
3. Участок слишком велик, чтобы быстро его закончить. Если участок разрастается и в нём слишком много задач, он превращается в отдельный проект со всеми недостатками длинного общего списка задач. Лучше разделить его на части, которые можно решить быстрее, чтобы по пути были победы, а между решаемыми проблемами — границы.

Закончим эту главу несколькими советами о разных видах задач и участков, с которыми вы будете сталкиваться.

#### Слоёные пироги

Адрес: https://producthub.live/shape-up/sloenye-pirogi

В большинстве программных проектов нужны дизайн интерфейса и тонкий слой кода под ним. Представьте приложение с базой данных, где всё, что нужно, — ввести информацию, сохранить её и показать обратно. Такая работа похожа на слоёный пирог: её объём можно оценить по площади интерфейса, потому что работа на бэкенде невелика и равномерно распределена. В таких случаях все задачи дизайна и программирования можно соединять в одном участке. Это хороший вариант по умолчанию для большинства приложений типа «информационная система».

![«Слоёный пирог»: фронтенд и тонкий равномерный слой бэкенда](https://producthub.live/assets/books/shape-up/light/p091-01.webp)

#### Айсберги

Адрес: https://producthub.live/shape-up/aysbergi

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

![«Айсберг»: небольшая видимая часть интерфейса и большой объём работы на бэкенде](https://producthub.live/assets/books/shape-up/light/p092-01.webp)

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

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

Прежде чем признать айсберг — во фронтенде или бэкенде — данностью, мы всегда ставим его под сомнение. Действительно ли сложность необходима и её нельзя уменьшить? Нужен ли нам этот замысловатый интерфейс? Можно ли иначе построить процесс на бэкенде, чтобы у него было меньше взаимозависимостей с остальной системой?

#### Похлёбка

Адрес: https://producthub.live/shape-up/pokhlebka

Почти всегда есть пара вещей, которые не вписываются ни в один участок. Мы позволяем себе список «Похлёбка» для отдельных задач, которым нигде не нашлось места. Но всегда смотрим на него скептически. Если он становится длиннее трёх–пяти пунктов, что-то здесь не так: вероятно, где-то нужно выделить участок работы.

#### Помечайте желательные задачи знаком ~

Адрес: https://producthub.live/shape-up/pomechayte-zhelatelnye-zadachi-znakom

По мере погружения в проблему постоянно появляются новые задачи. Вы находите код, который можно привести в порядок, крайние случаи, которые стоит обработать, и возможности улучшить существующие функции. Хороший способ обращаться со всеми этими улучшениями — записывать их как задачи в соответствующий участок, но ставить перед ними знак `~`. Это позволяет всем участникам команды постоянно отличать обязательные задачи от желательных.

В мире без сроков мы могли бы вечно всё улучшать. Но при фиксированном сроке нам нужен мачете, чтобы обрубать постоянно разрастающийся объём работы. Знак `~` в начале пункта или даже целого участка — лучший инструмент для этого. Мы вернёмся к этому приёму, когда будем говорить о сокращении объёма работы в [главе 8 «Определить достаточный результат»](https://producthub.live/shape-up/8-opredelit-dostatochnyy-rezultat).

### Глава 7. Отслеживать неопределённость и прогресс

Адрес: https://producthub.live/shape-up/7-otslezhivat-neopredelennost-i-progress

![Руководителю неловко спрашивать, как продвигается проект](https://producthub.live/assets/books/shape-up/light/p094-01.webp)

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

Руководители предпочли бы сами видеть состояние работы, когда им это нужно. В [главе 6](https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty) мы увидели, как распределение задач по участкам помогает команде держать работу под контролем. Но руководителю это напрямую не помогает. У задач есть несколько проблем, из-за которых их недостаточно для оценки состояния проекта.

#### Задачи, которых нет

Адрес: https://producthub.live/shape-up/zadachi-kotorykh-net

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

Иногда в начале проекта команда определяет участок, но ещё не наполняет его задачами. Это отмечает, что какая-то работа необходима, но сами задачи пока не обнаружены.

Или подумайте о проверке качества в конце работы над участком. Все задачи выполнены. Делать больше нечего. Затем тестирование наполняет участок новыми задачами по найденным проблемам.

Это связано с различием между предполагаемыми и обнаруженными задачами, описанным в [главе 6](https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty). В наивном представлении о заранее составленном списке кто-то заполняет его пунктами, которые постепенно отмечаются выполненными. В реальности проблемы обнаруживают, погружаясь в работу. Поэтому по мере продвижения команды списки задач на самом деле растут.

![В теории список задач сокращается, а на практике по мере работы обнаруживаются новые задачи](https://producthub.live/assets/books/shape-up/light/p095-01.webp)

Если бы мы попытались в момент `t₂` оценить, насколько продвинулся проект, картина ввела бы нас в заблуждение. Со стороны невозможно узнать, будет ли число невыполненных задач уменьшаться или расти. Для этого нужно больше знать о работе внутри участка: что означает выполнение именно этих задач и могут ли ещё появиться другие.

#### Оценки не показывают неопределённость

Адрес: https://producthub.live/shape-up/otsenki-ne-pokazyvayut-neopredelennost

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

Допустим, у вас две задачи, и на каждую, по оценке, требуется четыре часа. Если одну из них команда уже делала десять раз, оценке можно доверять. Предположим, вторую команда раньше не выполняла или у неё неясные взаимозависимости. Если всё пойдёт идеально, она может занять четыре часа, но из-за неизвестных факторов может растянуться на два–три дня. Писать в оценке «4 часа или, возможно, 3 дня» бессмысленно.

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

#### Работа похожа на холм

Адрес: https://producthub.live/shape-up/rabota-pokhozha-na-kholm

У каждого фрагмента работы есть две фазы. Сначала — подъём: мы выясняем, каким будет наш подход и что мы собираемся делать. Затем, когда видна вся предстоящая работа, — спуск: мы выполняем её.

![Подъём — разобраться, что делать; спуск — сделать это](https://producthub.live/assets/books/shape-up/light/p096-01.webp)

Чтобы почувствовать смысл холма, возьмём повседневный пример.

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

![Подготовка ужина ещё не начата](https://producthub.live/assets/books/shape-up/light/p096-02.webp)

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

На этом этапе вопрос «На сколько процентов завершён проект?» даже не имеет смысла. Если бы кто-то попросил оценить, сколько времени займут покупки и подготовка, вы тоже не смогли бы  ответить, потому что ещё не выбрали блюдо. Ответ был бы таким: «Я немного поработал над выбором кухни, но пока не определился с конкретным блюдом». Мы можем показать это, поместив вас на середину подъёма — на сторону «разбираемся».

![Выбор кухни — середина подъёма](https://producthub.live/assets/books/shape-up/light/p097-01.webp)

Затем вы ищете в интернете и просматриваете свои книги рецептов. Вы хотите найти интересный рецепт, для которого не нужны труднодоступные ингредиенты. Вы выбираете рецепт и составляете список покупок.

Теперь вы находитесь совсем в другом положении. Ощущение меняется с «Я пока не уверен, что делаю» на «Теперь я знаю, что делать». Вы на вершине холма.

![Блюдо выбрано, список покупок составлен — подход полностью понятен](https://producthub.live/assets/books/shape-up/light/p097-02.webp)

Отсюда видны все оставшиеся шаги. Теперь даже уместно оценить, сколько времени займёт вся работа: «Так… час на покупку продуктов, 30 минут на подготовку, 45 минут на приготовление…».

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

![Покупка ингредиентов продвигает работу по спуску](https://producthub.live/assets/books/shape-up/light/p098-01.webp)

Затем — подготовка и приготовление еды.

![Приготовление еды — дальнейшее продвижение по спуску](https://producthub.live/assets/books/shape-up/light/p098-02.webp)

Когда ужин закончится, останется лишь немного работы: уборка.

![Уборка — последний шаг до завершения](https://producthub.live/assets/books/shape-up/light/p098-03.webp)

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

#### Участки работы на холме

Адрес: https://producthub.live/shape-up/uchastki-raboty-na-kholme

Мы можем соединить холм с понятием участков из [главы 6](https://producthub.live/shape-up/6-razdelit-proekt-na-uchastki-raboty). Участки дают нам язык проекта — «Найти», «Ответить», — а холм описывает состояние каждого участка: «подъём», «спуск».

Чтобы видеть состояние участков, можно нанести каждый на холм своим цветом.

![Участки проекта повторяющихся событий на диаграмме-холме](https://producthub.live/assets/books/shape-up/light/p099-01.webp)

Это снимок состояния проекта по добавлению повторяющихся событий в Basecamp. Участок «Правки, распространяющиеся на будущие повторения» ещё прорабатывают: здесь остаются значительные неизвестные, которые нужно разрешить. На двух других участках существенных неизвестных уже нет, а «Глобальные повторяющиеся события» ближе к завершению.

#### Состояние работы без вопросов

Адрес: https://producthub.live/shape-up/sostoyanie-raboty-bez-voprosov

Мы создали функцию, доступную только в Basecamp: она позволяет создавать диаграммы-холмы и обновлять их несколькими нажатиями. Участники команды, которые полностью понимают состояние работы, интуитивно перетаскивают участки в нужные позиции и сохраняют обновление в журнале проекта. Каждая точка соответствует участку работы; при обновлении команда перемещает её в новое положение и при необходимости добавляет комментарий. История обновлений позволяет сравнить состояние участков в разные моменты.

![Участники команды обновляют положение участков работы на диаграмме-холме](https://producthub.live/assets/books/shape-up/light/p100-01.webp)

Для руководителей главная ценность — возможность сравнивать предыдущие состояния. Она показывает не только текущее положение работы, но и её движение.

![История диаграммы-холма показывает движение участков со временем](https://producthub.live/assets/books/shape-up/light/p100-02.webp)

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

Этот отчёт становится первым местом, куда руководитель обращается, когда начинает беспокоиться о проекте. Поскольку он может посмотреть всё самостоятельно, незачем прерывать команду неловким вопросом о состоянии работы. А если что-то выглядит неправильно, руководитель может сразу перейти к обсуждению соответствующего фрагмента: «Похоже, “Автосохранение” уже какое-то время остаётся на подъёме. Что за  неизвестность не даёт ему продвинуться?» Руководитель может вместе с командой разобрать эту конкретную часть проекта, не отделяя её предварительно от всего остального, что идёт по плану.

#### Никто не говорит «Я не знаю»

Адрес: https://producthub.live/shape-up/nikto-ne-govorit-ya-ne-znayu

Никто не хочет поднимать руку перед руководством и говорить: «Я не знаю, как решить эту проблему». Из-за этого команды скрывают неопределённость и накапливают риск. Моменты, когда кто-то застрял или ходит по кругу, несут самые большие риски и возможности. Если заметить их рано, можно разобраться с ними с помощью более опытного коллеги или пересмотреть концепцию. Если не заметить, нерешённые проблемы могут так надолго затянуться внутри цикла, что поставят проект под угрозу.

Диаграмма-холм позволяет всем увидеть, что кто-то, возможно, застрял, хотя человек не говорит об этом прямо. Неподвижная точка — по сути, поднятая рука: «Здесь что-то может быть не так».

![Неподвижная точка на протяжении нескольких дней сигнализирует о возможной проблеме](https://producthub.live/assets/books/shape-up/light/p101-01.webp)

Когда это замечено, язык подъёма и спуска облегчает разговор. Он в меньшей степени про человека — «Похоже, ты застрял!» — и в большей про работу. Вопрос такой: что мы можем решить, чтобы перевести этот участок через вершину?

#### Повод пересмотреть участки работы

Адрес: https://producthub.live/shape-up/povod-peresmotret-uchastki-raboty

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

Вот случай, когда участок «Уведомить» (*Notify*) слишком долго оставался на одном месте на холме.

![Участок «Уведомить» не сдвигается между шестым и двенадцатым днём](https://producthub.live/assets/books/shape-up/light/p102-01.webp)

Когда мы поговорили с командой, выяснилось, что работа продвигается вполне нормально. Проблема была в том, что «Уведомить» — не одна вещь. Участок состоял из трёх частей: дизайн электронного письма, отправка письма на бэкенде и отображение уведомления в меню приложения. Команда почти закончила код отправки письма. С дизайном письма почти разобрались. Но к отображению в приложении ещё не приступали. Невозможно было сказать, перевалил ли весь участок «Уведомить» через вершину: некоторые его части — да, другие — нет.

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

![«Уведомить» разделён на уведомление в меню Hey, электронное письмо и доставку](https://producthub.live/assets/books/shape-up/light/p102-02.webp)

Теперь команда может перемещать каждую точку и точно показывать состояние работы.

![Одна точка разделена на три, отражающие разные состояния работы](https://producthub.live/assets/books/shape-up/light/p103-01.webp)

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

![Три выделенных участка независимо продвигаются по холму](https://producthub.live/assets/books/shape-up/light/p103-02.webp)

#### Поднимайтесь по холму, создавая работающий результат

Адрес: https://producthub.live/shape-up/podnimaytes-po-kholmu-sozdavaya-rabotayushchiy-rezultat

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

Часто это происходит потому, что кто-то проделал работу подъёма головой, а не руками. Придумать подход в голове — лишь первый шаг вверх. У нас часто есть теория решения — «Я просто воспользуюсь этим API», — а реальность оказывается сложнее. Полезно понимать первую треть подъёма как «Я обдумал это», вторую — как «Я проверил свой подход», а последнюю, до вершины, — как «Я достаточно далеко продвинулся в создании решения и не думаю, что остались другие неизвестные».

#### Решайте проблемы в правильной последовательности

Адрес: https://producthub.live/shape-up/reshayte-problemy-v-pravilnoy-posledovatelnosti

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

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

Это побуждает команду сначала продвигать вверх самую пугающую работу. Выяснив, как её делать, участники оставляют её в этом состоянии и ищут другие критически важные проблемы, прежде чем полностью завершать работу на спуске. Лучше уже в начале проекта перевести несколько критически важных участков через вершину, а «подтягивание винтов» оставить на потом.

Работа заполняет всё доступное время. Если команда начнёт с шаблона письма, она легко может потратить недели на доработку текста или создание самого прекрасного дизайна письма на свете. Но это не нужно. Есть вариант шаблона, который можно придумать за день на последней неделе, и его будет достаточно. Геокодер, напротив, может преподнести новые проблемы, с которыми команда будет бороться неделями. Участники не хотят получить такой сюрприз в конце цикла.

У журналистов есть понятие «перевёрнутая пирамида». Его смысл в том, что статья начинается с самой важной информации, а затем идут подробности и фоновые сведения в порядке убывания важности. Это позволяет верстальщикам печатных газет поместить важнейшую часть истории на первую полосу и при необходимости обрезать конец, не потеряв ничего существенного.

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

К концу цикла команды должны завершить важное и оставить вокруг разные желательные задачи и «возможно». Это подводит нас к следующей главе — о том, как решить, когда остановиться.

## Часть 3. Завершить вовремя и двигаться дальше

### Глава 8. Определить достаточный результат

Адрес: https://producthub.live/shape-up/8-opredelit-dostatochnyy-rezultat

![Когда остановиться](https://producthub.live/assets/books/shape-up/light/p105-01.webp)

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

И всё же работы всегда больше, чем времени. Выпустить вовремя — значит выпустить что-то несовершенное. Когда смотришь на свою работу и спрашиваешь себя «Достаточно ли это хорошо? Готово ли это к выпуску?», внутри всегда немного неспокойно.

#### Сравнивайте с исходным положением

Адрес: https://producthub.live/shape-up/sravnivayte-s-iskhodnym-polozheniem

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

Гордость за работу важна для качества и настроя команды, но её нужно направить на правильную цель. Если стремиться к идеальному, безупречному дизайну, мы никогда до него не доберёмся. При этом снижать требования тоже не хочется. Как решить, что имеющийся результат достаточно хорош и можно двигаться дальше?

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

Когда мы видим, что уже сделанное лучше существующих альтернатив, нам легче оценить свой прогресс. Это побуждает принимать решения о том, что нас тормозит. Мы меньше думаем о себе и больше — о ценности для клиента. Так мы переходим от «никогда не будет достаточно хорошо» к «лучше того, что у них есть сейчас». Можно сказать: «Ладно, это не идеально, но точно работает, и для клиентов это будет заметное улучшение».

![Сокращайте объём, сравнивая результат с исходным положением, а не с недостижимым идеалом](https://producthub.live/assets/books/shape-up/light/p106-01.webp)

*Сокращайте объём работы, сравнивая результат с исходным положением, а не с каким-то совершенным идеалом.*

#### Ограничения побуждают выбирать компромиссы

Адрес: https://producthub.live/shape-up/ogranicheniya-pobuzhdayut-vybirat-kompromissy

Время проекта ограничено предохранителем: если работа не выпущена за выделенный цикл, по умолчанию её не продлевают. Команда останавливается, а нерешённую проблему возвращают на проработку. Дополнительное время требует нового обоснования; редкие условия продления рассмотрены ниже. Это не позволяет одному проекту бесконтрольно поглощать ресурсы.

Это заставляет команду выбирать компромиссы. Если кто-то говорит «А не было бы лучше, если…» или находит ещё один пограничный случай, сначала стоит спросить себя: есть ли на это время? Без крайнего срока легко задержать проект ради изменений, которые на самом деле не заслуживают дополнительного времени.

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

#### Объём работы растёт, как трава

Адрес: https://producthub.live/shape-up/obem-raboty-rastet-kak-trava

Объём растёт естественным образом. Его расползание — не вина плохих клиентов, плохих менеджеров или плохих программистов. На крупном масштабе проекты непрозрачны. Всех мелких деталей не увидишь, пока не погрузишься в работу. Тогда обнаруживаются не только неожиданные сложности, но и всевозможные вещи, которые можно исправить или сделать лучше.

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

Такова реальность. Вместо того чтобы пытаться остановить рост объёма, дайте командам инструменты, полномочия и ответственность, чтобы постоянно его сокращать.

#### Сокращать объём — не значит снижать качество

Адрес: https://producthub.live/shape-up/sokrashchat-obem-ne-znachit-snizhat-kachestvo

Выбор того, что делать и насколько далеко идти в реализации, не оставляет в продукте дыр. Выбор делает продукт лучше. Он помогает продукту лучше справляться с одними вещами, а не с другими. Придирчивость к объёму работы отличает продукт от остальных. Разделяя главное и второстепенное, мы меняем своё положение среди конкурентов: становимся более похожими или менее похожими на продукты, создатели которых выбрали иначе.

Гибкий объём работы не означает жертвы качеством. Мы чрезвычайно придирчивы к качеству кода, визуального дизайна, текстов интерфейса и быстродействия взаимодействий. Главное — спросить себя: что действительно важно, что заметно меняет результат и что существенно для основных сценариев использования, которые мы хотим поддержать?

#### Жёстко сокращайте объём

Адрес: https://producthub.live/shape-up/zhestko-sokrashchayte-obem

Обычно говорят «урезать» объём работы. Мы используем более сильное слово — *hammering*, буквально «обработка молотком», — чтобы передать усилие, с которым приходится снова и снова подбивать объём под отведённое время.

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

- Обязательно ли это для новой функции?
- Можем ли мы выпустить её без этого?
- Что произойдёт, если мы этого не сделаем?
- Это новая проблема или уже существующая, с которой клиенты и так живут?
- Насколько вероятно, что этот случай или условие возникнет?

- Когда это происходит, какие клиенты сталкиваются с этим? Это основной сценарий, которым пользуются все, или скорее пограничный случай?
- Каковы реальные последствия, если этот случай или условие всё-таки возникнет?
- Если что-то плохо работает в определённом сценарии, насколько этот сценарий соответствует нашей целевой аудитории?

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

На протяжении цикла команды обсуждают обязательные и желательные задачи по мере того, как обнаруживают работу. Обязательные задачи добавляют к соответствующему участку работы. Участок не считается завершённым, пока они не выполнены. Желательные задачи могут оставаться на участке и после того, как он признан завершённым. Перед ними ставят тильду (~). Это то, что можно сделать, если в конце у команды останется время, и от чего можно отказаться, если времени не будет. Обычно эти задачи так и не реализуются. Само отнесение задачи к желательным — уже жёсткое сокращение объёма.

![Завершённый участок работы с одной невыполненной желательной задачей, отмеченной тильдой](https://producthub.live/assets/books/shape-up/light/p108-01.webp)

*Завершённый участок работы с одной желательной задачей, отмеченной «~», которая так и не была выполнена.*

#### QA — для пограничных случаев

Адрес: https://producthub.live/shape-up/qa-dlya-pogranichnykh-sluchaev

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

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

Много лет у нас вообще не было роли QA. Но когда аудитория выросла до определённого размера, мы увидели, что небольшие пограничные случаи в абсолютных числах затрагивают сотни и тысячи пользователей. Дополнительная проверка QA помогла улучшить их опыт и снизить несоразмерную нагрузку на поддержку, которую эти случаи создавали бы.

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

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

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

#### Когда продлевать проект

Адрес: https://producthub.live/shape-up/kogda-prodlevat-proekt

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

Во-первых, оставшиеся задачи должны быть действительно обязательными и выдержать все попытки исключить их при жёстком сокращении объёма.

Во-вторых, вся оставшаяся работа должна находиться на спуске. Никаких нерешённых проблем и открытых вопросов. Любая работа на подъёме в конце цикла указывает на упущение при проработке или дыру в концепции. Делать ставку на неизвестное слишком рискованно. Если работа всё ещё на подъёме, лучше заняться в следующем цикле чем-то другим, а проблемный проект вернуть на этап проработки. Если найдётся жизнеспособный способ закрыть дыру, можно будет в будущем снова рассмотреть ставку дополнительного времени на этот проект.

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

> **Редакторское пояснение.** Передышка в Basecamp — две недели между шестинедельными циклами. На неё не назначают очередной набор проектов: это время для исправления ошибок, небольших незавершённых дел и подготовки следующего цикла. Она не является автоматическим запасом срока для каждого проекта.

### Глава 9. Работать с обратной связью после выпуска

#### Дайте буре утихнуть

Адрес: https://producthub.live/shape-up/dayte-bure-utikhnut

Если не быть осторожными, сам выпуск может создать новую работу. Новые функции вызывают новые запросы. Клиенты говорят: «Хорошо, это здорово, но как насчёт той другой вещи, о которой мы давно просим?» Всплывают ошибки. Приходят предложения улучшений. Все сосредоточены на новинке и реагируют на неё.

Обратная связь может быть особенно бурной, если выпущенная функция меняет привычный порядок работы. Даже чисто визуальные изменения иногда вызывают сильное сопротивление. Небольшая часть клиентов может реагировать чрезмерно: «Вы всё испортили! Верните как было!»

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

#### Не набирайте долгов

Адрес: https://producthub.live/shape-up/ne-nabirayte-dolgov

Может возникнуть соблазн пообещать изменения в ответ на обратную связь. Но тогда следующий цикл уже не начнётся с чистого листа. Помните: к вам поступают всего лишь сырые идеи. Отвечать на них стоит мягким «нет». Слово «нет» не мешает продолжать обдумывать идею и, возможно, проработать её в будущий проект. А «да» лишает свободы в будущем. Это похоже на долг.

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

#### Обратную связь тоже нужно проработать

Адрес: https://producthub.live/shape-up/obratnuyu-svyaz-tozhe-nuzhno-prorabotat

Здесь мы замыкаем круг. Сырые идеи, только что полученные из обратной связи клиентов, ещё не готовы к действию. Их нужно проработать. Это те самые исходные материалы, о которых мы говорили в первом шаге проработки: «Задайте границы».

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

---

Product Hub — продуктовый консалтинг: с 2019 года решили 120+ бизнес-задач. Обсудить задачу: https://producthub.live/shape-up (кнопка «Обсудить сотрудничество»).