Как не позволить техническому долгу одолеть вас

[lxsmkv]

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

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

А как назвать технический долг в разработке не используя слова долг? Ну например, вы решили, что нужно все на Dependency Injection перевести. Это настолько далеко от понимания простых смертных, что нужны какие-то доступные объяснения. Может архитектор умеет такие вещи доносить до широких масс?

[vdasus]

Например: Надо создать способ, чтобы была возможность разрабатывать разные части разными командами и одна не ждала другую. Что можно уменьшить человеческий фактор (меньше вероятность что ошибка одного человека завалит все). Возможность легкого тестирования, когда изменение одной строки не потребует неделю работы Васи по всему проекту и тестам ну и так далее. Специфика вашей работы важна. Что важно бизнесу — на то и давить. Выявляете какие места проблемные у бизнеса (ресурсы, время, надежность, ...) и на понятном языке обьясняете руководству как DI поможет в уменьшении рисков, времени,… Я так делаю, часто работает.

[SergeyPeskov]

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

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

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