Недавно я был принят на работу в крупную организацию в Великобритании в рамках масштабной кампании по найму, в которой участвовал бизнес в отношении их функции развития. Я старший разработчик, и мой менеджер отвечает за весь отдел.
Около 75% отдела являются новыми, и на подходе будет больше людей, поэтому на данный момент все еще предстоит установить. В настоящее время в отделе работает примерно 50/60 человек, а структура отчетности находится в постоянном движении с различными названиями должностей и странными линиями подчинения.
Насколько мне известно, я отчитываюсь перед своим менеджером по вашим обычным функциям отдела кадров (оценки, отпуска и т. д.). Для повседневных задач это зависит от того, какой проект вам был назначен.
Меня недавно поставили на проект. Компания реализует проекты, используя хорошо зарекомендовавший себя Agile-подход. Большое внимание уделяется сотрудничеству и общению.
Сам проект предельно прост. Я и очень небольшая команда новичков были поставлены перед задачей.
За проектом «наблюдает» другой старший разработчик (который, как мне кажется, работает здесь уже несколько лет), который за пределами организации называет себя «ведущим разработчиком». Он с большим энтузиазмом относится ко всей теме разработки, почти до такой степени, что кажется, что он «слишком старается». Он довольно властен в том, как он проинформировал нас, навязывая свои собственные сроки и результаты и даже преуменьшая сложность поставленной перед нами задачи.
Другие люди уже прокомментировали этого человека и его личность.
Я заметил, что на выходных, в нерабочее время, он сильно переделывал код (в том числе удалял различные части системы), хотя этот проект, очевидно, предназначался для того, чтобы мы, новички, могли отточить свои зубы. как команда. Здесь не было отправлено никакого сообщения/электронной почты — я полагаю, он просто изменил его, чтобы соответствовать его собственным «стандартам».
Это, конечно, не определение командной работы, и возникает вопрос, зачем вообще нужна была команда для завершения проекта.
Итак, вопрос; что мне здесь делать?
Первый подход — поговорить с моим руководителем — сообщить ему об этом как о проблеме? Я чувствую, что он разумен, но я новичок в компании, а этот разработчик — нет. Это может осложнить мою жизнь в отделе.
Второй подход — опубликовать мое резюме и переехать как можно скорее. Это, конечно, в некотором смысле легкий вариант, но я чувствую, что сдаюсь.
Третий подход заключается в том, чтобы обсудить это непосредственно с указанным разработчиком. Это, на мой взгляд, самый рискованный подход, учитывая его властный характер. Учитывая, что я новичок в компании, он может расценить это как вызов своей собственной власти.
В вашу организацию пришел огромный приток новых людей, и вы можете ожидать, что некоторые люди не справятся с ситуацией гладко. Наличие такого количества людей в вашем отделе ставит под угрозу стабильность и создает нагрузку на организационные структуры.
В вашей ситуации у вас есть коллега/руководитель, который, вероятно, чувствует угрозу и неуверенность. Он проявляет это, реагируя с властной и самонадеянной властью. Люди часто действуют способами, противоположными тому, что они чувствуют. Изменяя кучу кода без разрешения или общения, этот человек восстанавливает некоторую степень контроля и реагирует на эту новую среду, о которой он, вероятно, не просил.
Я думаю, что лучший способ решить эту проблему — сделать несколько жестов доброты этому человеку. Познакомьтесь с ним поближе, а затем попросите рассказать вам об изменениях, которые он вносит. Идея состоит в том, чтобы развить уровень доверия между вами и ним. Как только доверие установлено, вероятность того, что он будет вести себя бесполезно, гораздо меньше, или, по крайней мере, он находится в лучшем положении, чтобы с ним можно было договориться.
Может показаться, что этот совет применим к детям, и это не случайно. Взрослые часто ведут себя по-детски, когда оказываются в ситуации, когда они потеряли (или считают, что потеряли) контроль.
Бегство к руководству с этой проблемой поставит на их стол еще одну сложную проблему и, вероятно, вызовет еще худшую реакцию со стороны властного. Вы всегда можете уйти, если проблема станет неразрешимой, но на этом этапе стоит приложить усилия для ее решения. Люди выживали и процветали в гораздо худших ситуациях, чем ваша. Итак, я думаю, что «третий подход» на самом деле самый безопасный, если вы СНАЧАЛА работаете над установлением доверительных отношений с этим человеком и работаете с ним как с союзником.
Это все еще довольно ранние дни с этой компанией. Прежде чем официально поднять этот вопрос, можно пойти выпить кофе с другими людьми, которые тоже работают в компании несколько лет, и (тактично) спросить их об этом. Он может быть хорошо известен такими вещами.
Поскольку вы еще не знаете, как обстоят дела, я бы порекомендовал вести себя неконфликтно, вы можете осветить проблемы, которые у вас есть, с помощью электронного письма, номинально адресованного этому парню, но с копиями всех участников проекта (включая ваших менеджер), где вы задаете ряд невинных вопросов вроде «Я заметил, что код для завершения xyz был отредактирован в виде abc перед выпуском, можете ли вы подтвердить, почему / в чем проблема и т. д., чтобы мы могли избежать эти ошибки в будущем"
Я бы подошел к проблеме с простой точки зрения. Он внес некоторые изменения в код, но никому об этом не сообщил, верно? Если ему нравится авторитет и власть, просто скормите ему это. Когда у вас есть случайный момент (обед, возле кулера с водой и т. д.), спросите его вежливо, но в то же время с восхищением (подлизывание — это инструмент, который следует разумно использовать с вышестоящими сотрудниками).
«Привет, имя, я заметил, что ты сделал X изменений в коде ABC. Было интересно, какой код был раньше? Я просто хотел знать, чтобы снова быть в поиске подобных ситуаций. В чем была проблема с этим ( придумать какие-то общие причины, такие как плохая оптимизация, использование оперативной памяти и т. д.)?»
Это нравится его управленческой персоне и тонко восхищает его навыками кодирования, но не звучит некомпетентно. Как только вы узнаете, почему он сделал редактирование, у вас есть 2 решения:
«О, хорошо. Я всегда действовал так, чтобы убедиться, что каждый чувствует, что его работа ценится и ценится. Если у кого-то есть проблемы с кодом, я хочу обязательно показать им, как они могут улучшить его в будущем, и научить их некоторым трюкам, которые мы могли бы сделать. знаю. Кроме того, хорошо держать других в курсе на тот случай, если что-то зависит от этих кодов и есть проблемы с кросс-функциональностью/и т. д. Нет? (Добавьте смех с «а» здесь для беззаботного эффекта)»
Как инженер, я могу засвидетельствовать, что временами упрямый разработчик вызывает трения внутри команды; Я также могу засвидетельствовать, что некоторые из лучших разработчиков программного обеспечения, которых я знаю, являются этими людьми. Конечно, я не могу сказать так или иначе из вашего вопроса, так как он был представлен в сокращенной форме. Ваш сверстник может быть настолько невыносимым, насколько это подразумевается, и в этом случае вполне уместно сообщить о своих опасениях вашему руководителю. С другой стороны, возможно, вы сможете использовать этого человека для роста внутри компании.
Спросите его, почему он изменил код на выходных. Что, по его мнению, было неправильным, и почему он изменил это именно так? Если он был там какое-то время, у него могут быть какие-то племенные знания, о которых новые члены команды не знают. Если он меняет код, потому что считает, что может сделать это лучше, возможно, будет более конструктивно проводить документированные обзоры кода, если это позволяет ваш гибкий процесс. Это узаконило бы его редактирование кода ниндзя, но сделало бы его прозрачным для всех. Это уже не будет «ниндзя», просто обычная практика разработки.
папарацци
Анкетам
РедСоня