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


694

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

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


79
Эй, ребята, я «босс», который представил поле WTF. Вот почему я добавил поле «Peson to Blame» в нашу систему отслеживания ошибок: news.ycombinator.com/item?id=4179298
Jason

98
«Могу ли я назвать это чем-то более политически корректным, чтобы чувство не пострадало? Конечно. Но что в этом забавного? Цель состояла в том, чтобы повысить осведомленность о количестве производственных ошибок после каждого выпуска, так почему бы не добавить небольшую дозу публичного позора для хорошей меры? И чтобы быть ясным, цель области, и в конечном счете цель метрики, не состоит в том, чтобы точно определить причину ошибки. Дерьмо случается, и у нас есть более важные дела. Конечная цель метрика является напоминанием для каждого разработчика быть лучше каждый день ". --- Я думаю, что все эти "причины" по своей сути неверны.
ulty4life

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

68
@Jason Ошибка в коде, а не в разработчике. Вы должны быть одним из тех людей, которые думают, что обзоры кода предназначены для обзора разработчиков, а не кода.
Дэнни Варод

81
Ваш босс - "человек, который виноват", всегда
пишите

Ответы:


675

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

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


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

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

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

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

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


13
Это хороший момент. Тем не менее, основной причиной дефекта не всегда является один разработчик (что является основным пунктом этой области). В результате, идентификация одного разработчика, ответственного за дефект, приносит больше вреда, чем пользы, IMO.
MK_Dev

326
+1 за перенаправление идеи босса во что-то более продуктивное (всегда легче выиграть битву таким образом)
benzado

16
«Основная причина» также охватывает (мы надеемся, что большинство!) Случаи, когда никто не виноват, например, «сбой программного обеспечения поставщика», «ошибка документации API», «больший объем, чем ожидалось».
Джеймс Андерсон

29
Отлично. Даже в вашем примере для одного ответственного человека фигурируют два человека, прекрасно иллюстрирующие глупость этого упражнения.
Урс Рупке

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

272

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


300
Ну, босс будет счастлив! Будет меньше сообщений об ошибках, и, следовательно, качество должно повыситься.
nicodemus13

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

54
По опыту, это не «вероятный» результат, он на 100% уверен, что это произойдет, потому что разработчики - умные люди. То, что вы также увидите, это значительное увеличение времени, которое яростно спорил с тестировщиками, что их «ошибки» не являются ошибками.
Йорис Тиммерманс

Человек, сообщающий root causeоб ошибке, вряд ли будет тем человеком, который, я имею в виду, думает о попытке найти ошибку в вашем собственном коде после 36 часов написания кода на этой неделе?
Малахия

141

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

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

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

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

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


5
Действительно хороший процесс позволяет избежать того, чтобы аналитик и программист были двумя разными людьми - мой опыт работы с аналитиками, которые не могут программировать, и программистами, которые не могут анализировать, был действительно плохим. Тем не менее +1 за ваш ответ.
Док Браун

@DocBrown хорошо, мой опыт работы с аналитиком и программистом, состоящим из двух разных людей, до сих пор был довольно позитивным. Хотя в моем случае это были скорее аналитики, которые могут понять логику программы, и программисты, которые могут участвовать в анализе :)
gnat

@gnat: ИМХО, если аналитик, являющийся одним из программистов в вашей команде, может на порядок увеличить вашу скорость и качество разработки.
Док Браун

3
Эта книга поможет вам найти слова, чтобы отстаивать свои позиции amazon.com/The-Power-Positive-No-Relationship/dp/0553384260/…
zundarz

2
Ссылка для "предлагай это бесплатно" не работает.
Том Фобер,

79

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

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

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

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

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


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

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

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

68

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

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

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

Правильно:

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


6
Еще лучше: обновлены руководящие принципы / стандарты кодирования и контрольные списки проверки кода, чтобы избежать повторения этого.
Странное мышление

Так что, если ошибки неизбежны? Что плохого в том, чтобы обвинять кого-то в них? Я думаю, что ваш вариант «Wrong:» более понятен, чем ваш вариант «Right:». Неправильный действительно простой. Правильно: один многословный.
Адам Брусс

3
@ Адам: не отвечает ли мой ответ прямо на ваш точный вопрос "Что плохого в том, чтобы обвинять кого-то ...?"
Кевин Клайн

54

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

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


9
Я не думаю, что это отвечает на вопрос. Это хорошее настроение, но оно не дает аргументов против такого поля.
Брайан Оукли

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

