Как вести себя со старшим коллегой с потенциально вредными рабочими привычками?

Другие ответы охватывают многое, но я добавлю кое-что немного другое.

Почему ваши процессы позволяют ему доступ к любому производственному серверу в открытой форме?

Вы должны настроить систему развертывания таким образом, чтобы она была автоматизированной, воспроизводимой и закрытой — никто не должен был иметь возможности обойти систему развертывания.

1. Удалите доступ всех разработчиков к производственным серверам. Разрешите им удаленный доступ к системным журналам и отладчикам, но не более того.

2. Выполняйте сборку и упаковку кода с помощью системы непрерывной интеграции, такой как TeamCity.

3. TeamCity создает ваши конкретные ветки и теги в git — запускайте модульные тесты и интеграционные тесты.

4. Разверните весь свой код с помощью автоматизированной системы развертывания, такой как Octopus Deploy — она возьмет упакованный вывод вашей системы CI и развернет его автоматическим и воспроизводимым образом в любой настроенной вами среде. Он может развертывать определенные ветки в вашей среде разработки, продвигать эти пакеты в UAT или Production, и он никогда не позволит вашим разработчикам возиться в рабочей среде. Это также дает вам полный журнал аудита того, что и где было развернуто.

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

Если у ваших разработчиков нет прав администратора на рабочих серверах, они не смогут обойти ваши процессы.

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

Изменить: также см. мой ответ на Как избежать плохих методов работы сотрудников , так как это также имеет отношение к вашей ситуации. Вам нужно действовать как привратник, и для этого вам нужно на самом деле использовать некоторые ворота на практике.

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

TeamCity и Octopus Deploy (вам не обязательно их использовать, есть и другие) довольно легко настроить и запустить — их установка и настройка займет день или около того, плюс час или около того на каждый проект. конфигурация.

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

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

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

Если он продолжит, отрежьте ему доступ к мастер-серверу и производственному серверу. Затем скажите ему, что он находится на PIP, где его первой задачей будет объяснить вам, как он намерен в будущем загружать свой код в Мастер и Производственный блок (*).

В качестве руководителя команды вам нужен старший разработчик. Тебе не нужна головная боль. В частности, головная боль, которая играет примадонну и ведет себя так, как будто правила должны применяться ко всем, кроме него.

(*) Он должен сказать вам, потому что вы уже прямо сказали ему, и он не воспринял то, что вы сказали, достаточно серьезно, чтобы понять это. Когда разум не работает, попробуйте религию, например, штуку "молния на дороге в Дамаск" - я чрезвычайно гибок в своих методах управления и подходе :)

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

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

У такого человека, скорее всего, будет готовый ответ, потому что это не первый раз, когда кто-то говорит ему это. Я не могу сказать, каким будет этот ответ, но он будет намного ближе к реальной проблеме. Он будет на открытом воздухе, так что вы можете справиться с ним лучше.

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

Дайте понять, что это абсолютно необходимо.

Вы уже сделали это? Как руководитель я знаю, что может быть трудно напрямую противостоять сотрудникам, когда они делают что-то неприемлемое. Вы упомянули, что был примерно такой разговор:

Вы: Не могли бы вы организовать свой код и правильно использовать рабочий процесс разработки, который мы обсуждали.

Старший разработчик: Я еще не дошел до этого, потому что мне нужно выпустить эти срочные функции.

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

Шаг первый — четко сформулировать, что вы ожидаете.

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

Второй шаг — оказать ему поддержку в изучении процесса.

Я бы предложил ему, чтобы другой разработчик показал, как это устроено. Вы говорите, что проблема в его незнании Git (несмотря на то, что он утверждает, что знает). Если вы не уверены в этом на 100%, нет необходимости обращаться к нему напрямую. Просто укажите, что ему было бы проще и быстрее увидеть, как кто-то уже настроил его, и это гарантировало бы, что все делают все одинаково.

В долгосрочной перспективе, если существует систематическая схема сокрытия того факта, что он чего-то не знает с помощью обходных путей, то это проблема, которую необходимо каким-то образом решить (поскольку это будет весьма пагубно).

Третий шаг — эскалация — только если вышеперечисленное не работает.

Другие ответы дали указания о том, как это сделать.

Сделать предпочтительный путь фиксации обязательным — это хорошая практика сама по себе, но не используйте ее для решения этой проблемы.

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

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

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

Приоритеты: вы несете ответственность за четкое определение приоритетов. Если он уходит в другом направлении после того, как вы это сделали, и он подтвердил это, он вам не нужен в команде. Скажи ему так.

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

