Как подойти к «это будет просто небольшое приложение»? Да правильно?

Хорошо, я сталкивался с этим много раз, но здесь сценарий худшего случая немного преувеличен.

Клиент говорит: «Эй, можешь сделать этот маленький модуль для этой маленькой задачи»?
Я: «Конечно, нет проблем».

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

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

Что вы делаете, когда вас просят сделать что-то маленькое? Вы не знаете, будет ли он расти ... если клиент будет продолжать запрашивать дополнения (и они тоже не будут).

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

Они скажут «да, верно» и пойдут к кому-то еще.

Бюджет, время и восприятие так же важны, как и разработка самого приложения.

Как к этому следует подходить?

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

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

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

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

Убедитесь, что они понимают три вещи:

1. Если они действительно не хотят беспокоиться о полной переписке, вы все равно будете делать третий модуль. Это может занять у вас еще несколько часов, и вы выставите им счет за это. Напомните им, что им следует подумать о переписывании в будущем, потому что чем дольше они будут ждать, тем больше это будет стоить.

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

3. Что вы не пытаетесь быстро заработать. Вещь нуждается в перепроектировании.

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

Просто сделайте ему маленькое приложение и получите за это деньги.

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

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

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

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

Я не могу не чувствовать, что нужно поступить так, чтобы быть честным с клиентом и дать ему выбор: 1. Я могу сделать это быстро и (относительно) дешево сейчас. Это будет здорово - это будет работать - но будущие улучшения будут стоить чуть больше 2. Я могу потратить больше времени на это заранее, что будет стоить немного больше и не принесет никакой реальной выгоды для пользователей, НО это сэкономит вам деньги в долгосрочной перспективе, если вам нужно будет добавить новые функции.

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

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

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

Это один из способов взглянуть на это, вместо одного ... LONGGGGGG проекта.

как вы избегаете (или смягчаете) принятие архитектурных и проектных решений на раннем этапе, которые впоследствии будут совершенно неуместны?

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

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

• Требуются все изменения и дополнения, подписанные в письменной форме и с бюджетом.
  • Потому что у вас есть счета для оплаты
  • Письменная и подписанная часть гарантируют, что это действительно то, что они действительно хотят, и сокращают 90% несерьезных вещей, которые клиенты передумали на полпути во время проекта

Ваш заросший продукт

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

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

Медленно улучшайте итерацию кода за итерацией, сосредотачиваясь на тех частях, которые действительно важны.