Делайте ваши ставки

Изучите обстановку

Многое в 6-недельном цикле зависит от того, посвящён ли проект развитию существующего продукта (фичи) или созданию нового.

Принимая решения, нужно хорошо понимать, в какой стадии развития находится продукт в целом.

Развитие продукта

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

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

Новые продукты

Другое дело — новые продукты. Если, покупая диван, вы уже знаете размеры и обстановку комнаты, то разработка нового продукта — это скорее заливка фундамента и возведение стен.

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

Этап 1. Исследование

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

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

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

2. Вместо отдельной команды разработки, продукт берёт в работу руководство. Дэвид (CTO) — разработчик, Джейсон (CEO) — дизайнер. Это важно по двум причинам. Во-первых, нельзя делегировать другим работу, если не сможешь сформулировать, чего точно хочешь. Во-вторых, архитектурные решения, принятые на этом этапе, повлияют на будущее продукта в целом. Команда должна опираться на своё видение продукта и отвечать за долгосрочные последствия решений.

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

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

Этап 2. Разработка

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

1. Проекты снова проходят через полноценное формирование и презентацию. Все точно понимают, что должно получиться в конце цикла.
2. Над продуктом может параллельно работать несколько команд (каждая над своим проектом).
3. Цель работы — снова реализованный проект. Но поскольку продукт ещё не выпущен на рынок, «реализованный» в этом случае означает не «публичный релиз», а вливание кода в общую базу с намерением больше его не менять.

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

Этап 3. Чистка

Финальный этап перед выпуском продукта — «чистка». Мы откладываем в сторону все процессы.

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

Поэтому мы всегда оставляем запас времени перед запуском. Вот чем отличается этап чистки:

1. Проекты не формируются. Этот цикл скорее напоминает Багатон. Руководство оперативно определяет приоритеты и убирает отвлекающие факторы.
2. Нет чётких команд. Каждый берётся за то, с чем лучше всего может помочь.
3. Результаты заливаются в кодовую базу по мере готовности, не дожидаясь конца цикла.

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

Примеры

Календарь с точками

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

HEY

В 2020 году, после двух лет работы, мы запустили новый сервис электронной почты — HEY.

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

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

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

Каждый цикл на первом этапе исследования зависел от результатов предыдущего. Команда не планировала работать над продуктом именно два года. Уверенность в идее продукта пришла постепенно, и в какой-то момент руководство решило, сколько именно циклов можно потратить на разработку (но при этом ещё не сформировало проекты для этих циклов). Мы всегда имели в виду возможность отложить работу над новым продуктом и вернуться к основному продукту, Basecamp.

Эксперимент: графики-холмы

Третий пример — нечто среднее. Когда мы работали над идеей графиков-холмов в Basecamp (подробнее в главе 13), мы не были уверены, что идея вообще сработает. Basecamp был уже стабильным продуктом, и казалось рискованным отдавать пользователям экспериментальную фичу.

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

О чём спрашивать на голосовании

Стоит ли решать проблему?

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

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

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

Иногда сложность решения приводит к переосмыслению проблемы. Точно ли нужно столько работы? Можно ли упростить формулировку, чтобы 80% проблемы решить за 20% усилий?

Адекватен ли аппетит?

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

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

2. Стоит уточнить «а если ужать срок до 2 недель?». Возможно, выяснится, что участника смущает не трата ресурсов сама по себе, а что-то в проекте. Например, «я понял, очень не хочется добавлять в эту часть продукта ещё одну зависимость».

3. Если автор проекта чувствует, что интереса у других участников встречи нет, можно просто положить проект на полку или отменить.

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

Устраивает ли решение?

Проблема важна, аппетит адекватен, а всё ли хорошо с предлагаемым решением?

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

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

Подходящее ли время?

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

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

Доступны ли нужные люди?

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

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

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

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

Опубликуйте сообщение с результатами

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

---