Как скрам-мастеру не дать члену команды слишком легко сдаться?

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

Часто говорят мне, что «О, это не может быть решено», а затем «Я не знаю, сколько времени это займет, чтобы решить».

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

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

@nvoigt он сказал недели.
@JoeStrazzere, да, я сказал ему, что ему нужно перестать легко сдаваться, но он раздражается и затем делает свою работу. В конце концов, он заканчивает работу, но я должен услышать кучу жалоб, прежде чем он это сделает.
Является ли этот разработчик частью команды или работает в одиночку?
@JoeStrazzere Я фактически являюсь менеджером среднего звена, в настоящее время настройка заключается в том, что владелец продукта сообщает мне, что он хочет от продукта, моя роль заключается в том, чтобы затем организовывать спринты и следить за тем, чтобы команда своевременно выполняла свою работу на основе дорожная карта продукта. Это очень маленькая организация, поэтому у нас нет тех, кто занимается бакалавриатом, техническим руководителем и т. д. Мне приходится носить несколько шляп.
Обратите внимание, что в обязанности скрам-мастера не входит следить за тем, чтобы команда выполняла работу своевременно. Сделать это — собственная работа команды. Некоторое формальное обучение схватке звучит как хорошая идея.
Я голосую за то, чтобы закрыть этот вопрос как не по теме, потому что это либо элементарное «как мне управлять кем-то?» вопрос или что-то конкретное для SCRUM, и в этом случае он относится к управлению проектами (возможный кандидат на миграцию)
@Lilienthal - у меня нет проблем с тем, что это «элементарный» вопрос управления. Не у всех есть управленческие навыки. Это имеет достаточно узкую направленность, чтобы мы могли решить эту проблему. Как человек, который является руководителем группы и был им некоторое время, мне все еще было бы интересно увидеть решения, которые предлагают наши эксперты.
@Chad Вот для чего нужны книги. Возможно, есть смысл в общем вопросе «Каковы основы управления?» вопрос, но его нужно правильно сформулировать и создать с учетом этой цели. Честно говоря, кажется, что OP не является менеджером в этом сценарии, что делает этот вопрос больше похожим на вопрос Scrum, чем на что-либо еще, особенно на основе ответа, получившего наибольшее количество голосов.
@Chad Спасибо, что сказал, что у меня нет навыков управления - в любом случае, это оказалось правильным шагом, поскольку теперь он понял, почему он должен больше слушать меня из-за обнаруженных дополнительных ошибок. Следовательно, упражнение не является пустой тратой времени.
@ bobo2000 - я не имел в виду, что у вас нет управленческих навыков. Этот вопрос, возможно, был специально для вас, но при рассмотрении вопроса, следует ли закрыть его, это с точки зрения того, будет ли этот вопрос полезен для других в будущем.

Ответы (5)

Как скрам-мастер, вы не должны управлять разработчиком. Привлекать владельца продукта (PO) также не является вашей задачей. Работа вашего PO — следить за тем, что делает его команда, а ваша — следить за тем, чтобы они следовали процессу Scrum.

Ваш разработчик совершенно прав, что не обсуждает с вами детали работы над тикетом. Вы не тот человек, который поручает ему работу или судит, хорошо ли она сделана. Скрам-мастер — это не помощник-ПО.

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

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

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

Общая часть: не думайте, что Scrum — это всякая обидчивая, чувственная, теплая, пушистая штука только потому, что в ней не было старого менеджера проектов. Не стоит недооценивать давление сверстников. Если он не исправит ошибку, команда должна будет выполнить задание. И они тоже будут не в восторге. Но вам нужно на самом деле использовать Scrum. Как всегда, кажется, что вы все это раскрасили по Scrum, имея SM, PO и Team, но вы не ведете себя так. Вы по-прежнему «его босс» и «управляете им». Это не Scrum и так не пойдет. Scrum работает только в том случае, если вы действительно используете Scrum. Раздавать титулы и делать это по старинке не получится.

