У меня есть коллега, который в основном разрабатывает программы для внутреннего использования в компании. Они разрабатывают свои программы таким образом, чтобы постепенно укреплять свои позиции в компании, так что их постепенно становится все труднее заменить. Некоторые примеры:
Поскольку они разработали огромное количество программ, которыми мы пользуемся внутри, их невозможно заменить, а поскольку они не будут заменены, мы не можем выйти из этой ситуации. И мы становимся все более зависимыми от этого человека, поскольку он продолжает разрабатывать свой код, чтобы укрепить свое положение в компании.
Как вырваться из этого порочного круга? Как обратиться к руководству по этому поводу?
Вам необходимо составить отчет для руководства.
Напишите краткий документ с изложением того , почему текущий подход ведет компанию по опасному пути (например, сценарий столкновения с автобусом). Опишите риски безопасности, возможно, даже приведите предостерегающие истории из вашей отрасли, со ссылками на статьи и т. д.
Также включите список способов, которыми подход этого парня вредит вашей собственной работе, а также работе ваших коллег.
И последнее, но не менее важное: не забудьте составить список рекомендаций, которые необходимо реализовать немедленно, например, добавить код в систему контроля версий, чтобы все могли его увидеть, и запустить сервер на виртуальной машине, к которой у всех есть доступ. Объясните, как эти меры никоим образом не должны повлиять на работу этого человека, а просто добавят безопасности и прозрачности всему процессу — дайте понять, что нет никаких разумных возражений против этих мер.
Возможно, сядьте со своим начальником, когда будете передавать ему этот отчет, и устно изложите в точности те страхи, которые вы здесь написали: что этот парень строит себе империю в инфраструктуре компании и что, в конечном счете, он потенциально опасен . Если ваше начальство считает, что этот человек может стать неблагоразумным, вы можете последовать совету @BillLeeper и захватить контроль над его машиной, чтобы он не смог навредить вашей организации. Это, конечно, будут решать они сами.
Это проблема управления .
Прежде чем развертывать критически важный код, его следует контролировать версиями, проверять код и, по крайней мере, использовать документацию. Если речь идет о безопасности, выберите правильных рецензентов и защитите репозиторий и документы. Нет причин, по которым это нельзя было бы начать немедленно.
Существует более серьезная проблема, чем гарантия занятости .
Любой из этих разработчиков мог внедрить вредоносный код в компанию либо по ошибке, либо по собственным причинам. В худшем случае они могут активно совершать гнусные действия, используя созданную ими же самими ситуацию (вымогательство, саботаж, промышленный шпионаж и т. д.). В лучшем случае их непрозрачность подвергает всех опасениям по поводу безопасности и всегда оставляет под вопросом любые аудиты или подотчетность. Если что-то пойдет не так, кто скажет, что они не были как-то замешаны?
К сожалению, вы на самом деле не сказали, говорил ли кто-нибудь об этих проблемах с коллегой или руководством. Это действительно злонамеренно? Или ваш коллега просто слеп? А может руководство слепое?
Я сам был "тем" парнем.
На моей предыдущей работе у меня иногда были различные побочные задачи, чтобы «сделать этот маленький инструмент» или сделать что-то простое. Получается, ресурсов для внутреннего софта никогда не бывает... Обычно это происходило примерно так:
-- Может ли кто-нибудь взглянуть на решения, которые я выбрал, чтобы сказать, уместно ли это? -- Да ладно, нам просто нужен простой инструмент, который просто делает эту простую операцию, сделайте это, и все будет хорошо.
-- Могу ли я создать для этого виртуальный сервер на нашем сервере? -- Чувак, это только для внутреннего пользования. Просто поместите его вместе с другими вещами в эту сломанную физическую коробку. Или поставить его на ту коробку, которая делает мы-не-знаем-какие функции. Или поставить на свою рабочую станцию.
Конечно, времени на написание документов никогда не было. Если только я не решил сделать это в свободное время. Конечно, все, что я мог сказать, когда у некоторых инструментов были проблемы, было «работает над этим».
И тогда я решил бросить. Это был первый момент, когда кто-то вокруг меня понял, что «маленькие внутренние» инструменты на самом деле важны, а «простые» вещи не так уж и просты. Пару выходных я провел за написанием документации, чтобы меньше обманывать коллег. Прошел почти год, а я до сих пор каждый месяц получаю множество звонков о том, как что-то сделать с моими внутренними инструментами.
В некоторых комментариях указывалось, что я не должен помогать им бесплатно. Это в целом правильно. Я хотел уточнить, что я не трачу часы своего времени на решение их проблем, я просто трачу минуту, чтобы ответить на вопрос. Технически это по-прежнему верно, что таким образом я поощряю и поощряю существующие практики. Кстати, компания предложила мне работу на неполный рабочий день или с почасовой оплатой для решения проблем, как я делал раньше, и я отказался.
Дело в том, что я не хочу заставлять своих бывших коллег «лучше проводить исследования» вместо того, чтобы просто спросить меня: «На какой машине работает Veeam?» если я могу просто назвать имя или IP-адрес, не задумываясь, или сказать: «Это должно быть написано [..]». Кроме того, двухминутный телефонный разговор с бывшим коллегой обычно является таким же позитивным и расслабляющим отвлечением, как посещение биржи стека.
Итак, что я могу предложить? Ваш коллега кажется вполне способным, не так ли? Обсудите это с руководством. Не говорите, что «он становится незаменимым». Просто спросите их - а что, если он уйдет? А если он заболеет надолго? Убедите их, что проблема реальна. Они должны сами обсудить это с этим парнем, чтобы найти решение. Может ему просто не хватает ресурсов? Может быть, ему нужен еще один человек в команде «внутреннего программного обеспечения», чтобы сделать все красиво и красиво?
"Almost a year has passed and I still receive multiple calls every month"
- и вы будете продолжать получать звонки до тех пор, пока будете предоставлять бесплатную поддержку и документацию (я предполагаю, что написание документов по выходным не оплачивалось). Вы там больше не работаете — если вы им так нужны, они могут заплатить вам за звонки в службу поддержки или за документирование/поддержку реализованных вами проектов. Вы думаете, что помогаете своим бывшим коллегам, но на самом деле вы просто позволяете руководству продолжать плохие методы, ставя оставшихся разработчиков в такое же положение.Большинство из этих ответов ПУТЕШЕСТВУЮТ ЗА БОРТОМ, если предположить злонамеренность со стороны рассматриваемого разработчика.
Прежде чем сделать тайный образ сервера, а затем вывести парня из офиса, почему бы просто не перевести дух и не попытаться понять, что происходит?
Вполне может быть, что человек, о котором идет речь, перегружен работой, не имеет достаточных ресурсов и более чем готов поделиться знаниями. Или, может быть, он делал это таким образом в течение долгого времени и никогда не получал указаний, что ему нужно поступить иначе. Как минимум, особенно если его вещи РАБОТАЮТ, он заслуживает шанса решить проблемы и сотрудничать с коллегами.
Я не вижу никаких доказательств того, что что-либо из этого было предпринято в вопросе ОП. Прежде чем рассматривать драконовские варианты, попробуйте сначала пообщаться. Если у человека не было намерения причинить вред, от него можно ожидать сотрудничества.
Есть кое-что, чего я еще не видел в других ответах:
Конечно, это основано на предположении, что вы уже говорили об этом со своим менеджером. Другие ответы предоставили причины, по которым это не ваша проблема, а проблема вашего менеджера, и они также дали советы о том, как подходить к этому разговору с вашим менеджером.
Теперь я рассматриваю ситуацию, когда вы говорили об этом со своим руководителем, а затем, по прошествии разумного времени, ничего по этому поводу не произошло. У вас возникает ощущение, что ваш начальник не считает это такой большой проблемой, как вам известно.
Вот где вы можете начать искать новую работу. Независимо от того, думает ли ваш менеджер, что это проблема, или что он просто не понимает ее достаточно хорошо, чтобы увидеть проблему, здесь что-то не так. (И я говорю не о "приватном" коде, а о проблеме менеджера, который ничего с этим не делает.)
Такую проблему вы вряд ли сможете изменить с позиции разработчика. Однако есть и другие компании, и у них нет таких проблем, поэтому вы можете поискать другого работодателя.
Однако, если посмотреть на это с положительной стороны, сейчас на вас не слишком много давления. У вас есть работа, и вы не ожидаете, что потеряете эту работу. Вам не придется идти на компромисс, чтобы иметь возможность продолжать платить арендную плату/ипотеку/расходы на проживание. Вы можете просто случайно начать осмотреться и не бросать текущую работу, пока не найдете ту работу, которая вам действительно нравится.
Все текущие ответы и большинство текущих комментариев только констатируют текущую ситуацию или предлагают крайние меры.
Подведем итог: возможны две ситуации: сотрудники делают это намеренно, в этом случае они так или иначе злонамеренны, и тогда необходима крайняя осторожность. Или коллеги просто не видят потенциальных и реальных проблем и опасностей, которые они вызывают, тогда они «дружелюбны», но их нужно побуждать работать лучше.
Итак, следующая дорожная карта пытается одновременно выполнить две задачи: 1) постараться свести к минимуму потенциальный ущерб, который эти коллеги могут нанести, если они злонамеренны, и 2) постараться удержать их в компании (чтобы они могли развиться до сотрудничества). коллеги в будущем), если они дружелюбны:
(кстати: я знаю, что вы не босс, но с информацией, предоставленной другими, я думаю, у вас будет все в ваших руках, чтобы убедить своего босса отнестись к этой теме очень серьезно, поэтому эта дорожная карта касается того, что вы босс мог бы сделать, а не то, что вы бы сделали.Единственное, что вы можете сделать, это привлечь внимание к вашему боссу.btw2: Если ваш босс все еще не слушает, ищите новую работу и увольняйтесь, как только вы нашли новую.Потому что что коллеги тикают бомбы замедленного действия, независимо от того, дружелюбны они или злонамеренны - это вообще не имеет значения).
1.) Тихо делайте резервные копии всего, к чему вы можете получить доступ. Не выключайте системы в процессе, отключение систем потенциально может спровоцировать некоторые виды ловушек.
2.) Придумайте причину, по которой рабочие станции должны быть выключены. Если вам нужна идея, свяжитесь со мной в частном порядке.
3.) Извлеките жесткие диски, сделайте полный образ, вставьте их обратно. Сделайте это в выходные или около того.
4.) Если в системах есть средства обнаружения вторжений на уровне BIOS, и вы не можете их обойти, придумайте другую причину, почему эти системы обнаружения вторжений сработали.
Эти коллеги создают инструменты для внутренних дел, верно? Значит, им не нужен доступ к клиентским системам и тому подобное?
5.) Если у них есть доступ к системам, которые им не нужны, смените пароли, убедитесь, что нет входа по открытому ключу, проверьте порты на наличие процессов, допускающих нестандартный вход. Проверьте задания cron/at, проверьте inetd, проверьте все, что работает в данный момент. Для каждого отдельного pid вы должны быть в состоянии ответить, почему этот процесс вообще выполняется.
6.) Наймите какого-нибудь нового работника (действительно нового, совершенно неизвестного. Он должен быть действительно хорошим специалистом, потому что он должен быть в состоянии взять на себя их работу в одиночку на какой-то месяц, если в этом возникнет необходимость. случайного выпускника (даже не с высшим баллом), вам нужен какой-нибудь из тех ребят, которые вообще ни разу не были в университете, но все равно все знают) и вставьте его в эту команду, чтобы поддержать их. Тем более что они вызывают блокираторы на других воркерах, это можно легко оправдать. Его официальная работа состоит в том, чтобы поддерживать их, его настоящая работа состоит в том, чтобы узнать, как они работают.
Шаг 6 особенно важен, потому что таким образом у вас есть шанс выяснить, действительно ли эти сотрудники злонамеренны.
Если новый парень хорошо интегрируется в команду, то вы можете предположить, что он дружелюбный, этот новый парень должен быть в состоянии внести необходимые изменения без необходимости говорить этим ребятам, что против них вообще были какие-то подозрения.
Если новый парень выясняет, что они злонамеренные, но они интегрируют его, то его задача — подыграть. Изучайте все, находите крутым то, что они делают, и так далее. Платите ему вдвое больше денег, потому что ему приходится работать дважды, потому что, придя домой, он должен записать все, что выучил, и отправить какой-нибудь вновь сформированной команде, которая должна взяться за работу, как только будет передано достаточно знаний.
Если злоумышленники не интегрируют его, то ваш единственный шанс — надеяться, что у вас достаточно резервных копий данных (на всякий случай) и уволить эту команду. Тогда вам могут понадобиться два или более дополнительных суперэксперта, о которых я говорил выше, чтобы очень быстро вовлечь новую команду в этот код.
Я надеюсь, что эта дорожная карта поможет — по крайней мере, как источник вдохновения о том, как с этим справиться. Может быть, в вашей компании у вас есть какие-то варианты, которые я не могу рассмотреть, может быть, есть какие-то культурные различия, так что вам все равно придется подумать об этом и, возможно, скорректировать план.
Кажется, здесь есть несколько хороших средств, чтобы предотвратить это в будущем, но не то, что с этим делать сейчас.
Защитите компьютер. Либо пригласите руководство и ИТ-эксперта, когда он будет разблокирован и оставлен без присмотра, либо пойдите и потребуйте, чтобы он разблокировал машину и предоставил доступ. Тогда отключите этого монстра от сети. Сделайте немедленное изображение HD в случае, если у него есть выключатель мертвого человека.
Немедленно уволить этого человека. Выведите его за дверь. Не беспокойтесь о причине, на его компьютере будет много улик. Если компания беспокоится, пусть их юрист творит чудеса, за это им и платят.
Собери команду. Объясните, что пошло не так. Этот человек действовал безрассудно и непрофессионально. Он подверг компанию риску и был уволен за это. Чтобы разобраться с этим беспорядком, потребуются все ресурсы, которые у нас есть.
Используйте команду для повторной сборки и повторного развертывания этой работы надлежащим образом на защищенных машинах и т. д. Команде придется проходить приложение за приложением и разбираться во всем. Не беспокойтесь сразу о переписывании, просто убедитесь, что нет никаких лазеек и т. д., а затем запустите службы на свежем, контролируемом оборудовании.
Пригласите эксперта по безопасности. Этот парень, скорее всего, не будет молчать и попытается «взломать» обратно, чтобы саботировать или иным образом получить доступ к своей системе. У него также могут быть глобальные пароли к системам, с которыми он взаимодействовал, или с течением времени они получали индивидуальные пароли. ИТ-отдел должен инициировать принудительный сброс пароля для всех пользователей и блокировать любой доступ извне на какое-то время (например, VPN).
Данному программисту нельзя давать новую работу до тех пор, пока ситуация так или иначе не разрешится. Все новые требования должны быть переданы другому разработчику/команде, которые должны соблюдать надлежащие процедуры контроля исходного кода и экспертной оценки (при необходимости нанять новых сотрудников). Программист, о котором идет речь, может быть занят исправлением дефектов или «тушением пожара» своего существующего наследия. Ресурсы должны быть выделены для обратного проектирования существующего наследия и повторной реализации с помощью соответствующих процессов. Стоимость этого должна быть оправдана существующим риском — во что это обойдется бизнесу, если все, что сделал этот программист, будет внезапно потеряно? Или, что еще хуже, какие проприетарные (компанийные) данные уязвимы для конкуренции?
Возможно, стоит спросить этого сотрудника: «Что произойдет с нами, если вас собьет автобус или вы решите отправиться в месячный кругосветный круиз?» и оцените ответ, чтобы решить, добровольно ли он отдаст свой код. При сотрудничестве нет необходимости, чтобы ситуация стала враждебной; если с его стороны нет никаких признаков заботы о компании, пора заняться защитой всего, к чему он прикасался.
Это не ваша проблема, это ответственность и роль менеджера, вы просто коллега и, возможно, не обладаете всей необходимой информацией. Я бы больше беспокоился о своих собственных задачах, чем о своих коллегах. Я не вижу ничего хорошего в том, чтобы поднять шумиху вокруг вашего коллеги.
Вы сделаете из него врага, вы обнаружите своего начальника в некомпетентности и создадите впечатление, что у вас так мало работы, что у вас есть время для проведения внутренних расследований без просьб и полномочий.
Как обратиться к руководству по этому поводу?
Скажите, что лучше всего не допускать этого по многим причинам.
Профессиональные программисты должны знать, что это не способ ведения бизнеса; и если менеджеры не знают ничего другого, они должны знать хотя бы это (программисты должны сообщить об этом менеджерам, и/или менеджеры должны сообщить об этом программистам).
Причины, надеюсь, настолько хорошо известны, что мне не нужно рассказывать вам. Они включают в себя «резервное копирование», то есть у вас будут проблемы, если вы потеряете программиста (или если его переназначат на что-то другое) или если программист потеряет свою машину.
По крайней мере, у вас есть «контроль версий компании», поэтому вам не нужно сражаться в этой битве; просто сделайте это требованием задания/процесса, чтобы оно действительно использовалось.
Вероятно, вам не следует запускать производственное программное обеспечение на машине разработчика. Первый шаг может состоять в том, чтобы настаивать на том, что:
Реализация этого требует проверки исходного кода, опубликованы инструкции по сборке. Я бы посоветовал вам сделать это в полуаварийном порядке. Разрешить разработчику доступ для записи к производственному серверу или машине сборки (чтобы убедиться, что производственный код может быть создан с помощью системы контроля версий).
После того, как вы это сделаете (после того, как вы узнаете, что исходный код находится в системе контроля версий и инструкции по сборке опубликованы), другие разработчики могут подумать о проверке исходного кода и помощи в его поддержке.
Обратите внимание, что книга « Избавьтесь от незаменимого программиста как можно быстрее » была опубликована Джеральдом Вайнбергом в 1971 году (так что, на самом деле, все уже должны это знать). IIRC исходная цитата,
«Если программист незаменим, избавьтесь от него как можно быстрее».
Я не знаю, только ли это вы или другие в компании, но всех можно заменить. Могут быть задержки, но это можно и нужно делать, когда люди не выполняют свою работу. Ваши менеджеры не занимаются своими делами.
Эти разработчики нарушают практически все базовые стандарты кодирования. У руководства должно быть какое-то представление о том, что что-то не так, но они ничего с этим не делают. Я не вижу в них решения вашей проблемы.
Вы должны иметь гарантии занятости, а также. Если вам нужно исправить конкретную ошибку, получите исходный код. Если он находится на их компьютере, попросите их скопировать его в другое место. Если у них есть права на рабочие сервера, отберите их. Они могут пойти и пожаловаться руководству, если захотят. Они сделают вам одолжение и разоблачат свою некомпетентность.
Надеюсь, кто-нибудь поймет, что весь код должен храниться централизованно и резервироваться. Это собственность компании, и все участники должны хотеть, чтобы она была защищена. Не позволяйте им уйти с этим беспорядком. Они не владеют ничем и даже не продемонстрировали ни малейшего умения следить за интеллектуальной собственностью компании.
Вопрос в том, насколько сильно вы хотите вырваться из этого порочного круга? Потому что давайте не будем лукавить, это дорого обойдется фирме.
Свобода не бесплатна. Если фирма не желает тратить ресурсы на то, чтобы избавиться от этого человека, то все, что вы делаете, это хлопаете резинками. Вам всем придется столкнуться с ситуацией, потому что, если программист уедет или попадет под грузовик, фирма SOL.
Подумайте, почему они это делают. Вполне возможно, что углы срезаются, чтобы соответствовать временным ограничениям, целевым показателям производительности и постоянно растущим требованиям. Это часто приводит к техническому долгу и одному очень напряжённому программисту, у которого нет другого выбора, кроме как исправить каждую проблему с ходу.
Этот человек вполне может писать вещи таким образом, что только он может исправить, потому что у них нет времени на документирование, версию и своевременную поддержку кода. Поверьте мне, когда я говорю, что это оказывает крайне негативное влияние на любого, кто оказывается в таком положении. Это не легкая роль, когда кто-то может сесть и расслабиться.
Если, как следует из вашего названия, они не решают проблемы, то и проблемы не будет. Вы бы просто выбросили кодировщика со всем его кодом, потому что он бесполезен.
Предотвращение подобных ситуаций является чрезвычайно простой задачей управления. Отсюда следует, что руководство, которое знает о проблеме, некомпетентно, а руководство, которое компетентно, не осведомлено.
К сожалению, распутывание подобных ситуаций является сложной управленческой задачей. Так что, поскольку менеджеры, отвечающие за этого разработчика, даже не смогли предотвратить ситуацию, не рассчитывайте на то, что они смогут исправить ситуацию.
Единственный* способ исправить это — обратиться к более высокому уровню управления. Если они заинтересованы и могут исправить это, вам даже не нужно ничего объяснять больше, чем вы объяснили нам - просто сделайте это менее личным, сосредоточившись на программах и проблемах с ними, а не на программисте.
Вы должны знать, что это вариант с высоким риском и низким вознаграждением . Если вы сделаете это, даже если это сработает, разработчик и его менеджер (который, вероятно, также является вашим менеджером) пострадают и будут знать, что вы несете ответственность. Единственная выгода, которую вы получаете от этого, заключается в том, что вы (возможно) следуете своему собственному кодексу этики и чести, но вы можете потерять работу из-за этого. Вот почему некоторые из других ответов рекомендуют отпустить это или просто искать лучшую работу, что является разумным поступком.
* Другой способ исправить это — самому стать менеджером и исправить это, но здесь есть немало подводных камней.
После собственной самооценки он решил, что у него нет шансов на повышение, и что единственная причина, по которой компания должна его удержать, заключается в том, что он утаивает от них код.
Я не знаю, согласны ли вы с этим, но если да, код, вероятно, мог бы сделать кто-то лучше. Или если вы не объясните, почему такое поведение гарантирует, что его никогда не повысят.
Я думаю, что все сводится к тому, стоит ли исправлять эту ситуацию, а не к тому, как ее исправить.
Это задача для руководства. Сначала руководство должно попытаться выяснить, было ли это преднамеренным. Если это так, следует разработать план увольнения нарушителей. Если это не преднамеренно, следует составить план обучения нарушителей.
Они разрабатывают свои программы... так, чтобы их постепенно было труднее заменить.
Нет, если бы я был боссом!
Здесь есть две проблемы:
Это, конечно, при условии, что вы правильно представляете ситуацию.
Вы не можете решить проблему № 1. Есть небольшой шанс, что вы сможете решить проблему № 2. Этот небольшой шанс есть, если начальник по каким-то причинам просто не в курсе, что происходит. Подойдите к боссу и расскажите ему о проблемах, которые вы видите, и о том, почему они вредны для компании. Это, скорее всего, потерпит неудачу, потому что начальник уже знает о проблеме и некомпетентен для ее решения или так мало знает о программном обеспечении и управлении разработчиками программного обеспечения, что даже не компетентен понять проблему.
Единственное реальное решение — начать с решения проблемы № 2, в которой вы в лучшем случае можете сыграть второстепенную роль. Некомпетентного менеджера нужно заменить.
Затем новый менеджер встречается с этим программистом, просит его объяснить архитектуру и говорит ему прекратить любую новую разработку и задокументировать все протоколы. Тем временем он нанимает нового инженера, который должен «помочь» первому инженеру с документированием протоколов, поместить программное обеспечение в систему контроля версий и убедиться, что сам код хорошо документирован. Этот новый инженер занимается любой новой разработкой и, надеюсь, исправлением ошибок и незначительными улучшениями существующего программного обеспечения.
Первому инженеру это не понравится. Он может уволиться, закатить истерику, шумно протестовать или, что еще хуже, саботировать дела. Вот почему создание резервной копии является первым делом. Было бы неплохо иметь плавный переход от первого инженера ко второму, но не ждите, что это произойдет. План состоит в том, чтобы в конечном итоге уволить первого инженера, если он не уволится или не начнет (даже более) разрушительно действовать против компании первым.
Вы просто не можете позволить этой ерунде продолжаться. Чем дольше вы это делаете, тем больнее в конечном итоге это исправить. Не исправлять это, потому что это уже будет болезненно, — абсолютно неверный способ думать об этом.
В данном случае я использовал риторическое «вы». Чтобы ответить на вопрос, что лично вы можете сделать, начните с того, что сообщите о своих опасениях начальнику, как я уже говорил выше. Опять же, вряд ли это приведет к чему-то полезному.
Следующий шаг зависит от того, что вы нам не сказали. Это может быть очень опасно идти через голову вашего босса. Если да, то вы мало что можете сделать, кроме как оценить, действительно ли вы хотите продолжать там работать. Если это достаточно небольшая компания, где можно спокойно поговорить с высшим руководством, то вперед. Вполне возможно, что вышестоящее руководство уже почувствовало некомпетентность менеджера по программному обеспечению низшего звена, но вам, конечно, об этом не скажут. Это может быть дополнительной информацией для них, чтобы предпринять более решительные действия.
Еще одна отдаленная возможность, если ваша основная цель состоит в том, чтобы исправить этот беспорядок, и вы видите себя в этом месте надолго, — это предложить взять на себя часть внутренней разработки инструментов. Это должно дать вам законную причину поговорить с первым инженером, понять, как все работает, где живет код и т. д. В конце концов, вы станете специалистом по инструментам, и руководство сможет избавиться от первого инженера. Затем вы можете попросить их нанять кого-то на эту роль, чтобы вы могли вернуться к тому, что вы хотите делать. Опять же, это не то, что я серьезно предлагаю, но это альтернатива, если вы действительно хотите и готовы.
пользователь34102
БСМП
Боб Глаусл
БСМП
рат
смки
Кносс
Марк Роджерс
Нил П.
cst1992
Боб Глаусл
Т. Сар
пользователь44634
ланчмясо317
Марк Роджерс
StartupGuy
тиего1967
Марк Роджерс
Карл Виттофт
БезнадежныйN00b
эш
бобо2000
Саша
Юха Унтинен