Какова лучшая защита, когда Ваше приложение выдает исключение посреди демонстрации? [закрытый]
10 ответов
Если ваш клиент не доверяет вам, нет ничего, что вы действительно можете сделать. Я строю доверие к своим клиентам, поэтому, когда что-то вроде это происходит, они верят мне, когда даю им объяснение. И когда я говорю им, что я собираюсь сделать, чтобы предотвратить будущие проблемы, я обязательно следовать.
В зависимости от того, является ли это «окончательная» демонстрация или если его демонстрация среднего проекта также повлияет на то, действительно ли вы действительно облегчить опасения клиентов. Вы можете сделать очень мало, чтобы сделать заказчиком счастливым, если это конец договора, и нет больше бюджета для тестирования и исправлений ошибок.
Одна общая стратегия, которую я использовал: если у вас есть кто-то в комнате, документируют исключение / проблему перед клиентом, и сообщите им, что она вступает в систему отслеживания ошибок для расследования и тестирования, которые будут продемонстрировать их должность смягчения и облегчает обеспокоенность. Вы, конечно, нужно пройти через и обязательно исправить проблему.
Просто скажи правду, но юморно, как сказать, видимо, наше программное обеспечение все еще не так идеально, и мы делаем его идеальным.
Никогда не лгать и не пытайтесь скрыть его. Клиенты не тупые.
Я бы сказал, что это зависит от того, на каком этапе вы находитесь. Если вы что-то продаете, мой опыт в том, что всегда предпочтительно просто принести статический материал для демонстрации. PowerPoints в порядке, но напечатанные скриншоты, которые клиенты могут бросить вокруг таблицы, непобедимы. Это позволяет вам проявлять только то, что вы хотите, очень контролируемой, пока все еще выгляжу очень профессионально.
Если клиент уже купил проект, и демонстрационная демонстрация связана, скажем, запуск, который придет, лучшее, что вы можете сделать, это улыбаться и сказать «, как вы можете видеть, мы все еще разрабатываем Немногие причуды "
Я обычно позволяю клиенту знать, что я запускаю среду живой Dev, поэтому мы могли бы увидеть немного странности. Если я знаю о частях, у которых есть проблемы (непоследовательные сбои ..) Я позволил клиенту знать о них, прежде чем я покажу этот раздел (наряду с тем, что производство не сделает этого, и я уже работаю над этим).
Обновление: основываясь на других ответах, я согласен, что ранние демонстрационные статические материалы лучше для создания обсуждения.
Последний раз, когда я представил проект на конференцию, я запланировал живую демонстрацию, но я на самом деле имел набор слайдов, возглавляемых «Если вы видите это, живая демонстрация не работала ! " с большими экранами. Неизбежно живая демонстрация не работала (нуна необходим глобально маршрутизируемый IP-адрес, и это не было доступно), и были вызваны слайды.
Я думаю, что это лично зависит от ваших отношений с клиентом и насколько они удовлетворены своим продуктом.
Я обычно говорим им, что это было плохие данные из тестирования или шутки, что это тест, который был тестом, чтобы увидеть, как приложение обрабатывает ошибки (если у вас есть об ошибке / страницах / страницах об ошибках). Вы также можете использовать время, чтобы подтвердить важность тестирования / принятия пользователей.
Я никогда не делал демонстрацию, где я не стал заранее. Если это работает в процессе, убедитесь, что они знают, что вы вверх спереди. Это проходит долгий путь к тому, чтобы держать их позитивными. У всех есть проблемы во время демо. Просто улыбнись, скажи правду и продолжаю.
Вероятно, лучший способ помочь вашему клиенту позитивным - это проектировать позитивность и уверенность в себе. Если вы, кажется, не уверены в себе, он покажет как не уверен в вашем приложении.
Возможные стратегии:
Рассказывание аудитории «Мы все будем оставаться здесь, пока тот, кто не сделал это,».
жаловаться на распространенность злых обезьян.
Серьезно, я главным против демонстрационных продуктов. Не пытайтесь демонстрировать демонстрацию до 99,9999%, конечно, проклятые вещи работают. И даже тогда это плохое представление, вы настраиваете себя, чтобы провалиться со всеми переменными, которые могут пойти не так - что может даже не быть с вашим программным обеспечением. Если вы должны сделать это, пытаясь произвести впечатление на клиентов Flashy UI лучше всего сделать один на один. Вот как мы всегда делали это.
Это продукт доставки или еще в разработке?
Предполагая, что это продукт доставки, просто восстановить и двигаться дальше. Работайте комнаты при восстановлении (перезагрузка, перезапуская приложение и т. Д.) И не останавливайтесь на то, что произошло. Клиенты понимают вещи происходит.
Я был инженером приложений, и это произошло часто. IMO, ключ к восстановлению от этого начинается в начале процесса / демонстрации / продажи, а не одного конкретного события. Установите доверие и создайте доверие с вашей аудиторией как можно раньше. Если у вас есть это и привязанность, аудитория, вероятно, будет довериться вам достаточно, чтобы ничего не думать о неисправности программного обеспечения и просто пройти мимо него. Да, у вас будет счастливый человек, который хочет раскрасить вас независимо от того, что вы делаете, но это поставляется с территорией.
Будьте честны, если кто-то спросит (они, вероятно, не будут не отрицательно говорить о вашем продукте. Я также нашел вопрос о проблеме на фатальной ошибке, это помогает, и они очень предведуют, если вы сможете объяснить, что случилось в терминах, зрители понимают. Это демонстрирует ваши знания программного процесса и возвращается к доверие.
Запишите Исключение и почему/как оно произошло НЕЗАМЕДЛИТЕЛЬНО. Тогда они увидят, что вы это исправите.