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

Боб Глаусл

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

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

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

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

Как вырваться из этого порочного круга? Как обратиться к руководству по этому поводу?

пользователь34102

Если вы студент, вы, вероятно, ничего не можете сделать; это управленческая задача - установить некоторые стандарты и заставить их использовать всю компанию.

БСМП

Вы менеджер этого человека?

Боб Глаусл

Нет, мы вообще в разных командах.

БСМП

Согласна ли администрация с этой ситуацией? Влияет ли это на вашу собственную работу?

рат

Вместо того, чтобы быть враждебным и идти Смотри! Он самоутверждается! Несправедливый! вы должны обратиться к руководству за готовностью к тому, что ваш коллега попадет под автобус

смки

В чем конкретно для вас это проблема? Вы продолжаете говорить «мы», но вы не компания. Когда вы спрашиваете «Как с ними справиться...?», какие конкретно проблемы это вызвало у вас за последние несколько месяцев? Может быть, они не доверяют руководству, но если вы попросите их объяснить вам что-то (устно, на примере, как угодно), они сделают это или нет?

Кносс

@bobglausl: Процитируйте Bus Factor своему руководству. -- en.wikipedia.org/wiki/Bus_factor

Марк Роджерс

Кто знает, какова защита разработчика-нарушителя? Возможно, разработчик-нарушитель делает то, что ожидает руководство, и это действительно неправильно понимает ОП. Трудно объективно сказать, что здесь происходит.

Нил П.

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

cst1992

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

Боб Глаусл

@ cst1992 Это потому, что это напрямую влияет на мою работу.

Т. Сар

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

пользователь44634

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

ланчмясо317

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

Марк Роджерс

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

StartupGuy

Что он кодирует? У нас был разработчик, который делал это с проектами .Net. Мы декомпилировали все его "секретные" библиотеки DLL, убедились, что стек работает с декомпилированным кодом, и уволили его. Если вы не можете выйти, как предложил @Jasper

тиего1967

@MarkRogers, дело в том, что все хотят накапливать свой опыт, и в этой области многие люди стремятся быть в курсе последних событий. Это может происходить как с целыми группами, так и с отдельными людьми. Иногда люди бросаются вперед и начинают делать то, к чему они не готовы или с чем не знакомы, чтобы продвинуться вперед. Это не обязательно плохо, это демонстрирует готовность развиваться. ИМХО гораздо хуже иметь дело с новичками, которые не хотят пробовать новое.

Марк Роджерс

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

Карл Виттофт

Скопируйте его! Снизьте нагрузку и повысьте безопасность своей работы!

БезнадежныйN00b

Почему вы говорите, что его код не решает проблем? Звучит так, как будто это решает его проблему безопасности на работе.

эш

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

бобо2000

Гай гений, если честно. +1 Согласен с @CarlWitthoft

Саша

Интересно, чем закончилась эта история...

Юха Унтинен

Хотя я вижу, откуда он. В большинстве контрактов обычно говорится, перефразируя: «любой код, написанный в рабочее время, принадлежит компании». Таким образом, написав тонкий клиент для фактического кода, который он использует, он защищает свою реализацию и позволяет ему повторно использовать внешний код в другом месте.

АндрейROM

Вам необходимо составить отчет для руководства.

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

Также включите список способов, которыми подход этого парня вредит вашей собственной работе, а также работе ваших коллег.

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

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

Боб Глаусл

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

АндрейROM

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

HLGEM

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

БСМП

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

БСМП

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

алефзеро

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

jpmc26

"к которому у всех есть доступ" ... Я думаю, вы имеете в виду "к которому имеют доступ несколько человек".

смки

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

Джимм101

Это проблема управления .

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

Существует более серьезная проблема, чем гарантия занятости .

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

Моника Челлио

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .

Деннис Джахеруддин

Достойный ответ, но еще не полный. Если руководство считает сотрудника достаточно безупречным, оно не будет этим тронуто. -- Если бы вы включили риск недоступности (болезнь/отпуск, попадание под автобус), было бы здорово.

Майлз

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

Джимм101

@Myles Это обсуждалось в одном из удаленных комментариев.

Майлз

@ jimm101 jimm101 Видя, что в удаленных комментариях вы согласны с тем, что это слабое место в ответе, я отправлю запрос на редактирование.

Вальфрат

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

Джурис

К сожалению, вы на самом деле не сказали, говорил ли кто-нибудь об этих проблемах с коллегой или руководством. Это действительно злонамеренно? Или ваш коллега просто слеп? А может руководство слепое?

