Я работаю в ИТ-отделе (относительно) небольшой компании уже 2 месяца.
Недавно начальник другого отдела (бывший разработчик) сказал мне, что было бы неплохо, если бы мы начали использовать некоторые современные методологии программирования, такие как автоматические тесты и непрерывная интеграция. Поскольку я единственный, кто имеет некоторый опыт в этой области, он предложил мне провести несколько презентаций для моих коллег и попытаться представить концепции моей команде. Однако, поскольку он относится к другому ведомству, его слово не имеет «официальной» ценности. Я должен сам предложить эти изменения моему боссу.
Я беспокоюсь по двум причинам:
Это большие изменения. Написание автоматических тестов для унаследованного кода — медленная и сложная задача.
Эти методики требуют определенной дисциплины. Новичку будет сложно навязать эту дисциплину всей команде. Если мой начальник окажет мне нерешительную поддержку, я боюсь, что могу оказаться в неприятной ситуации с моими старшими коллегами.
Быть единственным «носителем знаний» — палка о двух концах. Это сделало бы меня ценным, но также возложило бы на меня большую ответственность, может быть, слишком большую после всего лишь двух месяцев здесь.
Что ты посоветуешь?
Я бы не стал серьезно относиться к предложению начальника другого отдела. Я не знаю, почему он разговаривал с вами, а не с вашим начальником (или высшим руководством), но на самом деле это не звучит правильно (может даже быть причина, по которой он не разговаривал с вашим начальником напрямую). Как вы упомянули в своем вопросе, эти изменения далеко не тривиальны. Они требуют серьезного планирования и реализации, и такие решения не могут приниматься на бегу только потому, что кто-то думает, что это было бы хорошо (даже если этот кто-то бывший разработчик, а ныне глава отдела).
Прежде чем предпринимать какие-либо действия, вы должны поговорить с вашим боссом. Поговорите один на один и расскажите своему боссу об этом предложении. Старайтесь воздерживаться от демонстрации какого-либо конкретного отношения (слишком тревожного или восторженного). Расскажите о своем замешательстве по этому поводу. Это поможет прояснить ситуацию, а также показать свой профессионализм и отношение к своей работе и своему начальнику.
Изменить: некоторые пояснения относительно комментариев. Я имею в виду, что вы не должны погружаться в эту задачу, не обсудив ее сначала со своим боссом. Я не имею в виду, что вам не нужно вносить предложения или пытаться что-то улучшить — это полностью отличается от погружения в работу, которую кто-то, не совсем уполномоченный, считает, что вы должны делать.
Другие ответы дали много хороших советов о том, когда, нужно ли и как вносить изменения. Но сделайте шаг назад: вы новичок в организации, вас идентифицировали как обладателя новых знаний, и вас попросили внести свой вклад.
Следующим логическим шагом для вас будет выступление с презентацией о соответствующих технологиях, т. е. с докладом о том, чему я научился, другими словами, точно так же, как с докладом, который вы сделали бы своим коллегам после возвращения с конференции, на которой вы узнал кучу всего. Давать рекомендации было бы преждевременно, независимо от того, как долго вы там были; первым шагом в любом рассмотрении изменений является образование. Вы в состоянии обучать. Сначала сделайте это, а потом посмотрите, что получится.
Я работаю в своей нынешней компании уже более десяти лет. Я видел много людей, пришедших с новыми идеями, вещами, в которых мы не были в курсе, потому что это не было нашим фокусом. Те, кто приходит и сразу же говорит: «Нам нужно сделать X», обычно не получают поддержки; с другой стороны, те, кто сказал: «Вот кое-что, что я узнал о X», сделали это.
Время имеет решающее значение для предложения серьезных изменений. Первое, что вам нужно сделать, это иметь хорошую репутацию среди ваших нынешних коллег и начальника. В два месяца у вас нет с ними послужного списка, я бы подождал, пока вы это сделаете. Дальнейшие изменения, скорее всего, будут приняты как решение проблемы, которая происходит прямо сейчас. Таким образом, время предложить написание модульных тестов наступает сразу после того, как что-то серьезное сломалось в продукте, чего можно было бы предотвратить, если бы тесты существовали.
Так что напишите свои предложения в терминах бизнеса (улучшение качества, снижение затрат и т. д.) и держите их до тех пор, пока не наступит подходящий момент. Тогда поднимите их. И помните, не пытайтесь сделать слишком много сразу. Выберите предложение, которое, скорее всего, будет принято первым. Успех в предложении дает вам больше доверия, когда вы предлагаете изменения, которые, вероятно, будут труднее всего принять другим.
Также начните находить союзников, других людей, которые могли бы поддержать изменения, которые вы предлагаете. Легче добиться принятия, если другие не сопротивляются этой идее. Если у вас есть люди, которые работают там долгое время, помните, скорее всего, они создали текущую систему и в нее вложены. Вам придется приложить больше усилий, чтобы заставить их принять изменения. Также почитайте о сопротивлении переменам. Это есть во всех организациях, и это помогает понять это и понять, почему это происходит и как с этим бороться политически.
Я предлагаю обсудить это с вашим боссом — в частности, спросить о проблемах, которые вы (в конечном итоге) видите. "Эй, почему наша сборка сломалась?" Это дает вашему боссу возможность дать вам представление о технической, деловой и, возможно, политической позиции по этому конкретному вопросу.
Если они хотят, чтобы это можно было исправить, но не знают как, то предложите, чтобы это было решено с помощью непрерывной интеграции во многих компаниях.
Если они отвергнут это как ничто, возможно, прикусите свой язык.
Если они хмурятся и говорят: «Вы говорите, как босс в том другом отделе», то вы знаете о политическом минном поле.
И вообще, лучше всего продавать эти вещи как «лучшие практические» решения проблем, а не изменения, которые, по вашему мнению, должны быть сделаны ради изменений.
Суть моего ответа такова: выясните, является ли это реалистичной задачей, задачей, которую вы хотели бы выполнить, и полезной ли она для вашей профессиональной карьеры. Если нет, ищите новую работу.
Как уже было сказано, я бы также посоветовал сначала поговорить с вашим боссом. И в более неформальной форме вашим коллегам, чтобы получить лучшую «оценку» того, как они отнесутся к этим изменениям. Кроме того, читайте между строк. Если он говорит «да», но на самом деле не в курсе, это означает «да, но нет».
Кроме того, попытайтесь получить представление о том, как они думают об изменениях в целом, а также о концепциях/идеях/мысле того, что вы хотите предложить. Как они справляются с техническим долгом? Поддерживают ли они код в долгосрочной перспективе, проводят ли рефакторинг и т. д.? Есть ли у них опыт работы с открытым исходным кодом? Значит, они проводят код-ревью?
Найдите такие предложения, как:
Если начальник не поддерживает (полностью) ИЛИ если у коллег есть серьезные возражения, я бы, по крайней мере, рассмотрел возможность поиска новой работы (особенно, если вы молоды). На следующем собеседовании задайте конкретные вопросы, чтобы увидеть, является ли культура развития хорошо подходит для вас.
Я не имею в виду уйти всякий раз, когда есть проблема. Я имею в виду, уходите, если есть непреодолимое сопротивление изменениям, и вы застрянете, ассимилируясь с культурой и практикой развития, которые не подходят ни вам лично, ни вашей профессиональной карьере.
С одной стороны, работа с этим изменением станет для вас отличным опытом и, вероятно, будет хорошо смотреться в вашем резюме. Однако вопрос в том, какова вероятность успеха?
Почему я говорю это:
Я бы предложил, чтобы менеджер этого другого отдела обсудил это с вашим боссом. Если руководитель другого отдела хочет, чтобы ваш отдел что-то сделал, не совсем уместно возлагать бремя принятия решения на любого члена вашего отдела (особенно на относительно нового члена, такого как вы) за пределами начальника отдела/менеджера старшего уровня.
«Человек умен. Люди тупые, панические, опасные животные, и ты это знаешь».
В то время как человек может быть рациональным перспективным инструментом для улучшения, организации обычно таковыми не являются.
Если вы хотите внедрить эти улучшения, важный вопрос заключается не в том , следует ли вам предлагать эти изменения, а в том , как предложить эти изменения с наибольшей вероятностью успеха.
Изучение того, как это все о перспективе. Кто на самом деле имеет право реализовать это? Какие лошади участвуют в скачках? Какова их цель? С какими потенциальными проблемами они столкнутся, если попытаются реализовать его?
Это самые важные вещи, которые нужно знать, но они обычно не очевидны для людей, которые только что присоединились к организации. Вот почему многие новые сотрудники, настаивающие на радикальных переменах, разочаровываются в очевидной иррациональности системы в целом — они не видят рациональности каждого из участников этой системы.
Не всех волнует, чего хочет их руководитель, или как устроена организация, или как лучше внедрить изменения, охватывающие несколько отделов (это действительно утомительная работа), поэтому, если вам не нравится получать перспективу, вы можете пойти другим путем. маршрут и попытаться завоевать доверие.
Завоевать доверие кого-то с перспективой означает, что они могут сформировать партнерство с вами, где они позволяют вам заниматься технической стороной, в то время как они занимаются политикой для реализации изменений. Ключом к построению доверия является то, что вам также нужно доверять политически способному человеку с перспективой, поскольку вы ограничены в том, что вы можете сделать, тем, что они могут заставить организацию принять.
Этот вопрос полностью зависит от двух вещей:
Краткосрочное воздействие
Если вы технически ориентированы, вы можете создать что-то, что отлично работает в качестве побочного проекта до такой степени, что ваш босс не сможет отрицать его эффективность. Много лет назад я работал в QA для некоторого программного обеспечения и написал программное обеспечение для автоматизированного тестирования, которое избавило меня от необходимости выполнять свою работу (я запрограммировал свою работу, чтобы она не существовала). Вашему начальнику будет трудно сказать, что программное обеспечение для автоматизированного тестирования — плохая идея, если оно имеет проверенный послужной список.
Если вы политически ориентированы, то вы можете потратить несколько недель на выяснение того, какова роль вашего босса в организации и сколько он позволит вам уйти, а затем попросить его разрешить вам заниматься побочным проектом в рамках организации. вы знаете, что он позволит вам это сделать (поскольку это не причинит вреда никому другому). Это позволит вам создать то, что вы хотите создать, завоевать доверие вашего босса и позволит вам построить его в ближайшем будущем.
Долгосрочное воздействие
Если вы стремитесь к долгосрочному успеху, я бы не стал предлагать больших изменений. Вместо этого я бы работал над укреплением доверия (если ориентирован на технику) или перспективой (если ориентирован на политику), чтобы я мог использовать это, чтобы поставить себя в положение, чтобы позже внести большие изменения.
Остерегайтесь политических мин. Люди из других отделов, предлагающие вам радикальные изменения, пахнут политическим оппортунизмом и кричат мне : «Опасно, Уилл Робинсон» . Поговорите со своим менеджером и выясните, что он думает. Нравится вам это или нет, но ваш менеджер будет иметь большое влияние на то, какие изменения вы можете внедрить, и понять его (или заставить его доверять вам) — хорошая идея.
В то же время не стоит расстраивать менеджера и в другой группе. Так что я бы поостерегся использовать эту возможность, чтобы понравиться вашему боссу, выставив этого менеджера в плохом свете.
Я бы нашел конкретный образец кода, который особенно сложен или склонен к нарушению настройки автоматического тестирования для этого кода. Подавать пример. Если есть системы, которые имеют необычно значительные проблемы с качеством, предложите использовать ваши методологии для их тестирования. Вместо того, чтобы говорить «мы все должны сделать это», «сделайте это» самостоятельно и позвольте некоторым преимуществам накопиться, прежде чем продвигать это более широко.
Если только вы не были привлечены специально для внесения изменений, то я думаю, что новый парень скоро будет говорить всем, что то, что они делают, неправильно. Часто, когда компания делает что-то, что общепринятое мнение считает неправильным, выясняется, что для этого есть веские причины. Если вы не знаете истории того, как вещи пришли к тому, что они есть, и оказывается, что изменения на самом деле нецелесообразны из-за специфики компании/проекта, тогда вы теряете доверие как раз в то время, когда вы должны строить свою работу. достоверность.
Мой совет всем новичкам: сначала смотрите, слушайте, учитесь и, самое главное, завоевывайте доверие. Кто знает, если вы будете делать то, что я говорю, вы можете чему-то научиться. Бывают случаи, когда вы обнаружите, что общепринятое мнение неверно для конкретной ситуации вашей компании. Очень может быть, что то, как они это делают, проще/лучше/больше подходит для их задач, как только вы к этому привыкнете. Даже если они делают что-то неправильно, если ваши коллеги доверяют вам, то убедить их измениться становится в сотни раз проще, чем если какой-то новый парень будет рассказывать им, как они все это время поступали неправильно.
А пока, если вы действительно серьезно относитесь к внесению изменений, посмотрите, что вы можете сделать, чтобы получить настройку только для себя. Возможно, кому-то еще будет любопытно, что вы делаете, и вам понравится то, что вы сделали, и они покажут кому-то другому, и он будет расти без особых усилий с вашей стороны. По крайней мере, вы поймете, как заставить ваши изменения работать в этой конкретной компании, когда придет время начать продвигать ваши изменения.
НиколайДанте
лортабак
пользователь5305
пользователь5305
Джей Би Кинг
лортабак
Анджело
пользователь5305
драбсв
МаксВт
Турбьёрн Равн Андерсен
скрежет729