Это все здорово, но люди должны нести ответственность за свою работу и высокое качество продукции, если бы он не слушал нас и просто занимался разработкой новых месторождений, технологический долг потенциально мог бы увеличиться. Выяснилось, что после выполнения работы, которую мы сказали ему изучить, он открыл банку с червями, где есть много критических для бизнеса ошибок, которые необходимо устранить. К вашему сведению, я не управляю разработчиком строго, в лучшем случае я направляю его, и мы, как правило, обсуждаем это со всей командой, прежде чем он зафиксирует.
Так что же происходит с багом, когда он его не исправляет? Кто-то другой подхватывает его работу или команда не достигает своей цели в спринте?
Мы делаем канбан прямо сейчас, вчера он закончил и достиг своей цели спринта. У нас есть система, в которой у нас есть спринты только для высокоприоритетных работ (чтобы убедиться, что они выполнены). Спринт обычно длится 4 дня, а затем на оставшуюся часть недели переходите на канбан. Мы обнаружили, что это работает очень хорошо, поскольку тогда мы можем быстро адаптироваться к подобным ситуациям, а не ждать до следующей недели и добавлять это в бэклог спринта. Если во время спринта случается нештатная ситуация, то бэклог спринта нужно менять после разговора с командой разработки.
Что именно вы имели в виду под его целью в спринте? Разве вы не получаете обязательств для всей команды?
Как определить цель спринта, если вы используете Канбан, а не спринты в Канбане?
@ bobo2000 — «люди должны нести ответственность за свою работу и высокое качество продукции» — да, для этого и нужна команда, КОМАНДА самоуправляется и имеет коллективную ответственность, поэтому они должны настаивать на том, чтобы ошибка была устранена и код должен быть требуемого качества, а не Scrum Master (тем более что Канбан все равно не имеет роли SM)
@bobo2000: если у вас есть вопрос, описывающий вас как Scrum Master, люди будут предполагать, что вы занимаетесь Scrum, и дадут вам ответ Scrum. Если вы делаете что-то совсем другое, лучше не упоминать термины Scrum.
@Thewandering Мы делаем 4-дневный спринт, в конце каждого спринта есть цель спринта. Мы экспериментировали с 2-недельными и 1-недельными спринтами, но проблема с обоими подходами заключается в том, что они делают цикл доставки медленным и жестким, учитывая, что отставание спринта не может измениться в середине, а приращение продукта показано в следующий понедельник. Выполняя 4-дневный спринт, мы можем показать заинтересованным сторонам, что было сделано на той же неделе, а затем использовать оставшуюся часть недели для исправления ошибок или настройки приращения, чтобы оно было таким, как он хочет. Затем мы развертываем в понедельник. Кажется, работает для нас.
Кроме того, если скрам-команда заканчивает работу раньше срока, как это было на этой неделе, мы переключаемся на Канбан до конца недели, а не начинаем новый спринт. Новый спринт всегда начинается в понедельник. Я надеюсь, что в этом есть смысл.

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

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

Если эти ошибки обнаружены в начале цикла разработки, не классифицируйте их как ошибки, а отклоните завершенные элементы как незавершенные.

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

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

Он не любит есть овощи. Ему нужно есть овощи. :-)

"Короткий ответ?" Деликатно!

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

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

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

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

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

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

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

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

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

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

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

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

PS. Я заметил, что вы отредактировали заголовок на «как скрам-мастер». Быть скрам-мастером — это одна из ролей, которую вы играете. Речь идет об организации скрамов, обеспечении того, чтобы задачи были хорошо определены и переходили в спринт, отслеживании прогресса и т. д. Качество разработчиков не является задачей скрам-мастера. Чисто с точки зрения скрам-мастера, если он не заканчивает задачу, то она считается незавершенной, пока ее не поднимет кто-то другой.

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

Мех, лично я сомневаюсь, что это как-то связано со сложностью исправления ошибок и с тем фактом, что работать над новыми функциями более «захватывающе», чем отслеживать ошибки. Исправление ошибок может доставлять удовольствие многим разработчикам, но я слишком часто сталкивался с теми разработчиками, которые предпочли бы заниматься своей работой с нуля, а не искать ошибки, что само по себе хорошо, когда они затем используют все оправдания. в книге, чтобы выйти из исправления ошибок, что это становится проблемой.
Благодаря этому, когда «разработчик» говорит «это не может быть решено», как вы отвечаете? И Му, ты на высоте.
@bobo2000 вы отвечаете: 99% of the time the problem is between the chair and the keyboard.. Каждый разработчик знает это, но им может понадобиться, чтобы кто-то когда-нибудь вспомнил об этом :)
Я также хотел бы отметить, что опыт различается у разных членов команды, что-то может быть чрезвычайно сложным для одного человека и легким для другого, например, потому что он видел это раньше. Его следует научить, что когда он говорит «это не может быть исправлено», он должен на самом деле сказать: «Я потратил на это время , но пока не смог это исправить — мне нужно привлечь другого члена команды».
Когда я работал в ситуации Scrum, спринт всегда был о том, сколько новых функций можно добавить, а не о том, сколько ошибок можно исправить. Если разработчик несет ответственность только за новые функции, может ли это заставить его пытаться достичь целей спринта и игнорировать вещи, выходящие за рамки целей спринта?

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

  1. Есть ли у этого разработчика какие-либо контакты с пользователями продукта?
    • Это может помочь ему начать видеть в ваших пользователях людей, а не просто какую-то другую группу, досаждающую ему. Я бы хотел, чтобы люди видели качественный продукт и были им довольны.
  2. Есть ли в команде внутренняя ответственность?
    • Можете ли вы поручить нескольким разработчикам работать вместе над решением сложных проблем? Обычно сложнее игнорировать коллегу, чем игнорировать рабочий билет
Как скрам-мастеру не дать члену команды слишком легко сдаться?
СпросиСетьПолитика конфиденциальности1y, 0v