Я являюсь частью группы разработчиков программного обеспечения, в настоящее время пытаюсь исправить ошибки. Мы наблюдаем проблему, при которой фронтенд-группа по умолчанию передает ошибки бэкенд-команде для анализа первопричин (RCA).
Например, команда инженеров по качеству (QE) зарегистрирует ошибку, в которой говорится, что «выполнение X, затем Y, затем Z в пользовательском интерфейсе вызовет ошибку, когда этого не должно быть». Ошибка будет передана фронтенд-команде. Иногда поведение по умолчанию, по-видимому, для фронтенд-команды состоит в том, чтобы назначить ошибку серверной части с комментарием, похожим на «Мы получаем ошибку из серверной части, поэтому это проблема серверной части». ", а затем назначить ошибку моей команде без какой-либо проверки.
Более чем в половине случаев мы проводим RCA и обнаруживаем, что QE было правильным, а ошибка на самом деле не связана с серверной частью, и возвращаем ее команде фронтенда. Важно отметить, что этот RCA находится на внешнем, а не на внутреннем коде, а это означает, что этот процесс не выходит за рамки возможностей ни одной из команд. Иногда это происходит несколько раз, когда проблема перемещается туда-сюда, пока ее, наконец, не возьмет на себя команда. Наши менеджеры сообщили команде, что нам не следует переназначать ошибки, как я описал, но проблема не устранена.
Я разочарован тем, что делаю RCA для вещей, за которые не получаю должного внимания, или, другими словами, я трачу время впустую, занимаясь тем, что не должно быть моей работой . В конце наших спринтов я отстаю по количеству ошибок, и похоже, что моя производительность очень низкая.
Как я могу эффективно сообщить команде внешнего интерфейса, что мне нужно прекратить работу над ошибками, которые не находятся в моей области? Есть ли мирное решение для обеих команд?
Здесь нужно исправить несколько вещей:
С технической точки зрения, если ваш внешний интерфейс получает ответ об ошибке , и они не могут сказать, что это их ошибка , то ответ об ошибке внутреннего интерфейса неисправен . Настройте свою серверную часть, чтобы отвечать сообщениями, которые можно понять, и вам не нужно будет объяснять это снова и снова.
С точки зрения организации, ошибка, которую вы проверяете, доказываете, что это не ваша часть, и переназначаете, должна быть ошибкой, которая учитывается при подсчете ошибок. Вы успешно над ним поработали.
Но самое главное:
Что вы можете исправить? Я не знаю. Вы можете сесть на корточки, удерживать форт, убедиться, что билеты переназначены правильно, другие возьмут на себя вину, и количество ваших ошибок возрастет. Так работает корпоратив, ты загребаешь деньги, а глупые люди выше тебя недоумевают, почему их продукт такой дрянной по сравнению с той огромной суммой денег, которую они в него вливают. Или вы могли бы попытаться выбрать большую дорогу. В следующий раз расследуйте баг, если кажется, что он во фронтэнде, не бросайте тикет обратно, поговорите с кем-нибудь, сформируйте с ними команду и исправьте баг вместе. Сосредоточьтесь на выполнении работы, а не на корпоративных показателях. Вы можете быть удивлены тем, насколько более вознаграждаемой является работа, когда речь идет о том, чтобы что-то сделать, а не отклонять билеты и обвинять других. Возможно, нет. Возможно, ваша корпорация слишком далеко зашла, чтобы вы могли что-то изменить. Затем вы должны решить, достаточно ли они платят вам, чтобы терпеть это.
Я разочарован тем, что занимаюсь RCA тем, за что не получаю должного внимания, или, другими словами, я трачу время впустую, занимаясь тем, что не должно быть моей работой.
Ваша система мотивации испорчена.
Скорее всего, фронтенд-команда также делает это, чтобы получить признание за инспекционную работу, которую они не выполняли.
Если вы хотите, чтобы поведение фронтенд-команды изменилось, менеджеры должны изменить структуру стимулов и способ оценки разработчиков.
В какой-то момент я был в похожей ситуации, с добавлением того, что интерфейс был программным, а серверный — аппаратным (без доступа к кодовым базам друг друга). Ты упомянул:
команда QE зарегистрирует ошибку, в которой говорится, что «выполнение X, затем Y, затем Z в пользовательском интерфейсе вызовет ошибку, когда этого не должно быть».
а затем эти билеты будут отправлены вам. Когда я получал такие билеты, я отбрасывал их, потому что «нужно больше информации». У меня нет ничего, связанного с пользовательским интерфейсом, на моем бэкэнде, поэтому тикет от команды QE не говорит мне многого, что для меня значимо. Вместо этого мы, по сути, потребовали бы, чтобы команда внешнего интерфейса написала отдельный дочерний тикет, а не переназначала исходный тикет, в котором говорилось бы: «Когда я отправляю такой -то и такой-то запрос на серверную часть, отформатированный таким образом , результат усекается». .
Это не позволяет команде внешнего интерфейса лениво отбрасывать проблемы через стену и заставлять вас выполнять работу. Они должны отладить проблему вплоть до интерфейса между нами. Конечным результатом было то, что 95% ошибок, которые они нам присылали, на самом деле были проблемами бэкенда. Процесс отладки вплоть до интерфейса прояснил бы, на чьей стороне проблема. Трудно написать описание того, что бэкенд делает неправильно, когда проблема во внешнем интерфейсе. Если они все равно попытаются, такие заявки обычно легко идентифицировать, например, показав, что тот же процесс работает, как и ожидалось, при использовании другого интерфейса.
Использование второго тикета между фронтенд- и бэкенд-командами также означает, что вы можете закрыть недействительные тикеты с крайним предубеждением, и это никак не повлияет на первоначальный тикет команды QE. Во время ретроспективы вы можете показать количество запросов, поданных фронтенд-командой, которые были либо недействительными, либо не содержали достаточно информации для принятия мер, что должно сделать проблему более заметной и очевидной для руководства.
По сути, перестаньте пересекать интерфейс между интерфейсом и сервером. На самом деле у вас есть доступ и набор навыков, чтобы заглянуть в кодовые базы друг друга (в отличие от моего случая), но только потому, что вы можете , не означает, что вы должны это делать . Большая часть причин для разделения программного обеспечения на части заключается в том, чтобы они могли обращаться друг с другом как с черными ящиками с четко определенными интерфейсами. Ошибка бэкенда должна быть зарегистрирована без какой-либо ссылки на конкретный интерфейс, а только на интерфейс бэкэнда. Если вам нужно проникнуть через эту границу в код другой команды, чтобы исследовать вашу заявку, то тот, кто подал эту заявку, еще не закончил свою часть.
Мне показалось особенно полезным иметь альтернативный упрощенный интерфейс для тестирования. Моя команда редко проводила тестирование с использованием официального интерфейса (GUI). Мы с нуля собрали утилиту командной строки, которая могла выполнять все внутренние функции по отдельности и не содержала никакой бизнес-логики, которая была во внешнем интерфейсе. Это позволило нам легко протестировать наш бэкэнд изолированно и проверить его поведение на соответствие спецификации. Когда от фронтенд-команды поступала ошибка, мы вручную тестировали ту же последовательность функций с помощью нашей утилиты. Если мы увидели ту же проблему, скорее всего, ошибка была в бэкэнде. Когда у нас это работало нормально, проблема почти всегда была во внешнем интерфейсе. Мы могли бы легко определить заявки, которые на самом деле не были проблемами бэкэнда, с помощью 5-минутного теста вместо того, чтобы тратить 2 часа на его изучение.
Наши менеджеры сообщили команде, что нам не следует переназначать ошибки, как я описал, но проблема не устранена.
Почему бы вам не решить этот вопрос с вашим менеджером? Кажется, это был бы правильный канал.
В конце наших спринтов я отстаю по количеству ошибок, и похоже, что моя производительность очень низкая.
Почему бы вам не задокументировать это и не представить в своих спринтах? "Вот почему я позади..."
В конце наших спринтов я отстаю по количеству ошибок, и похоже, что моя производительность очень низкая.
Похоже, вы решаете не ту проблему. Но сначала...
Я думаю, что многие другие ответы предполагают, что за действиями другой команды стоит злой умысел, но может быть ряд факторов, по которым ошибки могут быть ошибочно переназначены. Не все причины веские, но причины:
В конечном счете, если есть какая-то систематическая проблема, которую вы уже обсуждали со своим боссом, вы должны спросить своего босса, что они хотели бы, чтобы вы сделали, когда вы получаете билет, который не выглядит так, как будто он был расследован до того, как его переназначили.
Возможные вещи, которые ваш босс может попросить вас сделать:
Любой ответ здесь, который предписывает, что вы должны делать в этих обстоятельствах, является УГАДАНИЕМ, что ваш босс хотел бы, чтобы вы сделали. К счастью, вам не нужно гадать, вы можете просто спросить своего босса.
Хотя ваш босс сказал, что билеты не должны распределяться взад и вперед без надлежащего расследования, это не дает вам права произвольно выбирать одно из вышеперечисленного и делать это. Если кто-то не следует политике, это не значит, что и вы не должны следовать политике (как предполагают некоторые другие ответы).
Теперь, с точки зрения прикрытия своей задницы, вы также хотите лично задокументировать случаи, когда ваша собственная способность работать эффективно была скомпрометирована. И когда вы обсуждаете производительность со своим боссом, это то, на что вы должны ссылаться. Если ваш начальник доволен потраченным впустую временем, то проблем нет. Конечно, если ваш босс недоволен потраченным впустую временем, по крайней мере, вы действовали в соответствии с его указаниями.
Я не согласен с другими ответами. Я был в этой ситуации, и вот что я сделал, чтобы исправить это.
Что касается меня, как разработчика, когда мне поручают ошибку, моя работа заключается в ее расследовании. Только в том случае, если я утверждаю, что это не моя ответственность за исправление или по какой-то причине я не могу это исправить, я переназначаю это другому разработчику/команде. Если я не могу воспроизвести это или не могу понять, почему это проблема, я верну ее тому, кто ее поднял.
Вы должны спросить своего менеджера, согласны ли они с тем, что разработчики должны провести расследование перед переназначением. Если они этого не сделают, вы набиты, но если они попросят их сделать объявление, чтобы это было понятно всем. Если это будет продолжаться, сообщите об этом публично в любом удобном месте на вашем рабочем месте. Например, ретроспектива или статусная встреча. Например: «На этой неделе я потратил много времени на изучение ошибок, которые были переназначены мне FE, которые на самом деле оказались проблемами FE. Как это происходит? Почему FE не может понять это, прежде чем переназначить мне? они не расследуют должным образом?».
Некоторым это может показаться мелочным или осуждающим, но в ситуации, когда люди бросают на вас свою работу в надежде, что какая-то ее часть приживется или, по крайней мере, выиграет им немного времени и ваши расходы, я думаю, что это оправдано.
Если пользователи системы отслеживания ошибок используют ее не по назначению, то привилегии, которые они используют, что приводит к неправильному использованию, должны быть отозваны. При этом возможность изменить назначение тикетов другим командам.
Я работал над довольно большими программами, в которых было много команд, ответственных за многие части. Таким образом, ни одному разработчику не разрешалось в одностороннем порядке передавать заявку другой команде. Не существовало жесткой системы, препятствующей тому, чтобы вас переназначили в другую команду, но если бы вы это сделали, кто-нибудь сидел бы за вашим столом и спрашивал, какого черта вы делаете. Если кто-то хотел назначить тикет другой команде, у него было два варианта:
Ваш менеджер уже сказал вам ответ.
Вы все не должны передавать ошибки другим командам.
Когда они назначат вам ошибку, ответьте, что вас проинструктировали не мешать их работе и продолжать свой день. Вы создаете проблему, сотрудничая с ними вместо своего менеджера.
Вы можете оставлять их сообщения без ответа до тех пор, пока они не соберутся достаточно большой «кучей», чтобы ваш менеджер мог управлять ими на микроуровне и иметь дело со всеми сразу.
Чтобы пояснить пример, «QA решил, что ошибка, вероятно, связана с работой вашей команды, и ManagerX сообщил нам, что вы не должны переназначать нам ошибки, и поэтому мы отдаем приоритет рабочей нагрузке, которую мы изначально назначили. Если вы в состоянии найти ошибку и обнаружить, что это действительно ошибка в конкретном выводе из серверной части, мы примем это как приоритет, чтобы не задерживать вашу команду».
Это может быть прекрасной возможностью для вас проявить инициативу — назначьте время каждый день с руководителем (или каким-либо подходящим представителем) другой команды для совместной сортировки билетов .
Вы получите лучшее представление о процессах друг друга, возможно, быстрее придете к выводам и, что особенно важно, уменьшите разрозненность. Теперь у вас есть время каждый день, чтобы сосредоточиться на этой задаче, и теперь ваши усилия можно измерить.
Плохой менеджер скажет вам, что вы зря потратили время, и скажет вам остановиться, и я восприму это как знак того, что в этой компании ничего не изменится.
Хороший менеджер поймет, что вы сделали что-то стоящее.
Отличный менеджер поможет вам развить идею и сгладить процесс (и не забудьте отдать должное!)
Мне трудно представить, как столько времени в рабочем дне можно потратить на исправление ошибок. Вы говорите о внешнем и внутреннем интерфейсе, что, как мне кажется, указывает на какой-то веб-стек, но как может исправление ошибок быть такой проблемой, что целые команды обходят ее стороной и пытаются избежать ответственности за нее?
Если вы разрабатываете веб-приложения, то исследовательская часть процесса проектирования должна прояснить требования к приложению. Каждый разработчик должен иметь ясное представление о том, что ожидается от продукта.
Я подозреваю, что происходит то, что многие младшие разработчики должны работать над технологиями на более продвинутом уровне, чем то, на что они способны. Кому захочется нанимать старшего разработчика, когда вы можете просто заставить кучу новичков работать за небольшую плату?
Эти люди вместо того, чтобы взять на себя ответственность за работу, перекладывают ответственность просто потому, что они не знают, как решить проблему. Часто бывает трудно признать, что вы не можете решить проблему. Особенно, если вы любите своего работодателя и считаете, что не в состоянии что-то для него сделать, значит его подвести.
Я действительно не понимаю, как то, является ли проблема внешней или внутренней, может помешать кому-либо решить проблему. Да, я собираюсь работать фронтенд-разработчиком, но если приложению Angular необходимо взаимодействовать с базой данных MySQL, то это моя работа.
Я не могу в изнеможении опустить руки и прекратить работу только потому, что вдруг работаю с чем-то, что технически не обращено вперед. Кажется, что в том, как работают эти команды, есть разрыв, они должны быть двумя частями сплоченной единицы. Этот наш и их менталитет не способствует хорошей разработке программного обеспечения.
Как предлагается в комментарии, проведите комплексную проверку, проведите тесты, и если вы не найдете ошибок в бэкэнде, просто закройте тикет как «не ошибка».
Frontend переслал вам заявку, и как коллега вы должны ожидать, что они сделали это профессионально и по причине: через некоторое время, возможно, кто-то заметит тенденцию и решит исследовать.
Звучит мелко? Потому что это так...
Рискованно? Может быть; только ты можешь сказать сколько...
Если метрика — «количество закрытых тикетов», я думаю, интерфейс быстро заметит новый подход к управлению тикетами на бэкенде.
Соберите всех нужных людей для быстрой встречи и скажите им:
Меня расстраивает то, что я делаю RCA для вещей, за которые я не получаю должного внимания, или, другими словами, я трачу время впустую, занимаясь тем, что не должно быть моей работой. В конце наших спринтов я отстаю по количеству ошибок, и похоже, что моя производительность очень низкая.
Спросите их, как, по их мнению, следует решить эту проблему. Пригласите вашего менеджера. Слушай сначала.
Во-первых, когда у вас есть одна команда, работающая над внешним интерфейсом, и другая команда, работающая над серверной частью, было бы неплохо спроектировать системы таким образом, чтобы ошибки внешнего интерфейса приводили к сообщениям об ошибках и другим сообщениям, которые явно связаны с внешним интерфейсом. и то же самое для задней части. Проблемы во внешнем интерфейсе не должны приводить к ошибкам в серверной части, из-за которых может показаться, что проблема в серверной части, а затем требуется много RCA, чтобы определить, что это не так. Если бы вы, ребята, были все в одной команде, вам бы сошли с рук такие метания туда-сюда. Но поскольку вы — отдельные команды с отдельными спринтами, то, как вы обнаружили, перекладывание ответственности сделает работу очень неэффективной. Так что у вас явно системная проблема.
Конечно, проблема, вероятно, связана с тем, что для ее решения потребуется много времени и усилий (например, сколько ошибок потребуется отрефакторить?), и вы ищете быстрое магическое заклинание, которое вы можете сказать им, которое устранит проблему. Уходите. Это заклинание:
Эй, ребята из внешнего интерфейса! Я заметил, что мы получаем много ошибок, которые сначала кажутся ошибками внешнего интерфейса, но затем оказываются ошибками внутреннего интерфейса или наоборот. Например, в прошлом месяце серверная команда получила X ошибок, Y из которых оказались ошибками внешнего интерфейса. Я чувствую, что это могло бы сделать нашу жизнь намного проще и сэкономить нам много времени, если бы мы сократили это туда и обратно. Можем ли мы собраться, чтобы договориться о лучших критериях сортировки ошибок и регистрации их как интерфейсных или серверных? У меня есть несколько идей, которыми я могу поделиться, если хотите.
Что для меня странно, так это то, что вы указываете свою мотивацию как нежелание работать над таким количеством ошибок. Разве исправлять ошибки не твоя работа? Если да, то почему вы жалуетесь? Просто продолжайте исправлять ошибки, отмечайте тикеты выполненными, а в конце квартала расскажите своему боссу, как вы исправили так много ошибок и должны получить повышение. Или, если это не твоя работа, что ж, не делай этого? Разве у вас не должен быть менеджер, который говорит вам, над какими тикетами работать, вместо того, чтобы какая-то другая команда вываливала на вас тикеты? Как правило, билеты должны сначала отправляться вашему скрам-мастеру, чтобы он мог назначить их людям на следующей встрече спринта .
Начните назначать каждую ошибку интерфейсу, не глядя на нее. Проблема с фронтенд-командой (и вашим менеджером) естественным образом разрешится сама собой в течение нескольких дней.
Пока они вознаграждаются за свои действия тем, что отлично выглядят перед менеджерами, а вы тот, кто должен подавать отчеты о плохой работе, у фронтенд-команды нет причин останавливать их поведение; и они не будут. Похоже, менеджеры не заботятся о том, чтобы что-то с этим делать. Если все будет продолжаться так, как есть, вы примете на себя падение задолго до того, как передняя команда столкнется с каким-либо ответным ударом.
sf02
пользователь53861
пользователь53861
ОбезьянаЗевс
пользователь53861
Пол Д. Уэйт
заядлый
Марк Роттевил