Давайте по порядку.
1. Про «делать проще» или «закладывать архитектуру». Вы пошли по первому пути вполне закономерно, потому как зачем клиенту платить больше для решения своей задачи, если можно заплатить меньше? Для него это противоречит здравому смыслу. Поделюсь опытом, мы например работаем так всегда, но с небольшой (на самом деле ключевой) поправкой — мы планируем, как проект будет развиваться дальше и обязательно вместе с клиентом. Когда есть этот план работа строится итеративно, сначала выкатывается минимальная работоспособная версия (mvp), которая покрывает критический контур системы (то, без чего этот продукт точно не будет работать), затем v0, v1 и так далее. Мысль в том, что это нормальная практика. На счет «закладывать архитектуру», а откуда вы знаете какая она должна быть? Хватит пальцев одной руки чтобы посчитать сколько я видел клиентов, которые четко знают, что им нужно и в конце проекта что-нибудь не менялось. Зная это, как можно просчитать архитектуру или хотя бы даже желаемый функционал? Лучше идти итеративно и постепенно достраивать систему.
2. Теперь про постоянные фичи, костыли и прочее. Тут упираемся в бизнес-аналитику и сбор требований. Нельзя работать в режиме Клиент сказал сделать фичу — Сделали фичу. Да ещё и по нескольку раз в день. Важно моделировать бизнес-процессы и встраивать их в существующую систему, вы-то, видно, это понимаете, но клиент-то — нет. Чтобы он понял это, с ним нужно общаться на его языке и строить работу от бизнеса. Задайте на брифинге вопросы «Какую цель вы преследуете, внедряя эту фичу? Как ещё можно достигнуть этой цели, может есть решение, которое вообще не потребует внедрения никаких фич, может это можно сделать бесплатно? Например у нас есть бизнес-аналитик, который, занимается только этим — задаёт нужные вопросы, объясняет последствия тех или иных решений, затем сам формулирует задачи, переведя их с языка бизнеса на язык разработки и начинается работа.
3. По вашему тексту видно, что клиент воспринимает вашу компанию, как исполнителя, попробуйте перейти в статус партнёра. Не уверен, что это возможно на текущей стадии, работа у вас уже выстроена, но можно попробовать изменить подход на следующем проекте. Покажите, что вы продаёте не строчки кода, а решения для бизнеса, тогда отношения между вами и клиентом качественно изменятся. Ведь клиент искренне верит, что он один на один со своими проблемами и задачами, что только он и понимает как нужно и вашими руками это делает. Поэтому они и просят частых изменений и, вероятно иногда противоречащих друг другу — они ищут решение, ну так покажите, что вам можно довериться.
4. Про, собственно, сам вопрос, как быть и как попробовать объяснить, что накопился огромный техдолг и его нужно рефакторить. Возвращаемся к тому же вопросу, с бизнесом нужно говорить на их языке. Сделайте презентацию, позовите клиента на вечерний чай (или чего покрепче) и покажите как сейчас и как могло бы быть. Покажите, что костыли и плохая архитектура замедляют разработку новых фич, что они УЖЕ переплатили вот *столько-то* и дальше будут переплачивать *вот столько-то* каждый месяц (ну хотябы приблизительно посчитайте). Покажите, что качество продукта неуклонно снижается, что в итоге всё работает медленно и из за этого они теряют клиентов вот в таких-то местах. Объясните, что да, сейчас всё работает и держится на ваших офигенно качественных костылях, но может произойти реальный крах вот *в такой-то момент*. Покажите, где для них наоборот есть точки роста, если сделать как вы говорите.
Клиент должен быть разрабу друг и партнёр, а не мудак :)
Надеюсь помог и вы что-то извлечёте из этого текста для себя, вообще чтобы более предметно говорить про это нужно больше конкретики :)
P.S. Картинки — ТОП орал долго, спасибо)
Павел Паленин
Head of design in Athanor
