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

50

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

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

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

Карлос Гавидия-Кальдерон
источник
9
Вот почему «приоритет» глупо. Является ли Х Приоритетом 2 бессмысленным, Х важнее, чем Y отвечает и полезен. Единственное, что имеет значение, это порядок.
Натан Купер
7
@NathanCooper Да, но, видите ли, если у нас есть ошибка, которая очень важна, и нам нужно действительно дать ей немного больше усилий, чтобы вы знали, что мы делаем? Это верно - мы установили его приоритет на 11.
gbjbaanb
6
@CarlosGavidia, таким образом, вам нужен способ взять приоритет из прямых рук человека, отправляющего ошибку, и найти какой-то другой способ, который является объективным для определения ROI для исправления ошибки.
2
@JuliaHayward лично мне нравится pef / rev, хотя я специально рассматриваю показатель «боли» для ошибок: улучшение сортировки ошибок с помощью пользовательской боли также очень хорошо. Ни один из них не позволил человеку, сообщившему об ошибке, установить общий приоритет ошибки («приоритет» в метрике ошибки ошибки заключается в том, что именно его блокирует, а не в том, насколько важно это исправить).
16
Правдивая история: однажды я решил эту проблему с приоритетной инфляцией, вызвав на нее своих клиентов и пригрозив переименовать различные приоритеты в «оранжевый», «кумкват» и «орангутанг», если они не справились с задачей дифференциации серверности достаточно, чтобы сохранить смысл поля. Это сработало (что было неудачно, потому что у меня действительно были привилегии администратора для создания серьезности «кумквата», и я с нетерпением этого ожидал)
Cort Ammon

Ответы:

42

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

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

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

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

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

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

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

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

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

LSerni
источник
Люблю "поджечь" часть. У нас есть нечто подобное, запланированное для одного из наших модулей :)
Роман Рейнер
1
Я впечатлен тем, что у вас была такая организованная / согласованная система, и вам все же удалось сжечь разработчиков. Это, должно быть, был один интенсивный проект!
благодаря
На самом деле, у нас были сильные менеджеры, и не всегда с хорошей человеческой динамикой. Так что время от времени были ... проблемы. Некоторые справились, другие нет.
LSerni
Первоначальный вопрос: «(как избежать) каждая ошибка имеет высокий приоритет». Технически говоря, этот (принятый!) Ответ на самом деле НЕ отвечает. В нем просто упоминается «входящие ошибки были накоплены в буфере без приоритетов, и каждый понедельник мы будем просматривать список ошибок, (грубо) оценивать сложность и сортировать их по доступному времени». Но этот ответ дает много хороших наблюдений, хорошую пищу для размышлений.
RayLuo
@RayLuo Нет, это ответ. Вместо того чтобы журналисты оценивали приоритет, разработчики оценивают приоритет.
JAB
47

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

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

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

gbjbaanb
источник
8
Нет, подождите. Вы, кажется, sugesst ... Но это не может быть ... Есть на самом деле разработчики, которые не имеют больше ошибок, чем они могут обработать? Шутки в сторону? :-D
Мартин Ба
49
@MartinBa YMMV, но я работал в местах, где мы уделили время для тщательного проектирования и разработки нашего продукта, и, хотя были обнаружены ошибки, они были достаточно редки. Вы, дети сегодня, пишете код без особых предварительных мыслей о дизайне, не удивительно, что вы тратите все свое время на модульное тестирование и рефакторинг :-)
gbjbaanb
5
На самом деле, если потратить достаточно времени на юнит-тестирование, ошибки снова быстро исчезнут. В команде Scrum владелец продукта будет тем, кто подтвердит важность ошибок, а владельцы продуктов должны иметь достаточно знаний в области бизнеса, чтобы оценить истинную важность ошибок. Если ошибки не попадают в список заданий спринта, владелец продукта недостаточно хорошо выполняет свою работу.
Cronax
14
@Cronax, если кто-то тратит достаточно времени на тестирование модулей, вы обнаружите, что у вас нет времени, чтобы написать какую-либо функциональность. Так что я думаю, что это останавливает появление каких-либо ошибок :-)
gbjbaanb
4
@gbjbaanb, пока вы придерживаетесь реальных модульных тестов и не выходите за рамки, мне кажется, что метрика agile / scrum, тратящая 10-20% времени на единичное тестирование времени разработки, точна. Вы не можете проверить все, но это одно и то же, независимо от того, какое тестирование вы проводите, и оно не является целью тестирования. Вы просто гарантируете, что ваш код выполняет то, для чего он предназначен, тестировщик оценит, соответствует ли он цели.
Cronax
14

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

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

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

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

  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, некоторые правительства ... Хотя я не уверен из работы за кулисами вы замечаете, что их система поддержки, ориентированная на пользователя, имеет интерфейс, аналогичный тому, который я предлагаю здесь, со строгой системой категорий.

