Как стать автором
Обновить

Комментарии 49

Конечно ничего нового не написано, но хочется отметить что служба вашей поддержки действительно эффективна, жаль только что она существует лишь на английском. Хотя если посмотреть на ru-board.com, то можно увидеть тоже неслабую «службу поддержки» на родном языке, аж 4 темы по 100 страниц, вот последняя forum.ru-board.com/topic.cgi?forum=33&topic=10884#1
Спасибо за положительный отзыв о нашей службе поддержки, я им обязательно передам :-)

Я согласен, что иногда выглядит немного странно, когда два русскоязычных человека пишут друг другу по-английски (к в том старом анекдоте), но вроде технический английский не так уж и сложен для большинства наших сограждан (мы половину слов, что употребляем в своей речи, «калькируем» с английских терминов), а выгода от этого для суппорта большая.

P.S. Что бы мы делали без ру.боарда :-)
а на ру.боард действительно отвечают представители вашей компании?
и таблетки выкладывают тоже они. партизанят в тылу у работодателя ;)
подсаживают на таблеточки а потом, когда нужен чистый лицензионный продукт говорят — «купи!» :D
я не читала рубоард, поэтому не в курсе о содержимом.
У нас и бесплатные продукты есть ;-)

А вообще, можно поподробнее, о чём вы?
да ни о чем серьезном. пытался пошутить. просто на руборде кроме обсуждения софта можно найти и «таблетки от жадности». конкретно к вашим продуктам обычно чешского(?) производства.

в контексте диалога я пытался скрутить тему сотрудников отвечающих на вопросы на форуме и процесс появления таблеток в нечто вроде «партизанского маркетинга», ведь для вас пиратские копии компонентов работают так же как и пиратские винды — сначала привыкаем а потом покупаем, когда по ряду причин «пиратская» копия не подходит. сам несколько раз наблюдал как это происходило именно с вашими компонентами ;) — товарища сначала писали с использованием пираток, а когда дозрели до «монетизации» продукта купили лицензии чтобы все было «чисто»
да уж… в курсе мы про эти «таблеточки», и не только из Чехии… Но точно не от нас — это был бы совсем экзотический способ привлечения клиентов :-)

Хотя как-то на выставке у нас был случай, когда к нам подошли ребята из одного сибирского города и честно признались, что весь год использовали наши пиратские компоненты, чтобы написать свою программу, а вот теперь собираются выходить с этим продуктом на рынок и хотят купить у нас лицензию… прямо как то, что наблюдали вы.

Что касается наших «партизан» на руборарде, официально весь наш суппорт работает через основной канал поддержки… А в своё свободное время наши разработчики могут заниматься, чем им вздумается, так что за каждого поручиться не могу ;-)
>У нас и бесплатные продукты есть ;-)
хм… не замечал. а если не секрет, какие и где их можно найти?
Например, грид для Silverlight и ещё кое-что… Вообще, чтобы исправить ситуацию, я думаю, мы напишем пару статей на следующей неделе по этому поводу…
Кстати, совсем забыл упомянуть :-)

В отличие от многих конкурентов, наш суппорт тоже бесплатный.
>(плохой ответ):
> «Как это сделать, написано в этом документе.»
>
> (хороший ответ):
>
> «Для того чтобы решить вашу проблему, вам нужно сделать то-то и то-то. Ещё вам может >понадобиться это. Подробнее, вы можете прочитать здесь и здесь, а также посмотреть онлайн видео >или скачать рабочий пример с нашего сайта. Если у вас есть ещё вопросы по этой проблеме, сообщите >нам об этом, и мы будем рады вам помочь.»

Позвольте поспорить. В первом случае вы даёте ОДНУ ссылку на документ, или демо ролик. А во втором случае ссылок аж 4 штуки.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.

Другие вопросы вам — перезваниваете ли вы клиентам, если они просят?
Судя по их KB пользователи редко задают конкретный вопрос, ответом на который является одна ссылка, и довольно редко есть одно единственное правильное решение, в основном все получается так как описано в топике.
Ну тут всё от задачи зависит…
> Позвольте поспорить. В первом случае вы даёте ОДНУ ссылку на документ, или демо ролик. А во втором случае ссылок аж 4 штуки.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.

Ну, тут действительно часто всё зависит от «конкретности» вопроса.

