Без заголовка

Про услуги я не совсем корректно описал, имел в виду следующие 2 варианта: -- продукт (система) готовый, клиент может взять попробовать, провести пилот, определиться с влиянием на свои needs -- система создается на заказ, попробовать сильно заранее невозможно, не произведя серьезной работы Со всеми оговорками про инкрементную поставку, прототипирование и пилоты, конечно. -------- Если заземлять это на практику инженерных проектов (разработка или сложная настройка/интеграция), у меня сложился следующий набор принципов: -- про валидацию надо думать и практиковать; этот вопрос существенно определяется качеством коммуникации с клиентом -- достаточно формальным для контракта способом описать требования к валидации удается в редких, исключительных случаях; обычно получается на уровне декларации намерений -- для организации-разработчика задача имеет смысл при портфеле проектов; тогда управление переходит в плоскость поддержания коммуникаций (и практики постоянного "думания" о валидации), ограничении рисков и определении margin call'ов; должен быть буквально механический ограничитель, не дающих закапывать косты бесконечно в режиме "добавьте красненького" - плюс, нужен screening проектов на входе; как ни сложно бывает отказываться от предложений -- обычно не заканчиваются хорошим результатом проекты, в которых на входе нет определенных stakeholders / needs Анатолий, буду признателен за комментарии, если я насрезал углов!