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

Различия

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

Ссылка на это сравнение

Предыдущая версия справа и слева Предыдущая версия
Следующая версия
Предыдущая версия
foxdev_7:приоритизация_задач [22.12.2017 07:22]
admin
foxdev_7:приоритизация_задач [30.10.2020 05:15] (текущий)
denis
Строка 1: Строка 1:
 Инструкция рассчитана на уже выпущенный в продакшн софт. Для разработки с нуля правила могут отличаться. Инструкция рассчитана на уже выпущенный в продакшн софт. Для разработки с нуля правила могут отличаться.
-===== Общий принцип приоритизации задач ======+ 
 +===== Общий принцип приоритизации задач ===== 
 **Главный приоритет - Рост**.\\ **Главный приоритет - Рост**.\\
 Для свободного ПО и компаний на продажу - увеличение количества пользователей.\\ Для свободного ПО и компаний на продажу - увеличение количества пользователей.\\
Строка 9: Строка 11:
  
 ===== Приоритеты ===== ===== Приоритеты =====
 +
   - Первый приоритет - Новые модули,​ новые фичи, критичные исправления.   - Первый приоритет - Новые модули,​ новые фичи, критичные исправления.
   - Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании.   - Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании.
Строка 15: Строка 18:
   - Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей.   - Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей.
  
-===== Важность ======+===== Важность ===== 
   - Блокирующая:​ версию выпускать нельзя.   - Блокирующая:​ версию выпускать нельзя.
   - Обязательная:​ стандартный приоритет для выпуска полноценной версии.   - Обязательная:​ стандартный приоритет для выпуска полноценной версии.
Строка 21: Строка 25:
  
 ===== Планирование ===== ===== Планирование =====
 +
   * Позадачное планирование производится на одну версию.   * Позадачное планирование производится на одну версию.
   * Новые модули и большие изменения на 3 и более версий,​ обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами.   * Новые модули и большие изменения на 3 и более версий,​ обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами.
   * Планирование проводит релиз-менеджер,​ либо скрам-мастер,​ либо тимлид,​   * Планирование проводит релиз-менеджер,​ либо скрам-мастер,​ либо тимлид,​
 +
 обязательно совместно с продукт менеджером или другим отвественным за популяризацию/​коммерцию лицом. обязательно совместно с продукт менеджером или другим отвественным за популяризацию/​коммерцию лицом.
 +
   * Запас времени всегда 50% на каждого разработчика,​ то есть если разработчик сказал,​ что сделает за 1 день, то считаем,​ что 2 дня и тд. То есть не более 10 плановых человекодней на версию на одного разработчика.   * Запас времени всегда 50% на каждого разработчика,​ то есть если разработчик сказал,​ что сделает за 1 день, то считаем,​ что 2 дня и тд. То есть не более 10 плановых человекодней на версию на одного разработчика.
   * Если на разработчика запланирован модуль или сложная фича, то лучше не отвлекать его багами и критикал багами.   * Если на разработчика запланирован модуль или сложная фича, то лучше не отвлекать его багами и критикал багами.
  
 ===== Сортировка модулей ===== ===== Сортировка модулей =====
 +
 под модулем также будем понимать большие изменения под модулем также будем понимать большие изменения
 +
   * сортировка модулей производится на основе мнений экспертной группы в которую входят как минимум:​ продукт менеджер,​ технолог,​ тимлид,​ маркетолог.   * сортировка модулей производится на основе мнений экспертной группы в которую входят как минимум:​ продукт менеджер,​ технолог,​ тимлид,​ маркетолог.
   * вижн продукт менеджера,​ запросы новых клиентов,​ запросы старых клиентов,​ анализируем рынок, конкурентов,​ идеи сотрудников.   * вижн продукт менеджера,​ запросы новых клиентов,​ запросы старых клиентов,​ анализируем рынок, конкурентов,​ идеи сотрудников.
Строка 38: Строка 47:
  
 ===== Сортировка фич ===== ===== Сортировка фич =====
 +
   * стараться планировать не более 1-3 фич на человека на версию.   * стараться планировать не более 1-3 фич на человека на версию.
   * если нагрузка высокая,​ то выполняются только фичи которые принесут ближайшую прибыль,​ что позволит расширить штат   * если нагрузка высокая,​ то выполняются только фичи которые принесут ближайшую прибыль,​ что позволит расширить штат