Дайте ему честный шанс объяснить, почему этот случай был особенным... но если у него нет адекватной защиты (по вашему мнению, не его) и он не готов обещать, что это больше не повторится, это пора поговорить с его менеджером.

Здесь необходимы 2 линии атаки:

1. Вам нужен процесс, который позволяет легко делать правильные вещи и трудно делать неправильные.
2. Вам нужно, чтобы команда согласилась/приняла то, что правильно.

Ответ moo уже охватывает 1), поэтому я сосредоточусь на 2).

Ваша команда должна знать, что им нужна стабильная ветка, несколько стабильная общая ветка и общая стратегия слияния, которая гарантирует, что люди знают, какое изменение находится в какой ветке, что означает, что все объединяют вещи через ветки в одном и том же порядке. Если они этого не знают, отправьте их на обязательное обучение, которое проводит третья сторона . Да, это дорого, но иметь команду, не понимающую ветвление, в долгосрочной перспективе дороже.

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

Вы можете облегчить командную работу ретроспективами, встречами, на которых после каждой фичи/вехи/спринта команда собирается вместе и обсуждает, как можно было бы добиться большего успеха, как команда – частота таких мероприятий должна быть примерно раз в 1-4 недели, и вы можете найти тонны материалов о ретроспективах в Интернете. Если команда знает о ветвлении, то во время ретроспектив ваш единственный разработчик должен получить критику от всей команды, а не от вас. Затем вы можете направить команду на внедрение автоматизированных процессов, которые упрощают выполнение правильных действий и затрудняют выполнение неправильных действий. Это процессы, описанные в ответе му.

Вообще говоря, как непосредственный руководитель, вы не можете просто внедрить и обеспечить выполнение большого процесса, с которым не согласна ваша команда, без очень высокого риска последствий. Если они не знают о правильном ветвлении, вам нужно обучить их «правильному пути», тогда вы можете внедрить и внедрить второстепенные процессы, чтобы заставить их работать в команде: один из распространенных способов в вашем случае — потребовать код обзор слияния с Develop и Master; в следующий раз, когда слияние будет выполнено неправильно, теперь вы можете спросить двух человек, что пошло не так, кодировщика и рецензента.

Вы делаете это, устанавливая жесткие, физические политики, которые требуют, чтобы изменения проверялись в конкретном репо, иначе они не будут развернуты, что означает, что работа не выполняется, что означает, что он не выполняет свою работу, и это является основанием для прекращение. Если структура вашей команды «расслаблена», а разработчики имеют ключи к производству и могут развертывать их самостоятельно или имеют учетные данные БД для самостоятельного развертывания изменений схемы БД и не проходят надлежащие ПРОТОКОЛЫ, УСТАНОВЛЕННЫЕ РУКОВОДСТВОМ , вывод прост: вы плохо справляетесь. Управление в среде разработки программного обеспечения в основном заключается в разработке командных правил и протоколов, которые члены команды ДОЛЖНЫ соблюдать, а не в ежедневном присмотре за разработчиками.

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

Есть одна возможность, о которой никто не подумал: этот старший разработчик просто не понимает, как должен работать рабочий процесс и что он должен делать, чтобы оставаться в рамках этого рабочего процесса. Что он так и не научился правильно использовать git.

Если он использует git напрямую, то все, что ему нужно сделать, на самом деле довольно сложно, так что, надеюсь, у вас есть какой-нибудь дополнительный инструмент. Sourcetree работает достаточно хорошо; Я уверен, что есть и другие. После правильной настройки (что может быть болью) это делает жизнь намного проще.

Возьмите одного из разработчиков, который все делает правильно, и проверьте у него, как устроена машина этого парня. Есть ли у него инструменты, которые есть у всех? Если нет, установите их. Может ли он создать ветку? (На моей машине это выбор ветки, из которой вы хотите перейти, выбор одного пункта меню и ввод имени новой ветки). Без правильных инструментов это боль. Может быть, он действительно не знает, как это сделать.

Пройдите с ним через все, что ему нужно сделать. Заставьте его записать все шаги, которые ему нужно сделать. Вот что я сделал, когда впервые использовал git: я все записал. Во второй и третий раз я усовершенствовал то, что записал, потому что это не совсем сработало и были ситуации, которых я не предвидел. С четвертого по десятый раз я использовал свои заметки, чтобы что-то делать, а потом они мне уже не понадобились. Я мог видеть кого-то, кто не знал, какие инструменты использовать и как их использовать, был слишком гордым или упрямым, чтобы просить кого-либо о помощи, и создавал нечестивый беспорядок на своем пути.

