Майже кожна повідомляється про помилку є першочерговою помилкою [закрито]

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

Отже, я хотів дізнатись, чи є ця проблема частою чи мені просто невдача. Я здійснив швидкий пошук у Google, і виявив, що деякі команди застосовують вказівки щодо звітування про помилки або мають окрему команду "Помилка помилок". Якщо ви зіткнулися і вирішили це питання, який підхід працював для вас?

Це питання конкретно стосується проблеми "Пріоритетна інфляція": Якщо ви стикаєтесь зі сценарієм та які вимірювання приводять до ефективної проти цієї проблеми.

Я запитав деяких колег про те, що це може статися, і вони зазначили, що якщо помилка не має такого рівня пріоритетності, дуже рідко помилка привертає увагу розробника, що справді має сенс

Насправді, якщо ви запитаєте мене, це не так. Чим більше (використаних) рівнів пріоритетності, тим більше інформації ви маєте. Якщо ви маєте лише один пріоритет, це те саме, що взагалі не має пріоритету.

А оскільки у вас ще є однакова кількість помилок, з якою потрібно боротися, і стільки ж способів, як це зробити, то випливає, що буде використано ще якесь евристичне, можливо, нульове - «перший прийшов, вперше послужив». Отже, тепер у вас є показник пріоритету помилки, за винятком того, що час приїзду не перебуває під вашим контролем.

Це може бути симптомом недостатнього розподілу ресурсів для виправлення помилок (є деякі політики, такі як " Немає нових функцій, поки помилки не виправлені ", які можуть допомогти там. Джоел схвалює ; розуміння меж та наслідків є бізнес-рішенням ).

В одному з проектів, над якими я працював, вхідні помилки накопичувались у "буфері без пріоритету", і кожного понеділка ми переглядали список помилок, оцінювали складність (дуже приблизна оцінка; частіше за все ми просто вводили "Середнє значення") та сортуйте їх за доступним часом. Це, як правило, стикається зі списком нудних, нецікавих або важких помилок; щоб компенсувати це, наглядачі та маркетинг мали певну кількість кредитів на тиждень, які вони могли витратити, щоб збільшити пріоритет улюблених помилок, і їм було відшкодовано за невирішені помилки (це встановило обмеження на те, скільки помилок, зневірених розробником, може бути відкладено) .

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

Після декількох торгувань у нас був список завдань тижня, який розділився на "зробимо", "може зробити" і "не можу", які були зіткнулися на наступному тижні. Ось тут і з'явилися додаткові торгування: нам було сказано, що п’ятдесят годин виділяються на помилки, і ми були на 95% впевнені, щоб виправити перші двадцять. Керівництво дуже хотіло виправити помилку в двадцять першому і не залишилось кредитів; Тоді ми пропонуємо поміняти цю помилку на одну зі списку "Зробимо", або хтось скаже "Відірвіть мене від підтеми FooBazFeature на пару днів, і я це зроблю", або ми б сказали "Нам потрібно більше робоча сила ».

Система насправді нікого не влаштовувала, але це вважалося (принаймні серед розробників) хорошим знаком.

Деякі додаткові негативні зразки, які з’явилися, були "Бажаним мисленням" з боку менеджерів ("Ви заявили, що помилка 57212 вимагає вісім годин. Це неприпустимо. Зробіть чотири") та "Налагодження Фіат" ("Робіть все, що завгодно) але ці сорок помилок повинні бути виправлені до великої демонстрації на наступному тижні. Ви не можете мати більше часу, не можете мати більше людей "). Також синдром боксера ("я буду працювати більше"), який, як правило, працював дуже короткий час , але, як правило, призводив до того, що забудовник вибухнув або покинув зелені пасовища.

Якщо у вас є ця проблема, коли користувачі присвоюють все більш високі пріоритетні помилки, єдиним реалістичним рішенням є триадний механізм. Про всі помилки надходять повідомлення з будь-яким пріоритетом, але якийсь поганий менеджер повинен буде пройти кожну нещодавно повідомлену помилку та скинути її пріоритет на чутливий рівень.