Но на самом деле, я много раз сталкивался с ситуацией, когда человек задаёт свой вопрос и получает в ответ «это уже обсуждалось в Q1242, смотри там»… Это ему ещё надо там копаться, смотреть, что да как. А если сказать ему: «Это уже обсуждалось в Q1242, вам поможет такое-то свойство, вот вам пример в хелпе, вот вам ссылка на видео и онлайн пример (по тому же поводу)», то шансов, что он поймёт, как ему использовать этот подход, будет гораздо больше.
Согласен.
А по поводу звонков? Перезваниваете, если просят?
Просто интересно, а бывала такая необходимость? Может расскажете поподробнее про ситуацию?
> Другие вопросы вам — перезваниваете ли вы клиентам, если они просят?

Телефонной службы поддержки у нас нет… Да и смысл, если рано или поздно всё заканчивается вопросом: «а что вы видете на экране?», «а покажите ваш код?», «нет, сначала вы?»…

Я, конечно, утрирую, но реально телефонная поддержка нужна только в тех случаях, когда нужно обсудить проблемы по покупке компонентов или что-то с этим связанонное… Для этого в России у нас есть реселлеры, и телефонная поддержка там наверняка должна быть.
> В этой системе за каждым вопросом пользователя закреплён сотрудник службы поддержки. Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время (заболел, ушёл в отпуск или по иной причине покинул поле боя), у нас есть механизм оповещения об этом — чтобы координатор мог передать такой вопрос другому специалисту из службы поддержки.

Как бывший руководитель отдела техподдержки, обслуживавшего 15000 клиентов, со всей ответственностью заявляю — это порочная практика. Это очень, очень большое зло.

Не должно быть ответственного за тикет. Любой тикет должен обрабатываться любым сотрудником техподдержки. В противном случае сразу возникают две классически ситуации — «я за это не отвечаю» и «васи не было, вот и не отвечали долго».

> У каждой проблемы может быть много внешних и внутренних статусов, зависящих от типа вопроса (например, баг может быть Reproduced, Fixed или By Design)

Личный опыт подсказывает, что для любой проблемы необходимо и достаточно иметь два статуса — открыто/закрыто. Сколько я ни пытался применить в деле большее количество статусов, все равно все сводится к этим двум.

Не могли бы Вы более развернуто рассказать, зачем Вам множество статусов и какая в них, на самом деле, необходимость?

> Поэтому, задавая свой вопрос нам, он точно знает, что получит ответ (самое позднее) в течение 24-х часов, без учёта праздников и выходных.

Я считаю, это слишком много. Ответ должен быть получен максимум в течение ребочего дня. Ответ через 24 часа, т.е. на следующий день, это профанация работы техподдержки.

> Мы сделали публичной базу всех пользовательских проблем (вопросов, багов и реквестов).

Мало кто читает FAQ. Даже внимательно, грамотно и с любовью оформленный. В хаосе же всех пользовательских обращений вообще малореально разобраться. Подобная база представляется мне бессмысленной. Разве что Ваши пользователи — сами вполне специалисты, способные самостоятельно раскапывать информацию.

> В нашем же случае мы считаем, что телефонный суппорт нам не подходит…

Тут я согласен. Я даже больше скажу — необходимость телефонного сапорта — это вообще заблуждение, происходящее, как мне кажется, с тех древних времен, когда не было удобных средств управления заявками по электронной почте. Пережиток прошлого, короче говоря.

Диалог по телефону имеет смысл только в том случае, когда необходимо быстрое обсуждение какого-то вопроса, над которым нет необходимости серьезно думать.
Мне понравился Ваш коммент, хочу у вас работать :)
Но! Отрыто/Закрото это очень круто, а как быть с «Принято»? Или вот еще — если нет FAQ, то кто должен подсматривать туда, если не пользователь и не саппорт?
Упс, промахнулся с ответом, смотрите ниже.
> Как бывший руководитель отдела техподдержки, обслуживавшего 15000 клиентов,

Круто. Реально, очень приятно видеть, что человек с таким опытом делится своим мнением с нами :-) Но если что, количество наших клиентов как минимум сравнимо с вашей цифрой.

> со всей ответственностью заявляю — это порочная практика. Это очень, очень большое зло. Не должно быть ответственного за тикет. Любой тикет должен обрабатываться любым сотрудником техподдержки. В противном случае сразу возникают две классически ситуации — «я за это не отвечаю» и «васи не было, вот и не отвечали долго».

