Как убедить товарища по команде, который видит себя старшим, изучить концептуальные основы SVN? [закрыто]

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

До сих пор мне удавалось достаточно легко продвигать инициативы в области здравомыслия из-за низких затрат на усыновление (с точки зрения времени и усилий). Однако вещи немного выровнялись.

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

Например, он объявил политику «1 фиксация SVN в день на разработчика», потому что в противном случае «серверу скоро не хватит места на диске». Когда я объяснил ему, что SVN коммиты являются дельтами, а не полными копиями, он ответил с сомнением, и даже сегодня я не совсем уверен, понимает ли он, что это значит.

У нас также был горячий спор о том, включать ли .projectконфигурацию Eclipse в SVN. Мой товарищ по команде настоял, что мы должны, хотя это вызвало многочисленные бессмысленные конфликты. Я был против сохранения отдельных файлов конфигурации разработчика в SVN. Наконец, оказалось, что у моего товарища по команде была практика повторной проверки всего дерева исходных текстов после каждого коммита, чтобы просто убедиться, что «код, зафиксированный в репозитории, работает». По этой причине он был настолько непреклонен в сохранении конфигурации проекта в SVN - так что было бы легко повторно импортировать проект. Когда я объяснил, что коммит синхронизирует рабочую копию с удаленным побайтовым удалением, что делает ненужным повторное извлечение, мой товарищ по команде снова ответил с сомнением и в конечном итоге отменил всю проблему как незначительную.

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

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

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

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

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

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

Если ваша компания использует вики, напишите несколько качественных постов о SVN:

• Почему вы должны использовать это?
• Когда вы должны его использовать?
• Какие проблемы это решает?

и т.п.

Это привлечет внимание CTO, и каждый, кто откажется от использования, должен будет использовать :)

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

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

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

По моему опыту, программисты (включая меня) отказываются от хороших практик или новых инструментов по нескольким причинам:

• Источник не заслуживает доверия. В индустрии, которая с каждым днем ​​становится все более поляризованной между «культом Mac» и «поклонниками РС»; между «идеологией открытого исходного кода» и «практической практичностью» ... и т. д. и т. д. - есть много людей, которые всегда сомневаются в представленной информации и ее вероятности порчи из-за предвзятости автора или автора, даже когда эта информация проверено как заслуживающее доверия.
• Длительный плохой опыт ... с похожей или даже той же технологией или практикой. Ничто не идеально, когда оно начинается, и многие начинают с менее чем 1/4 функций, чем в итоге. Вполне возможно, что у него было много часов, дней или даже недель, когда он работал с худшим продуктом или с тем же самым в течение плохо реализованной фазы.
• «Достоверный» источник ... противоречит информации, которую он представляет. Под «правдоподобным» я имею в виду человека или организацию, которым он доверяет. Многие люди стремятся поднять людей, которым мы доверяем, до уровней, которые не представляют реальность. Этот источник даже не должен был навязывать это убеждение человеку. Чаще всего мы делаем это сами. Это часто дает нам что-то или кого-то, на кого мы хотим стремиться быть похожими, по крайней мере, в одном аспекте.
• Отсутствие безопасности Это было подчеркнуто предыдущим постером. Наши программы становятся активом с того момента, как мы начинаем над ними работать. Не только для компаний, в которых мы работаем, но и для людей, с которыми мы работаем. Это не просто проблема контроля. Некоторые из нас хотят быть в состоянии показать свои аккуратные вещи людям, о которых мы заботимся. Некоторые из нас хотят убедиться, что посторонний человек или продукт не пострадают от этого. Для некоторых это продолжение того, как мы думаем и чувствуем, даже. Он содержит некоторые из наших философий и идеологий и раскрывает наши интеллектуальные ядра. Для многих это наше будущее, будь то для класса, работодателя или клиента. Для некоторых это все те. «Безопасность» в этом смысле не распространяется ни на данные, ни на код.

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

Как только вы узнаете, в чем заключается проблема, вы сможете вооружиться соответствующими инструментами для ее решения. Если это сценарий № 1, предложите ему провести исследование из источников, которым он доверяет, и (это важно)вернуться к вам со своими собственными выводами. Это скажет ему, что его собственная информация имеет ценность для вас. В случае сценария № 2 предоставьте точное сравнение с тем, что сейчас отличается от предыдущего. Поощряйте его попробовать, но имейте запасной план на случай, если все пойдет не так. Для сценария № 3, скажите ему, чтобы запросить его источник с ВАШЕЙ информацией. Скорее всего, его источник не придерживается взглядов, которые, по его мнению, он имеет, но в свое время. Большинство из нас со временем адаптируются, поэтому его точка зрения, вероятно, изменилась. Если он не хочет, побудите его представить вас своему источнику. И наконец, для сценария № 4, заверьте его, что его заботы принадлежат вам. (Они должны быть на некотором уровне) Продемонстрировать, как этот «новый» инструмент может защитить его интересы и повысить его безопасность. И если это не может,

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

