Shape Up — Часть 3, Установите границы

От переводчика

Привет! Я Артем, а это мой любительский перевод книги Shape Up от основателей Basecamp. Первая глава тут. Найдете ошибки или опечатки — можете смело писать мне в телеграм. Ну и на телеграм-канал можете подписаться, там буду публиковать главы по ходу перевода. Enjoy 🤘

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

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

Определяем «аппетиты»

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

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

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

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

• Малый батч — проект, который команда из одного дизайнера и одного или двух программистов могут сделать за 1-2 недели. Мы объединяем такие бати в 6-недельный цикл (подробнее ниже).
• Большой батч — проект для такой же команды, но который займет весь 6-недельный цикл.

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

Фиксируем время, управляем объемом

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

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

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

«Хорошо» относительно

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

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

Как отвечать на новые идеи?

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

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

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

Детализируем задачу

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

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

Другой пример я описал в прошлой главе, «календарный вид». Каждый знает, как выглядит календарь. Но его разработка выявила тонны неопределенности и решений, которые сильно повлияли бы на объем. Если мы хотим потратить только 6 недель вместо полугода на разработку огромного календаря, как нам «урезать» его?

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

Пример: Что такое «Календарь»?

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

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

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

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

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

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

Остерегайтесь «булыжников»

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

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

Границы установлены

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