Я сам был "тем" парнем.

На моей предыдущей работе у меня иногда были различные побочные задачи, чтобы «сделать этот маленький инструмент» или сделать что-то простое. Получается, ресурсов для внутреннего софта никогда не бывает... Обычно это происходило примерно так:

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

-- Могу ли я создать для этого виртуальный сервер на нашем сервере? -- Чувак, это только для внутреннего пользования. Просто поместите его вместе с другими вещами в эту сломанную физическую коробку. Или поставить его на ту коробку, которая делает мы-не-знаем-какие функции. Или поставить на свою рабочую станцию.

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

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

Редактировать

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

Дело в том, что я не хочу заставлять своих бывших коллег «лучше проводить исследования» вместо того, чтобы просто спросить меня: «На какой машине работает Veeam?» если я могу просто назвать имя или IP-адрес, не задумываясь, или сказать: «Это должно быть написано [..]». Кроме того, двухминутный телефонный разговор с бывшим коллегой обычно является таким же позитивным и расслабляющим отвлечением, как посещение биржи стека.

Изменить конец

Итак, что я могу предложить? Ваш коллега кажется вполне способным, не так ли? Обсудите это с руководством. Не говорите, что «он становится незаменимым». Просто спросите их - а что, если он уйдет? А если он заболеет надолго? Убедите их, что проблема реальна. Они должны сами обсудить это с этим парнем, чтобы найти решение. Может ему просто не хватает ресурсов? Может быть, ему нужен еще один человек в команде «внутреннего программного обеспечения», чтобы сделать все красиво и красиво?

бричины

"Almost a year has passed and I still receive multiple calls every month"- и вы будете продолжать получать звонки до тех пор, пока будете предоставлять бесплатную поддержку и документацию (я предполагаю, что написание документов по выходным не оплачивалось). Вы там больше не работаете — если вы им так нужны, они могут заплатить вам за звонки в службу поддержки или за документирование/поддержку реализованных вами проектов. Вы думаете, что помогаете своим бывшим коллегам, но на самом деле вы просто позволяете руководству продолжать плохие методы, ставя оставшихся разработчиков в такое же положение.

Джурис

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

бричины

Почему вы не можете отказаться им «помочь»? Даже если разработчики являются личными друзьями вне работы (что сильно отличается от «рабочих друзей»), им платят за работу там, а вам — нет. Почувствовать себя «нужным и важным» в обмен на неоплачиваемую работу — это (косвенное) оскорбительное отношение к компании. Предоставление бесплатной помощи снижает (воспринимаемую) ценность сотрудников, устанавливает нереалистичные ожидания в отношении стоимости/требований проекта и побуждает менеджеров продолжать плохо относиться к разработчикам. Либо примите справедливую оплату напрямую от компании, либо перестаньте работать бесплатно и подрывать будущее своих друзей.

Эд Грибель

@brichins полностью прав. Поскольку поддержка предоставляется бесплатно, у «руководства» нет стимула решать проблему и выделять ресурсы (например, бывших коллег) для решения проблемы.

БобРодес

@Juris, вы почувствуете себя более нужным и важным, когда вам будут платить за ваше время по часам. Скажите им, что вы дадите им еще x часов свободного времени, и после этого счетчик должен начать работать, потому что у вас есть другие обязанности, за которые люди вам платят. Удивительно, насколько лучше люди изучают свои вопросы, когда они платят ответчику 80 долларов в час или около того. Так что, действительно, вы делаете им одолжение, обвиняя их. Побуждая их больше ценить ваше время, вы заставляете их также больше ценить свое.

Джурис

@BobRodes, может быть, ты меня неправильно понял. Я не трачу время на решение проблем, просто отвечаю на вопросы о том, что и как я сделал.

тиего1967

Я думаю, что некоторые комментаторы здесь работают в очень структурированной среде, где разработка программного обеспечения является «основной работой» организации. Но есть много компаний, не занимающихся программным обеспечением, которые до сих пор занимаются «разработкой программного обеспечения» только для удовлетворения внутренних потребностей или в качестве побочных проектов. В таких местах есть руководство, которое совершенно неправильно понимает природу разработки программного обеспечения, поэтому в итоге вы получаете специальные проекты, плохое планирование и отсутствие мыслей о поддержке. Это не оптимально, но с этого начинают МНОГИЕ люди. Сменить такую ​​организацию — все равно, что вскипятить океан для отдельного человека.

