Как предложить изменения в качестве недавно нанятого сотрудника? [закрыто]

Недавно меня наняли в большую компанию (тысячи людей, чтобы дать представление о размере). Они сказали, что наняли меня из-за моей строгости и потому, что я, несмотря на свою молодость (мне 25 лет), имел опыт работы программистом на C / C ++.

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

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

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

Спасибо.

Обновления

Следуя вашим ценным советам, я смог предложить изменения и теперь отвечаю за команду, которая должна создать и развернуть Subversion: D Спасибо всем вам!

6 месяцев спустя

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

Я был в аналогичной ситуации в моей предыдущей компании, где я был в течение 5 лет. Когда я присоединился в 2004 году, они были:

• по-прежнему использует Microsoft Access для своих баз данных (даже критически важных для бизнеса)
• использование Visual Basic 6 или Access / Excel VBA для разработки
• использование большого количества сторонних компаний вместо использования собственных ресурсов разработки (бизнес-менеджеры руководили собственными проектами разработки и 90% времени выставляли контракты на тендер без ведома ИТ)
• задыхаться нет контроля версий.

Когда я ушел в прошлом году, компании были:

• используя .NET и C # исключительно
• изгнал все разработки Access
• использование SVN для контроля версий
• имел 2 мощных блока SQL Server и переносил существующие базы данных Access в SQL
• все разработки проходили через собственные команды и принимали участие в тендерах, только если ресурсы были ограничены

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

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

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

Еще одним крупным достижением было создание полной системы внутри компании - я возглавлял проект, который экономил компании 120 000 фунтов стерлингов в год на лицензировании. Я потратил около 2 месяцев своего свободного времени на написание новой системы, представил ее ИТ-менеджеру и объяснил экономию средств. Затем он позволил мне представить это бизнесу и объяснил, как мы можем внедрить в систему все, что им нравится - больше не ограничиваясь «готовыми» системами.

Через 4 недели моя система была запущена в 10 местах, а через 6 месяцев она заработала. Год спустя они расторгли сторонний контракт, удалили все его следы из сети и обратились к нам за большим требованием по улучшению нашей внутренней системы.

Мой тебе совет:

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

Они сказали, что наняли меня из-за моей строгости и потому, что я, несмотря на свою молодость (мне 25 лет), имел опыт работы программистом на C / C ++.

Скорее потому что ты дешевле.

Вы когда-нибудь были в подобной ситуации?

Да.

какие советы ты бы дал мне

Покидать.

Есть ли тонкий способ изменить вещи, не становясь здесь черной овцой?

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

Или я должен просто отказаться от своей страсти и энергии?

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

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

Это займет некоторое время. Только не вынимайте людей из их зон комфорта слишком быстро.

Грустно, но вот почему ты здесь, а они нет.

Например. Настройте контроль версий локально и покажите им, как это может помочь. Затем дайте им некоторые ресурсы (простое чтение), которые могут поддержать вас.

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

Я старик (51 год), и у меня была такая же проблема на каждой работе, которую я когда-либо имел. Может быть, это из-за того, что ты всегда самый умный парень в комнате! :-) Серьезно, однако, когда вы знаете, как сделать это правильно, а они этого не делают, вы часто думаете: «Эй, я покажу всем эту новую и улучшенную технику, и они все будут впечатлены и захотят прыгнуть в чтобы использовать его. " Но в реальной жизни, в 90% случаев, вы показываете людям лучший путь, и они придумывают длинный список оправданий того, почему способ, которым они все это время делали, лучше. Когда вы демонстрируете, что их причины недействительны, у них появляются новые, даже более грубые причины. У меня было много раз, что я

Даже если вы действительно гений, вы должны признать, что никто не знает, что вы гений, пока не докажете это. Мне вспоминается Крис, мой друг, который начал новую работу после 10 лет работы в одной компании. Вскоре после начала новой работы он был на совещании, где обсуждали какую-то техническую проблему, и он начал предлагать предложенное решение. Потом кто-то еще прервал и сказал: «Да, спасибо. Боб, что ты думаешь?» Сначала он был раздражен: он знал правильный ответ, но никто не заботился! Вместо этого они пришли к мнению кого-то, кто знал намного меньше, чем он. Но потом он понял, что на моей старой работе я приобрел репутацию человека, который знал, о чем он говорит, поэтому, когда я разговаривал, люди слушали. Здесь у меня пока нет репутации, поэтому никого не волнует, что я думаю.

Я на своей нынешней работе 2 года, и только в последние несколько месяцев мое мнение стало иметь реальный вес. Ты должен быть терпеливым.

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

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

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

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

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

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