Строка 45: Строка 55:
  
 ===== Сортировка BUG ===== ===== Сортировка BUG =====
 +
 ==== Критикал патч: ==== ==== Критикал патч: ====
 +
   * если раньше что то работало,​ а с выпуском версии или по определенной дате перестало работать,​ то нужно срочно вносить исправление   * если раньше что то работало,​ а с выпуском версии или по определенной дате перестало работать,​ то нужно срочно вносить исправление
   * если может, с значительной вероятностью,​ привести к потери данных пользователя,​ то нужно срочно вносить исправление   * если может, с значительной вероятностью,​ привести к потери данных пользователя,​ то нужно срочно вносить исправление
-  * если может, с значительной вероятностью,​ то нужно срочно вносить исправление 
   * если в будущем придется писать сложный конвертер данных или сложную исправлялку,​ то нужно срочно вносить исправление   * если в будущем придется писать сложный конвертер данных или сложную исправлялку,​ то нужно срочно вносить исправление
-  * если может, с значительной вероятностью,​ привести к существенным убыткам или нарушению основной деятельности пользователя,​ то нужно срочно вносить+  * если может, с значительной вероятностью,​ привести к существенным убыткам или нарушению основной деятельности пользователя,​ то нужно срочно вносить ​исправление
   * юзабилити раздражающие баги, если более 20% пользователей затрагивают,​ то нужно срочно вносить исправление   * юзабилити раздражающие баги, если более 20% пользователей затрагивают,​ то нужно срочно вносить исправление
   * проблема приводящая к медленной отладке или медленной сборке или медленному тестированию. В зависимости от продукта от 3 секунд до 1 минуты,​ редко 10 минут с учетом fast_test(полная пересборка проекта делается редко и в расчет не берется).   * проблема приводящая к медленной отладке или медленной сборке или медленному тестированию. В зависимости от продукта от 3 секунд до 1 минуты,​ редко 10 минут с учетом fast_test(полная пересборка проекта делается редко и в расчет не берется).
Строка 56: Строка 67:
  
 ==== Правим в ближайшей версии:​ ==== ==== Правим в ближайшей версии:​ ====
 +
   * если у клиента что то правили,​ то исправить в ближайшую версию и запретить клиенту обновляться   * если у клиента что то правили,​ то исправить в ближайшую версию и запретить клиенту обновляться
   * если бага влияет сильно на репутацию,​ то исправить в ближайшую версию или выпустить критикал патч   * если бага влияет сильно на репутацию,​ то исправить в ближайшую версию или выпустить критикал патч
Строка 61: Строка 73:
   * если баг от больших клиентов и баг новых клиентов,​ то исправить в ближайшую версию   * если баг от больших клиентов и баг новых клиентов,​ то исправить в ближайшую версию
   * архитектурные и прочие технические баги на решение которых нужно не более 1 часа, то исправить в ближайшую версию   * архитектурные и прочие технические баги на решение которых нужно не более 1 часа, то исправить в ближайшую версию
 +
 ==== Правим позже: ==== ==== Правим позже: ====
 +
   * если бага даже супер критикал,​ но проявится через год или раз в год, то можно делать позже   * если бага даже супер критикал,​ но проявится через год или раз в год, то можно делать позже
   * если баг приходит от саппорта,​ но затрагивает 1-2 клиентов,​ то можно делать позже   * если баг приходит от саппорта,​ но затрагивает 1-2 клиентов,​ то можно делать позже
Строка 69: Строка 83:
   * исправлять только те, которые уже приносят убытки или недополучение прибыли   * исправлять только те, которые уже приносят убытки или недополучение прибыли
   * если задачу можно отложить и много других задач, то лучше отложить   * если задачу можно отложить и много других задач, то лучше отложить
 +
 +==== Статья Дениса на тему приоритезации ====
 +
 +  * [[https://​wika.carbonsoft.ru/​блоги_и_отзывы:​приоритезация_фич|https://​wika.carbonsoft.ru/​блоги_и_отзывы:​приоритезация_фич]]
 +
 +~~OWNERAPPROVE~~