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

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

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

672 голоса | спросил MK_Dev 28 J0000006Europe/Moscow 2012, 23:34:05

28 ответов


657

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

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


  

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

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

Расскажите своему боссу, когда там есть один разработчик виноват, поле первопричины наверняка покроет эту ошибку ( ", допущенную Бобом в фиксации 1234, пропущенная Джимом в обзоре 567" ). Точка использования термина root cause должна охватывать такие случаи, вдоль , с случаями, выходящими за рамки команды разработчиков.

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

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

ответил gnat 28 J0000006Europe/Moscow 2012, 23:58:12
262

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

ответил Laurent Parenteau 29 J0000006Europe/Moscow 2012, 00:32:21
138

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

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

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

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

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

ответил pdr 28 J0000006Europe/Moscow 2012, 23:43:58
76

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

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

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

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

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

ответил ptyx 29 J0000006Europe/Moscow 2012, 02:38:59
67

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

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

  

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

Справа:

  

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

ответил kevin cline 29 J0000006Europe/Moscow 2012, 01:30:26
52

Измените «Человек виноват» на «Человек, который хвалит»

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

ответил Darknight 29 J0000006Europe/Moscow 2012, 14:37:46
48

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

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

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

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

ответил GordonM 29 J0000006Europe/Moscow 2012, 00:11:09
45

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

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

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

ответил Caleb 29 J0000006Europe/Moscow 2012, 00:02:15
31

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

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

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

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

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

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

ответил fifthestei8ht 29 J0000006Europe/Moscow 2012, 19:27:36
20

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

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

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

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

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

ответил Mark Hancock 29 J0000006Europe/Moscow 2012, 03:44:41
19

Возможно, вам стоит взглянуть на это как «Кто в лучшем положении, чтобы исправить ошибку?» Часть меня также чувствует, вы сломали ее, вы ее исправите. Должна быть какая-то ответственность.

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

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

ответил JeffO 28 J0000006Europe/Moscow 2012, 23:43:44
19

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

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

ответил Bill B 29 J0000006Europe/Moscow 2012, 18:44:36
19

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

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

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

ответил vsz 29 J0000006Europe/Moscow 2012, 18:31:11
18

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

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

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

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

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

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

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

ответил psr 29 J0000006Europe/Moscow 2012, 02:03:25
14

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

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

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

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

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

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

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

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

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

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

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

ответил tahwos 29 J0000006Europe/Moscow 2012, 19:12:00
10

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

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

ответил Malachi 28 thEurope/Moscowp30Europe/Moscow09bEurope/MoscowFri, 28 Sep 2012 22:26:51 +0400 2012, 22:26:51
9

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

ответил José 29 J0000006Europe/Moscow 2012, 14:48:13
9

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

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

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

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

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

ответил Dmitriy Likhten 1 J000000Sunday12 2012, 09:51:39
8

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

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

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

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

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

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

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

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

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

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

ответил hasanyasin 29 J0000006Europe/Moscow 2012, 05:04:06
8

Если вы выполняете Agile, и похоже, что вы используете комментарий features /stories . Лицо , которое обвиняет , будет лицом, ответственным за качество, которое пропустит ошибку, или Владелец /Клиент продукта, который признал эту функцию /историю в полном объеме с ошибкой в ​​ней.

Я делал набор верстки в тот же день, вот мой подход к нему.

  

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

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

ответил Jarrod Roberson 29 J0000006Europe/Moscow 2012, 04:43:44
7

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

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

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

ответил Andrew 29 J0000006Europe/Moscow 2012, 20:58:56
7

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

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

ответил Dawood ibn Kareem 2 J000000Monday12 2012, 09:23:02
6

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

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

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

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

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

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

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

ответил holtavolt 29 J0000006Europe/Moscow 2012, 20:00:59
6

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

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

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

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

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

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

Сохраните стресс и стол, забирая решения, которые будут намного более длительными.

ответил Pat 30 J0000006Europe/Moscow 2012, 11:55:33
5

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

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

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

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

ответил hakre 29 J0000006Europe/Moscow 2012, 00:20:58
2

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

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

ответил Homer6 30 J0000006Europe/Moscow 2012, 11:59:38
1

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

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

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

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

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

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

ответил Andy Lester 13 J000000Friday12 2012, 21:37:39
-3

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

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

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

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

ответил Osvaldo Mercado 5 J000000Thursday12 2012, 08:03:56

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132