БобРодес

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

Симулятор проницательности

@ teego1967 Я могу сочувствовать этому комментарию, потому что я был этим человеком. Не до такой степени, как в вопросе OP, но я сделал несколько инструментов и баз данных для использования в масштабах всей компании (для небольшой производственной компании). Отчасти потому, что я знал о проблеме не понаслышке, но в основном потому, что если бы я ждал, пока это сделает корпоративный ИТ-отдел, то это никогда не было бы сделано. Тем не менее, это всегда было с намерением «Давайте попробуем это, и если это работает достаточно хорошо, тогда ИТ-отдел не может позволить себе не поддерживать его».

тиего1967

Большинство из этих ответов ПУТЕШЕСТВУЮТ ЗА БОРТОМ, если предположить злонамеренность со стороны рассматриваемого разработчика.

Прежде чем сделать тайный образ сервера, а затем вывести парня из офиса, почему бы просто не перевести дух и не попытаться понять, что происходит?

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

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

Боб Глаусл

У них есть ресурсы и время для правильной разработки своих программ, просто они не сотрудничают и страдают от того же синдрома, что и разработчики Gnome 3, то есть они думают, что лучше пользователей знают, чего хотят пользователи. Их программы работают большую часть времени, за исключением тех случаев, когда они не работают — тогда вы остаетесь ни с чем, потому что то, что вы запускаете на своей машине, — это тонкий клиент, и у вас нет доступа к серверу, чтобы вы могли даже не сказать, что именно пошло не так. Это было что-то, что вы сделали? Проблемы с подключением к сети? Сервер не работает? Не могу сказать, потому что ошибки вообще не описательные.

смки

@bobglausl: тогда пусть они улучшат свои сообщения об ошибках в качестве первой задачи.

кубанчик

Да. Я чувствую запах переутомления. Вероятно, парень слишком долго подвергался грубому давлению из-за критически важных внутренних приложений (которые теперь являются просто «инструментами», поскольку теперь они работают), и он решил позволить своим ничтожным менеджерам полностью справиться со своей ответственностью. Не уделял приоритетное внимание серверу git — хорошо, его нет. Админа не назначал - ладно, его нет. Не запланировал время, чтобы сообщить эти самые вопросы - хорошо, так что вы не узнаете об этом. И, наконец, его втянули в эту рутину, и теперь он бессознательно повторяет ее, даже если теперь у него больше времени. Сгорел. Просто моя дикая догадка.

Филип Окли

@bobglausl в исходном вопросе вы говорите «коллега» в единственном числе, но затем в комментарии здесь вы говорите «они». Что он? Я подозреваю, что вы говорите, что компания (сейчас?) достаточно велика, чтобы позволить себе ресурсы (но не имеет), и что сотрудник стал марионеткой для этого «бережного использования ресурсов». Сотрудник, возможно, был там, когда ресурсы были действительно ограничены. Во многом это нормально. Не вините никого, помогайте всем. Всем нам время от времени нужна помощь.

пользователь985366

@PhilipOakley «Они» можно использовать для обозначения одного человека. См. en.wikipedia.org/wiki/Singular_they

Шаути

@ user985366 только на некоторых диалектах английского языка, понятных небольшой группе людей.

Марк Бут

В единственном числе они не редкость @Shautieh и с каждым разом становятся все более распространенными.

Филип Окли

@MarkBooth как бы задает вопрос, продвигаются ли пользователи их к единственному числу (риторические/улыбки). Сила и слабость английского языка в том, что он постоянно меняется в употреблении и идиомах, а также в непонимании; Как говорится,- Америка и Британия, две нации, разделенные общим языком.

Марк Бут

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

Шаути

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

Марк Бут

Если королева может быть «мы», остальные могут быть «они» @Shautieh. Если вы хотите быть ограниченным викторианским женоненавистничеством, не стесняйтесь, но ваш «правильный английский» не так распространен, как вам кажется, и неуместен в открытом, эгалитарном обществе 21-го века. Тем не менее , дальнейшее обсуждение следует проводить в чате Workplace .

пользователь64742

@Shautieh термин «они» везде используется как местоимение в единственном числе. Это не малоизвестный диалект. Я слышал это от всех слоев общества, отовсюду, по всему Интернету. Я думаю, вы просто неправильно понимаете язык.

пользователь30031

Этот спор о семантике относится к другому месту.

пользователь30031

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

тиего1967