Я в принципе, понимаю, о чём вы. Но как раз про это и было написано в статье: «Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время...» — и не факт, что 24 часа уже прошло. В идеале, мы заранее знаем, если кто-то отсутствует, и вопросы этого человека подхватываются другими членами команды заранее.

Но ответственный за вопрос нужен в любом случае. Я уверен, был он и вашей системе. Как минимум, человек видит вопрос и собирается на него отвечать — он должен по-любому как-то дать знать остальным, что это вопрос мой, не берите его и даже не смотрите, не тратьте на него своё время. Плюс бывает полезно, что если пользователь реактивировал вопрос, то его возьмет тот же человек, который смотрел его до этого и уже вникал в его проблему — а если вопросы будут постоянно менять отвечающего, то каждому новому человеку нужно будет тратить время, чтобы вникнуть в суть проблемы.

Но в целом я с вами согласен — должна быть взаимозаменяемость. И мы у себя это тоже используем, у нас нет такого, что никто кроме Васи не может ответить на этот вопрос. Кстати, это используется и среди программистов — тут очень помогает такая практика XP как «парное программирование»… Но это уже тема для отдельной статьи :-)
>Я в принципе, понимаю, о чём вы. Но как раз про это и было написано в статье: «Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время...» — и не факт, что 24 часа уже прошло. В идеале, мы заранее знаем, если кто-то отсутствует, и вопросы этого человека подхватываются другими членами команды заранее.

Так это как-раз и означает, что ответственного быть не должно. Введя ответственного, вы сами же вынуждены были ввести дополнительный механизм для передачи тикета с ответственного на любого другого.

> Но ответственный за вопрос нужен в любом случае. Я уверен, был он и вашей системе. Как минимум, человек видит вопрос и собирается на него отвечать — он должен по-любому как-то дать знать остальным, что это вопрос мой, не берите его и даже не смотрите, не тратьте на него своё время.

Ну, право слово, вы меня смущаете. Любая приличная система обработки тикетов имеет встроенный механизм, лочащий тикет на того, кто его взял. Это простая техническая задача, административного назначения ответственных для этого не требуется.
> Так это как-раз и означает, что ответственного быть не должно. Введя ответственного, вы сами же вынуждены были ввести дополнительный механизм для передачи тикета с ответственного на любого другого.

> Ну, право слово, вы меня смущаете. Любая приличная система обработки тикетов имеет встроенный механизм, лочащий тикет на того, кто его взял. Это простая техническая задача, административного назначения ответственных для этого не требуется.

Хочется правды :-)

1. Например, в нашей работе бывает удобно, когда один и тот же сотрудник «ведёт» проблему пользователя от начала и до конца. Он уже разобрался с ней при первом рассмотрении, дал человеку совет; если совет не помог или помог, но не очень, то пользователь возвращается к тому же сотруднику, который снова пытается ему помочь и т.д. до достижения результата.

Это ценно со следующих точек зрения:
— Если постоянно переключать задачу между разными сотрудниками, каждому из них придётся вникать в проблему. Если она сложная, то это может отнимать значительное время у каждого из них, лишнее время;
— Если один и тот же человек ведёт проблему пользователя от начала и до конца, есть вероятность того, что его осенит или он получит совет от кого-то ещё, кто не мог дать этот совет раньше, и тогда можно будет сделать ценный follow-up;
— Пользователь общается с одним и тем же человеком, он знает его имя, он доверяет ему. И он знает, кому говорить спасибо :-) У некоторых пользователей даже есть любимые суппортисты! А если он постоянно будет видеть, что с ним общаются разные люди, у него возникнет ощущение, что все «спихивают» его проблему друг другу, и это будет раздражать…

Как вы на это смотрите? Имело ли это ценность в вашей работе?

2. Вы говорите, человек может «залочить» на себя вопрос… Хочется понять, в чём разница между «человек, ответственный за вопрос» и «человек, залочивший на себя вопрос» в вашем случае?
>Например, в нашей работе бывает удобно, когда один и тот же сотрудник «ведёт» проблему пользователя от начала и до конца.

