Оценка инициативы в IT‑портфеле: Task vs Epic vs Initiative + WSJF
Коротко
- Это дерево решений для оценки инициативы: задача, эпик или инициатива.
- Определяет корзину портфеля RUN / GROW / TRANSFORM.
- Для GROW считает Cost of Delay и WSJF по правилам портфеля (CoD / dev‑weeks).
- Может остановить оценку и вернуть на доработку, если цель/документы/сроки — "TBD".
Если в вашей компании IT‑задачи приоритизируются по принципу "кто громче попросил" — вы платите за конфликты, а не за результат.
Ниже — простой gamified‑квиз, который следует логике регламента управления IT‑портфелем: 70‑20‑10, Hard vs Soft Savings, Cost of Delay и WSJF.
Для кого этот оценщик
- Роль: CEO/COO, CIO/CTO, Head of Product/PO, руководитель направления, финконтроль.
- Контекст: портфель уже существует (или формируется), но спорите о приоритетах — и нужен быстрый способ сопоставлять инициативы на общих правилах.
Как отвечать на вопросы (с примерами)
Этот оценщик специально написан так, чтобы им могли пользоваться люди с разным опытом — от тех, кто впервые слышит про WSJF, до руководителей портфеля. Ниже — короткие подсказки, как думать над каждым шагом.
Шаг 1) RUN / GROW / TRANSFORM (Change/Disrupt)
- RUN: держим систему в рабочем состоянии (security, compliance, инциденты, техдолг). Пример: закрыть критические CVE, снизить MTTR, обновить платформу ради поддержки.
- GROW: улучшаем существующую модель и ожидаем понятный эффект. Пример: повысить конверсию, уменьшить cost-to-serve, ускорить цикл сделки.
- TRANSFORM: меняем способ работы/архитектуру/платформу; эффект может быть неопределённым, поэтому нужны learning milestones и Go/No-Go. Пример: миграция на новую платформу, переход на event-driven, выделение доменов, новый data stack.
Короткие примеры по доменам: e-commerce — RUN: антифрод/доступность checkout; GROW: конверсия корзины; TRANSFORM: новая OMS. Fintech — RUN: compliance/аудит; GROW: снижение отказов KYC; TRANSFORM: новая core-платформа. B2B SaaS — RUN: SLO и инциденты; GROW: активация/retention; TRANSFORM: переход на enterprise-архитектуру. Internal platform — RUN: безопасность/patching; GROW: ускорение delivery; TRANSFORM: платформа self-service.
Шаг 2) Метрика и числовой target (обязателен)
Если target нельзя проверить числом — это “TBD” и инициатива не сравнима с другими. В оценщике вы выбираете метрику и target из готовых списков (чтобы не было разночтений), а срок — из типовых вариантов.
- Хорошо: “MTTR ≤ 2 часа”, “P1 инцидентов −30% за квартал”, “доля автообработки 60% → 80% к Q2”.
- Плохо: “улучшить”, “сделать быстрее”, “попробовать”, “потом определим”.
Ещё примеры targets: e-commerce — “доля успешных платежей 92% → 95%”, fintech — “время открытия счёта ≤ 10 минут”, B2B SaaS — “time-to-first-value ≤ 1 день”, internal platform — “lead time −20%”.
Шаг 3) Драйвер эффекта (Revenue / Hard / Risk / Soft)
- Revenue: эффект — рост выручки/конверсий/ARPA. Нужны владелец P&L и дата старта эффекта.
- Hard Savings: реальное сокращение затрат (контракты/лицензии/позиции). “Экономия часов” сюда не относится.
- Risk: эффект — предотвращение risk-event (outage/штраф/срыв). Важно указать срок, через сколько недель событие может случиться, если ничего не делать.
- Soft Savings: экономия часов без сокращения штата. По правилам портфеля это не деньги, пока нет reinvestment plan и верификации.
Типичные ошибки: записывать Soft Savings как Hard, смешивать 3–4 драйвера в одном кейсе, или называть “risk”, не имея срока события.
Шаг 4) Доказательства эффекта
Это самый частый источник “магии” в инициативах. Если нет владельца, сроков и документов, портфель не может финансировать работу как инвестицию.
Для Risk: срок события тоже выбирается из типовых вариантов. Если вы не знаете срок — это признак “TBD”, и оценщик честно остановит инициативу до уточнения.
Шаг 5) Длительность (dev-weeks) и неопределенность
WSJF сравнивает инициативы по трудоёмкости: dev-weeks = разработчики × недели. В оценщике это делается через списки (сколько dev × какой диапазон недель), чтобы не спорить о “точных” цифрах. Пример: 3 dev × 4 недели = 12 dev-weeks. Если неопределенность оценки > 50% — сначала делайте спайк.
Неопределенность в оценщике тоже выбирается как диапазон (низкая/средняя/высокая). При высокой (> 50%) оценщик рекомендует сначала спайк.
Подсказка новичкам: если вы не можете объяснить, что будет сделано за 1–2 недели, скорее всего оценка “в месяцах” сейчас выдумана — сначала спайк/декомпозиция.
Шаг 6) Зависимости
Зависимости выбираются как уровень (нет/умеренно/тяжело). Кросс-командность и тяжелые зависимости почти всегда повышают риск и удлиняют сроки. Примеры: общий релиз-слот, внешний вендор, shared API, легаси-окна, согласования security/архитектуры.
Источник правил: внутренние правила управления IT‑портфелем (RUN/GROW/TRANSFORM, Hard vs Soft Savings, Cost of Delay и WSJF).
Как использовать результат
- RUN/CORE: не требуйте ROI — требуйте SLA/MTTR/качество и владельца.
- GROW: сравнивайте инициативы по экономике (CoD/WSJF), а не по статусу стейкхолдера.
- TRANSFORM: финансируйте по learning milestones и делайте Go/No‑Go каждые 3 месяца.
Если хотите сделать оценку точнее (и быстрее согласовать)
- Проверьте, есть ли метрика и числовой target (если нет — это сигнал "TBD").
- Если неопределенность срока > 50% — сначала сделайте спайк / дешёвый эксперимент. Lean‑валидация: как дешево проверять гипотезы
- Если нужно "проверить деньги" — используйте базовый шаблон: финмодель и метрики
Связанные материалы
Частые вопросы
Почему Soft Savings считаются как $0?
По регламенту Soft Savings — это экономия часов без сокращения штата. Пока нет reinvestment plan и верификации в QBR, эффект не признаётся как экономический.
Это точный расчёт WSJF?
Нет. Это быстрый оценщик. Его задача — заставить вас за 3–5 минут заполнить минимальные поля: эффект, длительность, метрика, риски, зависимости — и снять "TBD".