Добрый день все!
Хочется поделиться размышлениями и услышать мнения других на данную тему.
Недавно состоялся у нас спор с коллегами по поводу стратегии общения с заказчиком.
Речь идет о внедрении документооборотных и подобных им систем. Большая часть работ при внедрении заключается в допиливании под заказчика и работы по интеграции. Зачастую области ответственности пересекаются с ERP и системами BPM или управления проектами+планирования.
Суть спора проста: продавец против инженера.

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

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

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

А вопрос, собственно такой, как жить в такой ситуации техническому специалисту и что у вас делают, чтобы примирить шизофреническое рвение продавцов с "принципом реальности", диктуемым технарями?

В целом, понятно, конечно, что нет панацеи :)

Но когда тебе говорят: "поедешь в командировку для предпроектного обследования завтра, сколько тебе нужно дней?", становится не посебе. говоришь: "дайте договор почитать, может ТЗ там прилагается или еще чего...", а тебе в ответ: "ты слишком глубоко копаешь...".
Читаешь договор, написано предпроектное обследование подразделения ХХХ. Отодвигаешь командировку, высылаешь вопросник и запрос на документы. Приходят ответы, документы, а в структуре предприятия вообще нет подразделения ХХХ :(
Можно, конечно написать в отчете "подразделение ХХХ не обнаружено в обследованной организации", и выдвинуть технико-коммерческое предложение всем выпить иаду, но от этого никому легче не станет.
Начинаешь искать не букву, но дух соглашения, что-то там делаешь. Но, естественно, это уже никак не связано с тем бюджетом, который был заложен сейлзами.
Благо, нарезка на этапы в твоих руках и финальная цена еще не определена (к счастью заказчик не знает, чо купить и сколько у него рабочих мест, а то бы уже его обнадежили).
Но в соседних проектах выиграли тендер, а теперь раком стоит весь отдел по тому, что план мероприятий прописан заранее, буквально выдвигается требование: "у нас по плану вы должны приехать и что-то делать, так едьте и делайте, наконец"...
И так каждый раз :( Это наболело, просто, конечно, это все переживется, но когда-то надо начать узнавать в лицо клиентов которым "дешевле не продавать (с)"

Господа, а как обычно поступают с такой ситуацией.

Есть несколько (или даже один) крупных клиентов, которые способны построить свои подразделения прямо и перпендикулярно под внедряемую систему, то есть готовы принять единую политику в используемом софте, изменить БП и т.д., сведя к минимуму работы по интеграции и внедрению. Кроме этого частенько большие клиенты более расслаблены и не всегда стремятся к тотальной оптимизации своих процессов (темп работы у них поменьше, чтоли)
У средних и маленьких клиентов обычно зоопарк в смежном софте и они не готовы много строиться под систему, а предпочитают, чтобы система была допилена под них.
Получается, что большие деньги достаются часто меньшим геморроем, но бывают не всегда и, зачастую, не добавляют дополнительный функционал к системе.
У маленьких клиентов денег поменьше, они, как мне показалось, пытаются решить свои реальные проблемы, по этому в системе часто появляются полезные свойства и происходит настоящее осмысление методов ее применения, хотя и работать приходится много.
Зачастую начальство встает в позу: мы ориентированы на пару крупных клиентов и они будут построены под внедряемую систему, все остальные как хотят, так пусть и живут. А когда начинаешь общаться с маленькими клиентами только тогда начинается реальный сбор требований и понимешь, что они правы по сути и хотят действительно полезные штуки...
Каких клиентов предпочитают у вас и почему?

А зачем ставилась такая задача?