Должен ли я учитывать стоимость выхода при выборе решения?

10

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

Должен ли я пойти YAGNI по этому вопросу или я должен включить стоимость выхода в процессе принятия решений? Или по-другому спросить, является ли стоимость выхода частью ТШО?

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

PS Является ли стоимость выезда правильным сроком?

— dvdvorle
источник

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

— Яап

По сути, не являются ли все форматы проприетарными, даже если они считаются «стандартными» или «открытыми»? Yagni, вероятно, применяется, если «запатентованный» формат легче реализовать, он прост в использовании и / или формат defacto для обмена.

— JustinC

Не вдаваясь в подробности; Представьте, что вы помещаете лист Excel (разработанный заказчиком) в систему управления документами (решение 1) вместо создания соответствующих таблиц и графического интерфейса и создания листа Excel по требованию (решение 2). За исключением того, что это не Excel.

— dvdvorle

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

— JustinC

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

— dvdvorle

4

Стоимость выхода является частью совокупной стоимости владения ( T делает стенд для общей сложности ), но это трудно прибить , если вы не знаете , априори , как долго система будет последним. Другими словами, если вы знаете, что система будет использоваться ровно в течение одного года и ее вывод из эксплуатации через год будет стоить 52 000 долларов, вы можете быть достаточно уверены в том, что добавляете 1000 долларов в неделю в оперативный бюджет для ее покрытия.

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

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

(И теперь, написав этот ответ, я голосую, чтобы закрыть его как не по теме.)

— Blrfl
источник

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

— dvdvorle

1

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

— Blrfl

Я согласен с трудностями в точной оценке «затрат на выезд», я думаю, что есть смысл в их предоставлении, даже если это в сегодняшних деньгах. Сравните «это будет сложно и отнимает много времени» и «это будет стоить от 25000 до 50000 долларов, если будет сделано завтра».

— vaughandroid

@Blrfl, что делает этот вопрос не по теме?

— Неонтапир

1

@neontapir: суть вопроса действительно в управлении проектами; тот факт, что речь идет о программе, на самом деле не касается программирования. То же самое можно легко применить к телефонным коммутаторам или печам для пиццы.

— Blrfl

2

YAGNI - прекрасное правило на своем месте, но я не уверен, что оно должно применяться в этом случае. Вы оцениваете будущие затраты здесь, деятельность, которая должна включать некоторое рассмотрение будущих изменений требований. Если бы вы писали реализацию, это была бы другая история!

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

При составлении / представлении сметы расходов следует учитывать некоторые более тонкие аспекты:

Насколько вероятно, что данные будут перенесены в другую систему в будущем?
Вполне вероятно, что поставщик решений изменит свой собственный формат данных, чтобы в будущем было легче / сложнее переносить данные? Если это так, повлияет ли это на ваше решение?
Даже если вы не хотите изменять данные позже, есть ли вероятность, что вы захотите представить / получить к ним доступ другим способом? Мой опыт показывает, что это довольно часто!

— vaughandroid
источник

1

Исходя из вашего комментария о ситуации с файлом Excel, я смотрю на это как:

не меняя текущий формат (решение 1)
по сравнению с анализом формата сейчас и сохранением его в другом формате (возможно / возможно, более подходящий / готовый к будущему) (решение 1 + этап синтаксического анализа, или решение 2)

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

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

— Яап
источник

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

— dvdvorle

Или вы думаете, что это не актуально, потому что реализация решения 1 стоит дешево?

— dvdvorle

Суть в том, что я считаю, что если решение 2 можно считать улучшением решения 1, но это улучшение сейчас не является строго необходимым, применяется YAGNI.

— Яап

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

— dvdvorle

0

Если вы не уверены на 95%, что это изменится в будущем - Решение 1 - YAGNI =)

Конечно, это зависит от ваших клиентов, и от вашего опыта программирования чего-то для этого клиента.

— MikroDel
источник

2

То есть, вы говорите, что любая цена, связанная с 5% вероятностью изменения решения, не имеет значения?

— dvdvorle

Я имею в виду, что это какое-то чувство ... Вы сами знаете, что значит "ЯГНИ" - остальные чувствуют =)

— MikroDel

0

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

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

И наоборот, если # 1 больше не выглядит так просто, как вы думали, перейдите к # 2.

— btilly
источник