Я технический руководитель, который также управляет разработчиками. Один из разработчиков (назовем ее Элис), которым я руковожу, работает в отдельной скрам-команде, в которой я являюсь техническим руководителем. Все команды работают над одним и тем же проектом. Алиса недавно была помещена в команду, которая не очень хорошо работала, и начала прямо подчеркивать, как они могут улучшиться. Мой эквивалент в этой команде, давайте назовем его Бобом, предпочитает технический стиль руководства «сверху вниз» и не очень хорошо относится к этому новичку в команде. Он также считает, что команда играет хорошо.
Было довольно много разногласий, несколько раз Боб использовал свой авторитет, чтобы заставить Алису замолчать и предотвратить дальнейшее обсуждение способов улучшения команды. Я также получил отзывы об Алисе, жалующейся на то, что она мешает команде и что, если бы она была подрядчиком, «ее бы уволили».
Удобно, что у нас также есть консультант/тренер в команде, стремящийся улучшить свои методы работы, с которым я смог обсудить это, чтобы получить более сбалансированную картину. Их мнение состоит в том, что Алиса права в 90% случаев и что команде нужно здоровое разрушение, однако Алиса могла бы попытаться изложить свои точки зрения в более дипломатичной манере. Я также поговорил с Алисой и предложил ей начать перечислять все свои точки, в которых команда может улучшиться, расставить приоритеты в этом списке, а затем поработать с тренером, чтобы выяснить, как лучше всего донести их до команды. вместо того, чтобы выделять каждую проблему по мере ее возникновения.
Хотя Алиса согласна с этим подходом в большинстве случаев, она не считает, что может не выделить и продолжать выделять проблему, когда, по ее мнению, это серьезная проблема, например, отключение неудачных тестов или рассмотрение заявки завершенной, несмотря на неудачную сборку Jenkins. Я полностью согласен с ее точкой зрения на этот счет, но Боб по-прежнему недоволен Алисой, и я боюсь, что ситуация переходит от нормального нарушения к простому нарушению.
У меня нет власти над Бобом, потому что он эквивалентен, и я не думаю, что мне было бы полезно принимать непосредственное участие в каждом вопросе, поднятом Алисой, у меня также нет на это времени. Я устроил встречу со мной, Алисой, Бобом, мастером схватки команды и тренером, чтобы посмотреть, сможем ли мы найти путь вперед, и обсудить некоторые моменты, которые, по мнению Алисы, она не может не выделить. Если эта встреча не пройдет хорошо, а у меня есть все основания подозревать, что так и будет, то я немного в растерянности относительно того, что делать дальше, и в настоящее время чувствую себя застрявшим в середине. Не существует реального высшего технического органа, к которому это можно было бы передать из-за довольно плоской структуры технического управления, пока продолжается корпоративная реорганизация.
Это сложная ситуация, с которой нужно справиться.
Я думаю, что самым простым выходом из этого (на данный момент) было бы переместить Живую из команды Боба обратно в вашу или в место, которое более совместимо с ее стилем и ценностями. Может быть, есть своп, который можно организовать.
В долгосрочной перспективе должен быть способ устранить несоответствие между Бобом и вами/Алисой. Вам нужно создать последовательную культуру и набор ценностей, иначе у вас будут постоянные конфликты, подобные этому. Без вышестоящего органа это будет сложно, но, возможно, после реорганизации ситуация изменится. Пока не будет единой культуры, лучшее, что вы можете сделать, это свести к минимуму точки соприкосновения.
Боб хочет «уволить» Алису из-за разногласий по существу, а не просто из-за выражений. Между тем, вы считаете, что Алиса хорошо справляется со своей задачей, но, возможно, ей не помешало бы немного потренироваться в общении.
Похоже, вам действительно нужно перевести Алису из проектной группы Боба в вашу.
Попытка навязать «помощь» там, где она не нужна, просто не сработает. Неважно даже, кто "прав" в объективном техническом смысле, достаточно того, что просто нет подгонки.
Спросите Боба, хочет ли он освободить ее. Тогда проблемы или прогресс его команды могут быть его проблемами или достижениями, и вы можете помочь Алисе еще более эффективно представлять и применять свои решения в контексте, когда их намерения в целом приветствуются.
Если ваша организация не может перевести Алису из ситуации, где ее помощь не приветствуется, в ситуацию, где она нужна, то она, вероятно, потеряет ее как ресурс для какой-то другой организации, где ее вклад будет оценен.
«Несколько раз Боб использовал свою власть, чтобы заставить Алису замолчать и предотвратить дальнейшие обсуждения способов улучшения команды».
"отдельная схваточная команда".`
Скрам-команда — это команда разработчиков без ролей. Скрам-мастер должен сообщить об этом команде разработчиков, хотят ли они так работать.
Поговорите со скрам-мастером команды разработчиков, частью которой является Боб, и сообщите ему о текущем состоянии команды разработчиков. С другой стороны, Алиса была бы лучшим сервером, если бы обсудила этот вопрос со скрам-мастером и во время ретроспективы спринта со всей командой разработчиков.
Согласно OP, это проект scrum, поэтому мой первый совет - использовать тег scrum, который позволяет легче найти публикацию. Вторая критика заключается в том, что исходное предложение не имеет особого смысла.
цитата: «Я технический руководитель, который также управляет разработчиками. Один из разработчиков (назовем ее Элис), которым я руковожу, работает в отдельной скрам-команде, в которой я являюсь техническим руководителем».
В методике управления схваткой менеджер приравнивается к внешнему заказчику, но в ОП утверждается, что он является скрам-менеджером внутри компании. Причина, по которой Scrum называют agile, заключается в том, что владелец продукта не является частью команды, но создает стресс извне.
Вместо того, чтобы обращаться к членам команды по имени, лучше обратиться к пользователям с их социальной ролью. Каждый член команды расположен в иерархии по годовому окладу. И тот, кто ничего не получает, находится на вершине пирамиды, а тот, кто больше всего зарабатывает, должен делать всю работу за остальных.
Одно из объяснений путаницы с матричной организацией, социальными ролями и отсутствием иерархии можно объяснить тем, что схватка — это очень новая концепция управления. Это нормально, что поначалу большинство классических менеджеров с трудом вживаются в свою роль. Рекомендуемый способ понять скрам во время практического проекта — представить, что команда должна решить задачу в центре управления чрезвычайными ситуациями. Такая среда имеет тенденцию идти в одиночку в направлении схватки, особенно если уровень стресса для пользователя повышен, количество ресурсов ограничено и конфликты становятся видимыми.
Если вышестоящего органа нет, вы можете попросить руководителей других групп помочь написать некоторые технические стандарты.
Во-первых, это показывает Бобу (или, возможно, вам ;-) стандарт, которого хотят все остальные.
Если это не поможет, вы можете обратиться в нетехнический орган с доказательством того, что Боб не работает в команде и не поддерживает то, что сейчас называется «стандартами компании».
Первый игрок
Пауль