Через деякий час ваші користувачі отримають повідомлення, або ви можете змінити систему звітності, щоб кожна помилка мала пріоритет за замовчуванням. Якщо вони захочуть, щоби це наростало, їм доведеться зв’язатися з кимось, щоб зіткнутися з цим, що вимагатиме певного обгрунтування. Тільки цей факт призведе до того, що користувач не може ескалювати 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. Дуже пріоритетний ультра супер мега.

тощо.

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

В основному є два способи протистояти цьому:

1. Відведіть контроль від клієнта щодо рівнів пріоритетності.
2. Пов’язати вартість клієнта для підвищеного рівня пріоритетності.

До системи можна додати більш високі та більш високі рівні пріоритетності, особливо якщо це Джира. Надання нових високих пріоритетів дедалі дурнішим, але грізним іменам може збільшити вплив ефекту Хоторн на якість вибору пріоритету, зробленого усіма сторонами. Якщо найвищий пріоритет має дійсно чужу назву, ефект може бути постійним. Врешті-решт, коли хтось обирає пріоритет, він повинен зважувати соціальні наслідки вибору пріоритету "помилка смерті" проти отримання належної уваги. Отже, найвищий пріоритет - це фактично зарезервований для чогось, що трапилось із СОТ вдома перед його гостями, або інших випадків рівнозначної видимості.

Введіть витрати на підтримку запитів. Ви можете дозволити користувачеві повідомляти лише X кількість елементів з високим пріоритетом за певний проміжок часу, Y кількість елементів середнього пріоритету та Z низький пріоритет.

Звичайно, це також означає, що команда розробників та керівництво повинні будуть потім гарантувати, що певна кількість таких дійсно буде виправлена ​​- всі пункти з високим пріоритетом, більшість предметів із середнім пріоритетом та (можливо) деякі з пункти з низьким пріоритетом протягом певного періоду часу.

Але якщо це буде спрацьовувати, керівництву насправді доведеться купувати його, інакше ціла вправа - це марна трата часу.

Зрештою, ваша конкретна ситуація, як видається, є симптомом проблеми, що ваше керівництво не виділяє достатньо ресурсів для вирішення проблем підтримки. Якби питання вирішувались своєчасно, я не думаю, що це відбудеться.

Щось подібне було реалізовано в першій компанії, над якою я працював, оскільки процес підтримки був нефункціональним і призвів до ситуації, коли, якщо все є надзвичайною ситуацією, нічого не буде. У нашому випадку, після отримання внутрішньої ситуації під контроль, новий менеджер з розробки програмного забезпечення поставив жорсткий ліміт на кількість найвищих пріоритетних питань, які клієнт може подати залежно від того, скільки він заплатив у контрактах на підтримку. Якщо вони перевищували ліміт, або кашлювали більше грошових коштів, або питання підтримки було знижено у пріоритеті.

Це трапляється вкрай часто у великих корпораціях, де ІТ розглядають як допоміжні та / або переносять аутсорсинг. Ділові люди не розуміють програмне забезпечення і їм не байдуже, все, що їх хвилює, - це те, що "їх" помилка виправляється вчора, незалежно від того, наскільки це не критично. Вони не усвідомлюють і не піклуються про те, що сотні інших користувачів також подають помилки, і команда, можливо, 5 розробників доступна для виправлення речей.

Це посилюється поганим управлінням, особливо менеджерами, які не стосуються ІТ, які не можуть сказати "ні" або просто дозволяють діловим людям визначати пріоритет помилок. (У будь-якому випадку зазначений менеджер не виконує свою роботу.) Більшість менеджерів надають пріоритет помилку, з якою вони востаннє зв’язувалися, оскільки "це терміново"; чистий результат полягає в тому, що розробники закінчують стрибати з помилки на помилку, таким чином виправлення однієї помилки займає більше часу (переключення контексту), і в кінці дня всі незадоволені. "Коли кожна помилка - це помилка з високим пріоритетом, жодна помилка не має високого пріоритету."

Я був у цій ситуації, і взагалі єдиний спосіб уникнути цього - це вибратися. Настанови щодо звітування про помилки завжди ігноруються, оскільки користувачі не дають ** t. Спробі впровадити триагу помилок будуть або протидіяти, або вона буде реалізована, а потім ігнорується наступного разу, коли користувач зателефонує вашому менеджеру, щоб поскаржитися на "їх" помилку.

