Как получить оплату за сокращение технического долга?

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

Клиент говорит только о новой функции, бизнес-ценности и других подобных вещах. Проблема в том, что, хотя код написан на C #, он довольно процедурный. Абстракций нет, классы используются только там, где они нужны Visual Studio - например, Forms. Реализации этих классов действительно ужасны, и код действительно трудно поддерживать.

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

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

Я просто боюсь того момента, когда мы решим реализовать новую функцию, которая требует много изменений в унаследованном коде. Это может быть шокирующим для покупателя: зачем вам 8 часов на смену этих значков? Заказчику просто все равно, что в коде есть 500 мест, которые мне нужно изменить. И я должен сначала найти все эти 500 мест.

Есть идеи?

Шаг 1: Перестаньте работать неоплачиваемую сверхурочную работу.

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

Шаг 2: Делайте заметки

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

... код действительно сложно поддерживать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Один кусок за один раз» - Джонни Кэш

Похоже, что вы могли бы взимать с клиента плату за время, которое потребовалось бы для «изменения », и при этом все равно выйти НА ПУТИ в конечном счете.

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

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

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

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

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

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

Как только у вас будет время, чтобы поработать над этим, убедитесь, что вы действительно используете его (и не просто работайте на 10% сверхурочно, чтобы это сделать - держитесь за оружие). Создайте каталог технических долговых обязательств, расставьте приоритеты и начинайте выделяться. Вы должны съесть слона один укус за раз.

И не забудьте учесть лучшие инструменты. Resharper - отличный инструмент для рефакторинга, который подключается к Visual Studio.