Когда в техническую поддержку АСКОН поступают запросы, каждому из них присваивается индивидуальный номер SD#XXXXX. Под этим шифром обсуждаются предложения пользователей и отрабатываются сообщения об ошибках. Какие драмы скрывает код SD# и как разрешаются самые сложные случаи – в истории запроса Свердловского инструментального завода, над которым вместе работали инженеры техподдержки АСКОН, разработчики системы КОМПАС-3D и математики C3D Labs.
Алексей Павлович Греков, ведущий конструктор АО «Свердловский инструментальный завод», проектирует пресс-формы 36 лет и последние 15 из них работает в системе проектирования КОМПАС-3D. К своему делу он подходит весьма обстоятельно и ответственно, отслеживая судьбу своих изделий до самого их изготовления. Поэтому Алексея Павловича можно часто встретить в производственных цехах завода.
Помимо собственных изделий завод изготавливает пресс-формы по заказу сторонних организаций. Один из таких заказов и стал причиной запроса в техподдержку АСКОН под номером SD#7109384.
Модель, которую предстояло передать заказчику в обменном формате (stp, x_t, sat), пройдя через процедуры экспорта-импорта, создавалась в виде поверхности, а не твердого тела. Это означало, что заказчик не сможет в дальнейшем с ней работать.
Проблема совпала с переходом сотрудников КБ на КОМПАС-3D v17, что, конечно, вызвало подозрения в адрес новой версии: «Мало того, что интерфейс изменили, так еще и экспорт сломали!».
Алексей Павлович Греков, ведущий конструктор АО «Свердловский инструментальный завод»:
Ошибка экспорта была зафиксирована и ждала своей очереди на исправление. Но заказчик пресс-формы не собирался ждать, и Алексей Павлович вновь обратился в техподдержку АСКОН.
К запросу подключился Владимир Липин, руководитель Службы техподдержки АСКОН. Он обратил внимание разработчиков, что проблема стала критичной для пользователя.
Изучив ситуацию, разработчики выяснили – дело в математике. Внешне модель пресс-формы выглядела замкнутой, и КОМПАС-3D ее достраивал как замкнутую. На самом деле ребра не сходились, поэтому модель разбивалась и становилась поверхностной. Задача была узкоспециализированной, стандартная математика геометрического ядра С3D, на котором базируется КОМПАС-3D, ее не обсчитывала.
Разработчики предложили обходное решение: изменить геометрию, поправить ребра, чтобы модель замыкалась. Но оказалось, что геометрию изменить невозможно, т.к. очень важна точность. Обходное решение не прошло.
Владимир Липин, руководитель Службы технической поддержки АСКОН:
Математики из подразделения C3D Labs, которое занимается геометрическим ядром, были уже в курсе проблемы, им требовалось время разобраться.
Детальная диагностика показала, что построенная модель содержала дефекты, которые не препятствовали её редактированию, но были неприемлемы с точки зрения обмена данными.
То, что замкнутая оболочка после передачи через обменные форматы становилась открытой, было обусловлено наличием краевых ребер в модели. Они появились в результате булевой операции: на грани был сформирован контур, выдавлен и приклеен к «основному» телу. Контур немного выступал за габарит грани: это произошло из-за особенностей наложенной системы ограничений.
Скриншот модели пресс-формы. Зелёной стрелкой показано проблемное место
Александр Спиваков, математик-программист C3D Labs:
Так выглядит математическое решение проблемы экспорта в геометрическом ядре C3D
Другим источником краевых ребер стала операция скругления. В число исходных данных для операции скругления входят радиус скругления и цепочка ребер, которые следует заместить гранями. Часто операция скругления не локальна: она затрагивает не только те грани, которые примыкают к ребрам скругляемой цепочки, но и другие. Сложные ситуации могут возникать и с крайними ребрами незамкнутой цепочки, поскольку для корректного построения скругления приходится модифицировать грани всех ребер, которые примыкают к крайним вершинам.
Если радиус скругления больше, чем размер грани в «поперечном» (по отношению к ребру) направлении, нужно также модифицировать грани, непосредственно не прилегающие к ребрам, на базе которых строится скругление. Некоторые случаи подобного рода обрабатывались с помощью функционала, предназначенного для модификации граней, примыкающих к крайним вершинам. Другие случаи обрабатывались отдельно, и в результате работы по запросу SD#7109384 корректно обрабатываемых случаев стало больше.
Найденное математиками решение было сразу включено в новую сборку геометрического ядра С3D и в экспресс-обновление КОМПАС-3D v17, которое поступило конструкторам Свердловского инструментального завода. Оставалось применить команду «Перестроить», выполнить экспорт в обменный формат и проверить результат путем обратного импорта.
Через некоторое время Алексей Павлович вновь обратился в АСКОН:
Изделия, изготовленные с помощью пресс-формы
Вместо заключения
Владимир Липин, руководитель Службы технической поддержки АСКОН:
Личный email-адрес Владимир Липина lipin@ascon.ru (в нарушение всех правил инфобезопасности) размещен на сайте АСКОН, чтобы каждый пользователь мог напрямую обратиться со своим вопросом.
P.S. От лица компаний C3D Labs и АСКОН поздравляем Алексея Павловича с рождением пятого внука!
Пресс-форма под угрозой!
Алексей Павлович Греков, ведущий конструктор АО «Свердловский инструментальный завод», проектирует пресс-формы 36 лет и последние 15 из них работает в системе проектирования КОМПАС-3D. К своему делу он подходит весьма обстоятельно и ответственно, отслеживая судьбу своих изделий до самого их изготовления. Поэтому Алексея Павловича можно часто встретить в производственных цехах завода.
Помимо собственных изделий завод изготавливает пресс-формы по заказу сторонних организаций. Один из таких заказов и стал причиной запроса в техподдержку АСКОН под номером SD#7109384.
Модель, которую предстояло передать заказчику в обменном формате (stp, x_t, sat), пройдя через процедуры экспорта-импорта, создавалась в виде поверхности, а не твердого тела. Это означало, что заказчик не сможет в дальнейшем с ней работать.
Проблема совпала с переходом сотрудников КБ на КОМПАС-3D v17, что, конечно, вызвало подозрения в адрес новой версии: «Мало того, что интерфейс изменили, так еще и экспорт сломали!».
Алексей Павлович Греков, ведущий конструктор АО «Свердловский инструментальный завод»:У нашего заказчика не установлен КОМПАС-3D. Модель была нужна ему не только для просмотра (для этого сгодился бы и КОМПАС Viewer), но и для последующей обработки и сборки. Поэтому требовалось корректно провести экспорт-импорт и получить твердотельную модель, а не поверхностную. В предыдущей версии КОМПАСа (у нас была версия 15.2) транслятор в переходные форматы работал гораздо лучше, и подобные ошибки встречались очень редко.
Диалог с техподдержкой
Алексей Павлович: Мне надо, чтобы модель считывалась твёрдым телом. Причем срочно, т.к. сроки согласования с заказчиком уже прошли.
Техподдержка: К сожалению, в данном случае импорт проходит нештатно, это ошибка в КОМПАС.
Алексей Павлович: И что мне делать???????
Техподдержка: Разработчики признали ошибку, она будет исправлена позднее.
Алексей Павлович: Очень плохо. За последние лет 5-6 не припомню, чтобы компас меня так круто подвёл. :-((( А я на него надеялся.
Ошибка экспорта была зафиксирована и ждала своей очереди на исправление. Но заказчик пресс-формы не собирался ждать, и Алексей Павлович вновь обратился в техподдержку АСКОН.
Алексей Павлович: Описанная проблема встречается всё чаще и чаще, на разных деталях. А необходимость передавать проекты в переходных форматах всё увеличивается по мере разработки новых проектов. Очень просим ускорить устранение обозначенной ошибки.
К запросу подключился Владимир Липин, руководитель Службы техподдержки АСКОН. Он обратил внимание разработчиков, что проблема стала критичной для пользователя.
Изучив ситуацию, разработчики выяснили – дело в математике. Внешне модель пресс-формы выглядела замкнутой, и КОМПАС-3D ее достраивал как замкнутую. На самом деле ребра не сходились, поэтому модель разбивалась и становилась поверхностной. Задача была узкоспециализированной, стандартная математика геометрического ядра С3D, на котором базируется КОМПАС-3D, ее не обсчитывала.
Разработчики предложили обходное решение: изменить геометрию, поправить ребра, чтобы модель замыкалась. Но оказалось, что геометрию изменить невозможно, т.к. очень важна точность. Обходное решение не прошло.
Владимир Липин, руководитель Службы технической поддержки АСКОН:
Ситуация была эмоциональной: вы не хотите ошибку исправлять и предлагаете нам ребра двигать. У пользователей сложилось впечатление, что в старой версии все было хорошо, а в 17-й версии программисты сделали нечто такое, что модель перестала экспортироваться.
Жизнь такова, что пока конструкторы завода переходили с версии 15 на 17, они существенно доработали свою модель. И дело было не в том, что в КОМПАСе какой-то функционал перестал работать. Модель усложнилась: стали использоваться такие скругления, сгибы, сочетания ребер, которые математика не позволяла обработать.
Математики из подразделения C3D Labs, которое занимается геометрическим ядром, были уже в курсе проблемы, им требовалось время разобраться.
Формула пресс-формы
Детальная диагностика показала, что построенная модель содержала дефекты, которые не препятствовали её редактированию, но были неприемлемы с точки зрения обмена данными.
То, что замкнутая оболочка после передачи через обменные форматы становилась открытой, было обусловлено наличием краевых ребер в модели. Они появились в результате булевой операции: на грани был сформирован контур, выдавлен и приклеен к «основному» телу. Контур немного выступал за габарит грани: это произошло из-за особенностей наложенной системы ограничений.
Скриншот модели пресс-формы. Зелёной стрелкой показано проблемное место
Александр Спиваков, математик-программист C3D Labs:То, что контур выступает, само по себе ошибкой не является. Проблема возникла из-за того, что контур выступал за габарит грани совсем немного: характерный размер выступающей части был сопоставим с величиной погрешности. В результате алгоритм булевой операции шёл по той ветке, где грань не следовало создавать. Сами по себе грани малого размера являются источником вычислительных проблем в меньшей степени, чем зазоры примерно такого же размера. Это справедливо для задач редактирования тела, но, как оказалось, не для задачи экспорта модели. В данном случае проблему удалось устранить посредством доводки критерия, согласно которому принимается решение о создании или пропуске грани.
Так выглядит математическое решение проблемы экспорта в геометрическом ядре C3D
Другим источником краевых ребер стала операция скругления. В число исходных данных для операции скругления входят радиус скругления и цепочка ребер, которые следует заместить гранями. Часто операция скругления не локальна: она затрагивает не только те грани, которые примыкают к ребрам скругляемой цепочки, но и другие. Сложные ситуации могут возникать и с крайними ребрами незамкнутой цепочки, поскольку для корректного построения скругления приходится модифицировать грани всех ребер, которые примыкают к крайним вершинам.
Если радиус скругления больше, чем размер грани в «поперечном» (по отношению к ребру) направлении, нужно также модифицировать грани, непосредственно не прилегающие к ребрам, на базе которых строится скругление. Некоторые случаи подобного рода обрабатывались с помощью функционала, предназначенного для модификации граней, примыкающих к крайним вершинам. Другие случаи обрабатывались отдельно, и в результате работы по запросу SD#7109384 корректно обрабатываемых случаев стало больше.
Утром в ядре — вечером в КОМПАС-3D
Найденное математиками решение было сразу включено в новую сборку геометрического ядра С3D и в экспресс-обновление КОМПАС-3D v17, которое поступило конструкторам Свердловского инструментального завода. Оставалось применить команду «Перестроить», выполнить экспорт в обменный формат и проверить результат путем обратного импорта.
Алексей Павлович: Здравствуйте. Скачал. Установил. Для чистоты эксперимента взял деталь, с которой этот запрос и начался, чтобы исключить влияние возможных правок, которые производились после создания запроса.
Сохранил как: x_t; x_b; stp AP214.
Импортировал модель из каждого перечисленного формата. Получил тот же результат, т.е. все три новые модели получились в виде ПОВЕРХНОСТЕЙ.
Отсюда вопрос: А что же вы там исправляли?
Техподдержка: Добрый день, Алексей Павлович! Для решения проблемы необходимо сначала перестроить модель в КОМПАС, затем экспортировать. После этого при импорте получится тело.
Алексей Павлович: УРААААА!!! Спасибо, получилось. СПАСИБО, спасибо, и ещё раз спасибо. По мере возможностей будем пробовать на других проблемных деталях.
Через некоторое время Алексей Павлович вновь обратился в АСКОН:
Проект, при работе с которым возникла целая цепь запросов, благополучно завершен. Наше предприятие изготовило сложнейшую пресс-форму для получения отливки, с моделью которой и мы, и вы так долго работали. Сегодня прошли испытания изготовленной по проекту оснастки. Результаты положительные. Все эти работы были проведены не зря. Большое спасибо всему вашему коллективу. Прилагаю фотографии того, что получилось в конечном итоге.
Изделия, изготовленные с помощью пресс-формы
Вместо заключения
Владимир Липин, руководитель Службы технической поддержки АСКОН:
Ситуация с пресс-формой очень показательна с точки зрения взаимодействия пользователя, технической поддержки и разработчиков. Да, у нас есть стандартный регламент, когда подтвержденные ошибки вносятся в базу и затем постепенно исправляются. Но каждый запрос индивидуален. Мы работаем с людьми, и специалисту техподдержки нужно быть максимально внимательным, лишний раз уточнить, устроило предложенное решение или нет. Тот же самый регламент предусматривает привлечение дополнительных ресурсов в сложных ситуациях.
Личный email-адрес Владимир Липина lipin@ascon.ru (в нарушение всех правил инфобезопасности) размещен на сайте АСКОН, чтобы каждый пользователь мог напрямую обратиться со своим вопросом.
P.S. От лица компаний C3D Labs и АСКОН поздравляем Алексея Павловича с рождением пятого внука!
Комментарии (24)
Casufi
04.07.2018 14:01Вы просто в тех. поддержке не работали, у любого человека могут вылезти эмоции и гасить их и направлять диалог в правильное русло — стандартный навык хорошего сотрудника поддержки.
Newbilius
05.07.2018 07:15А где имя работника ТП? Страна должна знать своих героев, ведущих диалог в стиле:
"-У вас баг!
-Да, у нас баг. [покерфейс, 0 полезной информации]
-И что мне с этим делать? У меня сроки горят! [Производство физической вещи — это вам не софт!]
-Ждать неопределённый срок. [подумаешь, производство и сроки, не повод ставить этому багу критический приоритет]"
А то нехорошо, вот, в комментариях уже начали косточки Алексею Павловичи перемалывать, потому что он в данной истории личность, а работник ТП обезличен.SergeyMax
05.07.2018 08:44+1Почему вы считаете, что сообщение «у нас баг» не содержит полезной информации? Проблема могла возникнуть из-за некорректной модели (причём по-моему она именно из-за этого и возникла, если я правильно понял статью). И сообщение «у нас баг» означает, что модель переделывать не надо, а надо дождаться исправления.
MazayAl
05.07.2018 09:03+1Есть простой тест. Встать в позицию пользователя, представить для себя, что внутренности продукта — это черный ящик и перечитать свое сообщение. Если понятно что пользователю делать дальше, то все хорошо, если непонятно, то ответ плох. «У нас баг» — и что, пользователю то что делать? Если плохая модель — надо было так и отвечать, что «по коорднатам (x,y) в модели бяка, уберите и будет счастье». Но этого не было.
Критический момент здесь — понимать, что продукт нужен пользователю не сам по себе, он участвует в цепочке создания некоторой ценности. Если ценность клиента не создается — продукт бесполезен.
kompas_3d
05.07.2018 11:14-Да, у нас баг. [покерфейс, 0 полезной информации]
Помимо этого:
Разработчики предложили обходное решение: изменить геометрию, поправить ребра, чтобы модель замыкалась.
Максимум, что может сказать техподдержка, до того как за ошибку взялась разработка — это номер записанной ошибки, что для пользователя тоже не даст полезной информации.
а работник ТП обезличен.
Начальник технической поддержки присутствует. Конкретный работник обезличен, потому что поддержка оказывается не одним сотрудником, а несколькими. Кто-то проводит начальную диагностику проблемы, кто-то предлагает решение и т.п.
vessart
05.07.2018 09:41Так и не понял почему в предыдущей версии экспорт корректно работал.
vessart
05.07.2018 09:51Ещё, всё ждал когда слово возьмёт Контур: — Я совсем чуть-чуть выступал за край грани, но этого трагически хватило, чтобы алгоритм булевой операции шёл не по той ветке.
kompas_3d
05.07.2018 11:18Скругление раньше не строилось такое, которое стало возможно строить в новой версии.
Модель усложнилась: стали использоваться такие скругления, сгибы, сочетания ребер, которые математика не позволяла обработать.
UnrealQW
05.07.2018 09:41Мне кажется, что Аскон должны извиниться, что такая ситуация вообще произошла. И, возможно, выплатить компенсацию за недополученную прибыль. Это ведь платная производственная прога, а не фри-ту-плей ММО.
И я не понял: Из более ранних версий Компаса экспорт той же модели также выходил с косяками? А экспорт через другие форматы файлов тоже не работал?Am0ralist
05.07.2018 12:07+1И я не понял: Из более ранних версий Компаса экспорт той же модели также выходил с косяками?
Вообще-то из текста статьи явно понятно, что в предыдущей версии такую модель и создать было нельзя. Более сложная модель потребовала большей точности математики, алгоритм не переварил и в результате при экспорте всё рассыпалось. То есть тут-то как раз претензий к Компасу — быть не может, ошибки случаются.UnrealQW
06.07.2018 08:411. Сохраняем модель в более раннюю версию файл модели Компаса.
2. Открываем ее в старой версии Компаса.
3. Экспортируем оттуда в stp/x_t/sat
Не пройдет 2 этап?
ship2k
06.07.2018 10:02+2Первый диалог очевидно неудачен. «Это ошибка в компас.» Это не корректный ответ
Это корректный ответ, ошибка может быть и не в компас. Первейшая задача техподдержки — локализация ошибки.
Продолжение и того лучше. «Ошибка будет исправлена позднее»
Это действительно неудачный ответ, но другого очень часто нет. Клиент бывает не один и у компании может просто не быть ресурсов. Это безусловно минус компании. Но называть нереальные сроки тоже бессмысленно, если они все равно не будут выполнены.
Она должна вставать в позицию пользователя, понять его нужды и с его позиции пинать разработчиков
Нет. Основная задача ТП это выяснить у пользователя все обстоятельства. Большинство пользователей просто не умеют корректно формулировать проблемы. Вот саппорт и должен «разговорить клиента на правильный кейс». После чего проверить все варианты решений. Уточнить у разработки является ли кейс пользователя корректным.
И после этого или выдать решение или воркараунд, или зафиксировать ошибку в ПО и соответственно информировать клиента о ходе исправления.
Если ценность клиента не создается — продукт бесполезен
«Плюнь тому в глаза, кто скажет, что можно обнять необъятное!» Козьма Прутков.
И, возможно, выплатить компенсацию за недополученную прибыль.
Это распространенное заблуждение. В таком случае клиент должен платить разработчику процент от полученной прибыли, он же зарабатывает с помощью этого ПО.
Так можно и с каждого молотка при промахе по гвоздю требовать компенсацию с производителя.
Риск использования того или иного инструмента — это забота того, кто им пользуется. Предусмотреть все варианты здесь невозможно (см. К. Прутков).MazayAl
06.07.2018 11:53Нет. Основная задача ТП это выяснить у пользователя все обстоятельства...
Все равно что сказать, что задача повара нарезать травы и залить майонезом. Вроде и правильно, но нет, теряете из рассмотрения суть. Если смотреть конкретно по мейджорам EDA, то сотрудник поддержки отвечает за понимание флоу заказчика и выражение его интересов, он кстати и за внутреннюю приемку отвечает. И если он принял, а заказчик нет, то это его косяк. То есть это именно то о чем я говорю — он носитель интересов заказчика, его цель в том чтоб флоу заказчика работал. И это момент принципиальный, это позволяет компании сохранять связь с реальностью. А уж открытие тикетов, звонки про обстоятельства, согласование сроков это инструменты реализации его позиции, а не самостоятельные действия.
lexnekr
Мда, не умеют наши люди с техподдержкой общаться. Всё это хамство вида «Отсюда вопрос: А что же вы там исправляли?»
Понятно, что у человека сроки горят, работа стоит, ответственность и т.п. Но поведение очень не корректное.
Ребята в Техподдержке молодцы (это не только вашей ТП касается, есть немало программных продуктов для профессионалов, где сотрудникам приходится с таким сталкиваться).
P.S. эх, много лет не работал с компасом. В своё время на автокад заставили перейти. А продукт весьма неплох, прост в работе…
c3dlabs Автор
Мы много лет состоим с Алексеем Павловичем в отношениях взаимного уважения и дружбы ))) В данном случае ситуация действительно была критической для конструкторов, и эмоции взяли верх. Мы понимаем.
Am0ralist
Что прям так коломенским отношением ТП к клиентами повеяло…
scream_r
.del
scream_r
Вначале техподдержка тоже была не на высоте. Первый диалог очевидно неудачен. «Это ошибка в компас.» Это не корректный ответ. Как бы вообще не ответ. Он вызывает раздражение своей бессмысленностью. Разумеется на это последовал вопрос «И что!?» Потому что действительно, и чо.
Продолжение и того лучше. «Ошибка будет исправлена позднее». И всё. Я верю в добро и могу предположить, что может менеджеру трудно было назвать сроки, но со стороны спрашивающего такой ответ звучит как «Идите на и там ждите.»
Тому кто вёл этот первый диалог от лица техподдержки нужно поработать над эмпатией. Его ответы бьют собеседника мордой об стену, никак не решая его вопрос. Вполне вероятно что именно такое начало задало тон всему дальнейшему общению.
lexnekr
я и первый ваш комментарий видел, можно было не повторяться.
=)
Техподдержка отработала абсолютно корректно. Респект ребятам.
Вы, видимо, никогда в саппорте не работали и не были на поддержке технически сложных проектов и продуктов.
В статье вполне чётко сказано, что саппорт, клиент и разработчики — это 3 стороны. Ну не может саппорт ничего сделать кроме как передать в разработку информацию и сообщить об этом клиенту, если она серьёзная. Ну нет у них сроков. Может их вообще нету, может у них «скрам» и сейчас как раз середина итерации?
Судя по реакции Компании, это пример скорее «сарказма». Да, я тоже с таким сталкивался (да и сам к нему скатываюсь часто). Но конечно это тоже не очень правильно в рабочих отношениях, как мне думается.
scream_r
В первом комментарии были лишние эмоции )
Так это и требовалось. Ну вот он вторым ответом сообщил что передал проблему разработчикам и они будут её решать. Что мешало ответить так сразу? Это был бы корректный ответ. А не «У вас ошибка!» — «Да, у нас ошибка» Точка. Ну издевательство же.
Далее по срокам сказать, что не может сейчас их назвать, разработчики анализируют проблему и мы вас первого известим, как только разберёмся. Просим вас быть на связи, если у разработчиков возникнут к вам вопросы.
Всё то же самое по информативности, но без вот этого «Ви шо не видите у нас учёт!». И тогда может меньше придётся соболезновать бедной техподдержке, что у неё клиенты видите ли нервные.
lexnekr
Вы слишком эмоционально воспринимаете не только мой комментарий, но и реплики саппорта.
Если клиент долго работает с вендором, то обычно все истории про особенности кухни и сроков и так уже известны — их не надо повторять. А тем, с кем работаешь не долго такие вещи говорить бесполезно, т.к. начинается «я клиент, я заплатил».
Ну, т.е. я вашу мысль уловил, я согласен, что информативный ответ саппорта нужен. Но в данном конкретном случае ответ саппорта был ИМХО нормальным, а вот клиент заставил мои брови поползти вверх.
scream_r
История рассказана от лица компании и саппорта. Мы в блоге этой компании и её саппорта. Обсуждать клиента в данном случае неверно. Вот когда клиент расскажет историю со своей стороны, и вдруг будет тут публично жаловаться на компанию, я буду ему говорить что он не прав, люди работают, и всё не так просто, недостаточно того что «ты клиент ты заплатил». Но он этого не делает.
В данном случае поглаживание саппорта тут бессмысленно. И «клиент же должен понимать» это как раз то самое «вы шо не видите...». Ты саппорт. Будь корректен и информативен. Не оставляй недомолвок. Даже в 100500 раз. Это и есть твоя работа. А обсуждать клиента в истории от лица компании, где она вылизала свою позицию, а клиент в ней выглядит психом… Это как раз мало хорошего говорит о компании. История то была о том как быстро и эффективно решена проблема в движке по первому обращению клиента? Ну так представьте клиента хорошо, даже если были неприятные моменты. История ваша от этого только приобретёт. Это публичный ресурс, вы с именем и фамилией сор из избы вынесли, и вывесили в интернете для миллионной аудитории. Которая налетела и с жаром начала клиенту косточки перемывать. Молодцы. Или смысл и был пожаловаться на клиента? Тогда вообще треш. Короче как ни крути, а из компании тут так себе Д'Артаньян получился.
c3dlabs Автор
Вы правы, история о том, как решалась проблема в движке на основе обращения клиента. Не так быстро, как того требовала ситуация на заводе, отсюда и накал эмоций.
Фрагменты переписки с техподдержкой приведены без «вылизывания» позиций обеих сторон. Публикацию этого материала, со всеми персональными подробностями, Алексей Павлович одобрил.
MazayAl
Если бы тех-поддержка только файлы туда-сюда гоняла она была бы не нужна. Она должна вставать в позицию пользователя, понять его нужды и с его позиции пинать разработчиков, предложить/добиться принятия плана, удовлетворяющий по функциональности и срокам пользователя.
Но отвечать на «сроки согласования с заказчиком уже прошли» вот этим «ошибка будет исправлена позднее» это позорище как не крути.