Задний план
Я работаю в команде разработчиков программного обеспечения в крупной корпорации, основной бизнес которой не связан с программным обеспечением. Мы пытаемся развиваться в «гибкой» манере, но это часто противоречит более бюрократической и тяжеловесной структуре управления, в которой мы работаем. Существует общая атмосфера неудовлетворенности как со стороны нас самих, так и со стороны руководства нашей способностью укладываться в сроки, но не настолько сильно, чтобы от нас требовали неоплачиваемой сверхурочной работы.
Я разработчик с 6-летним стажем, 4 из которых в этой компании, с энтузиазмом отношусь к своей работе и хочу улучшить нашу ситуацию. В свободное время я иногда изучаю методы разработки и новые языки программирования. Я считаю, что я достаточно увлечен и хорошо осведомлен, чтобы помочь повысить производительность команды, но осознаю ограниченность своих знаний из-за моей относительной неопытности и отсутствия управленческой ответственности. Я плохо справляюсь с конфликтами и склонен либо уклоняться, либо реагировать слишком агрессивно.
Ситуация
На недавней схватке наш глава QA (назовем его «Джон») вошел и пожаловался, что мы не добавляем комментарии в наш трекер проблем при перемещении их из одного статуса в другой, потребовал, чтобы мы это сделали, и заявил, что это был «не подлежит обсуждению», ссылаясь на то, что это необходимо для целей внешнего аудита и аккредитации. Устал от подобного поведения Джона в прошлом (он является администратором сервера отслеживания проблем и часто вносит изменения, пытаясь заставить нас работать определенным образом), и совершенно уверен, что внешние аккредитации не являются такими предписывающими в отношении рабочий процесс, я рассмеялся и полушутя спросил: «Можем ли мы сделать его предметом переговоров?». (По общему признанию, это не самый мудрый шаг, который я сейчас признаю.) Джон категорически отказался. Я спросил, может ли он указать что-нибудь в нашей внутренней вики, что подскажет нам, какие комментарии следует делать и когда/где, но он сказал, что это просто «здравый смысл». Я ответил, что у него «явно имеются в виду конкретные требования к аудиту. Совершенно неразумно предъявлять нам требования, если [он] не собирается прямо их излагать». Затем последовало несколько горячих, но относительно несущественных обменов мнениями.
На выходе из схватки мы с Джоном плелись сзади. Вне пределов слышимости остальной команды он сказал мне, что «немножко поболтает со мной», так как я «веду себя враждебно». Он не довел дело до конца, но я весь день был в напряжении, ожидая, что он это сделает.
Основная причина моих возражений заключалась/является в том, что, насколько я понимаю, Джон, как глава QA, не имеет полномочий навязывать команду разработчиков подобным образом. Что касается использования средства отслеживания проблем, я полностью за размещение полезной информации, но в интересах сохранения хорошего отношения сигнал/шум я категорически против "штамповых" комментариев, которые служат лишь упражнением для галочки. Я знаю, что внешние аудиты предъявляют к нам определенные требования, которые необходимо выполнять, но я думаю, что Джон (намеренно или нет) смешивал эти требования со своим собственным мнением о том, как мы должны работать. Меня не столько волнует решаемая проблема, сколько принцип, согласно которому к нам как к команде следует относиться как к профессионалам, которые могут взять на себя ответственность за собственный рабочий процесс.
На следующее утро я объяснил ситуацию своему непосредственному руководителю, чтобы получить совет, как разрешить ситуацию, во время которого он согласился с моей оценкой того, что Джон выходит за пределы своих возможностей. После этого я отправил электронное письмо Джону, чтобы лучше выразить свои возражения, но не предъявлял ему никаких обвинений в его авторитете или иных обстоятельствах в этой ситуации. Это привело к встрече только между нами двумя, на которой он объяснил, что часто бывают случаи, когда мы реализовывали функции способом, который отличается от заявленных критериев приемлемости, что приводит к путанице среди команды тестирования. Я этого не знал и согласился с ним, что было бы хорошо решать такие проблемы со связью внутри отдела.
Однако на следующий день после того, как Джон распространил вики-пост, который, к сожалению, был гораздо ближе к словесной жалобе, которую он высказал на нашей схватке. Кажется, что он принял кое-что из того, что я сказал, пообещав быть «открытым для предложений», но он по-прежнему уделял столько внимания требованиям, касающимся внешнего аудита, опять же не уточняя, в чем они заключаются, что у меня сложилось впечатление, что он распространяет достаточно FUD, чтобы мы работали в установленном им порядке. К сожалению, он лишь косвенно затронул действительно хорошие моменты в вопросах общения, о которых рассказал мне на нашей частной встрече.
Мой анализ
Я думаю, что Джон ведет себя таким образом, потому что он действительно верит, что его идеи повысят нашу производительность (в отличие от циничного захвата власти ради самого себя), точно так же, как я верю в то, что мои идеи сделают это. Лучшее решение таких проблем — прагматичный компромисс между его взглядами и взглядами нас, команды разработчиков, но я не знаю, как заставить его взаимодействовать с нами таким образом. У меня складывается впечатление, что другие члены команды тоже недовольны им, но он добивается своего, потому что часто легче подчиниться его прихотям, чем убедить его в обратном.
Я читал другие вопросы на этом сайте, готовясь задать этот, и видел много разумных советов из статьи «Как завоевывать друзей и оказывать влияние на людей», которые предлагают мне попытаться представить свои проблемы в более совместной манере, которая позволит обе стороны уступают позиции, не теряя при этом лица. Однако весь мой опыт работы с ним приводит меня к мысли, что это никогда не может быть продуктивным, пока он ошибочно полагает, что последнее слово в том, как мы делаем свою работу, остается за ним.
Вопрос
Как я могу помочь исправить баланс сил между нашей командой и этим коллегой, чтобы мы могли достичь соглашений, которые наилучшим образом устраивают все стороны, не создавая ненужных конфликтов и не ведя себя непрофессионально?
Это клише, но ответ заключается в том, чтобы быть большим человеком.
Вы верите, что намерения Джона благие, это ключ. Уважайте его, будьте его защитником. Не давайте ему шанса изобразить вас враждебно настроенным. Если он искренне верит, что добавление комментариев повысит продуктивность, то подыграйте.
В следующий раз, когда вы соберетесь перенести проблему, хорошо подумайте, есть ли какой-либо значимый контекст, который вы можете добавить в качестве комментария. Действительно, на самом деле, честно - хорошенько подумайте. Просто потому, что что-то очевидно для вас и кажется, что это должно быть очевидно для всех, часто это не так. И даже если это так, информация часто эфемерна, витает в устной форме и скрыта в цепочках электронной почты. Есть ли у следующего человека, который будет работать над этой проблемой, даже если он только что вернулся из двухнедельного отпуска, вся информация, необходимая для того, чтобы сразу приступить к этой проблеме? Если нет, обновите и прокомментируйте, пока они не сделают. Применяются принципы бойскаутов: оставьте его в лучшем виде, чем вы его нашли, и неважно, по чьей вине это произошло. Всегда ошибайтесь в сторону недооценки и чрезмерного общения.
Теперь, если ваша версия событий верна, а Джон ошибается, вы очень быстро столкнетесь с проблемой, в которой буквально ничего нельзя будет улучшить. Теперь вы ударяете: «Джон, у тебя есть секунда? Я как раз об этом и говорил. НЕ будьте агрессивны или злорадствуйте, это честный вопрос: помните, Джон хочет только лучшего для команды.
После того, как вы сделали это несколько раз, и Джон потерпел неудачу, вы небрежно добавляете раздел на вики-страницу Джона под названием «Исключения» и перечисляете исключения. По мере того, как этот раздел разрастается одобренными Джоном исключениями, ему становится неловко, и он будет пересматривать свою позицию, делать ее менее жесткой. Джон поймет, что вы разумный парень, и с большей вероятностью учтет ваши опасения в будущем.
И если вы не получите такого списка исключений, возможно, Джон все-таки был прав, и его предложения, какими бы неуклюжими и неизящными они ни были, на самом деле улучшили вашу работу — и вы не встали у него на пути.
Это не будет популярным ответом или тем, что вы хотите услышать. Я думаю, что настоящая проблема заключена в этом предложении прямо здесь:
Я думаю, что большая проблема в нашей компании заключается в том, что нам (разработчикам) так много диктуют, что это душит любое стремление или чувство ответственности за повышение нашей производительности.
Похоже, на вашем рабочем месте много правил, бюрократии и общей культуры, которая душит часть удовольствия от программирования, и это (по понятным причинам) очень расстраивает. Итак, похоже, что вы набрасываетесь на просьбу Джона — не потому, что его просьба действительно имеет большое значение, а потому, что вы расстроены, а он не входит в вашу непосредственную цепочку подчинения, поэтому на него легко наброситься.
Просьба Джона разумна и мотивирована реальной необходимостью. Внешние аудиты и аккредитации являются обоснованной заботой руководителя отдела обеспечения качества и его вышестоящего руководства (даже если ваша компания не строго относится к их проведению). Если когда-нибудь будет проведен аудит, и они обнаружат проблему с дефектным программным обеспечением, проскользнувшим через ваш баг-трекер, или (что еще хуже) брешь в системе безопасности, которая прошла через ваш баг-трекер, и не будет комментариев, чтобы обеспечить какой-либо контекст для мыслительного процесса программиста, тогда оптика очень плоха для Джона и его отдела контроля качества. Первое, что они захотят узнать: «Почему ваши программисты не комментируют исправления ошибок?» И его лучшим ответом будет: «Потому что я позволил им не делать этого». Это неприемлемый ответ.
Джон не просит вас сделать что-то трудное. Если ошибка заключалась в том, что «кнопка отключена при нажатии флажка; не должна быть отключена», просто добавьте однострочный текст (точно так же, как вы (надеюсь) делаете в Subversion/Git: «фиксированная кнопка — больше не отключается при нажатии флажка "). Если вы перемещаете его из плавательной дорожки «В процессе» в «Завершение/приемка» (или любой другой процесс вашей компании), просто дайте Джону однострочный комментарий. Даже глупый / шаблонный комментарий. Главное, что нужно Джонсу, — это понимание свободного пространства программистов. Это занимает около 10 секунд и помогает удовлетворить насущную потребность.
Похоже, ваша компания хочет (по крайней мере , пытается ) писать хорошее программное обеспечение, поэтому они платят зарплату вашему отделу контроля качества. Борьба со способностью вашего отдела контроля качества защитить вашу компанию от некорректного программного обеспечения (даже если они делают это неправильно (по вашему мнению)) заставляет руководство выглядеть так, как будто вы трудны и работаете вразрез с реальным бизнесом. необходимость. Ваш босс не собирается вступать в эту битву, потому что знает, что это безнадежная кампания. Ваша компания не собирается мешать вашему отделу контроля качества (пытаться) выполнять свою работу. И аргумент Джона («Нам нужно, чтобы эта мелочь была более надежной для аудита») сильнее вашего («он мне не начальник»).
Наверняка вы как разработчик уже знакомы с концепцией человека, который знает, чего хочет, а что нет, но не может сформулировать набор четких и очевидных правил, описывающих это. Ирония в том, что ваш руководитель QA не может написать требования к этим комментариям об изменении статуса, богата, но это не помогает вам выполнять свою работу.
Я предлагаю вам подойти к коллеге и предложить (спросите, можно ли, предложить вам вдвоем) добавить несколько хороших и плохих примеров комментариев к начатой вики. Предложите поработать над ними вместе вслух до обновления вики. Поскольку вам не нравятся бессодержательные штампованные комментарии, вы можете включить некоторые из них («готово к тестированию», «программирование завершено», «как обсуждалось сегодня на схватке») к плохой стороне, и, если повезет, ваш руководитель отдела контроля качества предложит некоторые с хорошей стороны, которые решают проблемы, которые новое правило пытается предотвратить («переход к тестированию, даже если категории не в алфавитном порядке - клиент согласился, что нам это не нужно», «вернуться к коду, потому что клиент теперь хочет, чтобы все столбцы были центрированы» ) или нравилось в прошлом.
Вы должны выйти со встречи с
Что это может повредить?
Это работа вашего менеджера, если у команды возникла проблема с одним участником, менеджер уже должен был это заметить. Если нет, доведите это до его/ее внимания.
Все, что влияет на рабочий процесс и моральный дух команды, должно решаться менеджером. Это профессиональный путь, не ходить вокруг да около и не составлять собственные протоколы. Это одна из главных ролей менеджера.
Роб
кешлам
Роб
Замочить