Последние два года я работал в очень небольшой компании по разработке программного обеспечения на должности полумладшего разработчика. Когда я начинал, я внедрил процедуры, касающиеся развертывания кода, и автоматизировал большую часть процесса сборки, поскольку на момент начала работы ни для одного из них не было реальной структуры. С тех пор компания увеличилась вдвое, я перешел к более обычной разработке и выполняю большинство административных задач, запуская сценарии автоматизации, которые написал при первом запуске.
В рамках роста компании был сформирован отдел контроля качества, и мы перевели сотрудника из другого подразделения компании, чтобы он возглавил отдел. Из-за незначительного объема работы, которую я выполнял для развертываний в прошлом, он обращается ко мне, чтобы выполнить множество задач, связанных с базой данных, которые выполняются в то же время, что и развертывание кода, несмотря на то, что я не являюсь разработчиком SQL. В их число входит развертывание кода SQL для наших сотен баз данных, управление развертыванием тестовых баз данных на серверах QA и проверка схемы базы данных на предмет того, что могло быть упущено. Теперь я также отвечаю за отладку сборки, если какой-либо разработчик проверяет код, который ее ломает, за обработку всех задач управления исходным кодом, включая слияния и удаление плохого кода из сборок, а также за устранение любых технических проблем, возникающих у команды контроля качества.
Большинство этих задач по отдельности занимают мало времени, но для каждой из них менеджер по обеспечению качества доводит задачу до моего сведения, как только она появляется, и требует, чтобы она была моей задачей с наивысшим приоритетом. Меня прерывают 5-6 раз в день, пока я пишу код для выполнения задач, которые могут занять от 1 минуты до часа, чтобы его команда могла оставаться продуктивной. Если я не выполняю задание сразу, он часто подходит к моему столу, встает позади меня и наблюдает, пока задание не будет выполнено. Из-за этого моя продуктивность разработки упала, и я больше не могу уложиться в сроки написания кода, которые были у меня раньше, что негативно отражается на моем положении как разработчика.
Я ясно дал понять своему руководителю, что постоянные перерывы значительно усложняют мне разработку кода и, как следствие, страдает моя удовлетворенность работой. Он заявил, что предпримет шаги для разрешения моих жалоб, но через несколько месяцев ничего не изменилось, и менеджер по контролю качества все чаще требует больше моего времени. Менеджер по контролю качества пожаловался высшему руководству на то, что время, затрачиваемое мной на выполнение этих задач, было ниже номинала, поскольку я предпочитаю закончить свою текущую задачу, прежде чем начинать новую. Сообщив ему, как это негативно влияет на мою способность работать, он начал предпринимать шаги, чтобы отвлечь меня от разработки, чтобы работать в его команде на постоянной основе, чего у меня нет желания делать.
Я по-прежнему считаю себя младшим разработчиком и работаю здесь ради возможности учиться, которая в основном подавляется из-за того, что я считаю довольно черной работой. Я автоматизировал все, что мог, но мне трудно управлять автоматизацией наряду с другими моими программными и административными обязанностями. Есть ли хороший способ выбраться из этой ситуации и вернуться к программированию на полную ставку?
Вам нужна поддержка вашего менеджера, чтобы эта опция работала, но с ней QA-менеджера можно переобучить. Когда он попросит вас поработать над чем-то, попросите его отправить вам запрос, и вы добавите его в свою очередь. Если это нужно сделать перед другими делами в вашей очереди, ваш менеджер должен будет взвесить это.
А затем поговорите со своим менеджером и спросите у него, какие вещи он хотел бы задержать, чтобы вы могли поработать над этой задачей для QA-менеджера. Каждый раз, когда вы выполняете задание, ясно давайте понять, во что вам обойдется работа, которую вы будете выполнять для своего менеджера. Если ваш менеджер прикроет вашу поддержку, он посоветует вам выполнить работу по обеспечению качества после завершения хотя бы части вашей текущей работы. Затем, если менеджер по обеспечению качества стоит там, дайте ему понять, что он может стоять там сколько угодно, но вы не будете работать над его материалом, пока не сделаете то, что ваш менеджер поставил для вас в приоритет. И повернуться спиной и игнорировать его.
Это может иметь неприятные последствия, и в конечном итоге вы будете выполнять все больше и больше работы по обеспечению качества, потому что ваш менеджер скорее потеряет вас, чем будет иметь дело с менеджером по обеспечению качества. Но если ваш менеджер настолько слаб, возможно, стоит поискать в другом месте.
У менеджера по обеспечению качества нет стимула нести ответственность, так как он обнаружил, что вы сделаете работу, если он будет приставать к вам. Следовательно, вам нужно сделать проблему QA-менеджера проблемой QA-менеджера, позволив его/ее задачам опаздывать.
Как Генри Клауд, доктор философии. пишет на странице 15 Границы для лидеров ,
В конце концов, как лидер вы всегда получите сочетание двух вещей: того, что вы создаете, и того, что вы разрешаете.
...
Центральным принципом границ является принцип собственности.
Принимая на себя проблемы менеджера по обеспечению качества, выполняя его/ее работу, вы позволяете этому менеджеру перенаправить ваш труд. Только когда вы заставите его/ее взять на себя ответственность за свои обязанности, позволив ему/ей испытать на себе последствия пропущенных сроков, он/она перестанет приставать к вам.
Как отмечено в одном из других ответов, прежде чем сказать «нет» менеджеру по обеспечению качества, вы должны встретиться со своим менеджером и сообщить ему / ей, что вы собираетесь прекратить выполнять работу другого отдела, получить его / ее согласие и отправьте электронное письмо, подтверждающее ваш разговор.
Таким образом, у вас будет бумажный след, если кто-то попытается привлечь вас к ответственности за пропущенные сроки.
Если вам трудно допустить возникновение этого конфликта, вы должны выяснить, какова «отдача», которую вы получаете, подчиняясь требованиям менеджера по контролю качества. Эта награда может быть эмоциональной, статусной или финансовой.
В конце концов, вам нужно набраться смелости, чтобы управлять тем, что вы контролируете: своим поведением. Для многих работников установление границ на рабочем месте является тяжелым уроком, потому что рабочее место часто вознаграждает людей за то, что они выполняют чужую работу.
Если я не выполняю задание сразу, он часто подходит к моему столу, встает позади меня и наблюдает, пока задание не будет выполнено.
Это неприемлемо на личном/человеческом уровне. Такое поведение демонстрирует недоверие к вам и не является разумным. Если вы хотите что-то сделать, но не верите, что вы говорите: «Я сделаю это», зачем тратить время и идти к своему столу?
Я думаю, что ваш менеджер недооценивает его работу. Еще руководители других направлений не могут «часто подходить к рабочему столу» сотрудника. Они ДОЛЖНЫ спросить вашего менеджера, можно ли запланировать ваше время для выполнения других задач.
Таким образом, более важным моментом здесь является организационный уровень. Если ваша обязанность состоит в том, чтобы выполнять эти задачи QA, то переведите вас в команду QA. Если ваша обязанность заключается в другом, оставайтесь в разработке и передайте знания другому члену команды QA.
К ним относятся развертывание кода SQL в наших сотнях баз данных, управление развертыванием тестовых баз данных на серверах контроля качества и проверка схемы базы данных на предмет того, что могло быть упущено. Теперь я также отвечаю за отладку сборки, если какой-либо разработчик проверяет код, который ее ломает, за обработку всех задач управления исходным кодом, включая слияния и удаление плохого кода из сборок, а также за устранение любых технических проблем, возникающих у команды контроля качества. Многие из этих задач ранее выполнялись специалистом с наиболее подходящей квалификацией, но менеджер по обеспечению качества считает, что я должен выполнять все задачи самостоятельно.
Менеджмент должен также управлять рисками. В частности, я вижу здесь одну особенность: что, если вы уйдете? Как справятся с этой задачей? В «хороших» и «организованных» компаниях на каждую «должность» приходится как минимум два человека, чтобы смягчить уход людей.
Вопрос к вам: проводите ли вы периодические встречи менеджеров для обсуждения этих проблем?
папарацци
Питер М
Stop starting, start finishing
( agilebuddha.com/agile/… ). Я обнаружил, что работаю лучше, когда работаю таким образом, и я даже не работаю в гибкой среде.Звуковая Защита
Мандертон
Звуковая Защита
Мандертон
Патрисия Шанахан
Джонатон Коули-Том