Очень часто вы хотите знать, кто написал код и кто лучше всех его исправит, если он пойдет не так. Часть обратной реакции «человек виноват» в том, что он подразумевает, что кто-то обвиняется.
Муз

49

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

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

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

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


8
+1, культура вины всегда ведет к культуре
молчания

45

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

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

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


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

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

3
Кроме того, команда все еще будет страдать. Все только для того, чтобы доказать, что босс был неправ?
Волков Олег Викторович

29
Я всегда ставлю там имя менеджера. «В любой организации работа опускается на дно, а ответственность - на верх».
Дэвид Шмитт

3
@ Давид: и крем и мразь всплывают наверх. Чем вы занимаетесь в своей организации?
Донал Феллоуз

32

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

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

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

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

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

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


1
Твоя была забавная история и почти отвечает на вопрос. Вы могли бы рассмотреть настройку тона и словоблудия для более позитивного чтения. В противном случае, вы будете продолжать получать отрицательный голос. (Я проголосовал за ваш ответ.)
Эвик Джеймс

20

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

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


20

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

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

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

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

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


19

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

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

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


19

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

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

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


18

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

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

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

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

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

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

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


+1 за предложение объяснить положительно, как управлять информационными работниками, а не просто атаковать эту идею.
Странно,

14

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

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

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

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

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

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

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

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

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

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

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


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

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

10

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

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


9

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


2
Вы не можете "исправить человека" ...
SandRock

1
У нас есть поле "человек, чтобы исправить". Это не достаточно
MK_Dev

9

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

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

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

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

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


8

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

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

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

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

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

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

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

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

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

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


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

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

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

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

@hasanyasin О доброте жучка - это отлично! Мне грустно, я не могу поставить два возражения! Я тоже буду этим пользоваться!
Гангнус

8

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

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

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

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


3
Что еще хуже, разработчики теперь тоже QA. Я знаю ...
MK_Dev

Какое тревожное отношение.
фунтовые

1
Делая проворный, вся команда - "человек, чтобы обвинить". Agile ценности объединяют людей, и вся команда разрабатывает приложение, поэтому каждая ошибка - это проблема всей команды. Подумайте о ситуации, когда на CI-сервере происходит сбой сборки. Вся команда должна перестать работать и посмотреть, что нужно сделать. По крайней мере, так и должно быть!
Sgoettschkes

@Sgoettschkes Теоретически я согласен с вами на 100%, за продукт, который производится, отвечает команда в целом. Но если вы пытаетесь выделить конкретного человека, люди, проверяющие работу, являются более ответственными за то, что она проскользнула.

7

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

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

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


Я согласен с вашим первым утверждением 100%. Это были мои слова, когда я говорил о проблеме.
MK_Dev

7

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

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


6

Чтобы отдать должное боссу, понятие «назначение вины» уже внедрено в такие инструменты, как 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, неверными ожидаемыми результатами в тестах и ​​проблемами «ранее в цепочке» с неверными / отсутствующими требованиями, и должно быть очевидно, что подобный показатель обречен как бесполезный (если только цель состоит в том, чтобы повредить моральный дух и вызвать массовый исход.)

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


6

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

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

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

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

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

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

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


+1 за разумное решение (хотя я добавил собственный ответ) :-)
Homer6

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

5

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

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

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

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


Напомните ему, что в большинстве случаев он может быть виноват. Время, член команды, управляемые приоритеты, выбранные / одобренные инструменты ...
BillThor

О, чувак, я знаю разработчиков. Они часто ищут причину кем-то другим. И они не стесняются спорить. Я бы сказал, что разработчики должны активно искать возможности улучшить свои социальные навыки и подотчетность. Поле обвинений может быть только симптомом того, что в процессе разработки что-то идет не так. Бьюсь об заклад, разработчики несут ответственность за эту проблему. Менеджер тоже, похоже, ошибки растут над их головами. Поэтому им лучше провести некоторый анализ, почему Bugrate поставил их вне сфокусированного развития.
hakre

4
-1 для предположения, что developer == no social skills. Два совершенно не связаны. Вы можете быть хорошими в одном или обоих, и быть плохими в одном или обоих, и нет никакой связи.
Дениф

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

@hakre: Если это тот случай, когда он работает, то это только потому, что более ловкие ушли из компании из-за руководства
Daenyth

2

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

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


1

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

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

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

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

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

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


-3

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

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.