Я QA-менеджер с 5 отчетами. В нашей команде также есть менеджер по разработке, который в равной степени участвует в команде Scrum. Моя обеспокоенность постепенно росла из-за того, как она напрямую спрашивала моих подчиненных о том, как они отнесутся к смене своих обязанностей в команде. Например, прямо сейчас 2 QA отвечают за проверку проблем, а также за автоматизацию, она отправляет им письмо, спрашивая их напрямую, как бы они себя чувствовали, если бы 1 из них выполнял только проверку, а другой занимался автоматизацией (зацикливает меня на почте). Хотя в самой идее нет ничего плохого, но ситуация такова, что я уже сказал ему, что мы, команда QA, уже обсуждаем, как мы можем изменить ситуацию с точки зрения назначения, я действительно ожидаю, что она позволит это быть на моей тарелке для работы, пока я не сообщу ей о нашем решении как команды QA.
Как я могу:
Просто скажите руководителю разработки, как выглядит желаемый процесс. Нет необходимости делать из этого суету. Просто что-то вроде
Эй, я понимаю, что вы хотите оптимизировать рабочую нагрузку для всех, но нет смысла спрашивать QA напрямую. Это решение руководства, и если вы спросите QA напрямую, они могут подумать, что решение уже было принято. Поэтому, пожалуйста, просто спросите меня, чтобы избежать путаницы.
Эскалируйте, только если это не сработает.
Это уравновешивание
Хотя я, конечно, понимаю желание управлять своими сотрудниками, вы также должны понимать, что именно так это должно работать в agile-команде.
Многие люди используют Scrum, но менеджеры по-прежнему распоряжаются и распределяют работу. На самом деле это не так, как должно быть.
Правильный Agile управляется командой. Команда должна принимать решения и должна чувствовать себя комфортно, обсуждая и обмениваясь распределением работы в группе.
Команда схватки должна быть «границей». Не ваши управленческие отчеты! Люди, которые говорят, что кто-то «не должен связываться с вашими отчетами», не имеют опыта работы в гибкой среде.
Однако у вас есть организация, которая не полностью соответствует продукту. Когда у вас есть гибрид как тактического руководства проектом (Scrum-команда), так и ролевого управления (менеджер разработчиков, менеджер по обеспечению качества), может возникнуть путаница в отношении того, какие вещи должны обрабатываться через тот или иной канал.
Некоторые организации просто говорят: «Хорошо, мы решим эту проблему, просто заставив всех отчитываться перед одним менеджером по этому продукту/услуге/компоненту». Другие придумывают рекомендации или ограждения для того, что делает структура отчетности по сравнению с agile-командой.
Способ решить эту проблему — открыто спросить в духе исследования либо группу менеджеров, включая менеджера по разработке, либо тренера по Agile, если он у вас есть: «Эй, значит, я привык работать в среде, где Я говорю, кто что делает в моей команде. Но в нашей agile-команде команда начинает самостоятельно организовывать такие вещи. Как мы уравновешиваем команду, принимающую решения, с ответственностью руководства за разработку наших отчетов и т. д.?» и попросите управленческую команду выработать нормативный ответ, понятный всем.
Но просто настаивать на том, чтобы рабочие задания исходили от вас, может стать шагом, ограничивающим карьеру, если организация серьезно относится к гибкости.
PoloHoleSet
Ниса
PoloHoleSet
Ниса
папарацци
Ниса