@DoritoStyle, абсолютно нет, намерения коллеги - это самое важное, что следует учитывать при принятии решения о том, как реагировать. Тот, кто имеет незлобные намерения, будет готов измениться или сотрудничать и все исправить.

пользователь30031

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

Билл Липер

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

Джаспер

Есть кое-что, чего я еще не видел в других ответах:

Случайно начните искать новую работу

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

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

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

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

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

скрежет729

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

Джаспер

@ gnasher729 Причиной увольнения является не плохое поведение другого сотрудника. Это неспособность компании справиться с этой ситуацией и, следовательно, неспособность создать хорошую рабочую среду.

WoJ

@Jasper ... и, следовательно, провал компании, точка. Искать новую работу в качестве подстраховки — неплохая идея.

StartupGuy

Я не могу поверить, что это не самый популярный ответ. Я был именно в этой ситуации. Либо (A), карточный домик рухнет, и теперь вам нужно его починить, потому что злой разработчик ушел, независимо от того, признает или нет mgmt, или даже заботится о том, что он был злым, а вы были правы (B) mgmt продолжит принимать плохие решения, и в конечном итоге вам придется уволить людей, и угадайте, что ... они не нуждаются в вас, но другой парень укоренился, так что вы ушли. Серьезно, я был там, и это культурная вещь, которую вы не можете изменить больше, чем вы можете заставить немцев не пить пиво на Октоберфесте!

Чемби

У вас, ребята, есть отличное замечание по поводу корпоративной культуры, но я все еще не думаю, что лучшим решением будет немедленно искать другую работу. Многие небольшие или новые компании все еще ищут наилучший способ ведения бизнеса, поэтому тот факт, что у небольшой команды разработчиков есть «простой» надзор (по меркам менеджера, который может не до конца его понимать), не означает, что вся компания разрушен. Конечно, вы могли бы быть правы, но, основываясь на имеющейся у нас информации, трудно сказать наверняка.

Симулятор проницательности

Не понимаю, как это означает уход из компании... это не проблема, пока она не станет проблемой, в которой прямо сейчас это не так; это риск.

Джаспер

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

Бодо Тисен

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

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

Итак, следующая дорожная карта пытается одновременно выполнить две задачи: 1) постараться свести к минимуму потенциальный ущерб, который эти коллеги могут нанести, если они злонамеренны, и 2) постараться удержать их в компании (чтобы они могли развиться до сотрудничества). коллеги в будущем), если они дружелюбны:

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

1.) Тихо делайте резервные копии всего, к чему вы можете получить доступ. Не выключайте системы в процессе, отключение систем потенциально может спровоцировать некоторые виды ловушек.

2.) Придумайте причину, по которой рабочие станции должны быть выключены. Если вам нужна идея, свяжитесь со мной в частном порядке.

3.) Извлеките жесткие диски, сделайте полный образ, вставьте их обратно. Сделайте это в выходные или около того.

4.) Если в системах есть средства обнаружения вторжений на уровне BIOS, и вы не можете их обойти, придумайте другую причину, почему эти системы обнаружения вторжений сработали.

Эти коллеги создают инструменты для внутренних дел, верно? Значит, им не нужен доступ к клиентским системам и тому подобное?

5.) Если у них есть доступ к системам, которые им не нужны, смените пароли, убедитесь, что нет входа по открытому ключу, проверьте порты на наличие процессов, допускающих нестандартный вход. Проверьте задания cron/at, проверьте inetd, проверьте все, что работает в данный момент. Для каждого отдельного pid вы должны быть в состоянии ответить, почему этот процесс вообще выполняется.

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

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

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

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

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

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

Боб Глаусл

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

Бодо Тисен

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

Бодо Тисен

И, пожалуйста, обратите внимание на ответ @Juris. Он все равно попадет в категорию дружелюбных, но, возможно, его даже не нужно будет ничему учить, а просто поддерживать дополнительными разработчиками.

пользователь64742

Я считаю, что проблема здесь в том, что ОДИН сотрудник потенциально злонамерен, а не вся команда. Тем не менее, хороший ответ.

Бодо Тисен

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

пользователь30031

@bobo-thiesen, ты неправильно понял контекст. Местоимение относится к подлежащему «мой коллега», которое явно стоит в единственном числе.

Джаспер

«Если вам нужна идея, свяжитесь со мной лично». Такое заявление действительно не принадлежит SE. (Если бы это было так, не думаете ли вы, что в SE была бы система личных сообщений?)

Бодо Тисен