Это действительно хорошо, тут я согласен. Но это же работает только в пределах одной смены. Если вопрос не был решен за одну смену одним сотрудником, то он не должен оставаться повисшим в воздухе. Следующий сотрудник, заступивший на смену, должен взять вопрос в работу, не дожидаясь, пока истечет какой-то таймаут и вопрос перейдет от ответственного в общее пользование. Вот в чем дело.

>Вы говорите, человек может «залочить» на себя вопрос… Хочется понять, в чём разница между «человек, ответственный за вопрос» и «человек, залочивший на себя вопрос» в вашем случае?

Разница во времени залочки. Ответственный держит тикет, пока не истечет таймаут. Залочивший же держит тикет только пока непосредственно с ним работает.

Кроме того, ответственному тикет может быть отдан еще до того, как он начнет с ним работать, а это опять простой. А залочка начинается ровно в тот момент, когда человек берет тикет в работу.
> Я считаю, это слишком много. Ответ должен быть получен максимум в течение ребочего дня. Ответ через 24 часа, т.е. на следующий день, это профанация работы техподдержки.

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

А какой разброс был у ваших пользователей по часовым поясам? Как вы с этим справлялись?
Так это не важно, какой у него пояс. Вашим сотрудникам вообще не надо это знать, пусть просто отвечают и все, какой бы ни был пояс.

А пользователь должен знать, что если он написал вопрос утром (в смысле, когда утро в его поясе), то к вечеру он получит ответ. Если он написал вопрос вечером, то конечно, ежу понятно, что в этот рабочий день ответа уже не будет.

Короче, можно так сформулировать — максимальное время ответа должно быть 8 часов, а не 24.

> А какой разброс был у ваших пользователей по часовым поясам? Как вы с этим справлялись?

Мы работали по России, поэтому разброс поясов примерно 9 часов, если мне не изменяет память. Подход был вот как я выше написал — лимит 8 часов.

Собственно говоря, мы как-то вообще не рассматривали этот вопрос в разрезе часовых поясов. Рабочий день клиента — это понятно, ответ желательно уложить в рабочий день клиента, те самые 8 часов. А какой у клиента пояс — это не существенно. Поддержка работает круглосуточно без выходных и праздников, так что пояс клиента без разницы — любой клиент из любого пояса получает ответ максимум за время своего рабочего дня, 8 часов.
> Короче, можно так сформулировать — максимальное время ответа должно быть 8 часов, а не 24.

Для нас это важно. Например, человек послал нам свой вопрос в самом начале своего рабочего дня, а у нас в это время было 12 часов ночи. Если при этом у нас уже был поток вопросов, заданных ранее, то вопрос, заданный в 12 часов ночи, скорее всего пролежит какое-то время без ответа. Мы на него ответим нашим утром, а у человека, который его задал, рабочий день к тому времени закончится, и он получит ответ уже утром своего следующего рабочего дня. Вот оттуда и получается 24 часа.

> Поддержка работает круглосуточно без выходных и праздников

Ну вот в этом видимо и разница. У нас служба поддержки не работает круглосуточно — это было бы слишком дорого для нас, да и нет смысла так насиловать людей: сейчас в большинстве случаев время ответа пользователю вполне приемлемо и заметно меньше 24 часов… Хотя, работу в несколько смен, конечно же, никто не отменял. Опять же, и наша служба поддержки не всегда находится в одном и том же часовом поясе ;-)
> Личный опыт подсказывает, что для любой проблемы необходимо и достаточно иметь два статуса — открыто/закрыто. Сколько я ни пытался применить в деле большее количество статусов, все равно все сводится к этим двум.

> Не могли бы Вы более развернуто рассказать, зачем Вам множество статусов и какая в них, на самом деле, необходимость?

Согласен, вопрос статусов — это всегда достаточно спорная вещь, и тут наверное каждый просто пользуется тем, что больше отражает суть внутреннего воркфлоу. Я могу только поделиться тем, что есть у нас…

