Урок 03.04: Техники приоритизации требований
Цель урока
Освоить две ключевые техники приоритизации требований — MoSCoW (Must / Should / Could / Won't) и Модель Кано (Kano Model). Научиться распределять требования по категориям, аргументировать приоритеты перед заказчиком и командой, а также понимать, какие функции делают продукт «любимым», а какие — просто «терпимым».
Ключевые понятия
- Приоритизация (Prioritization) — процесс определения порядка реализации требований на основе их ценности, стоимости, рисков и зависимостей
- MoSCoW — метод приоритизации от Agile-фреймворка DSDM (Dynamic Systems Development Method): Must Have, Should Have, Could Have, Won't Have
- Модель Кано (Kano Model) — теория профессора Нориаки Кано, классифицирующая свойства продукта по их влиянию на удовлетворённость пользователя
- MVP (Minimum Viable Product) — минимально жизнеспособный продукт: версия с только Must Have требованиями, достаточная для выхода на рынок
- Value vs Effort — матрица «ценность / стоимость», часто используемая вместе с MoSCoW для обоснования
- Базовые свойства (Basic / Must-be) — в Kano: то, без чего продукт не работает; не повышает удовлетворённость, но вызывает недовольство при отсутствии
- Линейные свойства (Linear / One-dimensional) — в Kano: чем больше, тем лучше; прямо влияют на удовлетворённость
- Восторгающие свойства (Delighters / Attractive) — в Kano: неожиданные функции, которые вызывают восторг; их отсутствие не снижает удовлетворённость
1. Зачем нужна приоритизация?
1.1. Проблема: «Всё важно» — это результат отсутствия приоритизации
Когда заказчик говорит «Всё важно», он на самом деле не думал о приоритетах. Задача аналитика — заставить заказчика выбрать.
Что происходит без приоритизации:
- Команда делает всё подряд, наиболее интересные задачи — первыми
- К критическому функционалу приступают в последний момент
- Сроки срываются, потому что «важное» не было сделано вовремя
- Заказчик недоволен: «Почему вы сделали фичу X, а не Y?»
- Бюджет закончился на необязательных функциях
1.2. Три ограничения (Triple Constraint)
Любой проект ограничен тремя параметрами. Приоритизация — это ответ на вопрос «От чего мы отказываемся, если не успеваем?»:
Объём (Scope) + Время (Time) + Бюджет (Cost) = Качество (Quality)
- Время фиксировано (релиз 1 июня) → приоритизация определяет, какой объём войдёт
- Бюджет фиксирован (2000 часов) → приоритизация определяет, какие функции сделаем
- Объём фиксирован (контракт) → приоритизация определяет, что делаем сначала
Без приоритизации вы не сможете ответить на вопрос: «Что мы НЕ будем делать, если не успеем?»
2. Метод MoSCoW
2.1. История и контекст
MoSCoW — метод приоритизации, разработанный в рамках DSDM (Dynamic Systems Development Method) в 1990-х. Аббревиатура:
| Буква | Английский | Русский | Смысл |
|---|---|---|---|
| M | Must have | Обязательно | Без этого продукт не имеет смысла |
| S | Should have | Желательно | Важно, но можно отложить (найдём workaround) |
| C | Could have | Возможно | «Было бы хорошо», но если не сделаем — никто не заметит |
| W | Won't have | В этот раз не будет | Сознательно исключаем из текущей версии (но фиксируем на будущее) |
Важно: MoSCoW не работает без временной рамки. Нельзя сказать «это Must Have в принципе». Нужно: «Для релиза 1.0 (март 2026) — Must Have».
2.2. Критерии для каждой категории
M — Must Have (Обязательно)
Критерии:
- Без этого требования система не выполняет свою основную задачу
- Нет workaround (обходного пути) — или workaround неприемлемо дорог
- Если не сделать — продукт теряет смысл
Примеры Must Have:
- Регистрация и авторизация (система с личным кабинетом)
- Создание и оплата заказа (интернет-магазин)
- Ввод и хранение контактов (CRM)
- Выдача денег (банкомат)
Тест для Must Have: «Если мы выкатим продукт БЕЗ этой функции — откажутся ли пользователи его использовать?» Если да — Must.
Правило: Must Have должно занимать не более 40–50% объёма работ. Если всё Must — вы неправильно приоритизируете.
S — Should Have (Желательно)
Критерии:
- Важная функция, но есть workaround
- Не сделает продукт бесполезным, но сделает его менее удобным или эффективным
- Если не успеваем — можем выпустить без неё, но заказчик будет расстроен
Примеры Should Have:
- Автокомплит при поиске товара (работает, можно и без него — просто вбивать руками)
- Email-уведомления о смене статуса (можно заходить и проверять вручную)
- История заказов (можно позвонить в поддержку)
Тест для Should Have: «Если этой функции нет — пользователь может выполнить задачу другим способом (более медленным/неудобным)?» Если да — Should.
Ожидание: Should = «Будет больно, но можно жить».
C — Could Have (Возможно)
Критерии:
- Функция, которая добавляет небольшую дополнительную ценность
- Пользователь не заметит её отсутствия
- Легко реализовать, если останется время (low-hanging fruit)
Примеры Could Have:
- Украшения интерфейса (анимации, иконки, темы оформления)
- Экспорт данных в PDF (если есть базовый Excel — already enough)
- Кнопка «Поделиться» в социальных сетях
Тест для Could Have: «Если этой функции нет — кто-нибудь вообще заметит? А если мы реализуем — порадуются?» Если да на второй вопрос — Could.
W — Won't Have (В этот раз не будет)
Критерии:
- Сознательно исключено из текущей версии
- Не является приоритетом для данного релиза
- Зафиксировано в бэклоге для будущих версий
Важно: «Won't Have» — не значит «никогда». Это значит «не в этом релизе/спринте». Заказчик должен понять, что функция отложена, а не отменена навсегда.
Примеры Won't Have для MVP:
- Мобильное приложение (если делаем веб-версию)
- Интеграция с 1С (если она запланирована на 2-ю фазу)
- Многоязычность (если делаем русскоязычную версию)
2.3. MoSCoW — пошаговый процесс
Шаг 1: Установите временную рамку
«Для релиза 1.0 — 1 июня 2026 — 3 месяца разработки».
Без временной рамки MoSCoW бессмысленен — всё будет Must Have.
Шаг 2: Соберите все требования в список
Бэклог. 20–80 требований.
Шаг 3: Разделите на M / S / C / W (первый раунд, самостоятельно)
Каждый участник группы (аналитик, PO, разработчик) делает свою раскладку.
Шаг 4: Обсуждение и консенсус
Групповая сессия (2–4 часа). Сложные случаи:
- Два M, но одно нужно отложить → сравнить по бизнес-ценности + стоимости
- Заказчик говорит «всё M» → техника «Что, если мы не сделаем это?» (см. ниже)
- Команда говорит «S», заказчик говорит «M» → бизнес-ценность vs техническая сложность
Шаг 5: Проверка на 40% Must
Проверьте: общая трудоёмкость Must не превышает 40–50% от доступного времени. Если превышает — пересмотрите (что-то не может быть Must, если на всё не хватает времени).
Шаг 6: Фиксация
Результат — список MoSCoW для данного релиза, утверждённый заказчиком.
2.4. MoSCoW — таблица сравнения с примерами
| Категория | Критерий | Пример (интернет-магазин) | Пример (CRM) | Что будет, если не сделаем? |
|---|---|---|---|---|
| Must | Без него продукт не имеет смысла | Оплата заказа | Создание контакта | Систему нельзя использовать |
| Should | Есть workaround, но неудобно | Автокомплит поиска | Email-уведомления | Пользователи справятся, но будут недовольны |
| Could | Добавляет небольшую ценность | Кнопка «Поделиться» | Импорт из Excel | Никто не заметит |
| Won't | Отложено на будущее | Мобильное приложение (для MVP) | Голосовой ввод | Не влияет на текущий релиз |
2.5. Техника «Что, если это не сделаем?» (для спора с заказчиком)
Если заказчик говорит, что всё Must, используйте этот приём:
Аналитик: «Хорошо, давайте проверим каждое требование. [Функция X] — Must?»
Заказчик: «Да, Must!»
Аналитик: «Что произойдёт, если мы НЕ сделаем эту функцию в первом релизе?»
Заказчик: «Ну... пользователи не смогут быстро найти товар... но они могут воспользоваться поиском по каталогу».
Аналитик: «То есть есть workaround? Значит, это Should, а не Must. Давайте поставим Should, но реализуем сразу после Must».
Результат: заказчик сам снижает приоритет, когда видит альтернативу.
2.6. MoSCoW + Value / Effort Matrix (усиление)
Часто MoSCoW совмещают с оценкой Value (ценность) и Effort (стоимость):
ВЫСОКАЯ ЦЕННОСТЬ
┌──────────┬──────────┐
│ SHOULD │ MUST │
│ (если │ (делаем │
НИЗКИЕ │ быстро) │ в первую │ ВЫСОКИЕ
ЗАТРАТЫ │ │ очередь) │ ЗАТРАТЫ
├──────────┼──────────┤
│ WON'T │ COULD │
│ (отложить│ (если │
│ сейчас) │ останется│
│ │ время) │
└──────────┴──────────┘
НИЗКАЯ ЦЕННОСТЬ
Как читать:
- Must (высокая ценность, любые затраты) — делаем обязательно
- Should (высокая ценность + низкие затраты) — делаем сразу после Must
- Could (высокая ценность + высокие затраты ИЛИ низкая ценность + низкие затраты) — по ситуации
- Won't (низкая ценность + высокие затраты) — не делаем сейчас
3. Модель Кано (Kano Model)
3.1. История и суть
Профессор Нориаки Кано (Токийский университет) в 1984 году предложил модель, которая классифицирует свойства продукта не по «важности», а по их влиянию на удовлетворённость пользователя.
Ключевое открытие Кано: «Удовлетворённость и неудовлетворённость — это НЕ две стороны одной шкалы». Отсутствие базового свойства вызывает неудовлетворённость, но его наличие НЕ повышает удовлетворённость. И наоборот — восторгающие свойства повышают удовлетворённость, но их отсутствие не вызывает неудовлетворённости.
3.2. Три основные категории
Удовлетворённость
↑
Восторг │
│ * Восторгающие (Delighters)
│ *
│ *
│ * Линейные (One-dimensional)
│ *
─────────────┼──────────────────────→ Выполнение
│ *
│ *
Не выполнено │ * Выполнено полностью
│ *
──────────── ┼
* │
Базовые │
(Must-be) │
│
Нейтрально │
↓ │
Неудовлетворённость
Категория 1: Базовые (Must-be / Basic)
Также называют: Ожидаемые, «Гигиенические факторы».
Суть: Свойства, которые пользователь считает само собой разумеющимися. Они не повышают удовлетворённость, когда есть, но вызывают сильную неудовлетворённость, когда отсутствуют.
Аналогия из жизни: Чистые стулья в ресторане. Вы не похвалите ресторан за чистый стул — это само собой разумеется. Но если стул грязный — вы возмутитесь и больше не придёте.
Примеры в ПО:
- Кнопка «Зарегистрироваться» (логин) — никто не хвалит за наличие логина, но без него система бесполезна
- Сохранение данных при отправке формы — вы не радуетесь, что данные сохранились, но если они потеряются — вы в ярости
- Валидация email — не заметите, если работает, но будете кричать, если можно ввести «фыва» и форма примет
Стратегия: Базовые требования = Must Have. Они обязательны. Если их нет — продукт не принимается.
Категория 2: Линейные (One-dimensional / Performance)
Также называют: Линейные факторы, «Чем больше, тем лучше».
Суть: Свойства, которые прямо влияют на удовлетворённость: чем лучше реализованы, тем выше удовлетворённость, и наоборот.
Аналогия из жизни: Вкус еды в ресторане. Чем вкуснее — тем выше удовлетворённость. Чем хуже — тем сильнее недовольство. Зависимость линейная.
Примеры в ПО:
- Скорость загрузки (чем быстрее → тем выше удовлетворённость)
- Удобство интерфейса (чем интуитивнее → тем выше оценка)
- Количество фильтров в поиске (чем больше гибких фильтров → тем удобнее)
- Глубина функциональности отчёта (чем детальнее → тем ценнее)
Стратегия: Линейные требования = Should / Could в MoSCoW. Чем выше ценность при низких затратах — тем выше приоритет. Здесь хорошо работает Value/Effort матрица.
Категория 3: Восторгающие (Attractive / Delighters)
Также называют: Возбуждающие факторы, «WOW-факторы».
Суть: Свойства, которые пользователь не ожидает, но когда они есть — он в восторге. Их отсутствие не снижает удовлетворённость (пользователь же не знал, что так можно было).
Аналогия из жизни: В ресторане после ужина вам приносят комплимент от шеф-повара — маленькое пирожное бесплатно. Вы не ждали, но приятно удивлены. Если пирожного нет — вы не расстроитесь.
Примеры в ПО:
- Анимация конфетти при первом выполненном задании (Duolingo) — не обязательна, но вызывает эмоцию
- Интеграция с календарём автоматически — пользователь не ждал, но когда она есть — восторг
- Чат-бот, который поздравляет с днём рождения — не влияет на функционал, но создаёт лояльность
- Умные подсказки при вводе (Google: показывает варианты ещё до того, как вы допечатали)
Стратегия: Восторгающие требования = Could / Won't в MoSCoW. Делаем в последнюю очередь, когда базовое и линейное уже работают идеально. Но! Восторгающие со временем становятся линейными, а потом — базовыми.
3.3. Динамика восторгающих свойств (закон эскалации Кано)
Самое важное в модели Кано — свойства не статичны, они мигрируют со временем:
ВОСТОРГАЮЩИЕ → ЛИНЕЙНЫЕ → БАЗОВЫЕ
↓ ↓
Проходит время Ещё больше времени
Пример исторической миграции (интернет-магазины):
| Период | Свойство | Категория в тот период | Сейчас |
|---|---|---|---|
| 1995 | Возможность оплатить картой онлайн | Восторгающее (WOW, никто так не делал) | |
| 2005 | Оплата картой онлайн | Линейное (ожидаешь, но ценишь удобство) | |
| 2025 | Оплата картой онлайн | Базовое (без этого интернет-магазин невозможен) |
Другой пример — трекинг заказа:
- 2010: SMS при смене статуса → Восторг!
- 2015: SMS-уведомления → Линейное (чем детальнее, тем лучше)
- 2024: Трекинг курьера на карте в реальном времени → Базовое (Ozon, Яндекс доставка — без карты уже странно)
Вывод для аналитика:
- Не вкладывайтесь в восторгающие функции, пока базовые не работают идеально
- Учитывайте время: если ваш проект займёт 2 года, то восторгающие функции 2024 года могут стать базовыми в 2026
3.4. Как определить категорию по Кано (опросник Кано)
Кано разработал специальный опросник для классификации свойств. Каждое свойство оценивается по двум вопросам:
Функциональный вопрос (позитивный): «Как вы себя почувствуете, если [функция] будет в продукте?»
Дисфункциональный вопрос (негативный): «Как вы себя почувствуете, если [функция] НЕ будет в продукте?»
Варианты ответа (по Кано):
- Мне это нравится (Like)
- Я ожидаю это (Expect)
- Мне всё равно (Neutral)
- Я могу с этим жить (Tolerate)
- Мне это не нравится (Dislike)
Таблица классификации:
| Ответ на функц. / Ответ на дисфункц. | 1. Like | 2. Expect | 3. Neutral | 4. Tolerate | 5. Dislike |
|---|---|---|---|---|---|
| 1. Like | — | Восторг | Восторг | Восторг | Лин. |
| 2. Expect | Реверс | — | — | — | Базовое |
| 3. Neutral | Реверс | — | — | — | Базовое |
| 4. Tolerate | Реверс | — | — | — | Базовое |
| 5. Dislike | Реверс | Реверс | Реверс | Реверс | — |
Где:
- Восторг — если наличие радует, а отсутствие — не расстраивает (Like/Expect/Neutral/Tolerate + Dislike)
- Линейное — если наличие радует, а отсутствие расстраивает (Like + Dislike)
- Базовое — если наличие — ожидаемо, а отсутствие расстраивает (Expect/Neutral/Tolerate + Dislike)
- Реверс — свойство, которое вызывает негатив (например, «сбор личных данных»)
Пример для свойства «Тёмная тема» в приложении:
Вопрос: «Как вы отнесётесь к тёмной теме в приложении?» → Ответ: «Мне это нравится» (Like)
Вопрос: «Как вы отнесётесь, если тёмной темы НЕ будет?» → Ответ: «Мне всё равно» (Neutral)
Результат по таблице: Like + Neutral = Восторгающее свойство.
3.5. Как применять Kano + MoSCoW вместе
На практике эти две техники работают в комбинации:
| Категория Кано | MoSCoW | Стратегия |
|---|---|---|
| Базовые (Must-be) | Must Have | Делаем в первую очередь. Без этого продукт не имеет смысла. |
| Линейные (Performance) | Should / Could | Приоритизируем по Value/Effort. Дорогие и низкоценные — откладываем. |
| Восторгающие (Attractive) | Could / Won't (для MVP). Should (для следующей версии). | Делаем, когда база работает. Используем для маркетинга и WOW-эффекта. |
Алгоритм для аналитика:
1. Составить список всех требований
2. Для каждого требования определить категорию по Кано (опрос / экспертная оценка)
3. Все Базовые → в Must Have. Они не обсуждаются.
4. Оценить линейные по ценности и стоимости (Value/Effort)
5. Высокое Value + низкий Effort → Should (сразу после Must)
6. Высокое Value + высокий Effort → Should (но с осторожностью)
7. Низкое Value + низкий Effort → Could (делаем, если останется время)
8. Низкое Value + высокий Effort → Won't (сознательный отказ)
9. Восторгающие → Could (для MVP). Вынести в следующий релиз как Should.
3.6. Ограничения модели Кано
- Культурные различия — в разных культурах одни и те же свойства могут быть в разных категориях
- Опрос не всегда точен — пользователи могут не знать, что им нужно (до того, как увидят)
- Сложность массового опроса — для большого количества свойств опросник становится огромным
- Не учитывает стоимость — даже восторгающее свойство может быть нереализуемо по бюджету
4. Другие техники приоритизации (краткий обзор)
4.1. RICE (Reach × Impact × Confidence × Effort)
Каждое требование оценивается по 4 шкалам.
| Фактор | Шкала | Пример |
|---|---|---|
| Reach (Охват) | Сколько пользователей затронет? | 1–10 |
| Impact (Влияние) | Как сильно повлияет? | 1–10 |
| Confidence (Уверенность) | Насколько мы уверены в оценке? | 0%–100% |
| Effort (Стоимость) | Сколько человеко-дней? | Часы |
Формула: Priority = (Reach × Impact × Confidence) / Effort
4.2. Weighted Scoring (Взвешенное голосование)
Каждое требование оценивается по нескольким критериям с разными весами:
| Критерий | Вес | FR-001 | FR-002 | FR-003 |
|---|---|---|---|---|
| Бизнес-ценность | 6 | 10 | 5 | 7 |
| Срочность | 4 | 3 | 10 | 5 |
| Риск | 2 | 8 | 2 | 6 |
| Итого | 60+12+16=88 | 30+40+4=74 | 42+20+12=74 |
FR-001 получает высший приоритет.
4.3. Cost of Delay (Задержка как стоимость)
Оценка потерь бизнеса за каждый месяц задержки реализации:
- FR-001 (авторизация): каждый месяц без неё — 0 (проект не стартует)
- FR-012 (email-уведомления): каждый месяц без неё — нагрузка на колл-центр = 50 000 руб/мес
- FR-034 (экспорт отчётов): каждая задержка — 10 000 руб/мес
Приоритет: FR-012 (самая высокая стоимость задержки).
5. Практический пример: приоритизация 6 требований через MoSCoW + Кано
Кейс: Мобильное приложение для доставки еды (MVP, 3 месяца).
| Требование | Категория Кано | MoSCoW | Обоснование |
|---|---|---|---|
| Авторизация по телефону | Базовое | Must | Без неё пользователь не может оформить заказ |
| Просмотр меню ресторана | Линейное | Must | Основная функция приложения — выбирать еду |
| Оплата картой онлайн | Линейное | Should | Можно принять заказ и оплатить наличными курьеру (workaround есть) |
| Трекинг курьера на карте | Восторгающее (2024) → становится линейным в 2026 | Could (для MVP), Should (для релиза 2) | Пользователи привыкли к трекингу в Ozon — в 2026 это уже почти Must |
| Напоминание о забытой корзине push | Восторгающее | Could | Увеличит конверсию, но без неё можно жить |
| Распознавание адреса по фото | Восторгающее | Won't (MVP) | Дорогая имплементация (ML), отложена на будущее |
6. Как презентовать приоритеты заказчику (soft skills)
Заказчик часто эмоционально привязан к своим идеям. Как аналитику подать приоритизацию, чтобы не вызвать конфликт?
Шесть правил презентации
| Правило | ❌ Плохо | ✅ Хорошо |
|---|---|---|
| Не говорите «нет» | «Это Won't, не будем делать» | «Мы отложим эту функцию на следующую версию, чтобы в этой сделать её идеально» |
| Объясняйте «почему» | «Must — только это» | «Мы выбрали эти функции как Must, потому что без них вы не сможете принять ни один заказ» |
| Показывайте стоимость откладывания | «Это Should, не обязательно» | «Если мы сделаем это вместо авторизации — релиз сдвинется на 2 недели. Вы готовы?» |
| Фиксируйте Won't для будущего | «Это Won't, забыли» | «Давайте запишем это в бэклог для версии 2.0. Через 3 месяца вернёмся к обсуждению» |
| Вовлекайте заказчика в процесс | Аналитик сам распределяет приоритеты | «Давайте вместе оценим, какая функция принесёт больше пользы бизнесу» |
| Будьте готовы к компромиссу | Жёсткая позиция | «Мы не можем сделать всё, но можем сделать X, Y и Z. Что выберете?» |
Вопросы для самопроверки
- Какие 4 категории в MoSCoW? Приведите пример для каждой из реальной жизни (не ИТ).
- Какой тест помогает отличить Must от Should?
- Какая категория MoSCoW должна составлять не более 40–50% объёма? Почему?
- Какие 3 категории свойств продукта в модели Кано? Как они влияют на удовлетворённость?
- Что означает «миграция свойств по Кано»? Приведите пример (из истории технологий).
- Как скомбинировать MoSCoW и Кано? Какой категории Кано соответствует MoSCoW Must?
- Что даёт модель Кано такого, чего не даёт MoSCoW? (подсказка: взгляд на пользователя)
Практическое задание
Кейс: Вы аналитик в стартапе — приложение для ведения семейного бюджета (совместные счета, транзакции, цели, уведомления о превышении лимитов). У вас есть 12 требований на MVP.
Список требований:
- Регистрация по email / Google
- Добавление дохода / расхода с категорией
- Разделение бюджета на категории (продукты, транспорт, развлечения...)
- Добавление второго участника в семейный бюджет (совместный доступ)
- Push-уведомления о превышении лимита категории
- Экспорт отчёта в PDF / Excel
- Автоматическая категоризация транзакций по названию (ML)
- Тёмная тема
- График расходов за месяц
- Бюджет на день (лимит трат в сутки)
- Импорт банковских выписок (CSV)
- Виджет на экран телефона с текущим балансом
Задание 1. MoSCoW
Распределите 12 требований по категориям MoSCoW для MVP (релиз 1.0, 3 месяца, команда 3 разработчика).
Для каждого требования укажите:
- Категорию (M/S/C/W)
- Краткое обоснование (почему именно эта категория)
Задание 2. Модель Кано
Для каждого требования укажите предполагаемую категорию по Кано (Базовое / Линейное / Восторгающее).
Особое внимание уделите требованиям 7 (автоматическая категоризация) и 8 (тёмная тема) — обоснуйте, почему они могут быть в разных категориях.
Задание 3. Комбинированный анализ
Найдите требования, которые:
- Базовые (Кано) + Must (MoSCoW) — в MVP обязательно
- Восторгающие (Кано) + Could / Won't (MoSCoW) — откладываем сознательно
- Линейные (Кано) + Should (MoSCoW) — надо приоритизировать по Value/Effort
Напишите 2–3 предложения итогового вердикта заказчику: что входит в MVP, что отложено и почему.
Формат: Один файл (md) с тремя разделами.
Дополнительные материалы
- Оригинал MoSCoW: DSDM Handbook (последняя версия) — доступен на сайте DSDM Consortium
- Оригинал Kano: Kano, N. et al. (1984). «Attractive Quality and Must-be Quality» — первая публикация (на японском, но есть переводы)
- Книга: Jeff Gothelf — «When Is a Product Ready?» (про MoSCoW и Lean)
- Книга: Nielsen Norman Group — «The Kano Model: How to Delight Your Users» (статья)
- Статья: «Prioritization Techniques for Product Managers» — Folding Burritos (блог)
- Шаблон: MoSCoW Template в Miro / Confluence
- Инструмент: airfocus — инструмент для приоритизации (RICE, Weighted Scoring, Kano)