Мій бос вирішив додати поле "людина винна" до кожного звіту про помилку. Як я можу переконати його, що це погана ідея?

В одному з останніх кроків "WTF" мій начальник вирішив, що додавання поля "Person To Blame" до нашого шаблона відстеження помилок підвищить відповідальність (хоча у нас вже є спосіб прив’язання помилок до функцій / історій). Мої аргументи про те, що це зменшить моральний стан, збільшить вказівку пальцем і не буде враховувати пропущені / неправильно зрозумілі функції, про які повідомлялося, як помилка залишилася нечуваною.

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

Скажіть їм, що це лише аматорське ім'я для поля « Root Cause», яке використовується професіоналами (коли у трекера випуску немає спеціального поля, ви можете використовувати коментарі до цього).

Шукати в Інтернеті що - щось на зразок аналізу програмного забезпечення помилки першопричини , є багато ресурсів , щоб виправдати ці міркування ^{1 , 2 , 3 , 4 , ...} .

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

Саме тому "першопричина" є професійною, а "людина винна" - аматорською. Особиста підзвітність велика, але бувають випадки, коли вона просто лежить «поза» команди розробників.

Розкажіть свій бос , коли є один розробник винен, кореневе поле причини, безумовно , охоплює , що ( «кодування помилки , допущену Боб зробити 1234, пропустив Джим в огляді 567» ). Сенс використання терміна " першопричина" полягає у висвітленні подібних випадків разом із справами, які виходять за межі команди розробників.

^{Наприклад, якщо помилка була викликана несправним обладнанням (винна особа - хтось поза командою, яка придбала та протестувала її), поле першопричини дозволяє прикрити це, тоді як "один винуватця розробника" просто зламається випуск відстеження потоку.}

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

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

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

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

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

З цього ви зрозумієте, чи регулярно винна одна людина, і це може бути інша проблема.

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

З цим полем є щонайменше три проблеми.

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

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

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

Ще одна помилка метрики програмного забезпечення.

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

Неправильно:

Боб забув перевірити вхід, і програма перестала ділитися на нуль.

Право:

Код, вразливий до помилки поділу на нуль, не був виявлений перед розгортанням. Додано нові тестові випадки для перевірки правильного поводження з недійсним вводом. Код було виправлено, і всі нові тестові справи проходять.

Змініть "Особа винна" на "Людина, яку потрібно хвалити"

Основна особа, яка виправляє помилки, отримує на ній своє ім’я.

Проста відповідь.

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

Що важливіше - постраждати від когось за те, що вона зробила чесну помилку чи якнайшвидше усунула проблему?

Твій бос, здається, вважає, що помилки є ознакою ліні чи неохайності. Їх немає. Вони - факт життя. Скільки патчів Microsoft виштовхує за рік?

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

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

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

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

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

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

Те, що ми зробили, подарувало кожному з інших дизайнерів чверть наших наклейок, щоб у кожного з них були всі кольори, і замість того, щоб наносити лише свій колір на кожен дизайн, ми клали всі чотири кольори дизайнера.

Не просто записуйте своє ім'я у поле [Винуватий] - введіть ім’я кожного, хто є в команді / проекті, і переконайтесь, що вся команда робить те саме.

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

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

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

Це дуже схоже на те, коли Скотт Адамс підкреслив невдалу мудрість Бауд-Баунті, коли Точковий Волос Бос у Ділберті. Уоллі оголосив, що збирається поїхати, і «напиши йому новий міні-фургон».

Комікс «Ділберт» за 13.11.1995 р. З офіційного архіву коміксів «Ділберт».

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

Помилки можуть бути введені в код через погане програмування та поганий дизайн; але вони також можуть стати наслідком написання безлічі складних кодів. Дінгінг людей, які виробляють найбільше помилок, так само є ймовірними для бідних розробників Ding, як і високопродуктивних.

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

Можливо, ви повинні поглянути на це як "Хто найкраще виправити помилку?" Частина мене теж відчуває, ти зламав, ти це виправляєш. Має бути певна відповідальність.

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

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

