Приоритизация Задач
Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
foxdev_7:приоритизация_задач [21.12.2017 16:08] admin |
foxdev_7:приоритизация_задач [30.10.2020 05:15] (текущий) denis |
||
|---|---|---|---|
| Строка 1: | Строка 1: | ||
| - | ===== Общий принцип приоритизации задач ====== | + | Инструкция рассчитана на уже выпущенный в продакшн софт. Для разработки с нуля правила могут отличаться. |
| + | |||
| + | ===== Общий принцип приоритизации задач ===== | ||
| **Главный приоритет - Рост**.\\ | **Главный приоритет - Рост**.\\ | ||
| Для свободного ПО и компаний на продажу - увеличение количества пользователей.\\ | Для свободного ПО и компаний на продажу - увеличение количества пользователей.\\ | ||
| Строка 8: | Строка 11: | ||
| ===== Приоритеты ===== | ===== Приоритеты ===== | ||
| + | |||
| - Первый приоритет - Новые модули, новые фичи, критичные исправления. | - Первый приоритет - Новые модули, новые фичи, критичные исправления. | ||
| - Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании. | - Второй приоритет - Лояльность клиентов и к клиентам. Репутация компании. | ||
| Строка 14: | Строка 18: | ||
| - Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей. | - Пятый приоритет - Анализ различных идей сотрудников и разбор отложенных вишлистов и идей. | ||
| - | ===== Важность ====== | + | ===== Важность ===== |
| - Блокирующая: версию выпускать нельзя. | - Блокирующая: версию выпускать нельзя. | ||
| - Обязательная: стандартный приоритет для выпуска полноценной версии. | - Обязательная: стандартный приоритет для выпуска полноценной версии. | ||
| Строка 20: | Строка 25: | ||
| ===== Планирование ===== | ===== Планирование ===== | ||
| + | |||
| * Позадачное планирование производится на одну версию. | * Позадачное планирование производится на одну версию. | ||
| * Новые модули и большие изменения на 3 и более версий, обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами. | * Новые модули и большие изменения на 3 и более версий, обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами. | ||
| * Планирование проводит релиз-менеджер, либо скрам-мастер, либо тимлид, | * Планирование проводит релиз-менеджер, либо скрам-мастер, либо тимлид, | ||
| - | обязательно совместно с продукт менеджеромом или другим отвественным за популяризацию/коммерцию лицом. | ||
| - | ===== Сортировка BUG ===== | + | обязательно совместно с продукт менеджером или другим отвественным за популяризацию/коммерцию лицом. |
| - | aaa | + | |
| - | <code bash> | + | |
| - | qweqweqweq | + | |
| - | qweqwe | + | |
| - | 1231 | + | |
| - | /*1231*/ | + | |
| - | qwe | + | |
| - | </code> | + | |
| - | /* | + | |
| - | 1. баги обязательное исправление | + | |
| - | - если у клиента что то правили то исправить в ближайшую версию и запретить клиенту обновляться | + | |
| - | - если бага даже супер критикал но проявится через год можно делать позже | + | |
| - | - если бага влияет сильно на репутацию то выполнять в течение версии | + | |
| - | - если баг приходит от саппорта и влияет на всех клиентов оценивать как критикал. выставлять в CRM признак критикал. | + | |
| - | - если баг приходит от саппорта но затрагивает 1-2 клиентов то задача важная, выполнение в течение следующей версии ( исключение провайдер, либо те клиенты которые еще не купили ) | + | |
| - | - по простым багам выполнять только те которые приносят убытки или могут принести прибыль | + | |
| - | - концептуальные баги на решение которых нужно не более 1 часа необходимо выполнять в пределах текущей версии ( важность Низкая ) | + | |
| - | - влияет на работоспособность но лечится перезагрузкой или другим простым способом - следующая версия | + | |
| - | - по Вове если нагрузка не высокая то решаем все баги и добавляем фичи которые были реализованы в ICSM но не были добавлены в вебинт | + | |
| - | - юзабилити баги жестко критикл, если более 80% пользователей затрагивают | + | |
| - | - если раньше что то работало а с выпуском версии перестало работать то нужно срочно вносить исправление | + | |
| - | ===== сортировка модулей ===== | + | * Запас времени всегда 50% на каждого разработчика, то есть если разработчик сказал, что сделает за 1 день, то считаем, что 2 дня и тд. То есть не более 10 плановых человекодней на версию на одного разработчика. |
| - | - сортировка модулей производится на основе мнений экспертной группы в которую входят: * Сергей Осинцев * Руслан * Алексей * Артем | + | * Если на разработчика запланирован модуль или сложная фича, то лучше не отвлекать его багами и критикал багами. |
| - | и по запросам не купивших еще клиентов ( 50 и выше пользователей ), либо тех кому было обещано | + | |
| - | - в дальнейшем, на основе плана разработки и по запросам не купивших еще клиентов ( 50 и выше пользователей ), либо тех кому было обещано | + | ===== Сортировка модулей ===== |
| - | ===== фичи и небольшие возможности ===== | + | |
| - | - стараться планировать по одной фиче на человека. если на человека фича уже запланирована, больше не ставить. | + | под модулем также будем понимать большие изменения |
| - | - если нагрузка высокая то выполняются только фичи которые принесут прибыль | + | |
| - | - если фича не сильно важная переносить не на следующую версию а на через-версию | + | * сортировка модулей производится на основе мнений экспертной группы в которую входят как минимум: продукт менеджер, технолог, тимлид, маркетолог. |
| - | - если фича влияет на юзабилити она делается срочно | + | * вижн продукт менеджера, запросы новых клиентов, запросы старых клиентов, анализируем рынок, конкурентов, идеи сотрудников. |
| - | 4. резервирование 4 человеко-дней на каждого на непредвиденные работы от клиентов и от сотрудников | + | * планируем не более 1-3 модулей на одну ежемесячную версию на одну команду(3-9 чел), и обязательно через один месяц, то есть в год 6 запланированных версий и 6 внеплановых с фиксами и внеплановыми фичами. |
| - | 5. если поля Важность и Срочность переорпделены то такую задачу переносить на следующую версию крайне нежелательно | + | * модули выбираем 50% полезные и 50% пригодные для рекламы и PR |
| - | 6. если превышено количество задач или модулей то добавлять больше нельзя ( в будущем сделать что бы было программно и возможно в расчете на одного программиста ). небольше одного модуля в версию на человека, небольше одной фичи, баги по желанию. ( на текущий этап до момента пока не нагоним баги, потом можно фич делать больше ( пересмотр инструкции/правил ). | + | * реализуем минимальные возможности модуля, остальное расширяем потом |
| - | планирование производится на одну версию | + | * обязательно учитываем мнения клиентов и/или опросы |
| + | |||
| + | ===== Сортировка фич ===== | ||
| + | |||
| + | * стараться планировать не более 1-3 фич на человека на версию. | ||
| + | * если нагрузка высокая, то выполняются только фичи которые принесут ближайшую прибыль, что позволит расширить штат | ||
| + | * если фича не сильно важная, или осталась невыполненной, то переносим всегда на через одну версию, а не на следующую версию | ||
| + | * если фичу обещали пользователю, то планируем через одну версию, а не на следующую | ||
| + | * если фича сильно влияет на юзабилити или продажи она делается в ближайшей версии | ||
| + | |||
| + | ===== Сортировка BUG ===== | ||
| + | ==== Критикал патч: ==== | ||
| - | «Обязательно» «Желательно» «На потом» | + | * если раньше что то работало, а с выпуском версии или по определенной дате перестало работать, то нужно срочно вносить исправление |
| + | * если может, с значительной вероятностью, привести к потери данных пользователя, то нужно срочно вносить исправление | ||
| + | * если в будущем придется писать сложный конвертер данных или сложную исправлялку, то нужно срочно вносить исправление | ||
| + | * если может, с значительной вероятностью, привести к существенным убыткам или нарушению основной деятельности пользователя, то нужно срочно вносить исправление | ||
| + | * юзабилити раздражающие баги, если более 20% пользователей затрагивают, то нужно срочно вносить исправление | ||
| + | * проблема приводящая к медленной отладке или медленной сборке или медленному тестированию. В зависимости от продукта от 3 секунд до 1 минуты, редко 10 минут с учетом fast_test(полная пересборка проекта делается редко и в расчет не берется). | ||
| + | * проблемы с обновлением, которые могут привести к потери возможности автоматического обновления | ||
| - | планирование производится на одну версию | + | ==== Правим в ближайшей версии: ==== |
| - | + | ||
| - | 0. общий принцип построения приоритетов | + | |
| - | - прибыль: новые возможности, новые фичи, критичные исправления | + | |
| - | - лояльность клиентов и репутация | + | |
| - | + | ||
| - | 1. баги обязательное исправление | + | |
| - | - если у клиента что то правили то исправить в ближайшую версию и запретить клиенту обновляться | + | |
| - | - если бага даже супер критикал но проявится через год можно делать позже | + | |
| - | - если бага влияет сильно на репутацию то выполнять в течение версии | + | |
| - | - если баг приходит от саппорта и влияет на всех клиентов оценивать как критикал. выставлять в CRM признак критикал. | + | |
| - | - если баг приходит от саппорта но затрагивает 1-2 клиентов то задача важная, выполнение в течение следующей версии ( исключение провайдер, либо те клиенты которые еще не купили ) | + | |
| - | - по простым багам выполнять только те которые приносят убытки или могут принести прибыль | + | |
| - | - концептуальные баги на решение которых нужно не более 1 часа необходимо выполнять в пределах текущей версии ( важность Низкая ) | + | |
| - | - влияет на работоспособность но лечится перезагрузкой или другим простым способом - следующая версия | + | |
| - | - по Вове если нагрузка не высокая то решаем все баги и добавляем фичи которые были реализованы в ICSM но не были добавлены в вебинт | + | |
| - | - юзабилити баги жестко критикл, если более 80% пользователей затрагивают | + | |
| - | - если раньше что то работало а с выпуском версии перестало работать то нужно срочно вносить исправление | + | |
| - | + | ||
| - | 2. сортировка модулей | + | |
| - | - сортировка модулей производится на основе мнений экспертной группы в которую входят: | + | |
| - | * Сергей Осинцев | + | |
| - | * Руслан | + | |
| - | * Алексей | + | |
| - | * Артем | + | |
| - | и по запросам не купивших еще клиентов ( 50 и выше пользователей ), либо тех кому было обещано | + | |
| - | - в дальнейшем, на основе плана разработки и по запросам не купивших еще клиентов ( 50 и выше пользователей ), либо тех кому было обещано | + | |
| - | + | ||
| - | 3. фичи и небольшие возможности | + | |
| - | - стараться планировать по одной фиче на человека. если на человека фича уже запланирована, больше не ставить. | + | |
| - | - если нагрузка высокая то выполняются только фичи которые принесут прибыль | + | |
| - | - если фича не сильно важная переносить не на следующую версию а на через-версию | + | |
| - | - если фича влияет на юзабилити она делается срочно | + | |
| - | + | ||
| - | 4. резервирование 4 человеко-дней на каждого на непредвиденные работы от клиентов и от сотрудников | + | |
| - | + | ||
| - | 5. если поля Важность и Срочность переорпделены то такую задачу переносить на следующую версию крайне нежелательно | + | |
| - | + | ||
| - | 6. если превышено количество задач или модулей то добавлять больше нельзя ( в будущем сделать что бы было программно и возможно в расчете на одного программиста ). небольше одного модуля в версию на человека, небольше одной фичи, баги по желанию. ( на текущий этап до момента пока не нагоним баги, потом можно фич делать больше ( пересмотр инструкции/правил ). | + | |
| + | * если у клиента что то правили, то исправить в ближайшую версию и запретить клиенту обновляться | ||
| + | * если бага влияет сильно на репутацию, то исправить в ближайшую версию или выпустить критикал патч | ||
| + | * если баг приходит от саппорта и влияет на всех клиентов, то исправить в ближайшую версию | ||
| + | * если баг от больших клиентов и баг новых клиентов, то исправить в ближайшую версию | ||
| + | * архитектурные и прочие технические баги на решение которых нужно не более 1 часа, то исправить в ближайшую версию | ||
| + | ==== Правим позже: ==== | ||
| + | * если бага даже супер критикал, но проявится через год или раз в год, то можно делать позже | ||
| + | * если баг приходит от саппорта, но затрагивает 1-2 клиентов, то можно делать позже | ||
| + | * по простым багам и недочетам не влияющим на основную функциональность | ||
| + | * если баг в функционале, который никто не использует, то исправляем позже или не исправляем до первого использования | ||
| + | * влияет на работоспособность, но лечится перезагрузкой или другим простым способом, то можно делать через версию | ||
| + | * исправлять только те, которые уже приносят убытки или недополучение прибыли | ||
| + | * если задачу можно отложить и много других задач, то лучше отложить | ||
| + | ==== Статья Дениса на тему приоритезации ==== | ||
| + | * [[https://wika.carbonsoft.ru/блоги_и_отзывы:приоритезация_фич|https://wika.carbonsoft.ru/блоги_и_отзывы:приоритезация_фич]] | ||
| - | Определение приоритета задачи | + | ~~OWNERAPPROVE~~ |
| - | По умолчанию приоритет задачи medium | + | |
| - | Используют меньше 5% клиентов -1 | + | |
| - | Используют больше 50% клиентов +1 | + | |
| - | Сломался ранее работавший функционал +1 | + | |
| - | Может привести к пропускам фильтрации +1 | + | |
| - | Можно отложить на месяц -1 | + | |
| - | Хотелки по разработке -1 | + | |
| - | Проблема приводит к превышению итерацией "commit - push - build - update - test" интервала в 10 минут +1. | + | |
| - | Задача может принести денег 1% от текущего оборота +1 | + | |
| - | TODO 21.12.2017 Возможно стоит разделить разработку нового и поддержу биллинга. т.к. если программист работает с одной задачей постоянно, не переключаясь на устранение бага, то у него скорость работы выростает сильно. Например так - один месяц 1 ведущий разработчик отвечает за разработку нового. второй разработчик занимается переключениями между починкой различных багов и тп | ||
| - | */ | ||
admin