@Jasper: Если вам не нравится мой ответ, улучшите его (посмотрите, будут ли ваши улучшения приняты мной или воронами) или напишите свой собственный.

Джаспер

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

Билл Липер

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

  1. Защитите компьютер. Либо пригласите руководство и ИТ-эксперта, когда он будет разблокирован и оставлен без присмотра, либо пойдите и потребуйте, чтобы он разблокировал машину и предоставил доступ. Тогда отключите этого монстра от сети. Сделайте немедленное изображение HD в случае, если у него есть выключатель мертвого человека.

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

  3. Собери команду. Объясните, что пошло не так. Этот человек действовал безрассудно и непрофессионально. Он подверг компанию риску и был уволен за это. Чтобы разобраться с этим беспорядком, потребуются все ресурсы, которые у нас есть.

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

  5. Пригласите эксперта по безопасности. Этот парень, скорее всего, не будет молчать и попытается «взломать» обратно, чтобы саботировать или иным образом получить доступ к своей системе. У него также могут быть глобальные пароли к системам, с которыми он взаимодействовал, или с течением времени они получали индивидуальные пароли. ИТ-отдел должен инициировать принудительный сброс пароля для всех пользователей и блокировать любой доступ извне на какое-то время (например, VPN).

jpmc26

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

Тим Б.

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

Эмори

@ jpmc26 Я согласен, что это ответ, адресованный руководству (а не OP). Для управления я рекомендую text.sourcegraph.com/… вместо этого подхода.

Моника Челлио

Комментарии не для расширенного обсуждения; этот разговор был перемещен в чат .

пользователь1172763

Вы звучите весело (НЕ!)

пользователь64742

Это кажется невероятно жестоким. Что, парень просто некомпетентен?

Билл Липер

@TheGreatDuck это очень опасная ситуация для компании. Если в компьютере этого человека произойдет сбой жесткого диска, потери могут быть катастрофическими. Так что, даже если он некомпетентен, это справедливая реакция и даже более важная причина, чтобы исключить его из команды.

пользователь64742

@BillLeeper "Защитите компьютер. Либо попросите руководство и ИТ-эксперта пройтись, когда он разблокирован и оставлен без присмотра, либо пойти и потребовать, чтобы он разблокировал машину и предоставил доступ. Затем отключите этого монстра от сети. Сделайте немедленное изображение HD на случай, если у него есть аварийный переключатель». Я думаю, что конфисковать личный домашний компьютер человека и, по сути, сделать его собственностью компании — это довольно экстремально. Имхо, было бы гораздо разумнее просто попросить у парня исходный код и объяснить проблему. Этот ответ автоматически предполагает, что разработчик злонамерен, что является откровенно грубым.

Джошуа

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

Энтони Х

Данному программисту нельзя давать новую работу до тех пор, пока ситуация так или иначе не разрешится. Все новые требования должны быть переданы другому разработчику/команде, которые должны соблюдать надлежащие процедуры контроля исходного кода и экспертной оценки (при необходимости нанять новых сотрудников). Программист, о котором идет речь, может быть занят исправлением дефектов или «тушением пожара» своего существующего наследия. Ресурсы должны быть выделены для обратного проектирования существующего наследия и повторной реализации с помощью соответствующих процессов. Стоимость этого должна быть оправдана существующим риском — во что это обойдется бизнесу, если все, что сделал этот программист, будет внезапно потеряно? Или, что еще хуже, какие проприетарные (компанийные) данные уязвимы для конкуренции?

Возможно, стоит спросить этого сотрудника: «Что произойдет с нами, если вас собьет автобус или вы решите отправиться в месячный кругосветный круиз?» и оцените ответ, чтобы решить, добровольно ли он отдаст свой код. При сотрудничестве нет необходимости, чтобы ситуация стала враждебной; если с его стороны нет никаких признаков заботы о компании, пора заняться защитой всего, к чему он прикасался.

Эмори

Обязательный отпуск - text.sourcegraph.com/… - вы можете сделать этот месячный круиз реальностью

WoJ

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

Килиси

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

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

Боб Глаусл

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

Килиси

Работайте с ним, когда он влияет на ваши задачи, а не в целом. Это нормальный способ решения проблем на более низком уровне. Предполагая, что у вас есть система запросов на исправление, используйте ее. Но не прыгайте вверх и вниз, пытаясь уволить парня, потому что он «тормозит вас».

Бодо Тисен

Коллега становится проблемой @bobglausl, как только компания умирает. Так что это его проблема.

Килиси

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

