Чи варто включати вартість виходу у вибір рішення

10

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

Чи варто мені на це звернутися YAGNI чи слід включити вартість виходу у процес прийняття рішень? Або запитують по-іншому, чи є вартість виходу частиною TCO?

Я думаю про те, щоб повернутися до замовника, щоб запитати, чи він вважає, що витрати на виїзд є релевантними, але я хотів би знати, що спочатку думає громада.

PS Чи є вартість виходу правильним терміном?

— двдворле
джерело

Чи можете ви додати, чому ви думаєте, що перше рішення заблокує дані, і згодом їх буде важко змінити?

— Яап

По суті, чи не всі формати є власницькими, навіть ті, які вважаються "стандартними" чи "відкритими"? Yagni, ймовірно, застосовується, якщо "фірмовий" формат простіший у реалізації, прямому використанні та / або форматі defacto для обміну.

— JustinC

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

— dvdvorle

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

— JustinC

@JustinC зрештою, тут ми говоримо про готівку. Чи дешевше використовувати "фірмовий" формат у довгостроковій перспективі чи ні? Саме це, на мою думку, є найважливішим для спонсора проекту

— dvdvorle

4

Вихідна вартість є частиною TCO ( сума T становить загальну суму ), але її важко знизити, якщо ви апріорі не знаєте, як довго триватиме система. Іншими словами, якщо ви знаєте, що система буде використовуватися рівно один рік, а її зняття з експлуатації коштуватиме 52 000 доларів за рік, ви можете бути досить впевнені, додаючи 1000 доларів на тиждень до оперативного бюджету для її покриття.

Ця модель виходить у вікно, коли ви не знаєте життя системи. Теоретично ця система може залишатися у використанні назавжди, а це означає, що грошей на її припинення не буде. Все, на що ви зараз покладете увагу, буде становити сьогоднішні долари, і ці цифри цілком можуть бути безглуздими через п'ять років через зміни ставок праці та технологій, які полегшують процес (або складніше).

Вам краще за все давати своїм клієнтам уявлення про те, що потрібно для переходу від системи, і дозволити їм прийняти рішення про заміну, коли настане цей час.

(І тепер, написавши цю відповідь, я можу проголосувати, щоб закрити це як поза темою.)

— Blrfl
джерело

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

— dvdvorle

1

Має сенс для мене, і це вже майже висновок, до якого я прийшов. Ви дійсно не можете придумати фактичну загальну суму, поки вся справа не закінчиться.

— Blrfl

Я погоджуюсь з труднощами в точній оцінці "витрат на виїзд", я думаю, що є користь у забезпеченні їх, навіть якщо вони є в сьогоднішніх грошах. Порівняйте "це було б складно і забирає багато часу", і "це, швидше за все, коштуватиме від 25000 до 50000 доларів, якщо зробити це завтра".

— vaughandroid

@Blrfl, що робить це питання поза темою?

— neontapir

1

@neontapir: Основне питання справді стосується управління проектами; той факт, що мова йде про програму, насправді не означає програмування. Те ж саме можна було б застосувати так само легко до телефонних комутаторів або пічок для піци.

— Blrfl

2

ЯГНІ - це чудове правило на своєму місці, але я не впевнений, що він повинен застосовуватися в цьому випадку. Ви тут оцінюєте майбутні витрати, діяльність, яка повинна включати деякий розгляд майбутніх змін. Якби ви писали реалізацію, це була б інша історія!

Я б запропонував вам зробити калькуляцію, але переконайтеся, що замовник розуміє, чому ви це зробили. Якщо вони не дуже технічні, не дивуйтеся, якщо вони щось скажуть "це не може бути хорошим рішенням, якщо ви вже думаєте використовувати щось інше!"

Можливо, слід врахувати ще кілька тонких аспектів, коли ви робите / представляєте кошторис витрат:

Наскільки ймовірно, що дані будуть перенесені в іншу систему в майбутньому?
Чи є ймовірним, що постачальник рішення змінить свій власний формат даних, щоб легше / важче перенести дані в майбутньому? Якщо так, чи вплине це на ваше рішення?
Навіть якщо ви не хочете згодом змінювати дані, чи є ймовірність, що ви можете подати / отримати доступ до них по-іншому? Мій досвід полягає в тому, що це досить часто!

— вуандроїд
джерело

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 легко здійснити, і ви ставите питанням, скільки часу буде тривати, я б прислухався до цього питання. Реалізуйте №1 зараз, і подумайте про вдосконалення дизайну. Це допоможе вам, якщо згодом ви хочете його знову винайти.

І навпаки, якщо №1 вже не виглядає так просто, як ви думали, це перейдіть до №2.

— btilly
джерело