Решение «выкинуть фичу»
Когда лучше выкинуть или отложить чем доделывать — критерии и процесс.
Решаешь резать {{feature}} или дотягивать.
Когда РЕЗАТЬ
-
Эффорт уже превысил планку, а конец не виден
- Изначально оценили в 2 недели → 6 недель → "ещё чуть-чуть"
- Каждое "чуть-чуть" — ещё столько же. Режь сейчас.
-
Метрика после soft-launch не движется
- 2 недели в продакшене на 10% юзеров — нет изменений в целевой метрике
- Гипотеза провалилась. Резать или сильно переделывать.
-
Решения противоречат друг другу
- "Эта фича для новых юзеров" + "и для продвинутых сразу" — невозможно
- Не нашли target = режь
-
Маленький RICE по сравнению с альтернативами
- Сейчас в бэклоге есть в 5x более RICE-ёмкие задачи
- Open opportunity cost
-
Технический долг растёт быстрее ценности
- Каждая итерация требует чинить что-то старое
- Лучше переделать архитектуру чем продолжать
Когда ДОТЯГИВАТЬ
- Уже близко к запуску (80%+ готово)
- Есть пользователи которые активно ждут (не предполагаемые — реальные)
- Метрика двигается на soft-launch, нужна полировка
- Часть большой стратегической ставки
Алгоритм решения
1. Зафиксируй текущее состояние:
- Сколько уже вложили (time, money)
- Сколько ещё нужно до запуска
- Какой эффект ожидаем
2. Спроси: "Если бы стартовали с нуля сегодня — взялись бы?"
- Если нет — режь
- Если да — почему именно сейчас тяжело?
3. Альтернативы:
- Резать целиком
- Сократить скоуп до MVP (выпустить меньшее)
- Заморозить, вернуться через квартал
- Передать другой команде
4. Если режешь — что делать с уже сделанным?
- Закоммитить полезные части (рефактор, инфра)
- Удалить мёртвый код
- Документировать "что узнали"
Коммуникация
- Расскажи команде ПЕРВЫМ — не из коридора
- Объясни почему конкретно (не "ну как-то не пошло")
- Поблагодари людей за работу, не обесценивай
- Зафиксируй чему научились
- Если фича публично анонсировалась — сообщи юзерам
Sunk cost fallacy
Главное противоядие против "ну мы уже столько вложили". Деньги/время уже потрачены — назад их не вернёшь. Решение принимается только из будущего: что лучше сейчас делать дальше.
Анти-паттерны
- ❌ "Доделаем потому что обещали" — обещание было плохим
- ❌ "Жалко выбросить" — sunk cost fallacy
- ❌ Молча убрать из роадмапа — команда не доверяет
- ❌ Резать без анализа — может пытались хорошее
В конце
- Решение: режу / дотягиваю / меняю скоуп
- Обоснование (3-5 пунктов)
- План коммуникации
- Что забираем себе из проекта (knowledge / code / лиды)
Декомпозиция фичи в user stories
Разбить фичу на маленькие истории формата «As a … I want … so that …» с acceptance criteria.
ADR-практика: lifecycle, что туда писать, что НЕ
Когда писать ADR (architectural, не каждый PR), формат, lifecycle (proposed/accepted/superseded), как сделать живым, что НЕ ADR.
PRD из идеи фичи
От «давайте сделаем X» до спека, по которому команда может работать без 100 уточнений.