В основному, якщо розробники не контролюють пріоритет , ви вже програли.

Як компанія, ви хочете вирішити питання з найвищим співвідношенням важливості / вартості. Користувачі вирішують важливість, інженерія визначає вартість. Якщо користувачі надають однакове значення для всіх помилок, то вартість має значення лише одна.

На практиці це означає, що ви визначаєте пріоритет як важливість / вартість і не дозволяєте користувачам або розробникам встановлювати цей пріоритет безпосередньо. Жодна сторона не має повної картини.

Якщо користувачі вирішили оцінити всі питання однаково важливими, це добре - але це означає, що інженерія (вартість) вирішує, що робити. Поясніть їм, що важливість - це єдиний спосіб, яким вони можуть впливати (але не визначати) пріоритет.

Кілька факторів ...

• Часто людина, яка повідомляє про помилку, не знає більшої картини і не може вирішити, наскільки ця помилка значна.
• Часто помилки з низьким пріоритетом ніколи не спрацьовують і не розглядаються, тому краще надати пріоритет, який є занадто високим, і нехай людина, яка робить тріаду, знизить його.
• Як я, розробник, я часто переглядав звіт про помилку і виявляв, що за помилкою стоїть дуже пріоритетна проблема, але менеджер продуктів, що робить триаж, не піклується про помилку.

Тому я думаю, що всі звіти про помилки потрібно розглядати ШВИДКО від одного до двох досвідчених розробників, додаючи свої думки до звіту про помилки, тоді помилку потрібно тримати. Очікувати, що людина, яка виявить помилку, зможе встановити корисний пріоритет у той момент, коли вони її знайдуть, просто запитує занадто багато.

Цілком можливо, що всі згадані помилки мають високий пріоритет. Я працював над проектами, які були недостатньо профінансовані та недооцінені, і коли тестування розпочалося, QA, і користувачі просто відмовилися від повідомлення про позиції з низьким рівнем пріоритетності, тому що вони знали, що орфографічні помилки або збої в застосуванні є марною витратою часу, якщо основна функціональність проекту був повністю шлангом. Якщо ваша автоматизована система багажу розбиває візки разом і знищує багаж , кого хвилює, чи шрифт на тегах 2pt занадто маленький?

У такій ситуації проект провалюється. Якщо ви підозрюєте, що це навіть можлива можливість, вам потрібно по душі людям, які повідомляють про дефекти, щоб з’ясувати це. Якщо люди наповнюють повідомлення про помилки, то інші відповіді допоможуть. Якщо помилки такі ж погані, як повідомлялося, тоді вам потрібно вжити крайніх заходів .

Більшість вже було сказано, але я перенаправляю список "помилок зоопарку" до чогось менш деталізованого:

A: Помилка зупиняє користувача мертвим у її слідах, дає неправильний вихід, як правило, робить систему / функцію / функцію непридатною. Це помилка "високого пріоритету".

Б: Все інше. Це "переговорні" помилки.

Помилки NEGOTIABLE підпадають під різні проблеми (які ви розміщуєте у своєму конкретному порядку):

1: Помилки, які впливають на безпеку;

2: Помилки, які впливають на зручність використання (придатність за призначенням);

3: помилки, що впливають на естетику;

4: Помилки, які впливають на продуктивність (можливо, підмножина зручності використання);

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

6: помилки, які зменшують ДОСТУПНІСТЬ КОРИСТУВАЧА;

Отже, це утопічний світ, в якому насправді ніхто не живе. Зітхнення Для завершення моєї відповіді на поставлене питання ОП у всій індустрії програмного забезпечення вкрай звичайно, щоб зусилля з розробки були в стані, коли кожна помилка є пріоритетним, один-супер-чубчик-особливий. І ви знаєте, що кажуть про "особливих": коли всі особливі, ніхто не особливий.

