Как повлиять на приоритеты ошибок для разработчиков и относиться к ним соответствующим образом?

У нас есть ошибка, которая в настоящее время работает.

У нас есть 3 уровня ошибок:

Ошибка P1: ошибки, мешающие работе пользователей. Они должны быть решены на месте.
Ошибка P2: ошибки, которые влияют, но пользователи могут работать
Ошибка P3: ошибки, которые не влияют и где пользователи могут работать.

P1 является обязательным и должен быть сдан на месте. Но для P2 и P3 мы судим в каждом конкретном случае.

Имея 3 уровня, которыми мы располагаем, команда имеет тенденцию работать над более актуальными новыми разработками, запрашиваемыми клиентами, вместо того, чтобы иметь дело с P2 и P3, что почти не срочно.

Вопросы следующие:

Должен ли я добавить другой уровень приоритета, например, наличие P4?

Должен ли я также назначить им цели для работы с несрочными билетами, как на этой неделе, когда вы не назначаете задачу кодирования, вы должны обработать хотя бы 1 P2?

В настоящее время у нас нет целей, о которых я говорил выше, но я обеспокоен тем, что постановка таких целей может быть жестокой. Я уверен, что мне нужно поговорить с ними о целях, команде нравится участвовать в обсуждениях, особенно когда мы ставим цели.

Обновить:

Мне предложили этот вопрос с точки зрения сходства. Однако это совсем не похоже.

Мой вопрос заключается в том, как заставить людей справляться с ошибками, не навязывая строгую повестку дня и не решая ее. Так что нет, подразумеваемый вопрос не помогает мне. Тем не менее, спасибо.

agile debugging issue-tracking

— Энди К
источник

Возможный дубликат Как я могу убедить руководство справиться с техническим долгом?

— Комнат

обычно уровень приоритета не так полезен, как порядок приоритетов ... «ошибка X» более важна, чем «ошибка Y». если вы в конце концов добавите p4, вам понадобятся p5 и p3.5

— sudo rm -rf slash

Если у вас так много ошибок P1, что все ваши разработчики всегда заняты их исправлением вместо того, чтобы работать с P2 / P3, вы делаете что-то очень неправильное. Не добавляйте больше функций на некоторое время. Сосредоточьтесь на детализации и устранении архитектурных (или кадровых) проблем, которые почти наверняка вызывают многие из этих ошибок. Например, если вы пишете код на C ++, убедитесь, что вы используете RAII везде, где только можете, чтобы не забыть сделать это вручную .release().

— Фонд Моники Иск

Какова ваша цель? Хотите, чтобы разработчики больше работали над исправлением ошибок, а не над новыми функциями? Пожалуйста, отредактируйте свой вопрос, чтобы уточнить. Также, пожалуйста, опишите, как разработчики в настоящее время получают или принимают на работу? Что используется, чтобы решить, над чем работает?

— Слёске

Функция, ошибка, изменить как вы это называете, программное обеспечение не делает то, что ему нужно. Единственная разница между ошибкой и функцией заключается в том, кто за нее платит.

— Mattnz

Ответы:

Обычно у вас есть две оси для ошибок: гравитация и частота.

Очевидно, что что-то серьезное и частое имеет первостепенное значение. Однако то, что серьезно, но случается редко, следует взвешивать примерно так же, как то, что несерьезно, но случается часто. Итак, предположим, что вы оцениваете гравитацию от 1 до 3 и частоту от 1 до 3, ошибки, которые вы, вероятно, должны исправить, - это те, которые пересекают диагональ, определяемую гравитацией 1, частотой 3 и гравитацией 3, частотой 1.

Ошибка блокировки или ошибка, которая может привести к потенциальному повреждению информации клиента, всегда будет гравитацией 3. Аналогично, ошибка с гравитацией 1 вряд ли будет замечена пользователем или имеет низкий приоритет. Если вы здесь не уверены, возможно, 2 - это безопасный номер для назначения.

Ошибка, которую пользователь видит каждый раз при запуске программы, будет иметь частоту 3. Ошибка с частотой 1 будет чем-то, что случается редко, если вообще происходит. Опять же, если вы не уверены, 2 - это, вероятно, безопасный номер для назначения.

