Должен ли я предложить большие изменения как новичок?

Я работаю в ИТ-отделе (относительно) небольшой компании уже 2 месяца.

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

Я беспокоюсь по двум причинам:

  1. Это большие изменения. Написание автоматических тестов для унаследованного кода — медленная и сложная задача.

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

Быть единственным «носителем знаний» — палка о двух концах. Это сделало бы меня ценным, но также возложило бы на меня большую ответственность, может быть, слишком большую после всего лишь двух месяцев здесь.

Что ты посоветуешь?

Какую должность вы занимаете в ИТ-отделе? Разработчик, старший и т.д..?
@NikolaiDante Просто разработчик. Формальной разницы джуниор/сеньор нет, но есть разработчики, которые работают здесь почти 10 лет.
Что медленнее и болезненнее: один раз написать автоматические тесты или 50 раз вручную выполнить старую устаревшую кодовую базу, пытаясь протестировать одно из ваших изменений?
Еще один вопрос, я не думаю, что то, что вы новичок, влияет на этот вопрос, это не то, что вы не хотите делать это, потому что вы новичок, а потому, что вы не хотите, чтобы это стало вашей ответственностью, правильно это или нет? Если да, то мы можем отредактировать вопрос, сделав его более общим и получить больше ответов.
Говорили ли вы со своими товарищами по команде об этих изменениях?
@RhysW Одна из причин, по которой я боюсь этой ответственности, заключается в том, что я новичок. Я думаю, что удаление этой части вопроса даст неполную картину проблемы.
@RhysW, реальность никогда не бывает выбором между «одноразовым написанием автоматических тестов» и «50-кратным ручным тестированием». Достижение точки правильного внедрения автоматизированного тестирования там, где его раньше не было, — это ОЧЕНЬ ДОЛГИЙ процесс с долгосрочной рентабельностью инвестиций. Это требует глубоких изменений в организации, а новичкам особенно трудно осуществить любые изменения.
@Angelo согласился, но когда проект никуда не денется, для этого может потребоваться меньше времени, чем повторное обучение и ручное тестирование каждого отдельного изменения, каждый раз, когда кто-то новый присоединяется к компании.
"сказал мне, что было бы неплохо" - это подразумевает, что он сделал вам только предложение, никакого явного требования или я не прав? В любом случае, я не понимаю, почему бы не обсудить с ним сначала плюсы и минусы.
Пройдя через изменения методологии, позвольте мне заверить вас, что для проведения таких изменений требуется спонсор с достаточно высокими полномочиями, чтобы проводить изменения. Волновой эффект изменения организационной методологии широк.
CI должен быть очень легким плодом, если они используют современную систему контроля версий (например, git). Гитлаб хорош.
Не думайте, что вы единственный, кто знает о какой-то методологии. Наверное, почти все об этом знают и решили, что это не стоит усилий.

Ответы (9)

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

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

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

Точно, не похоже, что вас наняли для улучшения текущего процесса путем реализации этих вещей, так что не думайте, что это ваша ответственность. Это нормально, если вы обсудите это с начальником как с идеей, но не берите на себя ответственность только потому, что кто-то, кто не является вашим начальником, упомянул, что это может быть хорошей идеей.
Говоришь как истинный стойкий приверженец "Мы здесь не так делаем".
Людей редко нанимают только для того, чтобы улучшить рабочее место для других, но каждый может сам предложить улучшения рабочего процесса, само собой разумеется, вы не ожидаете, что кто-то не будет обсуждать проблему только потому, что ему за это не платят, не так ли? Парень нашел способ улучшить свою работу, и единственная причина, по которой он хочет поговорить об этом со своим боссом, заключается в том, что он не был нанят для этого, а хочет привлечь к этому внимание компании.
@RhysW, пожалуйста, посмотрите мое редактирование. Я думаю, ты меня не правильно понял
Извините, SuperM, мой комментарий на самом деле был адресован @Huntmaster, я по ошибке не отметил его.
@RhysW, не поймите меня неправильно, я не говорю не очищать корзину, потому что она заполнена, а вы не хранитель, или не исправлять ошибку в коде, над которым вы случайно работаете. Ранее я сказал, что это нормально, если он пройдет мимо его босса. Я говорю, что не думайте, что вам нужно браться за очень крупный проект по изменению процессов в масштабах отдела в качестве своей обязанности только потому, что кто-то предложил это. То, о чем он говорит, — это не несколько часов здесь или там, это изменение того, как работает каждый в его команде, и введение структуры и определенного уровня дисциплины для всех. Это большое дело.

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

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