Ух ты. Просто вау. Это настолько непрофессионально, просто невероятно. Но сначала поговорите с HR, чтобы убедиться, что они в курсе и что вы не делаете ничего, что может создать юридические проблемы для вашей компании. Затем вы разговариваете с ним, принимая во внимание любые советы HR, и говорите ему, что если он еще раз повторит это, вы примете меры, чтобы исключить его из команды. Что, вероятно, означает от компании.

Убедитесь, что отдел кадров понимает, какой ущерб может нанести такое безответственное поведение.

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

Каковы риски: Сломанный рабочий сервер представляет собой меньший риск. Рабочий сервер, допускающий дорогостоящие ошибки, представляет собой большой риск. Представьте себе сервер электронной коммерции, который взимает НДС, а не добавляет его к цене. У вас будет много-много очень довольных клиентов.

Является ли это блокировщиком: Не совсем. Когда я делаю ветку, я полностью ожидаю, что ветка разработки будет изменена, когда я хочу слить, так что никакой разницы нет. Если он переходит от ветки разработки к ветке master, это другое дело. Того, кто отвечает за ветку master, ждет большой сюрприз. С другой стороны, если бы я отвечал за основную ветку, то все несанкционированное было бы удалено, и тогда у того, кто это сделал, были бы проблемы.

Резюме:

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

  • т.е. в то время как большинство «бедствий» происходят из-за того, что несколько явно не связанных между собой и статистически невероятных событий произошли одновременно. В этом случае может быть достаточно одного события.

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

  • т.е. разработчик и, следовательно, вы, как его менеджер, можете (и, вероятно, подвергаете) проект риску больших потерь (измеряемых с точки зрения времени, ресурсов, потребности в воспроизведении работы, целостности системы, доверия клиентов и т. д. и т. д.). в конечном счете в $.Если такое событие произошло и было серьезным, даже если не «наихудшим случаем», нет оснований ожидать, что вы не потеряете работу.

• Вышеупомянутая потеря неизвестной пока величины может произойти в любое время - на следующей неделе, сегодня или никогда.

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

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

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

_______________________________________________________

Новый вопрос для вашего списка:

Q0: «Каковы мои самые неотложные приоритеты?»

A0: УБЕДИТЕСЬ, что то, что у вас есть, устойчиво к катастрофическим потерям.

Это не звучит так.
Если нет, то сделайте так.
В настоящее время!

_________________________

Возможные краткосрочные опасности и последствия и лучший путь вперед:

Следующее не должно быть грубым, но должно быть «надежным». Обязательно скажите, если не согласны. Если вы согласны. сделайте что-нибудь подходящее СЕЙЧАС.

Вы (или другие) упоминаете «украденную машину, неопределенность в отношении« резервных копий »и т. д. ....
Если вы не ЗНАЕТЕ , застрахованы ли вы от каких-либо единичных катастроф, то это ВАША« вина », если что-то произойдет, что уничтожит неизвестную пропорцию Если
это произойдет каким-либо значительным образом, вы должны быть уволены и, вероятно, будете уволены после того, как предпримете все возможные меры по исправлению положения.

Без дальнейшего ввода, посмотрите на свой второй (теперь третий) вопрос, решите, какие риски МОГУТ существовать, о которых вы не знаете, потому что система не контролируется, и примите немедленные меры для устранения этих рисков. Это может включать замораживание всей активности и/или файлов и/или ??? разработчиком. Значит, вовлекает их в процесс.

______________

Предложения по пунктам, которые должны стать частью (срочного) интервью с разработчиком:

Я так понимаю ххх дело. Это так да/нет?
Если я неправильно понимаю, поясните.

OK - если yyy произойдет, каков будет результат?
(Если ответ неверный, объясните, почему, и повторяйте до тех пор, пока не будет достигнуто соглашение.
(Если итерационный цикл не закроется после чрезмерного периода времени, используйте « 45 Clear » или приемлемый местный эквивалент :-( :-))

После того, как будут сделаны выводы о последствиях. Это неприемлемо для меня. Это ставит меня/компанию/систему в неприемлемо опасную ситуацию. Это ДОЛЖНО быть рассмотрено вчера. Я собираюсь реализовать xxx. Вы согласны? / Можете ли вы предложить альтернативы? Опять же, может возникнуть итеративный цикл. Опять же, может потребоваться использование "GOTO" ( или нет :-} ).

Если вы не сделаете это или что-то подобное, вы будете уволены. Когда-то.