Подумал-подумал — и решил сюда написать.

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

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

В одном заказчик говорит: "В той табличке, которую мы зашлем в вашу программу, будут не только корректные данные, но и некорректные. Если для какой-то из записей вы не найдете соответствующую ей запись в своей мастер-таблице, просто пропускайте ее." В таком случае, даже если у них самих в таблице полный ералаш, мы радостно скушаем все то, что не сможем точно определить как некорректные данные. Сначала я думал отменять все импортирование при обнаружении некорректности, сейчас предлагается делать вид, что ничего не было. Вариантом было бы потребовать от заказчика сливать нам не все подряд, а фильтровать на их стороне, но тогда они говорят "Мы хотим просто слать вам подряд все из нашей собственной таблички, и не напрягать мозги какой-то фильтрацией". И как же лучше поступить — пойти навстречу или стоять на своем?

Другой случай. У каждой организации, прописанной в БД, может быть несколько торговых точек. Но может быть и всего одна. В последнем случае заказчик не желает возиться с торговыми точками для данной организации, и говорит "сделайте так, чтобы, если у данной организации нет торговых точек, считается, что есть всего одна". То есть в каждой аналитической процедуре тогда придется рассматривать два варианта: если точки есть, то импортированные данные привязаны к точкам, в противном случае — прямо к организациям. Это притом, что на самом деле данные всегда определяются в точках, а вот если она всего одна, то вместо номера точки указывается NULL. Теряется логика кода, размывается структура БД, и все из-за того, что отделу программистов у заказчика лень написать маленькую формочку для одновременного редактирования данных об организации и ее торговых точках (ну, чтобы не заставлять оператора лазить по разным таблицам, что, собственно, его и раздражает, если точка всего одна). Опять же вопрос — требовать у них привести базу в логичное состояние или соглашаться на такой бред? Есть и еще один вариант, но в данной ситуации он недоступен. Можно было бы при импортировании их данных самостоятельно вводить недостающие точки и привязывать к ним "по умолчанию" данные без номера точки. Но если считать, что такое невозможно, то какую позицию лучше занять, имея альтернативу "или-или"?

Лучше — означает: чтобы и заказчик приобрел продукт, и не пришлось ради этого жертвовать надежностью или внутренней (а она обязательно влияет на внешнюю, видимую!) логичностью продукта.

Slicer