Nzall
источник
Очень хороший ответ Пользователям никогда не следует позволять себе устанавливать какой-либо приоритет в отчете об ошибке. Категории очень хороший совет. Любая ручная настройка приоритета должна быть сделана владельцем продукта или подобным. В наших проектах разработки проблемы, возникающие в ходе тестирования, имеют приоритет владельца продукта на дискуссионных встречах с мастером Scrum.
благоговение
11

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

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

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

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

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

Анаксимандр
источник
Этот. И короткая версия для целей PR заключается в том, что приоритет всегда относительно других вещей и, следовательно, может быть решен только путем сравнения с другими вещами в очереди. То, что ваша вещь, очевидно, нуждается в выполнении, не означает, что она имеет наивысший приоритет.
Стив Джессоп
1
Что ж, не стоит сбрасывать со счетов то, что проблема с наибольшим воздействием может быть гораздо сложнее, чем проблема с небольшим воздействием. Я имею в виду, над чем бы вы работали, если бы вы могли исправить две ошибки, каждая из которых стоила 100 евро в день, или одну, стоимостью 200 долларов, за одно и то же усилие?
Дедупликатор
1
Неплохо подмечено; в это также войдут оценки усилий.
Анаксимандр
@Deduplicator Извините, я не совсем получил ваш аналог за 100 € и 200 $. Вы пытались предложить немного более низкое воздействие, но гораздо более легкий вопрос должен быть решен до самого высокого, но гораздо более сложного? Другими словами, вы говорили о концепции возврата инвестиций (ROI)?
RayLuo
10

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

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

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

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

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

и т. д.

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

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

  1. Отнимите у клиента контроль над уровнями приоритета.
  2. Связать стоимость с клиентом для повышенных уровней приоритета.
Питер Б
источник
7
Это не нормальный процесс. Клиенты не имеют бизнеса, взаимодействующего с разработчиками на этом уровне, если это происходит, руководство полностью и полностью не справляется со своей работой.
Давор Адрало
@ DavorŽdralo, возможно, процесс не то слово, которое используется здесь. Я имел в виду, что это происходит нормально.
Питер Б
3
Это нормальный процесс, поскольку клиент всегда будет чувствовать, что ошибка, с которой он сталкивается, более важна, чем, вероятно,. В то же время разработчики известны тем, что недооценивают важность ошибок. Вот почему у Scrum есть владелец продукта, который сидит между ними со знанием бизнес-сферы в сочетании с высокоуровневым представлением о том, куда движется приложение. Они уникально подходят для правильной оценки приоритета любой истории или ошибки.
Cronax
5

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

кардифф космический человек
источник
4

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

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

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

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

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

