Мой босс решил добавить поле «человек виноват» в каждый отчет об ошибке. Как я могу убедить его, что это плохая идея?

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

Какие еще веские аргументы против этой практики я могу использовать? Есть ли какие-либо статьи на эту тему, которыми я могу поделиться с командой и боссом?

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

Искать в Интернете что - то вроде анализа программного обеспечения ошибки первопричины , есть много ресурсов , чтобы оправдать эти рассуждения ^{1 , 2 , 3 , 4 , ...} .

... коренной причиной дефекта не всегда является один разработчик (который является основным пунктом этой области) ...

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

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

^{Например, если ошибка была вызвана неисправным оборудованием (виноват тот, кто был за пределами команды, который приобрел и протестировал его), поле первопричины позволяет это исправить, а «виноват один разработчик» просто сломается выпуск отслеживания потока.}

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

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

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

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

Бесполезно, когда люди кусают и указывают пальцами, пытаясь избежать черной метки, которая не исчезнет, ​​как только она будет установлена. Это ничего не решает. Очень немногие люди злонамеренно небрежны. Вы должны сделать правильную ретроспективу , посмотреть, что пошло не так, и что вы можете сделать, чтобы убедиться, что это снова не пойдет не так.

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

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

Есть как минимум три проблемы в этой области.

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

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

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

Еще один сбой метрики программного обеспечения.

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

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

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

Правильно:

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

Измените "Человек, чтобы обвинить" в "Человек, чтобы похвалить"

Основной человек, который исправит ошибки, получит свое имя.

Простой ответ

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

Что важнее, жертва кого-то за честную ошибку или решение проблемы как можно быстрее?

Ваш босс, кажется, считает, что ошибки - признак лени или разгильдяйства. Они не. Это факт жизни. Сколько патчей Microsoft выпускает за год?

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

Другой вариант: подыграть. Не делайте ничего конкретного - просто хорошо поработайте и заполните поле как можно точнее в течение нескольких месяцев. Затем объясните боссу, что назначение вины за каждую ошибку делает всех в команде несчастными и неудобными. Скажите ему, что вы все чувствуете, что есть небольшая корреляция между созданными ошибками и чем-либо еще (навыком, усилием, здравомыслием). (Это поможет, если вы можете запустить некоторые цифры, которые показывают, что на самом деле нет корреляции.)

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

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

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

Заявленная цель босса для «инициативы по наклейке» состояла в том, чтобы установить источник всех ошибок нашего отдела (ошибки в оформлении документов, неправильная подача документов, плохая копия, по существу, печатный эквивалент ошибок)

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

Не просто напишите свое имя в поле [Обвинение] - напишите имя каждого участника команды / проекта и убедитесь, что вся команда делает то же самое.

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

Это приведет к наказанию его самого плодовитого программиста. Скорее всего, один или два человека могут быть лучшими сотрудниками, которые работали над большинством проектов. Если у вас в отделе из 10 человек есть один кодер, который является источником информации и он написал 60% кода интерфейса, то 60% ошибок будут в его коде.

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

Это звучит очень похоже на то, когда Скотт Адамс указал на неудавшуюся мудрость Бага Баунти, когда заостренный босс в Дилберте. Уолли объявил, что собирается пойти и «написать ему новый мини-ван».

Комикс Дилберта за 13.11.1995 из официального архива комиксов Дилберта.

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

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

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

Может быть, вы должны смотреть на это как "Кто в лучшем положении, чтобы исправить ошибку?" Часть меня тоже чувствует, что ты сломал это, ты исправил это. Должна быть некоторая ответственность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предлагаемое чтение со стороны вашего босса: 7 навыков высокоэффективных людей

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

Предлагаемое чтение и / или исследование с вашей стороны:

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

Прямо сейчас не похоже, что он готов что-то исправить, потому что у него нет четкого понимания того, что сломано, если вообще что-то сломано - кроме его менталитета «я хозяин».

Удачи! Я надеюсь, что вам удастся пройти через это приемлемым для всех способом, особенно в наше время.

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

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

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

Скажите ему, что «вина» отрицательна. Измените его на «человек, чтобы исправить», тогда, по крайней мере, это оформлено в позитивном ключе, и та же самая работа по-прежнему выполняется. Как люди могут работать, если их "обвиняют" ?!

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

1) Я бы сразу начал искать новую работу.

2) Каждый раз, когда сообщается об ошибке, в которой виноват какой-либо человек, там появляется имя моего босса и комментарий о том, почему за это ответственен плохой процесс в команде. И CC это его боссу (желательно в партии). У вас есть юнит-тесты? Если нет, то это означает, что процесс разработки нарушен, таким образом, ошибка. У вас есть постоянное автоматизированное интеграционное тестирование со всеми внешними системами? Тогда процесс разработки нарушается, таким образом, ошибка. У вас есть возможность сделать каждую среду идентичной в рабочей среде с помощью сценария, чтобы не допустить человеческой ошибки? Тогда процесс разработки нарушается, таким образом, ошибка. Один разработчик ужасен? Тогда критерии найма плохие, то есть вина босса. Все разработчики делают глупые ошибки из-за нехватки отдыха, потому что они работают 12 часов в день? Тогда процесс разработки нарушается.

