Сейчас команда решает сделать упрощенную архитектуру, а нюансы и улучшения «сделают потом»
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Еще один пример — отсутствие документации. Очевидно, что без нее доработка и поддержка становятся очень сложными.
Это технология "писать на коленке", каком бы в коллективе любого размера и проэкте любой сложности она не применялась. Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Я бы разделял техдолг по приоритетам. Что быстрее и больнее начнет отражаться:
на скорости разработки
на качестве приложения, что менее важно.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги. В подтверждение этого своего вывода я приведу еще одну Вашу же цитату:
Регулярно добавлять связанные с этим задачи в разработку, обосновывать и защищать перед заказчиком необходимость таких изменений.
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
Хотите продемонстрировать страдающее качество кода, представьте бизнесу сколько багов находят клиенты.
А причем тут прикладной бизнес, если это Вы заложили эту кучу багов, которые находят клиенты прикладного бизнеса и от которых страдает не Ваше, а его лицо? Вначале вы портите своему клиенту репутацию, а потом объясняете что за исправление ее появления, надо отдельно заплатить.
Если технической долг есть на уровне архитектуры, можно замерить максимальную нагрузку, которую выдержит приложение. Эта цифра наглядно покажет заказчику, что можно выжать из текущего приложения. Если бизнесу нужно больше пользователей, потребуются вложения.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика. Как написал предыдущий комментатор: Техдолг это несделанная работа. Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо. P.S. И не надо писать про сложность и трудоемкость процесса разработки ПО и сложности общения с Заказчиком. Просто представляйте, что вам в автосалоне продадут автомобиль с таки же техническим долгом, какой вы своим заказчикам оставляете. И да, работать с этим техдолгом, будут строго по принципам описанным в Вашей статье.
А почему нельзя несколькими квартирами под одной учеткой управлять?
ИМХО вообще людей на полезных сервисах надо через ЕСИА авторизовать...
Интересно, а этом новом календаре они изобретут понятие государственных праздников и переносов рабочих дней или ИИ этого еще не научился делать???
Это сознательный обман Заказчика вызванный сознательным/не сознательным желанием качать с него деньги.
Это технология "писать на коленке", каком бы в коллективе любого размера и проэкте любой сложности она не применялась. Суть IT разработчики не желают работать в строгом соответствии к требованиям производственного процесса.
Я специально отформатировал цитату чтобы яснее стали понятны Ваши приоритеты - "качество не важно, лишь бы сдать заказчику". А потом Вы начнете качать из заказчика деньги. В подтверждение этого своего вывода я приведу еще одну Вашу же цитату:
Другими словами, вначале мы сознательно закладываем "упрощенную архитектуру", а когда заказчик начинает понимать, что проект "ходит по граблям" начинаем ему объяснять, что устранение этих граблей это серьезная работа, которая делается за отдельные (серьезные) деньги.
А причем тут прикладной бизнес, если это Вы заложили эту кучу багов, которые находят клиенты прикладного бизнеса и от которых страдает не Ваше, а его лицо?
Вначале вы портите своему клиенту репутацию, а потом объясняете что за исправление ее появления, надо отдельно заплатить.
Собственно еще раз Вы демонстрируете, что не создаете инструмент для который решает его задачи. А все строго наоборот Вы создаете инструмент для решения своей задачи - доить заказчика.
Как написал предыдущий комментатор: Техдолг это несделанная работа.
Я продолжу его мысль, несделанная работа за которую получены деньги. что в свою очередь означает оказание услуг не надлежащего качества и теоретически уголовно наказуемо.
P.S. И не надо писать про сложность и трудоемкость процесса разработки ПО и сложности общения с Заказчиком.
Просто представляйте, что вам в автосалоне продадут автомобиль с таки же техническим долгом, какой вы своим заказчикам оставляете. И да, работать с этим техдолгом, будут строго по принципам описанным в Вашей статье.