Я работаю в своей нынешней компании уже более десяти лет. Я видел много людей, пришедших с новыми идеями, вещами, в которых мы не были в курсе, потому что это не было нашим фокусом. Те, кто приходит и сразу же говорит: «Нам нужно сделать X», обычно не получают поддержки; с другой стороны, те, кто сказал: «Вот кое-что, что я узнал о X», сделали это.

Это подлый, подлый способ заставить людей думать в нужном направлении...
@DeerHunter точно. Новый сотрудник не в лучшем положении, чтобы подтолкнуть, но любой может вдохновить . (И, по моему опыту, лучшие лидеры больше вдохновляют, чем диктуют.)
Я согласен, то, как вы формулируете это, действительно важно. Старайтесь не звучать так, будто вы всезнайка, или обвинять их в том, что они устарели. Вы показываете им то, с чем вы работали, и как это помогло вам в этом, а затем они, надеюсь, начнут складывать 2 и 2 и поймут, что это поможет решить их проблемы.

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

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

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

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

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

Если они отвергнут это как ничто, возможно, прикусите свой язык.

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

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

Ожидание возникновения проблемы может быть дорогостоящим, когда развертывание прерывается и стоит клиенту несколько сотен миллионов из-за отсутствия обслуживания. Никогда не будет вреда в обсуждении улучшений перед проблемой
@RhysW - Маковина. Если новый парень приходит и настаивает на улучшениях, не зная проблемы, которую он решает, или политического ландшафта, он может легко настроить людей против улучшений. Улучшения приносят пользу компании только в том случае, если они введены в действие.
Именно поэтому не помешает довести это до сведения его босса. Если это может решить проблему, босс подтолкнет его, если не сможет, босс скажет ему, что это не сработает, и объяснит, почему. В лучшем случае вы решили проблему, в худшем — узнали что-то новое о системе и почему ваше решение не работает. минусов не вижу
@rhysw - Вы действительно думаете, что начальник другого отдела еще не говорил об этом с начальником ОП? Я видел это полдюжины раз. Один отсталый начальник отдела отвергает попытки улучшения как изменение ради изменения, или из-за политической злобы, или из-за простого незнания воздействия, которое вызывает отсталость. Поскольку прямой такт не удался, другой руководитель отдела пытается подорвать изменение в отделе. Если ОП поднимет это прямо или косвенно, это быстро разрушит этот процесс.
Вы делаете много предположений, основанных только на своем опыте, это не всегда верно.
+1 за осторожный подход. Мой конкретный случай оказался простой нехваткой времени для организации встречи двух менеджеров. Теперь проблема решена, но в целом ваши пункты остаются в силе.

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


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

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

Найдите такие предложения, как:

  • «Мы всегда так делали»
  • «Никогда не ломайте работающую систему»
  • «У нас нет на это времени»
  • «Мы уже пробовали это, но возникли проблемы/не сработало…»

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

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

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

Почему я говорю это:

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

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

Могу я спросить, почему мой ответ был отклонен? Это политика, которой я следую в тех редких случаях, когда что-то подобное происходит, и я думаю, что в моих интересах понять, почему такой образ действий может быть плохим.
С моей точки зрения, в фактическом ответе нет ничего плохого, но другой босс никогда не ставил перед ним официальную задачу, это больше похоже на то, что другой босс упомянул в обсуждении, что X было бы неплохо, и если бы ОП согласился, то « вот способ сделать это, сделав powerpoint и отправившись к боссу
@RhysW ааа, тогда понятно. Я отредактирую свой ответ.

Думай на 4 хода вперед

«Человек умен. Люди тупые, панические, опасные животные, и ты это знаешь».

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

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

Перспектива — это все

Изучение того, как это все о перспективе. Кто на самом деле имеет право реализовать это? Какие лошади участвуют в скачках? Какова их цель? С какими потенциальными проблемами они столкнутся, если попытаются реализовать его?

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

Получение перспективы против завоевания доверия

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

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

Итак, стоит ли предлагать изменения новичку?

Этот вопрос полностью зависит от двух вещей:

  1. Вы стремитесь к краткосрочному эффекту или долгосрочному успеху с этой компанией?
  2. Вы технически или политически одарен?

Краткосрочное воздействие

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

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

Долгосрочное воздействие

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

Во всяком случае...

Остерегайтесь политических мин. Люди из других отделов, предлагающие вам радикальные изменения, пахнут политическим оппортунизмом и кричат ​​мне : «Опасно, Уилл Робинсон» . Поговорите со своим менеджером и выясните, что он думает. Нравится вам это или нет, но ваш менеджер будет иметь большое влияние на то, какие изменения вы можете внедрить, и понять его (или заставить его доверять вам) — хорошая идея.

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

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

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

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

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