Это в основном субъективно в отношении того, что представляет собой ошибка с гравитацией 3 или ошибка с частотой 3, но используйте ваш здравый смысл. Ошибка с гравитацией 1, частота 2, возможно, является ошибочной меткой. Ошибка с гравитацией 2, частота 1, может быть правильной обработкой ошибок, когда соединение с базой данных не работает.

Опять же, это просто грубая идея, но идея состоит в том, чтобы сделать акцент на том, что должно быть в центре внимания для исправления ошибок как своего рода сортировка. Ясно, что невозможно устранить все ошибки, блокировку или иное, хотя, по крайней мере, с помощью этой методологии, вы можете с уверенностью сказать, что ошибки не слишком острые или слишком частые. Если вы только исправлены ошибки , которые блокируют ошибки, то ошибки высокой частоты будут игнорироваться , и пользователи будут замечать , что вы не исправить эти ошибки.

Также, для удобства, вы можете обнаружить, что предпочитаете указывать буквенные оценки для гравитации или частоты, поэтому вы можете сказать, что ошибка - это ошибка B3, и она ясно как по гравитации, так и по частоте.

Удачи!

— Нил
источник

В действительности, есть только один показатель для ошибок - ROI - сколько это будет стоить, чтобы исправить по сравнению с тем, сколько компания теряет, чтобы не исправить это. Сравните это с особенностями. Конечно, как вы рассчитываете, что метрика включает в себя гравитацию, частоту и т. Д.

— CorsiKa

@corsiKa, да, ROI является составной метрикой: «доход» и «инвестиции». А для ошибок, возвращение может быть смоделировано как совокупность «гравитации» и «частоты».

— Пол Дрейпер

@corsiKa, такой хладнокровный эгоистичный анализ качественных решений на самом деле крайне безответственный. Это та же самая логика, которая приводит к тому, что фармацевтические компании обходят законы о тестировании эффективности, если они могут «сойти с рук», или сохраняют на рынке прибыльные лекарства, несмотря на серьезность и частоту побочных эффектов. Это та же самая безответственность, которая приводит к огромным бот-сетям, состоящим из небезопасных потребительских маршрутизаторов и «умных» устройств, потому что производитель не видит никакой долларовой ценности в хорошей безопасности. Гравитация и частота являются НАМНОГО лучшими показателями, чем «влияние на прибыль».

— Wildcard

@Wildcard Я буквально коммунист, поэтому я на 100% согласен с вами, что так лучше. Это не меняет того факта, что так работают компании-разработчики программного обеспечения, и если вы не будете руководить компанией, то если вы управляете компанией, вы утонете. Хотя стоит отметить, это не эгоистично. Это сингл, но этот сингл - это не я, это компания. Просто выбросить это там.

— CorsiKa

@Wildcard и corsiKa, компания не большая, и мы не можем позволить себе сказать: «О, мы собираемся потерять деньги, тогда давайте сделаем что-то иначе, давайте оставим это на месте». Однако я не считаю, что упомянутый вами подход является устойчивым в долгосрочной перспективе. Люди - клиенты далеко не глупы. Компании, которые проповедуют такое Евангелие, Солнце, чтобы назвать его, больше не здесь. Я работаю в управлении учетными записями достаточно долго, чтобы деньги не зарабатывались таким образом. Кому-то, если вам довелось работать в такой компании, где компании не хватает лояльности 1 / n

— Энди К

Это действительно сводится к тому, что вы считаете более важным. Ошибка P2 или новая функция?

Обычно гибкая система управления проектами включает в себя своего рода совещание по определению приоритетов, на котором задачи упорядочены по приоритету и работают в этом порядке.

Разработчикам не разрешается выбирать задачи, над которыми они работают. Это работа менеджера проекта. Кто должен обеспечить, чтобы в проекте было максимально возможное количество важных функций, включенных до истечения бюджета.

Это действительно самая важная вещь. Простые правила, такие как «исправьте хотя бы 1 P2 в неделю», не очень помогают этой цели.

— Ewan
источник

