Приоритизация Задач

Здесь показаны различия между двумя версиями данной страницы.

--- foxdev_7:приоритизация_задач [10.05.2019 23:08]
admin Approved(admin 2019/05/10 23:10)
+++ foxdev_7:приоритизация_задач [30.10.2020 05:15] (текущий)
denis
@@ Строка 1: / Строка 1: @@
+Инструкция рассчитана на уже выпущенный в продакшн софт. Для разработки с нуля правила могут отличаться.
+===== Общий принцип приоритизации задач =====
+**Главный приоритет - Рост**.\\
+Для свободного ПО и компаний на продажу - увеличение количества пользователей.\\
+Для окупаемого ПО - прибыль или входящий денежный поток.\\
+Рост обязательно с учетом лояльности и репутации текущих клиентов.\\
+Делать или нет задачу, делать эту или иную задачу, всегда спрашиваем у себя будет ли рост пользователей и/или будет ли рост прибыли, повысится/не снизится ли лояльность, улучшится/не снизится ли репутация.\\
+Да да только рост, и не спрашиваем про программистский долг, красивость кода и не рассматриваем крутизну технической идеи.
+===== Приоритеты =====
+  - Первый приоритет - Новые модули, новые фичи, критичные исправления.
+  - Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании.
+  - Третий приоритет - Анализ фичреквестов клиентов и голосовалок.
+  - Четвертый приоритет - Анализ фич конкурентов.
+  - Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей.
+===== Важность =====
+  - Блокирующая: версию выпускать нельзя.
+  - Обязательная: стандартный приоритет для выпуска полноценной версии.
+  - Желательная или интересная: если останется время или в нерабочее время можно делать.
+===== Планирование =====
+  * Позадачное планирование производится на одну версию.
+  * Новые модули и большие изменения на 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 клиентов, то можно делать позже
+  * по простым багам и недочетам не влияющим на основную функциональность
+  * если баг в функционале, который никто не использует, то исправляем позже или не исправляем до первого использования
+  * влияет на работоспособность, но лечится перезагрузкой или другим простым способом, то можно делать через версию
+  * исправлять только те, которые уже приносят убытки или недополучение прибыли
+  * если задачу можно отложить и много других задач, то лучше отложить
+==== Статья Дениса на тему приоритезации ====
+  * [[https://wika.carbonsoft.ru/блоги_и_отзывы:приоритезация_фич|https://wika.carbonsoft.ru/блоги_и_отзывы:приоритезация_фич]]
+~~OWNERAPPROVE~~

Приоритизация Задач

Различия