Как убедить клиента что пора переделать проект?

Question

[tushev]

Частая ситуация. Начинаем делать проект для нового клиента. Изначально не понятно во что выльется наше сотрудничество. Возможно после завершения проекта мы попрощаемся с этим клиентом. А возможно проект будет постоянно дорабатываться и работа над этим проектом перерастет в многолетнее сотрудничество, изначальный функционал будет многократно расширен, а требуемая производительность вырастит в NNN раз. При старте возникает вопрос, какая будет основа проекта. Есть два крайних варианта:
1. Делаем как можно проще. По сути делаем прототип на коленках, который потом доводим продакшена. Получается дешево и быстро. Но если проект будет долго играющим, то его развитие превратиться в кошмар. А если проект будет разовым, то все в порядке. Клиент счастлив (требуемый функционал получен), разработчик счастлив (не требуется работать с кривоватой архитектурой).
2. Закладываем крутую архитектуру. Думаем о долгосрочном развитии проекта. Только первая версия будет дорогая и сроки будут большими. Клиент скорее всего откажется, т.к. наш конкурент ООО "Govno-код" предложит тоже самое, но дешево и быстро по схеме №1.

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

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

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

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

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

Вариант просто объявить что с такой то даты мы полностью прекращаем с вами сотрудничество по старой версии программы - череват потерей клиента.

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

Для понятности, прилагаю страничку из своего рабочего блокнота, на которой я выражал эмоции, когда работал над одним из таких проектов:

Comments

[nektopme]

Хороший вопрос.
Хорошая картина.

Вы ещё не умеете закладывать "крутую архитектуру".
Вы зря "Думаем о долгосрочном развитии проекта".

Планы не выдерживают столкновения с реальностью.
Архитектура должна быть неотторжимой, как у Гауди.
Застегнув 1ую пуговицу мимо, остальные тоже мимо.

Answer 1

[Athanor]

Давайте по порядку.
1. Про «делать проще» или «закладывать архитектуру». Вы пошли по первому пути вполне закономерно, потому как зачем клиенту платить больше для решения своей задачи, если можно заплатить меньше? Для него это противоречит здравому смыслу. Поделюсь опытом, мы например работаем так всегда, но с небольшой (на самом деле ключевой) поправкой — мы планируем, как проект будет развиваться дальше и обязательно вместе с клиентом. Когда есть этот план работа строится итеративно, сначала выкатывается минимальная работоспособная версия (mvp), которая покрывает критический контур системы (то, без чего этот продукт точно не будет работать), затем v0, v1 и так далее. Мысль в том, что это нормальная практика. На счет «закладывать архитектуру», а откуда вы знаете какая она должна быть? Хватит пальцев одной руки чтобы посчитать сколько я видел клиентов, которые четко знают, что им нужно и в конце проекта что-нибудь не менялось. Зная это, как можно просчитать архитектуру или хотя бы даже желаемый функционал? Лучше идти итеративно и постепенно достраивать систему.

2. Теперь про постоянные фичи, костыли и прочее. Тут упираемся в бизнес-аналитику и сбор требований. Нельзя работать в режиме Клиент сказал сделать фичу — Сделали фичу. Да ещё и по нескольку раз в день. Важно моделировать бизнес-процессы и встраивать их в существующую систему, вы-то, видно, это понимаете, но клиент-то — нет. Чтобы он понял это, с ним нужно общаться на его языке и строить работу от бизнеса. Задайте на брифинге вопросы «Какую цель вы преследуете, внедряя эту фичу? Как ещё можно достигнуть этой цели, может есть решение, которое вообще не потребует внедрения никаких фич, может это можно сделать бесплатно? Например у нас есть бизнес-аналитик, который, занимается только этим — задаёт нужные вопросы, объясняет последствия тех или иных решений, затем сам формулирует задачи, переведя их с языка бизнеса на язык разработки и начинается работа.

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

4. Про, собственно, сам вопрос, как быть и как попробовать объяснить, что накопился огромный техдолг и его нужно рефакторить. Возвращаемся к тому же вопросу, с бизнесом нужно говорить на их языке. Сделайте презентацию, позовите клиента на вечерний чай (или чего покрепче) и покажите как сейчас и как могло бы быть. Покажите, что костыли и плохая архитектура замедляют разработку новых фич, что они УЖЕ переплатили вот *столько-то* и дальше будут переплачивать *вот столько-то* каждый месяц (ну хотябы приблизительно посчитайте). Покажите, что качество продукта неуклонно снижается, что в итоге всё работает медленно и из за этого они теряют клиентов вот в таких-то местах. Объясните, что да, сейчас всё работает и держится на ваших офигенно качественных костылях, но может произойти реальный крах вот *в такой-то момент*. Покажите, где для них наоборот есть точки роста, если сделать как вы говорите.

Клиент должен быть разрабу друг и партнёр, а не мудак :)

Надеюсь помог и вы что-то извлечёте из этого текста для себя, вообще чтобы более предметно говорить про это нужно больше конкретики :)

P.S. Картинки — ТОП орал долго, спасибо)

Павел Паленин
Head of design in Athanor

Comments

[Никита]

Спасибо за ответ, с удовольствием внял для своего опыта!

Answer 2

[Иван Шумов]

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