Используйте свои более современные знания, чтобы быть человеком, который сияет, и тогда люди начнут спрашивать, как вы это делаете. Когда ПК впервые появился на рабочем месте, я работал в государственном аудиторском агентстве. Все старшие были очень против иметь свои компьютеры (потому что это работа для секретарей). Младшие схватили все первые компьютеры и начали делать то, что старшие не могли сделать с Lotus 1-2-3 и Harvard Graphics, и внезапно пожилые люди заинтересовались, потому что молодые люди привлекали внимание очень старшего руководства.

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

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

Например, моя команда поддерживала, обновляла и использовала 16-битную утилиту для тестирования DOS. Утилита была огромной проблемой в обновлении, потому что приложение раздвигало пределы 16-битного компоновщика до такой степени, что, если вы добавили код, вам пришлось удалить что-то еще, чтобы он соответствовал. Когда его спросили, почему мы тратим столько времени и энергии на 16-битный код, они ответили «потому что он нужен нам для запуска в DOS, чтобы мы могли запускать его с загрузочной флешки». Я пытался убедить их перенести утилиту на 32-битный Linux, но руководство не хотело тратить время на это (у нас уже было слишком много работы, как было). Итак, я пошел дальше и портировал утилиту во время простоя (15 минут тут и там во время обеда, по выходным или в ожидании компиляции другого кода). В течение нескольких месяцев У меня была полностью перенесена утилита, дополненная всевозможными вещами, с которыми не справлялось исходное 16-битное приложение, и загрузка с флешки Linux. Люди заметили, когда я начал его использовать, и комментировали, как я могу сделать вещи быстрее и как моя утилита генерировала лучший результат отладки. Довольно скоро руководство услышало об этом. Как только они увидели преимущества (и самое главное, что работа уже была проделана), они больше не были против этой идеи.

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

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

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

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

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

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

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

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

Вот как я ВСЕГДА строю свой авторитет как младший разработчик: я идентифицирую излом / клудж / трату времени. Затем я исправляю это, автоматизируя его (командные файлы, скрипты PowerShell, простую программу, новые бесплатные программы, что угодно в выходные дни), не мешая никому другому. Я уверен, что сделаю это частью своего текущего технического самообразования, чтобы я мог думать об этом как о «дополнительных часах, чтобы научить себя чему-то новому и помочь компании».

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

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

ДОБАВЛЕНИЕ: Если ваш менеджер ставит под сомнение ваше поведение ... не делайте этого, пока он не почувствует, что ваша производительность остается на уровне "лучших 25%", IE убедитесь, что ваш босс доволен вами, прежде чем вы попытаетесь придумать все виды из умных исправлений, которые подталкивают вас выше в этот топ%, или он подумает, что вы тратите время. Если вы выбрасываете новые утилиты и решения, получая положительные отзывы о производительности, но он все еще настаивает на микроуправлении вами, у вас может быть проблема, выходящая за рамки этой темы.

Смешать в.

Как вы сказали, вы не хотите быть паршивой овцой. Однако, поскольку вы (как и я) хотите добавить некоторые полезные изменения:

Добавить значение в фоновом режиме.

Настройте cronjobs для проверки чужого кода в svn / hg / git. Создавайте собственные инструменты в свое свободное время, которые могут заметно улучшить усилия по разработке. В частности, вы хотите внести улучшения в компанию, чтобы вы могли показать своим пожилым людям в своем кабинете. И вот почему:

Вау фактор

Если вы можете сказать: «Привет, Алиса, ты знаешь, как Боб только что сломал сборку? Я могу отменить его редактирование, и сборка снова заработает». И когда ваш старший скажет «святое дерьмо», возможно, вы разбудите в них достаточно страсти, чтобы они пробовали или, по крайней мере, поощрили ваши новые практики.

Вот мой совет.

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

Когда я начинал, мы использовали Visual Studio 2005, когда VS2008 отсутствовал довольно долго, но заставить моего босса потратить деньги на модернизацию всех наших разработчиков было нелегко, мне пришлось медленно выдвигать идею, так как больше «было бы неплохо, если бы мы могли это сделать», но перед тем, как я передал это своему боссу, убедился бы, что другие разработчики будут хороши в этой идее, потому что они будут теми, кто его использует и имеет группу людей в услуга будет выглядеть не так, как решение одного человека.

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

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

Может быть возможность на всю жизнь - изменить способ работы компании в 25 лет. Если они сопротивляются и демонстрируют враждебность все время, это не место для вас.

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

PS мне тоже 25 и знаю как ты себя чувствуешь. Вы, вероятно, гораздо больше стремитесь учиться и пробовать новые вещи, чем ваши коллеги. В любом случае, я должен вернуться к этой работе .NET4, которую я представляю;)

Прочтите Джоэл Спольски: «Делай все, когда ты только хрюкаешь».

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

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

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

Работа с руководством; не "иди негодяй". Работайте в рамках процесса и делайте вещи в терминах, понятных людям, например: «внедрение svn займет у нас место на сервере, два дня на настройку, и нам нужно будет выполнить его резервное копирование, но мы получим x, y, z , что может сэкономить нам много денег. "

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