Голосование

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

6-недельные циклы

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

Работа 6-недельными циклами радикально упрощает планирование. Цикл задаёт нам стандартный размер проекта — сначала для формирования, затем для разработки.

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

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

Перерыв

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

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

Размеры команды и проекта

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

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

В течение цикла такая команда работает либо над одним проектом стандартного размера, либо над набором из нескольких мелких проектов. Размер мелкого проекта — обычно 1 или 2 недели. Мелкие проекты внутри набора не планируются заранее — команда работает над ними в удобном им порядке. Главное, чтобы все они были готовы к концу цикла.

Процесс голосования

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

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

В Basecamp голосующая команда состоит из CEO (в нашем случае за ним последнее слово в продуктовых вопросах), CTO, ведущего разработчика и продуктового стратега (это я).

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

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

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

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

Голосование вместо планирования

Мы используем термин «голосование», а не «планирование», и вот в чём различия.

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

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

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

Рассмотрим подробнее два последних пункта.

Не отвлекать

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

Не стоит верить «тут быстренько» или «мне всего пару часов». Для достижения результата требуется непрерывная последовательность действий. Когда вы отвлекаете кого-то на день, теряется не только календарный день, а всё «непрерывное ускорение», накопленное им к этому моменту. Отвлечение на день может стоить проекту недели.

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

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

Предохранитель

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

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

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

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

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

Исправление багов

Если мы не отвлекаем разработчиков в течение цикла, как мы исправляем баги?

Прежде всего, давайте подвергнем сомнению общепринятое мнение о багах.

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

При этом, конечно, никто не любит неисправленные баги. У нас есть три способа работы с ними не в ущерб проектам.

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

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

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

3. Багатон (марафон исправления багов). Каждый год (обычно ближе к праздникам) мы посвящаем целый цикл исправлению багов. Мы называем это Багатон (bug smash). Люди как раз готовятся к праздникам, возможно, переезжают или берут отпуск — неподходящее время для обычных проектов. Команды самостоятельно выбирают, какие баги они хотят исправить.

С чистого листа

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

Мы не знаем, что произойдёт в течение 6 недель — возможно, появится идея отличного проекта или придёт очевидно критичный запрос.

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

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

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

---