Приоритизация функций в маленькой команде: как выбрать правильную из кучи требований
У маленьких команд ограниченные ресурсы. Как решить, какую функцию делать первой? В этой статье представлена простая карточка приоритизации, которая поможет ранжировать функции за 30 минут, и обсуждаются типичные ловушки.
Приоритизация функций в маленькой команде: как выбрать правильную из кучи требований
На ранних этапах моей карьеры продакта приоритизация основывалась на интуиции. Кто громче кричал, того и делали первым.
Позже я понял, что быстрые функции редко используются, а долгие и масштабные — востребованы ежедневно. Но к тому моменту я уже потерял два месяца.
У маленьких команд ограниченные ресурсы и ещё более ограниченное время. Мы не можем делать всё сразу, поэтому приоритизация — не опция, а ежедневное решение.
В этой статье я делюсь методом, который использую сам: простая карточка с четырьмя измерениями, позволяющая ранжировать функции за 30 минут. Она не идеальна, но гораздо надёжнее интуиции.
Зачем нужна явная приоритизация?
Самый распространённый способ в маленьких командах — по срочности. Кто сильнее давит, тот и вперёд. Но срочность не равна важности. Пользователь, говорящий «мне нужно завтра», может просто бросать слова на ветер; ваш продавец, утверждающий, что «все клиенты просят это», может иметь в виду одного клиента.
Другой частый сценарий — «решает босс». Это ещё хуже, потому что у босса часто неполная информация.
Явная приоритизация помогает:
- Превратить неявные субъективные суждения в явные количественные сравнения
- Заставить команду обсуждать веса и оценки каждого измерения
- Оставить отслеживаемую запись решений
Карточка с четырьмя измерениями
Я разработал минималистичную карточку с четырьмя измерениями:
- Пользовательская ценность: Насколько болезненна проблема, которую решает функция? Сколько пользователей затронуто?
- Стоимость разработки: Сколько человеко-дней от дизайна, разработки, тестирования до релиза?
- Стратегическое соответствие: Соответствует ли функция основной позиции продукта и долгосрочному направлению?
- Риск/Неопределённость: Технология выполнима? Действительно ли это нужно пользователям? Стабилен ли рынок?
Каждое измерение оценивается от 1 до 5.
- Пользовательская ценность: 5 = ключевая боль, массовые пользователи нуждаются ежедневно; 1 = приятный бонус, лишь единицы используют изредка.
- Стоимость разработки: 5 = можно сделать за полдня; 1 = требуется две недели и более, задействовано несколько модулей. Обратите внимание: низкая оценка означает высокую стоимость, потому что мы хотим, чтобы более высокий итоговый балл указывал на более высокий приоритет.
- Стратегическое соответствие: 5 = полностью соответствует, обязательно к выполнению; 1 = отклоняется от основного направления, приятный бонус.
- Риск: 5 = полная уверенность, нет технологических или рыночных рисков; 1 = крайне неопределённо, может быть сделано, но никто не использует, или технология не работает.
Итоговый балл: Пользовательская ценность × 3 + Стоимость разработки × 2 + Стратегическое соответствие × 2 + Риск × 1. Веса можно менять в зависимости от ситуации команды.
Пример
Предположим, мы создаём инструмент для AI-письма, и у нас есть четыре кандидата:
- A: Добавить шаблоны академических статей
- B: Улучшить точность перефразирования предложений
- C: Поддержка экспорта в PDF
- D: Добавить функцию многоязычного перевода
Быстрая оценка:
| Функция | Пользовательская ценность (1-5) | Стоимость разработки (1-5) | Стратегическое соответствие (1-5) | Риск (1-5) | Итого |
|---|---|---|---|---|---|
| A | 3 | 4 | 5 | 4 | 31 |
| B | 5 | 2 | 5 | 3 | 32 |
| C | 4 | 3 | 3 | 5 | 29 |
| D | 2 | 5 | 2 | 4 | 24 |
Результат: B (улучшение точности перефразирования) набрал наибольший балл, D (многоязычный перевод) — наименьший. Это совпадает с интуицией, но количественная оценка делает решение более ясным и удобным для обсуждения в команде.
Ловушки метода
- Субъективность: Разные люди могут давать сильно разные оценки. Решение: оценивать вместе как команда, обсуждать разногласия, затем брать среднее или консенсус.
- Жёсткие веса: Веса не фиксированы. Когда денег мало, увеличьте вес стоимости разработки, чтобы отдавать приоритет дешёвым функциям.
- Игнорирование зависимостей: Некоторые функции зависят от других. Карточка это не учитывает — нужно проверять отдельно.
- Слишком статично: Потребности и рынок меняются. Переприоритизируйте каждые две недели или месяц, не делайте это один раз на весь год.
Альтернативы
Если у команды нет даже 30 минут, или запросов слишком много, попробуйте более лёгкие методы:
- ICE: Влияние (Impact), Уверенность (Confidence), Лёгкость (Ease). Каждый 1-10, перемножить для итога.
- RICE: Охват (Reach), Влияние (Impact), Уверенность (Confidence), Усилия (Effort). Похож, но больше ориентирован на количество пользователей.
Я предпочитаю свою версию с четырьмя измерениями, потому что она включает стратегическое соответствие и риск, которые маленькие команды часто упускают.
Последняя мысль
Приоритизация — не цель, цель — создавать правильные вещи. Карточка — лишь инструмент. Если функция получила высокий балл, но никто её не использует, пересмотрите, насколько точна ваша оценка, а не вините инструмент.
Главное преимущество маленьких команд — гибкость. Возьмите за привычку переприоритизировать каждые две недели, и вы заметите, что становитесь лучше в определении того, что действительно важно.
PaxLee