Дивно, що ніхто про це раніше не згадував: Додавання такої функціональності у програму відстеження помилок мотивує працівників намагатися грати в систему .

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

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

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

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

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

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

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

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

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

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

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

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

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

Пропоноване читання з боку вашого начальника: 7 звичок високоефективних людей

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

Пропоноване читання та / або дослідження з вашого боку:

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

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

Щасти! Я сподіваюся, що вам вдасться пройти це способом, прийнятним для всіх, особливо в ці часи.

РЕДАКТ: Особисто, з власного досвіду ... "Вперед, звинувачуйте мене. Оскільки я досить впевнений, я виправлю це, і по дорозі, коли це повториться, хто буде там, щоб врятувати день? Так, ви здогадався це ... я, з великою олею усмішкою ".

Для підзвітності я не хотів би person to blameполя, я хотів би Person who knows the codeполе чи person who can fixполе, щоб я знав, куди надсилати підтримку.

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

Скажіть йому, що «звинувачення» негативне. Змініть його на "людину виправити", тоді принаймні це буде обрамлено позитивно, і та сама робота все одно буде виконана. Як люди можуть працювати, якщо їх "звинувачують" ?!

Якщо мій начальник зробив таке, то в такому точному порядку:

1) Я б одразу почав шукати нову роботу.

2) Щоразу, коли повідомляється про помилку з винною людиною, там з'явиться ім'я мого начальника, і коментар щодо того, чому за це відповідає поганий процес у команді. І КС це своєму начальнику (бажано в партії). У вас є одиничні тести? Якщо ні, то це означає, що процес розробки порушено, таким чином, помилка. Чи є у вас постійні автоматизовані тестування інтеграції з усіма зовнішніми системами? Тоді процес розроблення порушується, таким чином, помилка. Чи є у вас можливість зробити кожне середовище однаковим у виробництві за допомогою сценарію, щоб не допустити помилок людини? Тоді процес розроблення порушується, таким чином, помилка. Хіба один розробник жахливий? Тоді критерії найму є шкідливими, отже, виною начальника. Чи всі розробники роблять дурні помилки через брак відпочинку, тому що працюють 12 годин на день? Тоді процес розроблення порушується.

Як зауваження: кожен хороший менеджер з розробки знає про те, що я написав вище. І Agile стратегії мають на меті вказати на начальника або його прихильників, чому Dev сповільнюється: Подивіться, ми витрачаємо 50% свого часу на виправлення помилок. Давайте розглянемо стратегії їх зменшення, щоб ми могли витратити 40% часу на виправлення помилок, а потім переглянути цю проблему, отримавши її до 30%. тощо.

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

Схоже, ваш начальник не має глибокого розуміння програмного забезпечення, і, можливо, він теж не має наміру. Тож у нього інша мова, інша культура.

Вихід із роботи за подібну проблему, перш ніж навіть намагатися зробити крок уперед для вирішення, це просто запитання. Вихід - це вихід. Не киньте, поки він не переконається, що ви ніколи не можете зрозуміти один одного. Щоб бути впевненим у цьому, спершу слід спробувати.

Оскільки він не знає нашої мови, а він - начальник, першим кроком тут буде намагання поговорити з ним своєю мовою. Що я маю на увазі з мовою? Давайте подумаємо разом:

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

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

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

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

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

Отже, зосередьтеся на його реальній проблемі: Про помилок. Покажіть йому, що помилки можуть бути дуже корисними. Без проблем стосунки нудні. Все, що тебе не вбиває, робить тебе сильнішим. Кожна помилка - це чудова можливість, яку ви можете використовувати для збільшення щастя клієнта.

Це лише одне, що ви можете сказати. Подумайте про його занепокоєння, і ви знайдете багато інших пунктів, які можна додати до свого списку. ЗОЛОТИЙ КЛЮЧ - запропонувати альтернативну річ, а не боротися зі своєю ідеєю!

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

Я робив набір ще в той день, ось мій взяти на це.

Це як звинувачувати машинопис у неправильних написаннях та інших речах, які коректор повинен був знайти, але пропустив. Набір тексту зробив помилкове написання, але коректор пропустив це, тому винна коректор винна в помилках друку, а не людина, яка помилилася в першу чергу.

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

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

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

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

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

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

