Хотя, если прям все обложено тестами и на этого разраба есть выделенный тестировщик, то все проще

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

Чёт баба яга категорически против для рефакторинга нанимать куашниками разраба.

А еще интересный вопрос: стоит ли нанимать такого человека или лучше организовать выделение времени на такие штуки текущим разработчикам?

Почему?

Как продать, можно потренироваться) Допустим, встретим такой вопрос: "Почему этим тех долгом не могут заняться уже имеющиеся разработчики?"

Именно! Ну там много разных вопросов менеджерских, по сути я о них и призывала подумать)

У меня в текущей теме путаются понятия "нанимать", "иметь человека в составе КуА/Разработчиков кто занимается тех долгом"

Если так можно сделать например 20-30% времени выделять  на техдолг, как это обычно принято, то именно с этого и нужно начать и наймом можно и не заниматься, но я бы как раз исходил из предположения что ситуация скорее крайне "плохая" и такой заход не пройдет.

Плохая - не хватает ресурсов пилить задачи и разгребать тех долг?

И осознания этого тоже нет.

Осознания у команды? Тогда у кого такое осознание вдруг есть, хоть у технички, при должном наборе аргументов может поднять вопрос о найме ещё одного сотрудника, внедрение о необходимости такого сотрудника в сознание остальных. А если ни у кого нет - может и проблемы нет?) Бизнесу ОК?)

Ага, понимаю тебя. Но тогда мне видится две задачи из описанных: "настройка" разработческого окружения (базовые классы для юнит-тестирования, линтеры и др. из кухни разработческого процесса) и рефакторинг.

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

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

А это уже другой вопрос.

1. Нанятый не знает особенностей, нюансов и подводных камней. Как знает команда разработчиков.
2. Разработчики тоже хотят после себя оставить хороший код. Если они не рефакторят - скорее всего они серьёзно ограничены. И один внешний не справится с этим ограничением.
3. Скорее всего у команды уже есть понимание, что, как и куда надо рефактортть. Хороший программист это держит в уме.
4. (самое серьёзное) ты говоришь команде разработчиков - смотрите, вы тут говнокодили, говнокодили. Мы привели вам Васю, он тут все отрефакторит и будет хорошо.
Скорее всего именно так и воспримут это разработчики
Разработчик, если он сам сделает конфету своим рефвакторингом - он будет доволен, счастлив.
Если кто то другой, левый, будет рефактортть - полная демотивашка

Не надо лишать разработчиков прерогативы убрать свои костыли

Да, согласен, есть такой поведенческий изъян.

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

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

@oneumyvakin, пока что найм разработчика QA лидом выглядит как решение проблем разработчиков извне. А может этот разработчик решать именно проблемы тестирования?

Например?

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

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