Как остановить сотрудника от удержания компании в заложниках?

Что я могу сделать, чтобы исправить эту ситуацию?

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

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

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

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

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

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

*Шорт-Ответ: * Ваша организация в настоящее время находится в серьезной опасности Фактор шины .

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

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

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

Остальные ответы довольно хороши, но есть еще одна вещь, которую я бы рассмотрел:

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

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

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

Но до тех пор, все, что вам нужно знать, находится в статье блога Joel on Software: Getting Things Done When You’re Only a Grunt

И у него есть конкретный призыв для работы с бозо: ФИЛЬНЫЕ БУГГИ. Пер Спольский:

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

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

Просто сказать это более ясно, чем текущие ответы…

Ваша проблема :

никто не знал, как это исправить.

Ваше решение :

• Узнайте, как это исправить самостоятельно.

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

Поставь это на стену: (Придется изменить некоторые названия и места).

Несколько лет назад я провел неделю, обучаясь на собственном курсе по проектированию программ в одной из производственных компаний на среднем западе США. В пятницу днем все закончилось. Менеджер DP, который организовал курс и оплачивал его из своего бюджета, пригласил меня к себе в офис. “Что ты думаешь?” спросил он. Он попросил меня рассказать ему о своих впечатлениях о его операции и о его персонале. “Довольно неплохо”, - сказал я. “У тебя там хорошие люди”. Курсы по разработке программ - это тяжелая работа; я очень устала, и за консультацию по оценке персонала взимается дополнительная плата. В любом случае, я знала, что он действительно хотел рассказать мне свои собственные мысли.

“Что ты думаешь о Фреде?” спросил он. Мы все думаем, что Фред гениален.“ "Он очень умный”, - сказал я. “Он не очень увлечен методами, но он много знает о программировании.” “Да”, - сказал менеджер ДП. Он повернулся в кресле, чтобы столкнуться с огромной блок-схемой, приклеенной к стене: около пяти больших листов линейной бумаги для принтера, может быть, двести символов, сотни соединительных линий. “Фред сделал это. Это накопление брутто-оплаты за нашу еженедельную зарплату. Никто другой, кроме Фреда, этого не понимает.” Его голос затих в благоговейном молчании. “Фред сказал мне, что он сам не уверен, что понимает это.”

“Потрясающе”, я пробормотал с уважением. Я ясно понял картину. Фред в роли Франкенштейна, Фред - блестящий создатель неконтролируемой чудовищной блок-схемы. “А как же Джейн?” Я сказал. “Я думал, что Джейн очень хороша. Она очень быстро подхватила идеи дизайна программы”.

“Да”, - сказал менеджер DP. “Джейн пришла к нам с отличной репутацией. Мы думали, что она будет такой же блестящей, как и Фред. Но она еще не проявила себя. Мы дали ей несколько проблем, которые, как мы думали, будут действительно тяжелыми, но когда она закончила, оказалось, что они совсем не были тяжелыми. Большинство из них оказались довольно простыми. Она еще не проявила себя — если вы понимаете, о чем я?”

“Я видел, что он имел в виду”

• Выдержка из книги “Требования и спецификации программного обеспечения” - Майкл Джексон (Хорошо, что стоит прочитать).

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

Есть перспектива, которую нужно рассмотреть.

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

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

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

Это не ваша работа, чтобы управлять компанией. Компания сделала свой выбор. Ты должен сделать свой. Учитесь у парня (он проработал на одной и той же работе 7 лет, он должен что-то делать правильно) или двигаться дальше.

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

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

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

Быть незаменимым преувеличено.

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

С точки зрения бизнеса, существует, в основном, два решения:

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

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

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

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

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

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

Ваша работа is написать хорошее программное обеспечение. Так что беспокойтесь о программном обеспечении, а не о людях.

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

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

Сейчас очень вероятно, что:

A. Это большое предприятие, в которое компания не готова инвестировать, потому что они не видят необходимости

B. Господин А будет спорить против этого и будет к нему прислушиваться, так как он более старший

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

Если это всплывет, и они тебя послушают, ты записался на кучу работы.

Целенаправленно держался подальше от современных фреймворков разработки ПО

Ему, наверное, просто больше всего нравится то, что он знает лучше всего?

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

Это плохая привычка и делает неоптимизированную инфраструктуру, но на самом деле имеет свои достоинства.

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

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

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

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

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

Что бы вы сделали? поговорить с вашим менеджером или без него в высшее руководство или с коллегой в вопросе?

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

Если вы говорите с его начальниками без него, вы рискуете оттолкнуть его.

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

Единственный способ исправить это - отнять у господина А контроль.

Сначала получить одобрение руководства.

Сделать совершенно новый git.

1. Импорт хороший, согласованной начальной точкой.

2. Начните оттуда и перенесите код вперёд.

3. Не давайте Mr. A доступ вообще (даже не говорите ему, что он существует)

4. Порт мистера А. изменяет ваше собственное репо, или переписывает.

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

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

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

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

Это будет большая работа, так как вам придется переписать много существующего кода.

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

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

Кроме того, никогда не интерпретируйте вслепую “Мы хотим, чтобы проблема XY была решена” в утверждение “…из-за проблемы XY”.

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

Если вы делаете это, сделать это с личным планом, и владеть последствиями в любом случае.

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

Это абсолютный лучший ответ, который вы получите. Готовьтесь к прыжку.

“Я хочу сделать программное обеспечение современным, поддерживаемым и стабильным”

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

Для него, чтобы остаться в положении так долго показывает, что бизнес сознательно или бессознательно применяет Бритва Ханлона :

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

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

Вы также должны учитывать, что мистер А может страдать от эффекта Даннинга-Крюгера , в том, что он не может видеть, что то, что он делает, неправильно.

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

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

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

Вы заявляете о своей цели.

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

Давайте разобьем это на бизнес-потребности

1. Современное

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

2. Поддерживаемая

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

3. Стабильный

Вы говорите, что хотите сделать систему HA, но вы также говорите, что это

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

Который не звучит так, как будто он нуждается в HA.

Так что же делать?

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

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

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

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

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

• Есть некоторые аргументы в пользу поддержки majectic monolith поверх microservices , но предполагается, что монолит хорошо спроектирован. В вашем случае, система может быть хороша как хорошо сконструированный монолит, но если она не хорошо сконструирована, вам нужно разделить вещи. Это выглядит хорошей статьей, чтобы начать с:

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

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

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

Почему все так хотят уволить мистера А? Я думаю, что он не сделал ничего плохого. Разработка программного обеспечения - это не создание новых вещей с помощью крутых инструментов или фреймворка. Речь идет о том, чтобы сделать стабильную вещь, которая просто “работает”. Ваша компания любит господина А и довольна его работой.

Целенаправленно держится подальше от современных фреймворков для разработки ПО

Ваша система находится в стабильном состоянии, так зачем команде вообще нужен современный фреймворк для разработки ПО, такой как Scrum или agile?

Написана основная бизнес-логика на языках, которые не могут быть протестированы

Существует ли требование, чтобы основная бизнес-логика была протестирована автоматически?

Переработанные программные компоненты в 30 модулей, чтобы добавить сложности и вопросы сертификации версий

Сколько еще стоила эта реализация вашей компании?

Разработан в нескальзываемом виде, гарантируя отсутствие HA (высокая доступность) возможностей

Все тот же вопрос - сколько еще стоила эта реализация вашей компании?

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

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