Почти каждая обнаруженная ошибка является ошибкой высокого приоритета [закрыто]

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

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

Этот вопрос конкретно касается проблемы «Приоритетная инфляция»: если вы столкнулись со сценарием и какие результаты окажутся эффективными против этой проблемы.

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

На самом деле, если вы спросите меня, это не так. Чем больше (используемых) уровней приоритета, тем больше у вас информации. Если у вас фактически есть только один приоритет, это то же самое, что вообще не иметь приоритета.

И так как у вас все еще есть то же количество ошибок, которые нужно устранить, и такое же количество человеко-часов, на которые это нужно сделать, из этого следует, что будет использоваться некоторая другая эвристика, возможно, нулевая - «первым пришел, первым обслужен». Итак, теперь у вас есть метрика приоритета ошибки, за исключением того, что это время прибытия и больше не находится под вашим контролем.

Это может быть признаком того, что для исправления ошибки выделяется недостаточно ресурсов (есть некоторые политики, такие как « Нет новых функций, пока ошибки не исправлены », которые могут помочь в этом. Джоэл одобряет ; понимание ограничений и последствий - это бизнес-решение ).

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

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

После некоторого торга у нас был список дел на неделю, который был разделен на «будет делать», «может делать» и «не может делать», которые были перенесены на следующую неделю. Вот тут-то и произошли дополнительные торги: у нас было пятьдесят часов, чтобы выделить ошибки, и мы были на 95% уверены, что исправим первые двадцать. Руководство настоятельно хотело, чтобы двадцать первый баг был исправлен, и у него не осталось кредитов; Затем мы предложили бы поменять эту ошибку на одну из списка «Будет делать», или кто-то сказал бы: «Вытащите меня из подгруппы FooBazFeature на пару дней, и я сделаю это», или мы скажем: «Нам нужно больше». рабочая сила».

На самом деле система никого не устраивала, но это считалось (по крайней мере, среди разработчиков) хорошим знаком.

