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

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

Тема может и флуд, но думаю интересна будет не только мне...

1 раз было подобное. Только суть была такова, что квартирой владела 1-я хозяйка и система строилась под нее и достаточно интересная. Потом она пропала на 4 года не оплатив половину суммы. Объявилась в прошлом году с человеком, которому она продала квартиру, у которого денег не было достаточно для завершения реализации всех задумок. Он порезал все функции и заплатил за необходимый минимум, без которого вообще бы ничего не задышало. В конце заказчик разумеется сказал, что УД не оправдал его ожиданий. Но тем не менее кое что все равно его радовало.

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

Вы бы своим опытом поделились, тему то не спроста подняли (;

Или такого ни у кого не случалось, или никто не хочет вспоминать неприятные моменты.

А тему поднял по принципу - лучше учиться на чужих ошибках

Наших проектов пока не так много, пока что тьфу тьфу тьфу такого, о чём эта тема, не случалось.

УД это или просто автоматизация чего-либо (щас модно всякие довески а-ля SMART указывать), всегда можно "попасть" на недовольство зака. И опыт такой далеко не печальный, а очень даже полезный. Прежде всего вы должны понимать какие предлагаемые фунуции системы действительно полезны и эффективны, а какие - просто "тюнинг". То бишь, когда что-то предлагаете, оцените клиента, что он хочет, что ему действительно надо, и скока у него денег. Объективно оценив эти параметры предложите заказчику составить ТЗ, и не просто в фразах по функциям, а подробное, включающее все аспекты, вплоть до требований к безопасности, ПО (лучше отдельное ТЗ на ПО, если это что-то серьезное, SCADA, например), со всеми оговорками, и т.п. Если зак на такое не способен, не ленитесь, сами подготовьте. ТЗ - это документ, по которому и будет сдаваться система. И что зак подпишет, то и получит. Если ТЗ пространное, как водохранилище, то у заказчика, во время пуско-наладки обычно, разгорается аппетит, и результат один из двух, либо зак недоволен, либо вы сожрали всю свою маржу на удовлетворение хотелок заказчика. Вот так как-то в двух словах...

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

Вопрос лишь в том, как до этих "ожиданий" достучаться?
Дело в том, что когда Заказчик пытается сформулировать (сказать или написать на бумаге) свои пожелания (требования), то уже здесь, зачастую, происходит искажение информации. Если между Вами и Заказчиком появляются дополнительные звенья в виде ген. подрядчиков, представителей Заказчика и т. п., то ситуация ещё более осложняется и достигнуть положительного результата ещё труднее.

Отсюда, "золотое" правило: исключайте "прокладки" между Вами и Заказчиком.
Это ключевой момент, от которого зависит успех совместного мероприятия.

Кроме того, считаю, что не нужно заставлять Заказчика писать ТЗ.
Лучше просто попросить изложить мысли в свободной форме.
Причём в этих мыслях, в первую очередь, отразить то, что не нужно делать ни при каких обстоятельствах.
Может что-то не нравится, есть какие-то фобии и т. п.
На эти моменты обратить особое внимание.

ТЗ должен составлять специалист, причем в случае с частными Заказчиками, лучше сразу перейти к "концепции", такой упрощённый вариант стадии "П", где Заказчик сможет согласовать не требования к системе, а у же конкретные технические решения.

У меня был замечательный сюжет в практике, когда в ТЗ было написано, что нужно в рамках KNX "предусмотреть возможность дистанционного управления по IP".
Я, добросовестно, заложил KNX IP-роутер. А Заказчик ожидал, что я ему поставлю коммутатор, маршрутизатор, выберу провайдера, оплачу месяц интернета и сделаю визуализацию

Именно об этом я и говорил... ТЗ должно быть четкое, формулировки звконченные, не допускающие инакомыслия, приведены все структуры и схемы. А концепция - это понятие "блудливое"... Лучше уж тогдда "утверждаемая часть".
Что касается написания ТЗ заком - никто ему не запрещает нанять спецов для его написания...