Да, для пользователя всегда важно только два состояния его проблемы — Active или Closed. Если рассмотреть для примера проблему типа «баг», то мы добавляем к Closed разъяснение: Closed (Fixed), Closed (Can't Reproduce) или Closed (By Design). Это внешние статусы, важные для пользователя, по ним он понимает, что случилось с его проблемой и как мы её трактуем.

Для нас же внутри существует три состояния бага:
— баг требует действия службы поддержки (например, он был только что создан; или пользователь спрашивает, когда он будет пофикшен; или сообщает какую-то другую информацию по проблеме),
— баг требует фикса со стороны разработчика,
— баг не требует от нас никаких действий, и мы считаем его закрытым.

Получается, что первые два статуса — Active для пользователя, но для нас это разные Active — один требует реакции в течение 24 часов, другой — нет. Поэтому приходится вводить внутренние статусы…
Но позвольте.

>то мы добавляем к Closed разъяснение: Closed (Fixed), Closed (Can't Reproduce) или Closed (By Design)

А зачем? Кому нужна эта информация, кто ее реально использует для дела?

Closed (Fixed) — это просто Closed, это окончально и бесповоротно решенный вопрос, о нем больше сказать нечего.
Closed (Can't Reproduce) — это переданный пользователю тикет, в запросом уточнений, правильно я понимаю? Это Active, на самом деле.
Closed (By Design) — это тоже просто Closed, все равно добавить больше нечего.

> Для нас же внутри существует три состояния бага:

Опять же, вопрос в том, действительно ли эта информация используется в деле?

баг требует действия службы поддержки — это просто Active.
баг требует фикса со стороны разработчика — это Active, только тикет перемещен в очередь разработчиков, а не сапорта.
баг не требует от нас никаких действий, и мы считаем его закрытым — так это просто Closed.

Я тоже пытался вводить статусы, разрабатывал политики их назначения. Но на практике все-равно все как-то сводилось к открыт/закрыт.

Я тут, впрочем, не настаиваю — если у Вас получается успешно применять статусы — то вам везука:)
Мне как клиенту достаточно интересно, закрыт ли тикет с предложением потому, что его реализовали (Fixed), или потому, что решили этого никогда не делать (By Design).
Решили этого никогда не делать — это Rejected или на крайний случай Won't Fix :)

By Design — это когда сделать ничего, увы, нельзя.
Еще один случай для By Desing — это когда с нашей точки зрения все работает как должно, про это обычно отписывают в последнем ответе подробно.
> Подобная база представляется мне бессмысленной. Разве что Ваши пользователи — сами вполне специалисты, способные самостоятельно раскапывать информацию

Учитывая, что DevExpress делает инструменты для разработчиков, здесь как раз этот случай. Правда, встроенный поиск в их KB неидеален — у меня чаще получалось найти нужную информацию на их же сайте через Гугл. Но уж как найдешь — красота, в большинстве случаев не просто описан способ решения, а прикреплен проект с примером.
Скажите, а для поиска на нашем сайте вы пользуетесь search.devexpress.com?Просто он какое-то время был в бете, и может быть не очень хорошо был заметен…

Но по идее он должен давать достаточно релевантные результаты.
Пользовался тем, что в Support Center предлагалось по умолчанию.

Даже сейчас сравните: в Гугле я спрашиваю «devexpress .net localization», и первая ссылка — A421, чего я и хотел.

А на вашем сайте по запросу «localization» (категорию .net я выбрал) это где-то пятое по очереди, да еще и таб надо переключить — это, по-моему, не лучшее решение.
Надеюсь очень скоро, у нас будет обновленный поиск…
Как человек принимавший участие в разработке обоих версий поиского движка, могу сказать что есть у этих движков и преимущества по сравнению с гугл и недостатки.

Например, ваш пример.
Гугл при поиски принимает в расчет количество ссылок на документ с других сайтов. Наш же поиск, даже в теории этого сделать не может. Соотвественно, он может посчитать только релевантность документа и внутренние ссылки на него.
Но с другой стороны, гугл не знает ничего о типах наших документов — он не может отличить, например, документацию от вопроса на форуме.
Ну или например, сделанный suggestion от rejected (по логике, выше в результатах поиска должны быть именно отвеченные/реализованные suggestion).
> Мне понравился Ваш коммент, хочу у вас работать :)

К сожалению, компания Петерхост, где я проводил подобную политику техподдержки, была в свое время продана компании РБК и я был вынужден уйти в другое место, уже не в техподдержку, а в разработку.

К тому же, некоторые считают, что я очень вредный и провожу собеседования как бездушная бесчеловечная машина:) Вот — habrahabr.ru/blogs/personal/70262/

> Но! Отрыто/Закрото это очень круто, а как быть с «Принято»?

