Шкаф с недоделанными фичами: простая система, чтобы спасать заброшенную разработку, не начиная с нуля

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

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

Думайте о нём как о структурированной системе, которая помогает:

• Сделать заброшенную работу видимой, а не закопанной
• Сохранить достаточно контекста, чтобы её было безопасно переиспользовать
• Превратить большие неизвестные в маленькие, чётко очерченные задачи по спасению
• Решать, когда спасать, а когда отпускать

В этом посте разберём, как спроектировать и запустить шкаф фич, который держит ваш код (и совесть) в порядке.

Почему нужен «шкаф фич», а не кладбище

У большинства команд уже есть де-факто кладбище:

• Старые ветки с названиями вроде final-final-wip
• Тикеты в JIRA, перекинутые в «Blocked» и тихо забытые
• PR’ы в статусе Draft, которые так и не взрослеют до merge

Проблема не в том, что работа остановилась — это нормально. Проблема в другом:

• Нет видимости — никто не может ответить на вопрос: «Какая недоделанная работа у нас уже есть?»
• Нет контекста — даже если что-то нашли, нет внятного описания, что готово, а чего нет.
• Нет процесса принятия решений — фичи висят вечно; их никто не спасает и не убивает окончательно.

Шкаф фич переворачивает это с ног на голову:

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

Это не место, куда код уходит умирать. Это место, откуда он либо:

• Аккуратно спасается в виде небольших доработок, или
• Осознанно архивируется с чётким «нет», а не с вечным подвешенным состоянием.

Шаг 1. Сделайте шкаф фич видимым

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

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

Хорошие варианты:

• Отдельная доска/колонка в вашем проектном инструменте: Шкаф с недоделанными фичами
• Страница в Notion/Confluence с таблицей записей
• GitHub Project board с отдельным label, например half-finished

Минимальный набор полей для каждой записи:

• Название — понятное имя фичи или инициативы
• Владелец (исторический) — кто последний над этим работал
• Статус — например, «Кандидат», «Готово к спасению», «Архив»
• Ссылки — на ветку/PR/тикеты

Теперь этот список — ваш единый источник правды о том, «что мы начали, но не закончили».

Шаг 2. Используйте простой шаблон для каждой недоделанной фичи

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

Используйте стандартный шаблон:

Шаблон недоделанной фичи

• Краткое описание: 2–3 предложения о том, что делает эта фича и зачем её начали.
• Технологии / Область: например, React + TypeScript (frontend), Node.js API, миграция PostgreSQL и т.п.
• Что сделано:
  • Список пунктов с завершёнными частями
  • Пометка, какие части покрыты тестами или проверены вручную
• Чего не хватает:
  • Список оставшихся задач, неизвестных и решений, которые нужно принять
• Подводные камни / Риски:
  • Известные баги, проблемы с производительностью, сложные edge‑кейсы
  • Архитектурные моменты («затрагивает auth», «меняет логику биллинга»)
• Текущее состояние:
  • Ссылки на ветки/PR’ы
  • Дата последнего обновления
• Исходный контекст:
  • Почему работу остановили (смена приоритетов, изменение scope, блокирующие зависимости и т.д.)

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

Совет: сделайте шаблон копируемым блоком в документации, чтобы его можно было заполнить за 5–10 минут.

Шаг 3. Превратите заброшенные фичи в маленькие задачи по спасению

«Доделать недоделанную фичу» — плохая задача. Она расплывчатая, пугающая и плохо оценивается по времени.

После того как шаблон заполнен, следующий шаг — нарезать фичу на маленькие, чётко очерченные rescue‑задачи. Например:

Вместо:

• «Закончить новый дашборд отчётности»

Разбейте на:

• «Подключить API дашборда к существующему metrics endpoint’у»
• «Сделать пагинацию и базовые фильтры»
• «Добавить happy‑path‑тесты для API дашборда»
• «Подключить feature flag и конфигурацию rollout’а»

Каждая задача по спасению должна:

• Быть достаточно маленькой, чтобы комфортно поместиться в один спринт
• Иметь чёткое определение готовности (Definition of Done)
• Содержать ссылку обратно на запись в шкафу

Цель в том, чтобы разработчик мог:

1. Открыть запись в шкафу
2. Понять состояние по шаблону
3. Взять rescue‑задачу и доставить ощутимый результат

Шаг 4. Приоритизируйте по влиянию и усилиям, а не по давности и чувству вины

Худший способ расставлять приоритеты по спасению:

• «Это самое старое, надо доделать» (ошибка, связанная с давностью)
• «Мы уже столько сюда вложили, надо закончить» (синдром невозвратных затрат)

Относитесь к спасению так же, как к любой другой работе: ему нужна бизнес‑логика.

Оценивая кандидатов из шкафа, спрашивайте:

• Влияние: Если фича будет доделана сейчас, какую пользу она принесёт?
  • Решает ли она всё ещё актуальную боль пользователя?
  • Соответствует ли стратегическому направлению продукта?
• Усилие: Сколько работы реально осталось, исходя из шаблона?
  • Это пара дней или несколько недель?
• Риск: Не принесёт ли продолжение работы технических или организационных рисков?

Можно использовать простую модель оценки:

• Влияние: 1–5
• Усилие: 1–5 (обратная шкала; 1 = много, 5 = мало)
• Риск: 1–5 (обратная шкала; 1 = рискованно, 5 = безопасно)

Сортируйте по сумме Влияние + Усилие + Риск и берите в работу записи с самыми высокими баллами. Так решения остаются рациональными, а не эмоциональными.

Шаг 5. Задайте правила: когда спасать, а когда архивировать

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

Задайте понятные правила, чтобы не бесконечно откладывать сложные решения.

Примеры правил:

Спасать, если:

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

Архивировать, если:

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

Когда решаете архивировать, делайте это осознанно:

• Пометьте запись в шкафу как «Архив»
• Добавьте одну строчку с причиной («Заменено новым биллинговым флоу, Q3 2025»)
• Решите, удалить ли код/ветку или оставить только как справочный материал

Чётко сказанное «нет» намного лучше, чем вечно висящая «зомби‑работа».

Шаг 6. Заложите время на спасение в регулярное планирование

Если ждать «свободного времени» для спасения фич, этого не произойдёт.

Вместо этого закладывайте время на rescue‑работу прямо в спринты или итерации:

Варианты:

• Фиксированный процент: например, 10–15% ёмкости каждого спринта — на спасение из шкафа и уборку
• Ротация по спасению: в каждом спринте 1–2 разработчика фокусируются на rescue‑задачах
• Тематические спринты: периодически делайте спринт «Rescue & Refine», чтобы закрыть самые ценные элементы

Во время планирования:

1. Посмотрите на приоритезированный список шкафа
2. Вытащите несколько самых полезных rescue‑задач в спринт
3. Убедитесь, что они оценены как обычные тикеты и имеют явных ответственных

Так работа по спасению становится частью нормального процесса, а не побочной активностью «если вдруг останется время».

Шаг 7. Требуйте базовый уровень качества для всего, что спасаете

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

• Структура кода: соответствует текущим паттернам и архитектуре (или есть план рефакторинга в рамках спасения)
• Тесты: новая или изменённая логика должна быть тестируемой; тесты добавляются как часть rescue‑задач
• Документация: хотя бы базовые docstring’и, комментарии или заметки в README, где это уместно
• Feature flags / rollout: для рискованных или пользовательских фич должна быть возможность контролировать их включение

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

Так ваш шкаф превращается в источник высокодоходной работы, а не в свалку будущих головных болей.

Собираем всё вместе

Итак, здоровый шкаф с недоделанными фичами выглядит так:

1. Видимый список: одно место, где собирается вся незавершённая работа
2. Простой шаблон: для каждой записи понятно, что сделано, чего не хватает, какие технологии и подводные камни
3. Rescue‑задачи: крупная, размытая работа нарезана на маленькие, чётко очерченные тикеты
4. Приоритизация по влиянию: вы выбираете, что спасать, исходя из ценности, а не чувства вины
5. Явные правила: понятные критерии, когда спасать, а когда архивировать
6. Плановое время: спасение заложено в спринты, а не делается «если вдруг успеем»
7. Стандарты качества: спасённая работа должна соответствовать базовым требованиям к поддерживаемости

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

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