Некоторые дополнительные негативные паттерны, которые были обнаружены, были «Желаемое за действительное» со стороны менеджеров («Вы заявили, что ошибка 57212 требует восьми часов. Это недопустимо. Сделайте это четырьмя») и «Отладка по Fiat» («Делайте все, что хотите» но эти сорок ошибок должны быть исправлены перед большой демонстрацией на следующей неделе. У вас не может быть больше времени, у вас не может быть больше людей "). Также синдром Боксера («Я буду работать усерднее»), который обычно работал очень хорошо в течение короткого времени , но обычно приводил к тому, что разработчик сходил с ума или уходил на более зеленые пастбища.

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

Через некоторое время ваши пользователи либо получат сообщение, либо вы можете изменить систему отчетов так, чтобы у каждой ошибки был приоритет по умолчанию. Если они хотят, чтобы это усилилось, им придется связаться с кем-то, чтобы столкнуться с этим, что потребует некоторого обоснования. Уже один этот факт приведет к тому, что 99% всех ошибок останутся не обостренными пользователем.

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

ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ: У меня еще не было опыта работы с сообщениями о приоритетах ошибок пользователей. Я знаю, что вопрос требует этого, но это могло бы помочь иметь перспективу постороннего.

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

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

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

1. Программа становится непригодной для использования или вылетает, когда я что-то делаю.
2. Программа имеет графический дефект, который влияет на функциональность.
3. Программа не позволяет мне делать то, что я должен уметь.
   Программа позволяет мне делать то, что я не должен делать.
4. Программа дает неправильный результат, когда я что-то делаю.
5. Программа занимает слишком много времени, чтобы что-то сделать.
6. В программе есть графический дефект, который не влияет на функциональность.
7. Программа имеет дефект, который не подходит ни к одной из вышеперечисленных категорий.

Чтобы привести примеры:

1. Мой iPhone падает, когда я получаю сообщение, содержащее ивритские символы.
2. Мой экран блокировки Android поворачивается таким образом, что половина его падает на экран.
3. Мой телефон Android иногда не принимает мой код блокировки экрана, хотя я и ввел правильный код.
4. Когда я пытаюсь перейти на PhoneHub.net, мой телефон перенаправляет меня на сайт для взрослых.
5. Когда я открываю приложение Facebook, открывается минута, даже при быстрых соединениях и без запуска других приложений.
6. В вашем приложении есть орфографическая ошибка.
7. Я обнаружил дефект безопасности в вашей программе и хотел бы сообщить об этом.

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

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

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

Части этой системы можно увидеть в ситуациях поддержки высокой пропускной способности: гигантские технологические компании, такие как Microsoft, Facebook, Google, игровые компании с большим количеством пользователей, таких как Valve и Blizzard, некоторые правительства ... Хотя я не уверен из работы за кулисами вы замечаете, что их система поддержки, ориентированная на пользователя, имеет интерфейс, аналогичный тому, который я предлагаю здесь, со строгой системой категорий.

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

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

1. Полная потеря функциональности
2. Частичная потеря функциональности
3. Широкое снижение эффективности
4. Локальное снижение эффективности
5. Раздражение или помеха (обходной путь существует)
6. косметический
7. Никто на самом деле не заметил, был найден во время малоизвестных предварительных испытаний

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

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

Это выглядит примерно так:

Mgr: над чем вы работаете? Dev: задачи с низким приоритетом Mgr: разве вы не должны работать над задачами с высоким приоритетом?

Клиент: когда моя ошибка будет исправлена? Dev: это низкий приоритет, у нас есть приоритетные задачи. Клиент: ну, тогда установите мой статус ошибки на высокий приоритет.

Это приведет к повышению уровня приоритета. Я вижу, вы уже вышли за пределы высокого приоритета в очень высокий приоритет. Что будет дальше:

1. Супер Высокий Приоритет
2. Ультра Высокий Приоритет
3. Очень Супер Ультра Высокий Приоритет.
4. Очень Супер Ультра Мега Высокий Приоритет.

и т. д.

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

Есть в основном 2 способа противостоять этому:

1. Отнимите у клиента контроль над уровнями приоритета.
2. Связать стоимость с клиентом для повышенных уровней приоритета.

Можно добавить все более и более высокий уровень приоритета в систему, особенно если это Jira. Придавать новым высоким приоритетам все более и более глупые, но мрачные имена могут усилить эффект Хоторна, который повысит качество выбора приоритетов, сделанного всеми сторонами. Если наивысший приоритет имеет действительно диковинное имя, эффект может быть постоянным. В конце концов, когда кто-то выбирает приоритет, он должен взвесить социальные последствия выбора приоритета «ошибка смерти» вместо того, чтобы привлечь к нему должное внимание. Таким образом, наивысший приоритет де-факто зарезервирован для того, что случилось с CTO дома перед его гостями, или других инцидентов с аналогичной видимостью.

Ввести стоимость поддержки запросов. Вы можете разрешить пользователю сообщать только о количестве элементов с высоким приоритетом за определенный период времени, количестве элементов со средним приоритетом и низким приоритетом.

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

Но если это сработает, руководству на самом деле придется покупать его, иначе все упражнение - пустая трата времени.

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

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

Это происходит очень часто в крупных корпорациях, где ИТ рассматривается как вспомогательное и / или передается на аутсорсинг. Деловые люди не разбираются в программном обеспечении и не заботятся о том, что их волнует только то, что «их» ошибка была исправлена ​​вчера, независимо от того, насколько она некритична. Они не понимают или не заботятся о том, что есть сотни других пользователей, которые также сообщают об ошибках, и команда из примерно 5 разработчиков может исправить ошибки.

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

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

По сути, если разработчики не имеют контроля над приоритетом , вы уже потеряли.

Как и компания, вы хотите решить вопросы с наивысшим соотношением важности и стоимости. Пользователи решают важность, инженерия решает стоимость. Если пользователи присваивают одинаковые значения всем ошибкам, тогда важна только стоимость.

На практике это означает, что вы определяете приоритет как важность / стоимость и не позволяете пользователям или разработчикам устанавливать этот приоритет напрямую. Ни одна из сторон не имеет полной картины.

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

Несколько факторов ...

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

Поэтому я думаю, что все сообщения об ошибках должны просматриваться БЫСТРО одним-двумя опытными разработчиками, добавляя свои мысли в отчет об ошибках, а затем ошибка должна быть устранена. Ожидать, что человек, который обнаружит ошибку, сможет установить полезный приоритет в тот момент, когда он ее обнаружит, просто требует слишком много.

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

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

О большинстве уже сказано, но я бы перевел список "bug zoo" к чему-то менее детальному:

A: Ошибка останавливает пользователя в его треках, дает неправильный вывод, обычно делает систему / функцию / функцию непригодной для использования. Это ошибка с высоким приоритетом.

Б: Все остальное. Это «оборотные» ошибки.

ПЕРЕГОВОРНЫЕ ошибки связаны с рядом проблем (которые вы бы поставили в своем собственном порядке):

1: ошибки, которые влияют на безопасность;

2: ошибки, которые влияют на удобство использования (пригодность по назначению);

3: ошибки, которые влияют на эстетику;

4: ошибки, влияющие на производительность (возможно, подмножество юзабилити?);

5: ошибки, которые оскорбляют ваши чувства как профессионального программиста;

6: ошибки, которые уменьшают доверие пользователей;

Так что это утопический мир, в котором на самом деле никто из нас не живет. Вздохните. Чтобы завершить мой ответ на поставленный OP вопрос во всей индустрии программного обеспечения, усилия разработчиков находятся в состоянии, когда каждая ошибка является приоритетом. один-супер-сосиска-специальное. И вы знаете, что они говорят о «особенном»: когда все особенные, никто не особенный.

В основном эта проблема коренится в проблеме децентрализации приоритетов. Всегда должно быть нечетное количество людей, способных расставить приоритеты в рабочей нагрузке команды, а 3 - это слишком много. Так что 1 человек отвечает за эффективно -перевозку. И это должен быть менеджер / аналитик в консультации с ведущим разработчиком / архитектором. И этот процесс довольно прост и может быть применен к запросам функций. Сколько стоит разработка? Какова ценность ожидаемого результата для бизнеса. Выход этой функции является назначенным приоритетом.

Конечно, каждый пользователь хочет, чтобы их проблема была решена первой. И как только вы позволите это, хаос. У вас нет действительных приоритетов. Это необходимо сделать ОДНОМУ человеку с полномочиями (при необходимости консультируясь с другими), который имеет ВИДИМОСТЬ во ВСЕХ проблемах и бизнес-потребностях и достаточно компетентен, чтобы собирать необходимые консультации бизнес-экспертов и ИТ-специалистов и, таким образом, генерировать достаточно точные оценки показателей. выше.

С риском констатировать очевидное, я собираюсь предположить, что нет программного обеспечения для отслеживания ошибок, которое устанавливает ошибки с высоким приоритетом по умолчанию (или было установлено на этот параметр).

Я боюсь, что в отсутствие элементов управления это сценарий по умолчанию для нескольких команд, клиентов и т. Д., Которые отправляют отчеты. Если статус-кво злоупотребляют, тогда определённый процесс сортировки определённо в порядке.

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

Здесь я предполагаю, что вы говорите обо всех ошибках, а не только о начальных разработках. Если вы, как правило, нанимаете пушку для разработки «зеленых» месторождений, то, конечно же, нет ничего необычного в том, что большинство ошибок имеют высокий приоритет после первоначальной альфа-версии.

Вы не можете просто иметь приоритет и ожидать, что все волшебным образом сработает. Иногда люди понимают это самостоятельно, но не всегда.

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

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

Если трудность возникает из-за невозможности создать объективные критерии, вы можете использовать относительные критерии:

• Есть простая очередь всех ошибок. Пользователи могут вставлять ошибки в любом месте очереди. Они должны вставлять только в заданной позиции, если они чувствуют, что их ошибка важнее, чем все, что ниже. Исправители ошибок начинаются с вершины очереди.
• Предполагая, что у вас уже есть набор хорошо классифицированных ошибок, скажите всем, что условием для размещения ошибки в приоритете Xявляется то, что она должна быть важнее всех ошибок в приоритете X-1.
• Сообщите отправителям, что количество ошибок с приоритетом никогда не может Xпревышать количество ошибок с приоритетом X-1.

Но, похоже, ваша проблема не в определении, а в том, что авторы считают, что ошибки с низким приоритетом не исправляются. Предположительно, вы не можете убедить их в обратном, поскольку (из того, что вы говорите) их убеждения основаны на действительности. Тогда, почему вы заставляете их отправлять эти ошибки? В конечном итоге это всего лишь занятая работа. Например, вы можете, после того, как достигнуто определенное количество активных ошибок, сказать всем не беспокоиться о создании отчетов, если они не почувствуют, что нашли что-то более важное, чем большинство выдающихся ошибок. Конечно, это просто решение для очереди с верхним пределом длины очереди.