Как заставить команду работать над продуктами прежней версии

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

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

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

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

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

Проведите сеанс или два, чтобы определить, что делает унаследованный код, а затем получите представление о том, что потребуется, чтобы сделать это заново в новой архитектуре. Часть «новой архитектуры» является ключевой, потому что в 9 из 10 случаев страшнее всего архитектура (спагетти-код, предварительные стандарты и т. Д.).

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

Только мои 2 цента.

Вы можете, например, попробовать делать необычные вещи на стороне тестирования. Попробуйте имитировать фреймворки и т. Д.

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

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

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

Дополнительные наличные? :) Больше ничего не знаю ...

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

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

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

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

Мне очень нравится "Пошлите свою команду на встречу с пользователями и посмотрите, как они используют программное обеспечение"

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

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