Проблема с назначением приоритетов состоит в том, что независимо от выбранной вами детализации сегмента вы всегда будете иметь более одного фрагмента на сегмент. Вы должны навести порядок, а не просто сказать: «Все это НАИБОЛЕЕ ПРИОРИТЕТНО!»

— Эван

@Ewan Существует также возможность приоритетной инфляции, когда у вашего самого высокого сегмента больше проблем, чем вы когда-либо могли бы решить, и за пределами системы отслеживания ошибок изобретены новые уровни приоритетов. Я слышал, что люди говорят о P минус 2 вопроса.

— kasperd

Заявив, что разработчики не имеют права выбирать задачи, над которыми они работают, это повредит вашей производительности. Если разработчик заблокирован из-за проблемы с наивысшим приоритетом, над которой он работал, лучше, если он тем временем поработает над другой проблемой, чем если он ничего не сделает, пока первая проблема заблокирована. Более того, проблемы, которые не наносят вреда пользователям, но наносят ущерб производительности разработчиков, часто не имеют приоритетного значения. Наконец, сказать разработчикам, что им не разрешено принимать собственные решения, - верный способ уничтожить мотивацию.

— Касперд

@kasperd Я думаю, что большинство разработчиков признают, что они являются сотрудниками, а также техническими супер гениями, и признают, что их работодатель решает, какие задачи следует выполнить в первую очередь. Очевидно, что если один из них заблокирован, вы перейдете к следующему наиболее важному, но вы не пропустите 10 важных заданий, чтобы поработать над классным.

— Эван

Я обнаружил, что если работа завершена или заблокирована, вместо того, чтобы затягивать в спринт еще одну задачу по разработке (делать разборки), ошибка должна иметь приоритет. MS классно отдает все ошибки наивысшему приоритету по сравнению с любыми задачами разработки при работе в Windows 2000 - они обнаружили, что это лучший способ для создания программного обеспечения без ошибок (одна из причин, почему 2000 действительно понравился), как если бы они этого не делали ошибки, как правило, уходят, так как вместо этого обычно требуется новая разработка.

— Baldrickk

Это довольно распространенный цикл для программного обеспечения, накапливающий некритические ошибки, пока что-то не дает, затем происходит большое событие, и многие из них исправляются одновременно; возможно, посвящая спринт или два только исправлениям ошибок перед большим новым выпуском, или тем, что программное обеспечение было EOL и пережило кучу ошибок.

Так что вы в хорошей компании, если ваши разработчики просто позволяют им скользить. Конечно, вы можете манипулировать «правилами», как вы упомянули («если вы не работаете над новой функцией, вы должны работать как минимум с одним P2 в неделю»), но это, скорее всего, сделает вас непопулярным.

Мой вопрос заключается в том, как заставить людей справляться с ошибками, не навязывая строгую повестку дня и не решая ее.

Вместо этого я бы предложил немного изменить общее мышление и сделать ошибки более похожими на функции в том смысле, что они являются первоклассными гражданами в вашем отставании. Да, новые функции великолепны; да, управление и продажи очень сильно зависят от новых функций. Но также важно иметь стабильное, хорошо работающее приложение вместо огромной кучи грязных ошибок.

Не говорите своим разработчикам, что они должны выполнять работу, которая им не нравится; но попробуйте изменить атмосферу, чтобы им нравилось работать над ошибками. Попробуйте привить чувство гордости в приложении без ошибок. Сделайте более увлекательным (sic) работать над ошибкой, специально позволяя им на самом деле исправить основную причину, которая сделала эту ошибку очевидной (то есть, не просто быстрые обходные пути / взломы), если они есть. Извлечение какой-то сломанной структуры классов и замена ее чем-то более подходящим может быть очень интересным для разработчиков. Если у вас есть сломанная центральная часть, которая регулярно делает ошибки обнаруженными в другом месте, исправьте центральную часть.

То, как вы достигаете своей цели, во многом зависит от вашего собственного характера и характера ваших команд - не пытайтесь обмануть их в том, чего вы хотите достичь, но проводите открытые дискуссии, старайтесь задействовать эффект сверстников, дайте им придумать рабочий процесс сами и тд.

— Anoe
источник