Какие-нибудь советы о том, как «продать» необходимость решения технического долга нетехническим заинтересованным сторонам?

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

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

Это немного похоже на паузу в рубке дров, чтобы наточить топор.

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

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

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

Мне нравится этот более активный подход, который отстаивает Стив МакКоннелл: Как классифицировать и сообщать о техническом долге.

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

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

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

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

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

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

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

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

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

https://www.youtube.com/watch?v=u5reSgbrVrM

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

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

Вот простая идея, как создать другую метафору:

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

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

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

У этой истории счастливый конец. Альтернатива (менее счастливый конец) заключается в том, что Майк решает установить свой новый душ рядом с телевизором, а позже он все равно вынужден переместить и умывальник, и душ в свою ванную.

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

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