Бодо Тисен

Когда дело доходит до решения, остаться или уйти, это становится его делом.

смки

@bobglausl: Так что пусть парень проведет еще немного тестов и улучшит свои сообщения об ошибках. Или, по крайней мере, составьте план тестирования, наймите младшего тестировщика/QA/SET для выполнения грязной работы и пусть этот парень научит их. Похоже на более душевный подход. Вполне вероятно, что работа вместе с тестировщиком улучшит их код.

Гусдор

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

Килиси

@Gusdor нет, я несу ответственность за свои задачи, менеджер несет полную ответственность и должен иметь четкий надзор, его босс несет ответственность за него и других и должен иметь четкий надзор за их работой ... когда-нибудь слышали об иерархии? Я не несу ответственности за своих коллег и не собираюсь брать на себя роль менеджера. У меня нет ни его зарплаты, ни доступа к его информации.

Гусдор

@Kilisi Если вы обнаружите серьезную ошибку в работе, которую вам не поручали, позволите ли вы продукту выйти из строя и пострадать вашему коллеге из-за того, что он не был назначен вам? Звучит как очень веселая командная культура.

КрисВ

Как обратиться к руководству по этому поводу?

Скажите, что лучше всего не допускать этого по многим причинам.

Профессиональные программисты должны знать, что это не способ ведения бизнеса; и если менеджеры не знают ничего другого, они должны знать хотя бы это (программисты должны сообщить об этом менеджерам, и/или менеджеры должны сообщить об этом программистам).

Причины, надеюсь, настолько хорошо известны, что мне не нужно рассказывать вам. Они включают в себя «резервное копирование», то есть у вас будут проблемы, если вы потеряете программиста (или если его переназначат на что-то другое) или если программист потеряет свою машину.

По крайней мере, у вас есть «контроль версий компании», поэтому вам не нужно сражаться в этой битве; просто сделайте это требованием задания/процесса, чтобы оно действительно использовалось.

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

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

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

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

Обратите внимание, что книга « Избавьтесь от незаменимого программиста как можно быстрее » была опубликована Джеральдом Вайнбергом в 1971 году (так что, на самом деле, все уже должны это знать). IIRC исходная цитата,

«Если программист незаменим, избавьтесь от него как можно быстрее».

пользователь8365

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

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

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

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

Вьетни Пхуван

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

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

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

А. Дж. Фарадей

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

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

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

pjc50

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

А. Дж. Фарадей

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

Питер

Предотвращение подобных ситуаций является чрезвычайно простой задачей управления. Отсюда следует, что руководство, которое знает о проблеме, некомпетентно, а руководство, которое компетентно, не осведомлено.

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

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

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


* Другой способ исправить это — самому стать менеджером и исправить это, но здесь есть немало подводных камней.

PSтег

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

Я не знаю, согласны ли вы с этим, но если да, код, вероятно, мог бы сделать кто-то лучше. Или если вы не объясните, почему такое поведение гарантирует, что его никогда не повысят.

Я думаю, что все сводится к тому, стоит ли исправлять эту ситуацию, а не к тому, как ее исправить.

Брэдли Томас

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

Олин Латроп

Они разрабатывают свои программы... так, чтобы их постепенно было труднее заменить.

Нет, если бы я был боссом!

Здесь есть две проблемы:

  1. Плохой программист.

  2. Некомпетентный менеджмент.

Это, конечно, при условии, что вы правильно представляете ситуацию.

Вы не можете решить проблему № 1. Есть небольшой шанс, что вы сможете решить проблему № 2. Этот небольшой шанс есть, если начальник по каким-то причинам просто не в курсе, что происходит. Подойдите к боссу и расскажите ему о проблемах, которые вы видите, и о том, почему они вредны для компании. Это, скорее всего, потерпит неудачу, потому что начальник уже знает о проблеме и некомпетентен для ее решения или так мало знает о программном обеспечении и управлении разработчиками программного обеспечения, что даже не компетентен понять проблему.

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

Затем новый менеджер встречается с этим программистом, просит его объяснить архитектуру и говорит ему прекратить любую новую разработку и задокументировать все протоколы. Тем временем он нанимает нового инженера, который должен «помочь» первому инженеру с документированием протоколов, поместить программное обеспечение в систему контроля версий и убедиться, что сам код хорошо документирован. Этот новый инженер занимается любой новой разработкой и, надеюсь, исправлением ошибок и незначительными улучшениями существующего программного обеспечения.

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

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

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

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

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