user1666620
источник
1
Я мог бы неправильно понять вашу суть, но если программное обеспечение, как правило, низкого качества, почему клиент должен быть оштрафован за то, что поднял серию ошибок с высоким приоритетом?
Робби Ди
@RobbieDee, кто говорит, что программное обеспечение низкого качества? Это не вопрос о том, как исправить плохую практику кода, а о том, как не дать клиентам перевести все проблемы поддержки в высокий приоритет.
user1666620
Итак, вы говорите о условной стоимости или квоте?
Робби Ди
@RobbieDee - Это зависит. Нечто подобное было реализовано в первой компании, на которую я работал, поскольку процесс поддержки был неэффективным и приводил к ситуации, когда, если все является чрезвычайной ситуацией, ничего не происходит. В нашем случае, получив контроль над ситуацией внутри компании, новый менеджер установил жесткий лимит на число приоритетных вопросов, которые клиент может подать в зависимости от того, сколько он заплатил в контрактах на поддержку. Если они превысили лимит, они либо откашлялись, либо проблема поддержки была в приоритете.
user1666620
Ах, хорошо - это имеет смысл.
Робби Ди
3

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

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

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

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

Ян Кемп
источник
Разработчики, имеющие контроль над приоритетами, могут быть в равной степени проблематичными. Они могут прыгнуть на быстрые победы или только выбрать ошибки в областях, с которыми они знакомы.
Робби Ди
@RobbieDee Я не вижу ничего плохого в том, чтобы сначала пойти на низко висящие фрукты в качестве политики.
Питер Б
1
Политика отсутствия ошибок - замечательная цель, но IMO - абсолютно нереальная - ошибки являются артефактом разработки программного обеспечения, потому что люди не совершенны. Вот почему вам нужна сортировка - чтобы выяснить, что нужно исправить сейчас , что можно исправить, если / когда есть время, и что, возможно, не нужно исправлять никогда. Таким образом, вы сможете избавиться от самых вопиющих проблем, все еще предоставляя функции.
Ян Кемп
1
@RobbieDee Я был как разработчиком функций, так и исправителем ошибок, и я обнаружил, что проблема в том, что ребята из функций и их помощники в конечном итоге превращаются в свои собственные мини-команды, потому что они не работают над тот же код и, следовательно, не нужно взаимодействовать. Это создает всевозможные проблемы, связанные с командным сплочением и моральным духом, особенно если ребята из отдела игровых функций и помощники никогда не меняют свои роли.
Ян Кемп
1
@RobbieDee И еще хуже, если роли поменялись местами - если вы сделаете это в фиксированный период времени, люди будут остановлены в середине работы, и «новым» людям придется снова набирать обороты; если вы сделаете это на основе того, когда работа будет завершена, будет несчастье, потому что неизменно кто-то будет чувствовать себя недовольным («почему я всегда заканчиваю тем, что трачу больше на ошибки»). По моему опыту, единственный способ, который работает, состоит в том, чтобы обеспечить работу всех функций разработчика и исправление ошибок, например, разработку функций в течение 4 дней в неделю и ошибки в течение 1 дня.
Ян Кемп
3

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

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

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

MSalters
источник
1
Это работает. Пока все проблемы влияют на каждого пользователя примерно одинаково. В противном случае, помните, что мои ошибки всегда имеют приоритет.
Дедупликатор
Это работает, в теории. Но это на самом деле не решает исходную проблему «почти каждая сообщаемая ошибка является ошибкой высокого приоритета», пользователь все равно может сообщать о каждой ошибке как о «высокой важности», и в конечном итоге она становится «легкой ошибкой в ​​первую очередь».
RayLuo
3

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

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

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

Ян
источник
3

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

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

Алан Шутко
источник
2

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

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

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

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

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

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

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

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

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

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

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

dwoz
источник
2

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

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

Брэд Томас
источник
1

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

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

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

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

Робби Ди
источник
В JIRA приоритетом по умолчанию для проблем является Major («Значительная потеря функции»)
Карлос Гавидия-Кальдерон
1
@CarlosGavidia Тогда ошибка, казалось бы, с настройкой. Системы ошибок, как правило, настроены на то, чтобы все имело какой-то средний приоритет.
Робби Ди
0

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

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

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

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

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

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

Superbest
источник