Не совсем понятен вопрос. Вы скажите, зачем нужно «Принято», а я скажу, как я без этого обхожусь.

> Или вот еще — если нет FAQ, то кто должен подсматривать туда, если не пользователь и не саппорт?

Ээ… если FAQ нет, то и подсматривать туда никто не должен:) Вы, наверное, как-то иначе хотели вопрос сформулировать:)
А можно попросить Вас дать чуть больше пояснений, как реализуется система хотфиксов?
— Каждому клиенту отдельную версию?
— Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
— Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
— Проходят ли все эти сборки полное тестирование?
… и как все это поддерживается в рабочем состоянии в течение полугода до нового апдейта? :)

По своим проектам наболело.
Для понимания картины.

Каждая мажорная версия живет в отдельной ветке в source control. После того как конкретная мажорная версия выпущена в свет, в её ветке исправляют только баги, никакого нового функционала не пишется. Все новое пишется в другой ветке.

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

Теперь про хотфиксы.

Клиент запрашивает хотфикс на конкретный баг, закрытый со статусом Fixed. Дальше ручками, т.к. пока нет необходимости автоматизировать. Суппортист смотрит на дату закрытия бага, берёт готовую инсталляцию, собранную на день/другой позже этой даты, выкладывает её на сайт в раздел хотфиксов, даёт клиенту ссылку.

>> Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
Если речь о хотфиксах, то ему просто очередной хотфикс отдают. В нём уже оба бага исправлены. Т.е. любой хотфикс является кумулятивным. Когда в версии набирается некоторое достаточно большое кол-во поправленных багов, выпускаем публичное минорное обновление для этой версии.

>> Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
Если хотфикс уже был запрошен и выложен, просто скачивает его, в баг мы ссылку на выложенный хотфикс добавляем. Если хотфикс ещё никто не запрашивал по данному багу, то просто запрашивает хотфикс, кнопочка есть.

>> Проходят ли все эти сборки полное тестирование?
Все автотесты на этих сборках проходят успешно. Ручками хотфиксы не тестируют.
Спасибо за подробный ответ! Спрашивал, так как надеялся увидеть чудодейственное решение которое бы позволило избежать ручного мержа багфиксов в бранч c выпущенной версией. А вдруг :)
Эта проблема стоит особенно остро, так как несколько проектов, выпускающихся в разное время, используют общий код — и хотфикс в этом коде очень трудозатратен. Обдумывая Ваш ответ, появилась идея выносить общий код из бранчей каждого проекта, надо еще обдумать) Так что вдвойне спасибо.
> … и как все это поддерживается в рабочем состоянии в течение полугода до нового апдейта? :)

Обычно наши апдейты выходят гораздо чаще: для «живых» версий это каждый месяц или около того. А какая у вас версия? Опять же, .Net или VCL?
Пока вашим клиентом не являюсь :) Про «полгода» — это просто цитата из статьи "… который будет через полгода" :) Плюс DRogov упомянул про минорные обновления, и все стало на свои места.
Я работал с вашими продуктами почти год. Суппорт у вас действительно неплох, чего, к сожалению, нельзя сказать о компонентах. Я использовал ASP.NET контролы и в них содержится столько багов, что я порой думал, что являюсь вашим тестеровщиком, а не пользователем. Это достаточно печально, учитывая немалую стоимость ваших компонент.
Сейчас мой знокомый использует компоненты Windows Forms и он вроде тоже не в восторге, хотя тут я как раз-таки сказать ничего не могу. Сам не использовал.
А можно по подробнее о проблемах с которыми пришлось столкнуться?
Несколько лет назад, мы постарались измениться в asp.net в лучшую сторону :) — и надеюсть с тех пор, наши контролы становятся быстрее и лучше.
Я использовал контролы в течения этого года. В основном это были AspxHtmlEditor & AspxTreeList. Особенно мне запомнилась переписка с саппортом, когда вы никак не могли воспроизвести баг (тут признаю, была моя ошибка — я не правильно указал версию продукта), в процессе которой вы нашли еще одну ошибку, пытаясь повторить мои шаги.
Из проблем — совместимость с браузерами и некорректно работающий функционал при определенных сценариях.
Спасибо за feedback. Как я понимаю, вы A.G.?
Непосредственных разработчиков попросили еще раз, повнимательнее относиться к cross-browser совместимости…

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.