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

Еще до того, как меня наняли, как мне лучше всего оценить, насколько команда будет реагировать на мои попытки изменить их привычки? Уместно ли просто спросить начистоту? Если да, то есть ли способ сформулировать вопрос, чтобы поощрять более честные, реалистичные и вдумчивые ответы?

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

НЕ

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

ДЕЛАТЬ

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

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

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

Боже, да... внедрить git было бы здорово, это сделало бы мою жизнь намного проще!

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

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

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

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

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

Это 2018 год, и они не используют никакой системы контроля исходного кода. Моя память может быть недостаточно далекой, но я использовал систему управления исходным кодом (в то время SCCS) в 1996 году. Они отстали на 22 года. Мне жаль это говорить, но у вас нет ни малейшего шанса изменить то, что они делают.