Инструкция рассчитана на уже выпущенный в продакшн софт. Для разработки с нуля правила могут отличаться.
Общий принцип приоритизации задач
Главный приоритет - Рост.
Для свободного ПО и компаний на продажу - увеличение количества пользователей.
Для окупаемого ПО - прибыль или входящий денежный поток.
Рост обязательно с учетом лояльности и репутации текущих клиентов.
Делать или нет задачу, делать эту или иную задачу, всегда спрашиваем у себя будет ли рост пользователей и/или будет ли рост прибыли, повысится/не снизится ли лояльность, улучшится/не снизится ли репутация.
Да да только рост, и не спрашиваем про программистский долг, красивость кода и не рассматриваем крутизну технической идеи.
Приоритеты
Первый приоритет - Новые модули, новые фичи, критичные исправления.
Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании.
Третий приоритет - Анализ фичреквестов клиентов и голосовалок.
Четвертый приоритет - Анализ фич конкурентов.
Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей.
Важность
Блокирующая: версию выпускать нельзя.
Обязательная: стандартный приоритет для выпуска полноценной версии.
Желательная или интересная: если останется время или в нерабочее время можно делать.
Планирование
Позадачное планирование производится на одну версию.
Новые модули и большие изменения на 3 и более версий, обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами.
Планирование проводит релиз-менеджер, либо скрам-мастер, либо тимлид,
обязательно совместно с продукт менеджером или другим отвественным за популяризацию/коммерцию лицом.
Запас времени всегда 50% на каждого разработчика, то есть если разработчик сказал, что сделает за 1 день, то считаем, что 2 дня и тд. То есть не более 10 плановых человекодней на версию на одного разработчика.
Если на разработчика запланирован модуль или сложная фича, то лучше не отвлекать его багами и критикал багами.
Сортировка модулей
под модулем также будем понимать большие изменения
сортировка модулей производится на основе мнений экспертной группы в которую входят как минимум: продукт менеджер, технолог, тимлид, маркетолог.
вижн продукт менеджера, запросы новых клиентов, запросы старых клиентов, анализируем рынок, конкурентов, идеи сотрудников.
планируем не более 1-3 модулей на одну ежемесячную версию на одну команду(3-9 чел), и обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами.
модули выбираем 50% полезные и 50% пригодные для рекламы и PR
реализуем минимальные возможности модуля, остальное расширяем потом
обязательно учитываем мнения клиентов и/или опросы
Сортировка фич
стараться планировать не более 1-3 фич на человека на версию.
если нагрузка высокая, то выполняются только фичи которые принесут ближайшую прибыль, что позволит расширить штат
если фича не сильно важная, или осталась невыполненной, то переносим всегда на через одну версию, а не на следующую версию
если фичу обещали пользователю, то планируем через одну версию, а не на следующую
если фича сильно влияет на юзабилити или продажи она делается в ближайшей версии
Сортировка BUG
Критикал патч:
если раньше что то работало, а с выпуском версии или по определенной дате перестало работать, то нужно срочно вносить исправление
если может, с значительной вероятностью, привести к потери данных пользователя, то нужно срочно вносить исправление
если в будущем придется писать сложный конвертер данных или сложную исправлялку, то нужно срочно вносить исправление
если может, с значительной вероятностью, привести к существенным убыткам или нарушению основной деятельности пользователя, то нужно срочно вносить исправление
юзабилити раздражающие баги, если более 20% пользователей затрагивают, то нужно срочно вносить исправление
проблема приводящая к медленной отладке или медленной сборке или медленному тестированию. В зависимости от продукта от 3 секунд до 1 минуты, редко 10 минут с учетом fast_test(полная пересборка проекта делается редко и в расчет не берется).
проблемы с обновлением, которые могут привести к потери возможности автоматического обновления
Правим в ближайшей версии:
если у клиента что то правили, то исправить в ближайшую версию и запретить клиенту обновляться
если бага влияет сильно на репутацию, то исправить в ближайшую версию или выпустить критикал патч
если баг приходит от саппорта и влияет на всех клиентов, то исправить в ближайшую версию
если баг от больших клиентов и баг новых клиентов, то исправить в ближайшую версию
архитектурные и прочие технические баги на решение которых нужно не более 1 часа, то исправить в ближайшую версию
Правим позже:
если бага даже супер критикал, но проявится через год или раз в год, то можно делать позже
если баг приходит от саппорта, но затрагивает 1-2 клиентов, то можно делать позже
по простым багам и недочетам не влияющим на основную функциональность
если баг в функционале, который никто не использует, то исправляем позже или не исправляем до первого использования
влияет на работоспособность, но лечится перезагрузкой или другим простым способом, то можно делать через версию
исправлять только те, которые уже приносят убытки или недополучение прибыли
если задачу можно отложить и много других задач, то лучше отложить
Статья Дениса на тему приоритезации