FuzzicalLogic

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

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

Если «видит себя старшим» означает то, что я думаю, он не отпустит этого, потому что видит в этом источник власти и контроля. Поэтому обходной путь для вас может заключаться в том, чтобы использовать Git локально для управления вменяемыми единицами фиксации и ветвями, а затем просто нажимать svn один раз в день, как он просит. Git спроектирован как одноранговая система и имеет полную копию репо на каждом локальном компьютере. Вы могли бы предложить git другим разработчикам, которые предпочли бы делать это таким образом, и это может остаться просто дополнением к SVN, которое отдельные рабочие группы (будь то один или несколько разработчиков, формальные или специальные) используют внутри страны. И когда наступает день, когда старший парень смягчается, переходит в другой отдел или компанию или попадает в неустранимый угол с его политикой SVN, у вас есть шанс начать все это с чистого листа.

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

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

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

Несколько недель спустя кто-то еще может пойти.

Я постараюсь дать вам несколько советов, подкрепленных моим личным опытом.

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

Например, он объявил политику «1 фиксация SVN в день на разработчика», потому что в противном случае «серверу скоро не хватит места на диске». Когда я объяснил ему, что SVN коммиты являются дельтами, а не полными копиями, он ответил с сомнением, и даже сегодня я не совсем уверен, понимает ли он, что это значит.

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

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

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

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

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

У нас также был горячий спор о том, включать ли конфигурацию Eclipse .project в SVN. Мой товарищ по команде настоял, что мы должны, хотя это вызвало многочисленные бессмысленные конфликты. Я был против сохранения отдельных файлов конфигурации разработчика в SVN. Наконец, оказалось, что у моего товарища по команде была практика повторной проверки всего дерева исходных текстов после каждого коммита, чтобы просто убедиться, что «код, зафиксированный в репозитории, работает». По этой причине он был настолько непреклонен в сохранении конфигурации проекта в SVN - так что было бы легко повторно импортировать проект. Когда я объяснил, что коммит синхронизирует рабочую копию с удаленным побайтовым удалением, что делает ненужным повторное извлечение, мой товарищ по команде снова ответил с сомнением и в конечном итоге отменил всю проблему как незначительную.

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

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

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

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

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

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

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

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

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

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

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

Просто мои 2 цента.

Укажите ему некоторые учебные материалы о том, как работает SVN и каковы лучшие практики при использовании SVN.

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

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

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

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

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

3. Ищите поддержку сверху. Не вступайте в спор с парнем «ты мне не начальник», но если его поведение вызывает у тебя проблемы, то убедись, что твой менеджер знает о ситуации. Если вы не знаете, как обратиться к своему менеджеру, попробуйте спросить совета: «Майк, я пытался поговорить с Ларри, но я просто не справляюсь. Он настаивает на X, Y и Z, и Остальные из нас проводят много ненужного времени, работая над проблемами, которые создают. Можете ли вы дать мне какие-либо советы о том, как бороться с парнем? "

4. Игнорировать его. Почему кто-то в команде слушает этого парня? Имеет ли он реальную власть над проектом? Кого волнует, если он объявит политику «один коммит на разработчика», если у него нет полномочий для ее применения? Пусть он думает, что он черепаха Йертл, если это заставит его чувствовать себя лучше, только не позволяйте ему создавать реальные проблемы для вас.

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

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

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

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

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

По сути, тщательно выбирайте свои битвы, так как вы можете не выиграть этот. Если это так, либо вам все равно, или ищите другую работу. Суров, я знаю.

Когда-то я был на обратном пути около 8 лет назад, когда SVN была достаточно новой технологией. Я был старшим разработчиком, и меня попросили / прослушали для установки SVN младший разработчик (на самом деле он был более точной ИТ-поддержкой, чем разработчик). Я был открытым, несмотря на мои первоначальные подозрения в отношении увеличения рабочей нагрузки, ненужной сложности и т. Д., А затем стал большим поклонником этого.

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

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

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

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

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

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

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

А пока у вас есть реальные проблемы:

1. Парень проверяет свой файл .project в репо: просто проигнорируйте его. вам не нужно изменять файл, равно как и кому-то в команде, кто знает лучше. Отпусти ситуацию. Если это дает вашему «старшему члену» теплое, счастливое чувство как одеяло безопасности, пусть будет так.
2. На диске существует предполагаемый бюджет: по этой причине г-н Сеньор требует 1 коммит в день. Является ли дефицит пространства реальным или ощутимым? Даже если это только воспринимается, возможно, вы можете что-то сделать, чтобы изменить это восприятие. Это должно быть решено немедленно - если вы проявите инициативу, это также поможет укрепить доверие.

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