Не замечать того, что в stateless протокол уже лет 30 всеми правдами и неправдами пытаются запихнуть state - это конечно не проблема.
Разработчики строят вокруг него (протокола) кучу фреймворков, библиотек и т.п. для реализации одних и тех же велосипедов, отличающихся количеством катафотов и местами куда их можно прикрутить.
Гораздо важнее то, что некто неправильно дисаблит кнопки на клиенте - это же может привести к тому что функциональноть по развешиванию катафотов окажется нафиг не нужна в реальности.
В реальности нужны удобство разработки и надежность эксплуатации.
Подключение внешних монторов к ноуту - решение рабочее, но сразу теряется мобильность.
Простой вариант - планшет, на него можно вывести второй экран. Использую так Lenovo T14 + Lenovo Ideapad.
А проcтое техническое решение - это сделать вместо клавиатуры еще экран, можно на е-инке, для чтение и разработки самое то. Клавиатура или внешняя или съемная. Дешево, практично и мобильно, немножко сердито.
Вы еще забыли добавить что в фонде у Васи работает жена, дети, etc... Они получают зарплату, ездять на хороших служебных машинах, пользуются другим имуществом, путешествуют за счет этого фонда по "командировкам"
Первый диалог очевидно неудачен. «Это ошибка в компас.» Это не корректный ответ
Это корректный ответ, ошибка может быть и не в компас. Первейшая задача техподдержки — локализация ошибки.
Продолжение и того лучше. «Ошибка будет исправлена позднее»
Это действительно неудачный ответ, но другого очень часто нет. Клиент бывает не один и у компании может просто не быть ресурсов. Это безусловно минус компании. Но называть нереальные сроки тоже бессмысленно, если они все равно не будут выполнены.
Она должна вставать в позицию пользователя, понять его нужды и с его позиции пинать разработчиков
Нет. Основная задача ТП это выяснить у пользователя все обстоятельства. Большинство пользователей просто не умеют корректно формулировать проблемы. Вот саппорт и должен «разговорить клиента на правильный кейс». После чего проверить все варианты решений. Уточнить у разработки является ли кейс пользователя корректным.
И после этого или выдать решение или воркараунд, или зафиксировать ошибку в ПО и соответственно информировать клиента о ходе исправления.
Если ценность клиента не создается — продукт бесполезен
«Плюнь тому в глаза, кто скажет, что можно обнять необъятное!» Козьма Прутков.
И, возможно, выплатить компенсацию за недополученную прибыль.
Это распространенное заблуждение. В таком случае клиент должен платить разработчику процент от полученной прибыли, он же зарабатывает с помощью этого ПО.
Так можно и с каждого молотка при промахе по гвоздю требовать компенсацию с производителя.
Риск использования того или иного инструмента — это забота того, кто им пользуется. Предусмотреть все варианты здесь невозможно (см. К. Прутков).
Не замечать того, что в stateless протокол уже лет 30 всеми правдами и неправдами пытаются запихнуть state - это конечно не проблема.
Разработчики строят вокруг него (протокола) кучу фреймворков, библиотек и т.п. для реализации одних и тех же велосипедов, отличающихся количеством катафотов и местами куда их можно прикрутить.
Гораздо важнее то, что некто неправильно дисаблит кнопки на клиенте - это же может привести к тому что функциональноть по развешиванию катафотов окажется нафиг не нужна в реальности.
В реальности нужны удобство разработки и надежность эксплуатации.
За это исследование авторам статьи была присуждена Шнобелевская премия по психологии за 2000 год (с) wiki
КР2 - это старая добрая Elite с rts и квестами
Подключение внешних монторов к ноуту - решение рабочее, но сразу теряется мобильность.
Простой вариант - планшет, на него можно вывести второй экран. Использую так Lenovo T14 + Lenovo Ideapad.
А проcтое техническое решение - это сделать вместо клавиатуры еще экран, можно на е-инке, для чтение и разработки самое то. Клавиатура или внешняя или съемная. Дешево, практично и мобильно, немножко сердито.
... он кнопку красную нажал - и никого не стало
Вы еще забыли добавить что в фонде у Васи работает жена, дети, etc... Они получают зарплату, ездять на хороших служебных машинах, пользуются другим имуществом, путешествуют за счет этого фонда по "командировкам"
А в чем проблема была свести количество отпущенных со склада заклепок и количество "оплаченных"?
Это корректный ответ, ошибка может быть и не в компас. Первейшая задача техподдержки — локализация ошибки.
Это действительно неудачный ответ, но другого очень часто нет. Клиент бывает не один и у компании может просто не быть ресурсов. Это безусловно минус компании. Но называть нереальные сроки тоже бессмысленно, если они все равно не будут выполнены.
Нет. Основная задача ТП это выяснить у пользователя все обстоятельства. Большинство пользователей просто не умеют корректно формулировать проблемы. Вот саппорт и должен «разговорить клиента на правильный кейс». После чего проверить все варианты решений. Уточнить у разработки является ли кейс пользователя корректным.
И после этого или выдать решение или воркараунд, или зафиксировать ошибку в ПО и соответственно информировать клиента о ходе исправления.
«Плюнь тому в глаза, кто скажет, что можно обнять необъятное!» Козьма Прутков.
Это распространенное заблуждение. В таком случае клиент должен платить разработчику процент от полученной прибыли, он же зарабатывает с помощью этого ПО.
Так можно и с каждого молотка при промахе по гвоздю требовать компенсацию с производителя.
Риск использования того или иного инструмента — это забота того, кто им пользуется. Предусмотреть все варианты здесь невозможно (см. К. Прутков).