В качестве примечания: каждый хороший менеджер по разработке знает о том, что я написал выше. А Agile-стратегии призваны указать боссу или его сторонникам, почему dev замедляется: посмотрите, мы тратим 50% нашего времени на исправление ошибок. Давайте посмотрим на стратегии по их уменьшению, чтобы мы могли тратить 40% времени на исправление ошибок, а затем снова обратимся к этой проблеме, получив 30%. и т.п.

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

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

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

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

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

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

Чтобы «увеличить прибыль от ошибок», вы должны предложить сделать отчеты об ошибках еще более открытыми. С каждым отчетом об ошибках и его быстрым, чистым, хорошим решением клиенты чувствуют и видят, что «вау, эти ребята потрясающие! Они работают очень усердно. Посмотрите на эти вещи, которые они решают. Мы даже не знали, что программное обеспечение было таким сложным». вещь!" бла бла и бла ...

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

Командная этика, эффективность или любые разговоры, которые вы бы сделали, могли бы работать противоположным образом, как вы планировали. Если вы хотите выйти, он подумает: «Ага, мое решение начало работать с самого первого дня! Плохие ссылки уже начали сбрасываться сами по себе, прежде чем они были раскрыты!» Он верит в свою идею найти плохих парней в компании, и очень трудно убедить его в обратном. Особенно, когда ты можешь быть одним из тех плохих парней!

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

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

Если вы делаете Agile, и это звучит так, как будто вы из комментария к функциям / историям . Человек виноват бы быть QA человек , который пусть ошибка проскочить, или продукт Владелец / Клиент , который принял функции / историю как завершенное с ошибкой в нем.

Я сделал набор в те дни, вот мое мнение.

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

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

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

Использование тестовой разработки и настройка сервера непрерывной интеграции (например, Jenkins ) помогут решить эту проблему, не вводя «игру вину». Для этого важен сервер непрерывной интеграции, потому что, когда кто-то фиксирует код, который «нарушает сборку», электронная почта отправляется команде, показывающей виновного. Поскольку этот код не был выпущен в производственную среду, этот тип обвинений является более активным и поощряющим (и интересным!).

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

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

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

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

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

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

Проблемы с добавлением этого в качестве поля ошибки / потенциальной метрики легко начать перечислять:

1. Ошибки могут варьироваться по сложности, и простая статистика количества ошибок / разработчик не будет отражать это.
2. Разработчики сильно различаются по возможностям "" "" "" "" "" "
3. Многие программные системы имеют компоненты, которые нуждаются в рефакторинге, однако рефакторинг устаревших компонентов (особенно, если у устаревшей базы нет / ограниченные возможности модульного тестирования) первоначально будет приводить к ошибкам. Разработчики, скорее всего, будут обескуражены этой «хорошей» деятельностью, если есть стигма / страх, связанные с созданием новых ошибок (даже если они тривиальны для устранения, и в результате это приводит к значительному улучшению системы).
4. Тестеры могут подавать очень изменяющееся количество ошибок, связанных с одной и той же проблемой, что приводит к сильно искаженному числу ошибок / разработчику, если не будет проведен более подробный анализ.

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

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

Просто отпусти. Ваш босс сам обнаружит, что это вызывает проблемы, если это так.

Давайте будем тупыми, у вас есть мнение и он тоже. Он твой менеджер, и его мнение побеждает.

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

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

В тот момент, когда это действительно имеет значение, вы не хотите, чтобы начальник помнил, что вы были тем человеком, который активно саботировал его идею «обвинять человека».

Уважайте офис, даже если вы не уважаете решение.

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

Скажите своему боссу, что развитие в команде требует социальных навыков. Он может даже кивнуть.

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

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

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

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

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

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

мой босс решил, что добавление поля «Person To Blame» в наш шаблон отслеживания ошибок увеличит ответственность

По моему опыту, когда руководство хочет «сделать людей более ответственными», они имеют в виду, что хотят быть в состоянии наказать за неудачу. Будь то увольнение плохих исполнителей или просто увольнение в годовом отчете о зарплате («Извините, Боб, у вас 17 ошибок, помеченных как ваша вина, и это превышает предел 15»), это наказание.

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

Так что он намерен? Он хочет сказать: «Покажи мне все ошибки, в которых виноват Боб?» Почему? Или он хочет сказать: «Покажи мне, кто виноват большую часть времени?» Почему? Первый не имеет смысла, а второй только карательный. Или третий вариант - у него нет реальной причины.

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

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

С точки зрения разработки, «обвинение» уже включено в основной инструмент, такой как SVN, поэтому я действительно не вижу никакого вреда в том, чтобы сказать «Джон, пожалуйста, исправь ту чушь, которую ты написал» и поставив имя рядом с Это. JIRA также включает в себя имя человека, когда вы сообщаете об ошибке (однако это поле на самом деле не предназначено для человека, который несет за него ответственность, скорее всего, чтобы кто-то это исправил).

Но вот в чем дело, как многие упоминали выше, многие, если возникает ошибка, это общая ответственность: от разработчика, до тестеров, до QA, до менеджеров. Если ваш босс в какой-то момент обращается с раздраженным клиентом по телефону с такими вещами, как « извините, Джон никогда не проверял это должным образом », то я бы определенно искал другую работу. Хороший босс должен сказать: «Мы позаботимся об этом». Никаких имен, никаких указаний, только решения.

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