Давая базу по технологиям в течении небольшого времени по-моему сложно надеятся что она может быть использована грамотно.

Я понимаю Сергей, что у вас есть успешный опыт такого рода действий.

Но мне сложно представить что имея дело именно с бизнесс-заказчиком, можно получить такие полезности. Оперировать ему ИТшными терминами без подготовки после небольших презентаций всё равно сложно. Если речь о техническом персонале то всё логично.

С миру по нитке насобираем Вам материал на целую книгу

“Плюсы”-то ладно, не забывайте про “минусы”…

Сергей: “Про 200К пример был в том, что он вложился не только в железо, но и софт, который был очень недешев. А так как Заказчик не понимал технологий, то и впарили ему все что могли “полный фарш”, который оказался излишним.”

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

Пример:
Предположим, на тренинге по внутренним технологиям системы будет озвучено: “Наша система использует собственные алгоритмы шифрования в базе данных”.
Как это поможет среднестатистическому Заказчику понять, что ему не нужен MS SQL Server 2008, а достаточно 2005-го?

В чём цимес _нужности_ тренингов Заказчика внутренностям проекта? В данной заметке и, тем более, примере с котлом, это не заметно.

(И это мы ещё не начинали говорить про негативные аспекты подобных тренингов, а они есть, шишки уже нАбиты…)

Roman :

В-общем, из моей практики самой важной пользой подобного погружения Заказчика в детали реализации проекта было обоснование эстимейтов и feasibility тех или иных изменений функциональности, требуемых/предлагаемых Заказчиком.

А вот эти пункты также можно записать как “плюсы” того, что Заказчик владеет технологиями. Спасибо за хороший пример!

Часто ссылаетесь на мануалы и юзер-гайды. Это конечно тоже обучение Заказчика, но это уже 4 пункт – Обучение конечному продукту (который еще не опубликован). Терпение, и мы доберемся и до юзер-мануалов.

Про 200К пример был в том, что он вложился не только в железо, но и софт, который был очень недешев. А так как Заказчик не понимал технологий, то и впарили ему все что могли “полный фарш”, который оказался излишним.

При условии, что со стороны Заказчика есть специалисты, готовые понять то, что им рассказывают.

Сергей Бережной :2. Заказчик сможет лучше объяснять свои проблемы службе поддержки.

Промышленные системы, а, соответственно, эксплуатационные документы к ним, и так достаточно объёмисты…

Чтобы пользователь системы и саппорт говорили на одном языке – глоссарий системы и юзер-мануал им в помощь вкупе с тренингом и аттестацией по этому материалу.

Добавление же новых терминов в этот процесс, типа классов, объектов, таблиц, и прочей айтишной начинки лишь добавит сложности и путаницы в и так нелёгкую долю саппорта.

Сергей Бережной: Я знаю одного Заказчика, который вкинул 200К денег в то, чтобы заказать сервера, которые в итоге “не совсем подошли”. В общем, он мог бы сэкономить где-то 80К. Хороший стимул для того, чтобы поучиться?

Заказчик при приобретении техники пользуется системными требованиями разрабатываемого продукта. В Вашем примере Заказчик либо ими не пользовался, либо требования были неадекватны.
Как тренинг Заказчика по верхам применяемых айти в том проекте мог заменить банальные стресс- и перформанс-тесты, в ходе которых можно определить наиболее адекватные системные требования/конфигурацию?

Цитата:
”
как эта система работает?
как необходимо обслуживать систему?
как и куда звонить в случае проблем?
”

Эти вопросы решаются грамотной инструкцией по эксплуатации (юзер/оперейшн мануалом) и тренингом операторов при поставке продукта.

А как объяснить заказчику зачем ему тратить время на изучение технологий? Ему же это не надо?

В общем случае, конечно, вы не должны его заставлять. Искусство как раз состоит в том, чтобы сделать это ЕГО (заказчика) желанием. Для этого нужно перечислить несколько преимуществ, которые он получит в результате изучения технологий. Опять же мы говорим об изучении на базовом уровне, а не на уровне профи.

Возвращаясь к преимуществам. Мне кажется, что вы были не очень внимательны в прочтении. Как минимум две из трех указанных выше выгод принесут пользу Заказчику:
1. Он будет лучше понимать, как решения его бизнес-проблем превращаются в систему. Соответственно, у него больше шансов быстрее найти «отклонение от курса», а значит сделать продукт быстрее и дешевле.
2. Заказчик сможет лучше объяснять свои проблемы службе поддержки.
++++
3. Он сможет лучше рассказать своим пользователям, как это все работает.
4. Он будет все время держать вас “тонусе”, если вы ошибетесь попытаясь “overestimate” данный проект (вот не знаю, будет ли этот довод в вашу пользу, но ему он точно понравиться).
5. Если дело касается железа (серверов, устройств), то знание технологий поможет Заказчику сделать более оптимальный выбор.
6….

Кстати, по поводу пункта 5. Я знаю одного Заказчика, который вкинул 200К денег в то, чтобы заказать сервера, которые в итоге “не совсем подошли”. В общем, он мог бы сэкономить где-то 80К. Хороший стимул для того, чтобы поучиться?