Должен ли лидер команды брать на себя ответственность за подчиненные ошибки?

Ответ 1

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

Очень важно, чтобы вы не использовали слово "винить".

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

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

Снова никогда не привыкать к вине игра. Легко попасть в зависимость от он.

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

Там разница между менеджером и лидер.

Учитесь быть лидером, а не менеджером.

Что касается технических проблем (QA, бюрократия, бла-бла), поверьте мне, неважно, понимаете ли вы основная философия в приведенном выше.

Ответ 2

Отвечая на вопрос заголовка: Вы просто не можете обвинять сотрудника в работе клиента

Возьмите вину, а затем, внутренне, при необходимости примите соответствующие меры.

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

Ответ 3

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

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

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

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

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

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

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

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

Ответ 4

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

Один вариант: запустить ленивого программиста и нанять кого-то лучше.

Лучший вариант: Сделайте QA, чтобы проверить, кто-то является основной ответственностью за работу.

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

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

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

Ответ 5

Ответьте на этот вопрос для себя: знаете ли вы о проблеме до того, как это произойдет? Что вы сделали с этим?

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

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

В любом случае, я принял решение, и если это было только "мне все равно", значит, я не могу винить кого-либо еще. Если вы болото, то почему? Потому что на вас работают все кучи? Как они могут это сделать без вашего согласия? Говорят ли они "Да", когда они дают вам работу?

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

Ответ 6

К вашим менеджерам нет, не обвиняйте своих подчиненных.

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

Для ваших клиентов нет, не обвиняйте своих подчиненных.

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

Что делать?

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

Ответ 7

Представьте себе, что второй из них - генеральный директор Microsoft, в котором работает более 50 000 человек, и что-то ужасно неправильное каждый день делает кого-то невероятно несчастным. Если что-то не пошло не так, никогда не было никаких инцидентов, с которыми можно было столкнуться, без неудовлетворенных клиентов с неотложными проблемами, и команда никогда не потерпела неудачу, тогда вы бы действительно не научились многому примеру команды, не так ли?

И вы можете видеть себя в обуви CEO Microsoft, перекладывая вину "Thats из-за того, что Стив не выполняет свою работу должным образом!" во время одной из этих важных деловых встреч?

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

Сдвиг вины на подчиненную привычную работу для команды:

• Поскольку он или она представляет команду и компанию, проблема не исчезнет, ​​поскольку она остается даже дистанционно связанной с компанией в сознании клиентов.

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

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

Часто обвинение не имеет отношения к решению проблемы.

Некоторые советы о приближении к сценарию "несчастный клиент":

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

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

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

• Сосредоточьте беседу на пути вперед и промежуточное средство, где это возможно.

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

• Прежде всего, сообщите клиенту о каких-либо известных проблемах, которые окажут на них негативное влияние.

• Прежде всего, сообщите руководству о любых проблемах для обеспечения их поддержки.

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

• При необходимости измените процесс.

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

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

• Соберите информацию сначала, прежде чем принимать какие-либо решения.

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

Ответ 8

Как однажды сказал мне человек,

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

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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

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

Ответ 11

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

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

Попробуйте получить клиента, чтобы он встретил команду и продал ее, почему важно получить свой бай-ин.

Ответ 12

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

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

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

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

Ответ 13

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

Ответ 14

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

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