Небольшие команды: сначала бюджет времени, потом объём

Небольшие команды: сначала бюджет времени, потом объём работ

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

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

Почему сначала бюджет времени

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

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

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

Простая рамка бюджетирования

Вот четыре шага.

Первый: рассчитайте доступное время. Не используйте идеальные значения вроде «восемь часов в день». Вычтите встречи, общение, переключение контекста, исправление багов, ответы пользователям. У небольшой команды реально доступно для разработки часто только 50–60% номинальных часов.

Второй: разделите время на категории. Не просто «разработка» и «не разработка». Детальнее: новая функциональность, исправление проблем на проде, технический долг, операционная поддержка. Для каждой категории задайте максимум. Например, на новую функциональность — не более 20 часов в неделю, на исправление багов — не более 5.

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

Четвёртый: оставьте буфер. Никогда не заполняйте итерацию целиком. Резервируйте минимум 20% на неожиданности — срочные исправления, внезапные отзывы пользователей, несовместимость библиотеки. План без буфера — это по сути план на удачу.

Как бюджет времени влияет на решения об объёме

С бюджетом решения об объёме становятся арифметикой.

Допустим, на новую функциональность на этой неделе выделено 15 часов, а требование оценивается в 20 часов. У вас есть варианты: сократить объём вдвое и сосредоточиться на ключевом сценарии; потратить 10 часов на более простую версию, которая закроет 60% потребностей пользователей; или вообще не делать.

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

Пример сценария

Вот пример (иллюстративный, не реальный случай): небольшая команда делает AI-инструмент для письма и планирует за неделю запустить функцию «изменение тона». В идеале хочется поддерживать три тона: официальный, неформальный и юмористический. Но оценка показывает, что все три потребуют 24 часов разработки. А бюджет новой функциональности на эту неделю — только 16 часов.

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

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

Что делать, если бюджет превышен

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

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

Резюме

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

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

PaxLee