Щоб надати босу певну заслугу, поняття "присвоєння звинувачення" вже вкладено в такі інструменти, як SVN , і відповідне використання даних може бути конструктивним для розробників, щоб "дізнатися, з ким спілкуватися" під час налагодження, наприклад: http: / /www.codinghorror.com/blog/2007/11/who-wrote-this-crap.html

Хоча я згоден з вищезгаданою відповіддю gnat, що поле « Root Cause» - це непогана річ, це не та сама інформація, і «денормалізувати» поле, щоб іноді призначити попереднє ім’я розробника для джерела, що постраждало, а іноді мати Технічний опис (наприклад, "не набув масштабу до 10000 користувачів") просто замутить води. Я б виступав за збереження кореневої причиниполе чітко описує технічний опис (наприклад, навіть при явній помилці програміста, чи є в ньому дані про захоплення, такі як "IndexOutOfRange Exception, коли fooData = 999"). Це потенційно може забезпечити корисні відгуки при масовому перегляді та дозволяти вживати певних коригувальних дій. вирішити цілі класи проблем із архітектурними або рамковими змінами (наприклад, поліпшення спеціальних класів контейнерів, передача винятків верхнього рівня)

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

Проблеми з додаванням цього як мети поля / потенційної мети просто почати перераховувати:

1. Помилки дуже мінливі за труднощами вирішення, і проста статистика кількості помилок / розробника цього не відображатиме.
2. Розробники сильно відрізняються за можливостями "" "" "" "" ""
3. У багатьох програмних системах є компоненти, які потребують рефакторингу, проте рефакторинг застарілих компонентів (особливо, якщо в застарілій базі немає / обмежених одиниць тестування) спочатку будуть вводитися помилки. Розробники, швидше за все, не будуть відштовхуватися від цієї "доброї" діяльності, якщо існує стигма / страх, пов'язаний з генеруванням нових помилок (навіть якщо вони є тривіальними для вирішення, а кінцевий результат призведе до значного вдосконалення системи).
4. Тестери можуть подати дуже мінливу кількість помилок, пов’язаних із однією і тією ж проблемою, в результаті чого кількість помилок / розробник може бути дуже перекошеною, якщо не буде зроблений більш детальний аналіз.

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

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

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

Будемо тупими, у вас є думка, як і він. Він ваш менеджер, і його думка - це та, яка виграє.

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

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

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

Поважайте офіс, навіть якщо ви не поважаєте рішення.

Збережіть стрес і стукіт для прийняття рішень, які триватимуть набагато довше.

Скажіть своєму начальникові, що для розвитку в команді потрібні соціальні навички. Він може навіть кивнути.

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

Натомість вам потрібні стимули для вдосконалення соціальних навичок, а комунікаційна інфраструктура, яка у вас є, повинна це підтримувати. Наприклад, придумайте це позитивно: Назвіть особу, яка відповідає за квиток, яка піклується про нього.

Почніть також з огляду коду, щоб ви могли вчитися один у одного. Це позбавляє провини пізніше.

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

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

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

мій начальник вирішив, що додавання поля "Особа до вини" до нашого шаблона відстеження помилок підвищить відповідальність

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

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

То що він має намір? Чи хоче він мати можливість сказати "Покажіть мені всі помилки, які винні в Бобі?" Чому? Або він хоче мати можливість сказати: "Покажіть мені, хто винен більшу частину часу?" Чому? Перший не має сенсу, а другий - лише каральний. Або третій варіант полягає в тому, що у нього немає реальної причини.

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

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

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

Ось у чому справа, як багато хто згадував вище, якщо виникає помилка, це спільна відповідальність: від розробника, до тестерів, до QA, до менеджерів. Якщо ваш начальник в якийсь момент поводиться з роздратованим клієнтом по телефону з такими речами, як " Мені дуже шкода, Джон ніколи цього не перевіряв належним чином ", то я б точно шукав іншу роботу. Хороший начальник повинен піти «ми подбаємо про це». Ні імен, ні вказівки пальцем, просто рішення.

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