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

Я QA-менеджер с 5 отчетами. В нашей команде также есть менеджер по разработке, который в равной степени участвует в команде Scrum. Моя обеспокоенность постепенно росла из-за того, как она напрямую спрашивала моих подчиненных о том, как они отнесутся к смене своих обязанностей в команде. Например, прямо сейчас 2 QA отвечают за проверку проблем, а также за автоматизацию, она отправляет им письмо, спрашивая их напрямую, как бы они себя чувствовали, если бы 1 из них выполнял только проверку, а другой занимался автоматизацией (зацикливает меня на почте). Хотя в самой идее нет ничего плохого, но ситуация такова, что я уже сказал ему, что мы, команда QA, уже обсуждаем, как мы можем изменить ситуацию с точки зрения назначения, я действительно ожидаю, что она позволит это быть на моей тарелке для работы, пока я не сообщу ей о нашем решении как команды QA.

Как я могу:

  1. Настойчиво сообщить ему, что распределение ресурсов QA лежит на мне и команде QA в целом?
  2. Четко определите, каковы границы моей роли и его - что для него кажется размытым?
Не то чтобы это имело особое значение, но менеджер разработчиков меняет пол между вашим описанием («она») и вопросом, состоящим из двух частей («он»). Как я уже сказал, в этом вопросе нет ничего специфичного для пола, но я заметил это, поэтому упоминаю об этом.
@PoloHoleSet Верно. Это произошло потому, что у нас только что был временно исполняющий обязанности менеджера по разработке, женщина. Наш менеджер разработчиков вернулся. :)
И они оба делают/делали это? Или штатный есть? Или это не имеет значения, потому что вы все равно хотите знать, как лучше всего справиться с чем-то подобным, потому что это может произойти снова?
На самом деле тот, кто вернулся, именно такой. Временный такими вещами не занимался. Я хочу управлять им правильно. Я новичок в управлении.
Если они не находятся выше вашей прямой цепочки подчинения, они не должны связываться с вашими отчетами по проблемам процесса. Я бы поговорил об этом с вашим боссом, как будто все пойдет плохо, они должны быть готовы.
Я понимаю, откуда вы. Вот правильная ситуация. Однако наши команды не организованы таким образом. распределение ресурсов между командами по-прежнему является обязанностью менеджера по обеспечению качества. Насколько я понимаю, внутри скрам-команды должна быть самоорганизующаяся команда. Я работал в таких командах. Однако эта модель команды не такая. Распределение ресурсов разработчиков является обязанностью исключительно менеджеров разработчиков. Так же и для QA.

Ответы (2)

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

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

Эскалируйте, только если это не сработает.

Это уравновешивание

Хотя я, конечно, понимаю желание управлять своими сотрудниками, вы также должны понимать, что именно так это должно работать в agile-команде.

Многие люди используют Scrum, но менеджеры по-прежнему распоряжаются и распределяют работу. На самом деле это не так, как должно быть.

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

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

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

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

Способ решить эту проблему — открыто спросить в духе исследования либо группу менеджеров, включая менеджера по разработке, либо тренера по Agile, если он у вас есть: «Эй, значит, я привык работать в среде, где Я говорю, кто что делает в моей команде. Но в нашей agile-команде команда начинает самостоятельно организовывать такие вещи. Как мы уравновешиваем команду, принимающую решения, с ответственностью руководства за разработку наших отчетов и т. д.?» и попросите управленческую команду выработать нормативный ответ, понятный всем.

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

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