В основному це питання вкорінено в проблемі децентралізації пріоритетності. Завжди має бути непарна кількість людей, які мають можливість визначити пріоритет навантаження в команді, а 3 - це занадто багато. Так що 1 людина відповідає за ефективне перевезення. І це повинен бути менеджер / аналітик, консультуючись із розробником / архітектором. І процес досить простий, і його можна застосувати і до запитів на функції. Яка вартість розробки? Яке значення очікуваного результату для бізнесу. Висновок цієї функції - призначений пріоритет.

З КУРСУ кожен користувач хоче спочатку виправити свою проблему. І як тільки ви дозволите це, хаос. У вас немає дійсної пріоритетності. Це потрібно зробити єдиною особою, яка має повноваження (консультується з іншими, де це необхідно), яка має ВІДОМОСТІ ВСІХ питань та потреб бізнесу, і достатньо компетентна для збору необхідних консультацій щодо ділових та ІТ-експертів і тим самим генерує досить точні оцінки показників. вище.

Ризикуючи сказати очевидним, я буду вважати, що не існує програмного забезпечення для відстеження помилок, яке встановлює помилки як високий пріоритет як за замовчуванням (або було встановлено для цього налаштування).

Я боюся, що за відсутності контролю це сценарій за замовчуванням для декількох команд, клієнтів тощо. Звіт про те, якщо зловживання статусом зловживається, то певний процес тріади, безумовно, в порядку.

Швидка перемога, яку я бачив, що працювала дуже добре в минулому, - це те, що P1 (помилки з найвищим пріоритетом) породила безліч попереджень управління. Якщо система зловживала, вона негайно стискається. Або якщо це справді терміново, трапляється конференція або фізична зустріч, щоб вирішити цю проблему якнайшвидше.

Я припускаю, що ви говорите про всі помилки, а не лише про початкові розробки. Якщо ви, як правило, наймаєте пістолет для розробки зеленого поля, то, звичайно, незвично, що більшість помилок мають високий пріоритет після початкового випуску альфа.

Ви не можете просто мати пріоритет і очікувати, що все магічно вийде. Іноді люди розуміють це самостійно, але не завжди.

Щоб правильно призначити пріоритети, повинно бути визначено, що саме становить кожен пріоритет. Ці критерії повинні бути об'єктивними, щоб уникнути фаворитизму помилок та політичної пріоритетності. Якщо об'єктивні критерії не дотримуються, потрібно змусити команду слідувати цьому.

Насправді цього не обійтися - якщо у вас немає об'єктивних критеріїв того, яка помилка куди йде, і якщо люди навмисно відмовляються виконувати ці критерії, то ви можете також не мати пріоритетів, призначених представникам - або без пріоритетів, або мати третя сторона призначає пріоритет, як пропонували інші. Дані, що перебувають у грудному ресурсі, працюють лише в тому випадку, якщо відправники співпрацюють і не активно саботують збір даних.

Якщо складність виникає з-за неможливості створити об'єктивні критерії, ви можете використовувати відносні критерії:

• Майте просту чергу з усіма помилками. Користувачі можуть вставити помилки в будь-яку чергу черги. Вони повинні вставлятись у задану позицію, лише якщо вони вважають, що їх помилка важливіша за все, що знаходиться під нею. Виправники помилок починаються з верхньої частини черги.
• Припускаючи, що у вас вже є набір добре класифікованих помилок, скажіть всім, що умовою для визначення помилки в пріоритеті Xє те, що вона повинна бути важливішою за всі помилки, що мають пріоритет X-1.
• Повідомте заявникам, що кількість помилок із пріоритетом не Xможе перевищити кількість помилок із пріоритетом X-1.

Але це здається, що вашою проблемою є не визначення, а віра серед представників, що помилки з низьким пріоритетом не виправляються. Імовірно, ви не можете переконати їх в іншому, оскільки (з того, що ви говорите) їхня переконаність обґрунтована фактично. Тоді, чому ви змушуєте їх надсилати ці помилки? Це закінчується не що інше, як насичена робота. Наприклад, ви зможете, наприклад, після того, як буде досягнуто певної кількості активних помилок, сказати всім не турбуватися робити звіти, якщо вони не вважають, що знайшли щось важливіше, ніж більшість непогашених помилок. Звичайно, це лише рішення черги з верхньою межею щодо довжини черги.