Комментарии 49
Конечно ничего нового не написано, но хочется отметить что служба вашей поддержки действительно эффективна, жаль только что она существует лишь на английском. Хотя если посмотреть на ru-board.com, то можно увидеть тоже неслабую «службу поддержки» на родном языке, аж 4 темы по 100 страниц, вот последняя forum.ru-board.com/topic.cgi?forum=33&topic=10884#1
Спасибо за положительный отзыв о нашей службе поддержки, я им обязательно передам :-)
Я согласен, что иногда выглядит немного странно, когда два русскоязычных человека пишут друг другу по-английски (к в том старом анекдоте), но вроде технический английский не так уж и сложен для большинства наших сограждан (мы половину слов, что употребляем в своей речи, «калькируем» с английских терминов), а выгода от этого для суппорта большая.
P.S. Что бы мы делали без ру.боарда :-)
Я согласен, что иногда выглядит немного странно, когда два русскоязычных человека пишут друг другу по-английски (к в том старом анекдоте), но вроде технический английский не так уж и сложен для большинства наших сограждан (мы половину слов, что употребляем в своей речи, «калькируем» с английских терминов), а выгода от этого для суппорта большая.
P.S. Что бы мы делали без ру.боарда :-)
а на ру.боард действительно отвечают представители вашей компании?
и таблетки выкладывают тоже они. партизанят в тылу у работодателя ;)
подсаживают на таблеточки а потом, когда нужен чистый лицензионный продукт говорят — «купи!» :D
подсаживают на таблеточки а потом, когда нужен чистый лицензионный продукт говорят — «купи!» :D
я не читала рубоард, поэтому не в курсе о содержимом.
У нас и бесплатные продукты есть ;-)
А вообще, можно поподробнее, о чём вы?
А вообще, можно поподробнее, о чём вы?
да ни о чем серьезном. пытался пошутить. просто на руборде кроме обсуждения софта можно найти и «таблетки от жадности». конкретно к вашим продуктам обычно чешского(?) производства.
в контексте диалога я пытался скрутить тему сотрудников отвечающих на вопросы на форуме и процесс появления таблеток в нечто вроде «партизанского маркетинга», ведь для вас пиратские копии компонентов работают так же как и пиратские винды — сначала привыкаем а потом покупаем, когда по ряду причин «пиратская» копия не подходит. сам несколько раз наблюдал как это происходило именно с вашими компонентами ;) — товарища сначала писали с использованием пираток, а когда дозрели до «монетизации» продукта купили лицензии чтобы все было «чисто»
в контексте диалога я пытался скрутить тему сотрудников отвечающих на вопросы на форуме и процесс появления таблеток в нечто вроде «партизанского маркетинга», ведь для вас пиратские копии компонентов работают так же как и пиратские винды — сначала привыкаем а потом покупаем, когда по ряду причин «пиратская» копия не подходит. сам несколько раз наблюдал как это происходило именно с вашими компонентами ;) — товарища сначала писали с использованием пираток, а когда дозрели до «монетизации» продукта купили лицензии чтобы все было «чисто»
да уж… в курсе мы про эти «таблеточки», и не только из Чехии… Но точно не от нас — это был бы совсем экзотический способ привлечения клиентов :-)
Хотя как-то на выставке у нас был случай, когда к нам подошли ребята из одного сибирского города и честно признались, что весь год использовали наши пиратские компоненты, чтобы написать свою программу, а вот теперь собираются выходить с этим продуктом на рынок и хотят купить у нас лицензию… прямо как то, что наблюдали вы.
Что касается наших «партизан» на руборарде, официально весь наш суппорт работает через основной канал поддержки… А в своё свободное время наши разработчики могут заниматься, чем им вздумается, так что за каждого поручиться не могу ;-)
Хотя как-то на выставке у нас был случай, когда к нам подошли ребята из одного сибирского города и честно признались, что весь год использовали наши пиратские компоненты, чтобы написать свою программу, а вот теперь собираются выходить с этим продуктом на рынок и хотят купить у нас лицензию… прямо как то, что наблюдали вы.
Что касается наших «партизан» на руборарде, официально весь наш суппорт работает через основной канал поддержки… А в своё свободное время наши разработчики могут заниматься, чем им вздумается, так что за каждого поручиться не могу ;-)
>У нас и бесплатные продукты есть ;-)
хм… не замечал. а если не секрет, какие и где их можно найти?
хм… не замечал. а если не секрет, какие и где их можно найти?
Например, грид для Silverlight и ещё кое-что… Вообще, чтобы исправить ситуацию, я думаю, мы напишем пару статей на следующей неделе по этому поводу…
Кстати, совсем забыл упомянуть :-)
В отличие от многих конкурентов, наш суппорт тоже бесплатный.
В отличие от многих конкурентов, наш суппорт тоже бесплатный.
Вот, например, обзор DXCore.
>(плохой ответ):
> «Как это сделать, написано в этом документе.»
>
> (хороший ответ):
>
> «Для того чтобы решить вашу проблему, вам нужно сделать то-то и то-то. Ещё вам может >понадобиться это. Подробнее, вы можете прочитать здесь и здесь, а также посмотреть онлайн видео >или скачать рабочий пример с нашего сайта. Если у вас есть ещё вопросы по этой проблеме, сообщите >нам об этом, и мы будем рады вам помочь.»
Позвольте поспорить. В первом случае вы даёте ОДНУ ссылку на документ, или демо ролик. А во втором случае ссылок аж 4 штуки.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.
Другие вопросы вам — перезваниваете ли вы клиентам, если они просят?
> «Как это сделать, написано в этом документе.»
>
> (хороший ответ):
>
> «Для того чтобы решить вашу проблему, вам нужно сделать то-то и то-то. Ещё вам может >понадобиться это. Подробнее, вы можете прочитать здесь и здесь, а также посмотреть онлайн видео >или скачать рабочий пример с нашего сайта. Если у вас есть ещё вопросы по этой проблеме, сообщите >нам об этом, и мы будем рады вам помочь.»
Позвольте поспорить. В первом случае вы даёте ОДНУ ссылку на документ, или демо ролик. А во втором случае ссылок аж 4 штуки.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.
Другие вопросы вам — перезваниваете ли вы клиентам, если они просят?
Судя по их KB пользователи редко задают конкретный вопрос, ответом на который является одна ссылка, и довольно редко есть одно единственное правильное решение, в основном все получается так как описано в топике.
> Позвольте поспорить. В первом случае вы даёте ОДНУ ссылку на документ, или демо ролик. А во втором случае ссылок аж 4 штуки.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.
Ну, тут действительно часто всё зависит от «конкретности» вопроса.
Но на самом деле, я много раз сталкивался с ситуацией, когда человек задаёт свой вопрос и получает в ответ «это уже обсуждалось в Q1242, смотри там»… Это ему ещё надо там копаться, смотреть, что да как. А если сказать ему: «Это уже обсуждалось в Q1242, вам поможет такое-то свойство, вот вам пример в хелпе, вот вам ссылка на видео и онлайн пример (по тому же поводу)», то шансов, что он поймёт, как ему использовать этот подход, будет гораздо больше.
На самом деле чем меньше употребляешь ссылок — тем лучше на мой взгляд. Тем более если пользователь задаёт конкретный вопрос.
Ну, тут действительно часто всё зависит от «конкретности» вопроса.
Но на самом деле, я много раз сталкивался с ситуацией, когда человек задаёт свой вопрос и получает в ответ «это уже обсуждалось в Q1242, смотри там»… Это ему ещё надо там копаться, смотреть, что да как. А если сказать ему: «Это уже обсуждалось в Q1242, вам поможет такое-то свойство, вот вам пример в хелпе, вот вам ссылка на видео и онлайн пример (по тому же поводу)», то шансов, что он поймёт, как ему использовать этот подход, будет гораздо больше.
> Другие вопросы вам — перезваниваете ли вы клиентам, если они просят?
Телефонной службы поддержки у нас нет… Да и смысл, если рано или поздно всё заканчивается вопросом: «а что вы видете на экране?», «а покажите ваш код?», «нет, сначала вы?»…
Я, конечно, утрирую, но реально телефонная поддержка нужна только в тех случаях, когда нужно обсудить проблемы по покупке компонентов или что-то с этим связанонное… Для этого в России у нас есть реселлеры, и телефонная поддержка там наверняка должна быть.
Телефонной службы поддержки у нас нет… Да и смысл, если рано или поздно всё заканчивается вопросом: «а что вы видете на экране?», «а покажите ваш код?», «нет, сначала вы?»…
Я, конечно, утрирую, но реально телефонная поддержка нужна только в тех случаях, когда нужно обсудить проблемы по покупке компонентов или что-то с этим связанонное… Для этого в России у нас есть реселлеры, и телефонная поддержка там наверняка должна быть.
НЛО прилетело и опубликовало эту надпись здесь
Мне понравился Ваш коммент, хочу у вас работать :)
Но! Отрыто/Закрото это очень круто, а как быть с «Принято»? Или вот еще — если нет FAQ, то кто должен подсматривать туда, если не пользователь и не саппорт?
Но! Отрыто/Закрото это очень круто, а как быть с «Принято»? Или вот еще — если нет FAQ, то кто должен подсматривать туда, если не пользователь и не саппорт?
> Как бывший руководитель отдела техподдержки, обслуживавшего 15000 клиентов,
Круто. Реально, очень приятно видеть, что человек с таким опытом делится своим мнением с нами :-) Но если что, количество наших клиентов как минимум сравнимо с вашей цифрой.
> со всей ответственностью заявляю — это порочная практика. Это очень, очень большое зло. Не должно быть ответственного за тикет. Любой тикет должен обрабатываться любым сотрудником техподдержки. В противном случае сразу возникают две классически ситуации — «я за это не отвечаю» и «васи не было, вот и не отвечали долго».
Я в принципе, понимаю, о чём вы. Но как раз про это и было написано в статье: «Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время...» — и не факт, что 24 часа уже прошло. В идеале, мы заранее знаем, если кто-то отсутствует, и вопросы этого человека подхватываются другими членами команды заранее.
Но ответственный за вопрос нужен в любом случае. Я уверен, был он и вашей системе. Как минимум, человек видит вопрос и собирается на него отвечать — он должен по-любому как-то дать знать остальным, что это вопрос мой, не берите его и даже не смотрите, не тратьте на него своё время. Плюс бывает полезно, что если пользователь реактивировал вопрос, то его возьмет тот же человек, который смотрел его до этого и уже вникал в его проблему — а если вопросы будут постоянно менять отвечающего, то каждому новому человеку нужно будет тратить время, чтобы вникнуть в суть проблемы.
Но в целом я с вами согласен — должна быть взаимозаменяемость. И мы у себя это тоже используем, у нас нет такого, что никто кроме Васи не может ответить на этот вопрос. Кстати, это используется и среди программистов — тут очень помогает такая практика XP как «парное программирование»… Но это уже тема для отдельной статьи :-)
Круто. Реально, очень приятно видеть, что человек с таким опытом делится своим мнением с нами :-) Но если что, количество наших клиентов как минимум сравнимо с вашей цифрой.
> со всей ответственностью заявляю — это порочная практика. Это очень, очень большое зло. Не должно быть ответственного за тикет. Любой тикет должен обрабатываться любым сотрудником техподдержки. В противном случае сразу возникают две классически ситуации — «я за это не отвечаю» и «васи не было, вот и не отвечали долго».
Я в принципе, понимаю, о чём вы. Но как раз про это и было написано в статье: «Если человек, назначенный ответственным за вопрос, по какой-то причине не реагирует на него в нужное время...» — и не факт, что 24 часа уже прошло. В идеале, мы заранее знаем, если кто-то отсутствует, и вопросы этого человека подхватываются другими членами команды заранее.
Но ответственный за вопрос нужен в любом случае. Я уверен, был он и вашей системе. Как минимум, человек видит вопрос и собирается на него отвечать — он должен по-любому как-то дать знать остальным, что это вопрос мой, не берите его и даже не смотрите, не тратьте на него своё время. Плюс бывает полезно, что если пользователь реактивировал вопрос, то его возьмет тот же человек, который смотрел его до этого и уже вникал в его проблему — а если вопросы будут постоянно менять отвечающего, то каждому новому человеку нужно будет тратить время, чтобы вникнуть в суть проблемы.
Но в целом я с вами согласен — должна быть взаимозаменяемость. И мы у себя это тоже используем, у нас нет такого, что никто кроме Васи не может ответить на этот вопрос. Кстати, это используется и среди программистов — тут очень помогает такая практика XP как «парное программирование»… Но это уже тема для отдельной статьи :-)
НЛО прилетело и опубликовало эту надпись здесь
> Так это как-раз и означает, что ответственного быть не должно. Введя ответственного, вы сами же вынуждены были ввести дополнительный механизм для передачи тикета с ответственного на любого другого.
> Ну, право слово, вы меня смущаете. Любая приличная система обработки тикетов имеет встроенный механизм, лочащий тикет на того, кто его взял. Это простая техническая задача, административного назначения ответственных для этого не требуется.
Хочется правды :-)
1. Например, в нашей работе бывает удобно, когда один и тот же сотрудник «ведёт» проблему пользователя от начала и до конца. Он уже разобрался с ней при первом рассмотрении, дал человеку совет; если совет не помог или помог, но не очень, то пользователь возвращается к тому же сотруднику, который снова пытается ему помочь и т.д. до достижения результата.
Это ценно со следующих точек зрения:
— Если постоянно переключать задачу между разными сотрудниками, каждому из них придётся вникать в проблему. Если она сложная, то это может отнимать значительное время у каждого из них, лишнее время;
— Если один и тот же человек ведёт проблему пользователя от начала и до конца, есть вероятность того, что его осенит или он получит совет от кого-то ещё, кто не мог дать этот совет раньше, и тогда можно будет сделать ценный follow-up;
— Пользователь общается с одним и тем же человеком, он знает его имя, он доверяет ему. И он знает, кому говорить спасибо :-) У некоторых пользователей даже есть любимые суппортисты! А если он постоянно будет видеть, что с ним общаются разные люди, у него возникнет ощущение, что все «спихивают» его проблему друг другу, и это будет раздражать…
Как вы на это смотрите? Имело ли это ценность в вашей работе?
2. Вы говорите, человек может «залочить» на себя вопрос… Хочется понять, в чём разница между «человек, ответственный за вопрос» и «человек, залочивший на себя вопрос» в вашем случае?
> Ну, право слово, вы меня смущаете. Любая приличная система обработки тикетов имеет встроенный механизм, лочащий тикет на того, кто его взял. Это простая техническая задача, административного назначения ответственных для этого не требуется.
Хочется правды :-)
1. Например, в нашей работе бывает удобно, когда один и тот же сотрудник «ведёт» проблему пользователя от начала и до конца. Он уже разобрался с ней при первом рассмотрении, дал человеку совет; если совет не помог или помог, но не очень, то пользователь возвращается к тому же сотруднику, который снова пытается ему помочь и т.д. до достижения результата.
Это ценно со следующих точек зрения:
— Если постоянно переключать задачу между разными сотрудниками, каждому из них придётся вникать в проблему. Если она сложная, то это может отнимать значительное время у каждого из них, лишнее время;
— Если один и тот же человек ведёт проблему пользователя от начала и до конца, есть вероятность того, что его осенит или он получит совет от кого-то ещё, кто не мог дать этот совет раньше, и тогда можно будет сделать ценный follow-up;
— Пользователь общается с одним и тем же человеком, он знает его имя, он доверяет ему. И он знает, кому говорить спасибо :-) У некоторых пользователей даже есть любимые суппортисты! А если он постоянно будет видеть, что с ним общаются разные люди, у него возникнет ощущение, что все «спихивают» его проблему друг другу, и это будет раздражать…
Как вы на это смотрите? Имело ли это ценность в вашей работе?
2. Вы говорите, человек может «залочить» на себя вопрос… Хочется понять, в чём разница между «человек, ответственный за вопрос» и «человек, залочивший на себя вопрос» в вашем случае?
> Я считаю, это слишком много. Ответ должен быть получен максимум в течение ребочего дня. Ответ через 24 часа, т.е. на следующий день, это профанация работы техподдержки.
Тут необходимо уточнить — обычно мы отвечаем гораздо быстрее. Но иногда бывают такие ситуации, что вопрос поступил от пользователя, чей часовой пояс сильно отличается от нашего. Да, мы рассмотрим его в течение своего рабочего дня, но его рабочий день к этому времени может закончиться, и тогда он всё равно получит ответ на другой рабочий день.
А какой разброс был у ваших пользователей по часовым поясам? Как вы с этим справлялись?
Тут необходимо уточнить — обычно мы отвечаем гораздо быстрее. Но иногда бывают такие ситуации, что вопрос поступил от пользователя, чей часовой пояс сильно отличается от нашего. Да, мы рассмотрим его в течение своего рабочего дня, но его рабочий день к этому времени может закончиться, и тогда он всё равно получит ответ на другой рабочий день.
А какой разброс был у ваших пользователей по часовым поясам? Как вы с этим справлялись?
НЛО прилетело и опубликовало эту надпись здесь
> Короче, можно так сформулировать — максимальное время ответа должно быть 8 часов, а не 24.
Для нас это важно. Например, человек послал нам свой вопрос в самом начале своего рабочего дня, а у нас в это время было 12 часов ночи. Если при этом у нас уже был поток вопросов, заданных ранее, то вопрос, заданный в 12 часов ночи, скорее всего пролежит какое-то время без ответа. Мы на него ответим нашим утром, а у человека, который его задал, рабочий день к тому времени закончится, и он получит ответ уже утром своего следующего рабочего дня. Вот оттуда и получается 24 часа.
> Поддержка работает круглосуточно без выходных и праздников
Ну вот в этом видимо и разница. У нас служба поддержки не работает круглосуточно — это было бы слишком дорого для нас, да и нет смысла так насиловать людей: сейчас в большинстве случаев время ответа пользователю вполне приемлемо и заметно меньше 24 часов… Хотя, работу в несколько смен, конечно же, никто не отменял. Опять же, и наша служба поддержки не всегда находится в одном и том же часовом поясе ;-)
Для нас это важно. Например, человек послал нам свой вопрос в самом начале своего рабочего дня, а у нас в это время было 12 часов ночи. Если при этом у нас уже был поток вопросов, заданных ранее, то вопрос, заданный в 12 часов ночи, скорее всего пролежит какое-то время без ответа. Мы на него ответим нашим утром, а у человека, который его задал, рабочий день к тому времени закончится, и он получит ответ уже утром своего следующего рабочего дня. Вот оттуда и получается 24 часа.
> Поддержка работает круглосуточно без выходных и праздников
Ну вот в этом видимо и разница. У нас служба поддержки не работает круглосуточно — это было бы слишком дорого для нас, да и нет смысла так насиловать людей: сейчас в большинстве случаев время ответа пользователю вполне приемлемо и заметно меньше 24 часов… Хотя, работу в несколько смен, конечно же, никто не отменял. Опять же, и наша служба поддержки не всегда находится в одном и том же часовом поясе ;-)
> Личный опыт подсказывает, что для любой проблемы необходимо и достаточно иметь два статуса — открыто/закрыто. Сколько я ни пытался применить в деле большее количество статусов, все равно все сводится к этим двум.
> Не могли бы Вы более развернуто рассказать, зачем Вам множество статусов и какая в них, на самом деле, необходимость?
Согласен, вопрос статусов — это всегда достаточно спорная вещь, и тут наверное каждый просто пользуется тем, что больше отражает суть внутреннего воркфлоу. Я могу только поделиться тем, что есть у нас…
Да, для пользователя всегда важно только два состояния его проблемы — Active или Closed. Если рассмотреть для примера проблему типа «баг», то мы добавляем к Closed разъяснение: Closed (Fixed), Closed (Can't Reproduce) или Closed (By Design). Это внешние статусы, важные для пользователя, по ним он понимает, что случилось с его проблемой и как мы её трактуем.
Для нас же внутри существует три состояния бага:
— баг требует действия службы поддержки (например, он был только что создан; или пользователь спрашивает, когда он будет пофикшен; или сообщает какую-то другую информацию по проблеме),
— баг требует фикса со стороны разработчика,
— баг не требует от нас никаких действий, и мы считаем его закрытым.
Получается, что первые два статуса — Active для пользователя, но для нас это разные Active — один требует реакции в течение 24 часов, другой — нет. Поэтому приходится вводить внутренние статусы…
> Не могли бы Вы более развернуто рассказать, зачем Вам множество статусов и какая в них, на самом деле, необходимость?
Согласен, вопрос статусов — это всегда достаточно спорная вещь, и тут наверное каждый просто пользуется тем, что больше отражает суть внутреннего воркфлоу. Я могу только поделиться тем, что есть у нас…
Да, для пользователя всегда важно только два состояния его проблемы — Active или Closed. Если рассмотреть для примера проблему типа «баг», то мы добавляем к Closed разъяснение: Closed (Fixed), Closed (Can't Reproduce) или Closed (By Design). Это внешние статусы, важные для пользователя, по ним он понимает, что случилось с его проблемой и как мы её трактуем.
Для нас же внутри существует три состояния бага:
— баг требует действия службы поддержки (например, он был только что создан; или пользователь спрашивает, когда он будет пофикшен; или сообщает какую-то другую информацию по проблеме),
— баг требует фикса со стороны разработчика,
— баг не требует от нас никаких действий, и мы считаем его закрытым.
Получается, что первые два статуса — Active для пользователя, но для нас это разные Active — один требует реакции в течение 24 часов, другой — нет. Поэтому приходится вводить внутренние статусы…
> Подобная база представляется мне бессмысленной. Разве что Ваши пользователи — сами вполне специалисты, способные самостоятельно раскапывать информацию
Учитывая, что DevExpress делает инструменты для разработчиков, здесь как раз этот случай. Правда, встроенный поиск в их KB неидеален — у меня чаще получалось найти нужную информацию на их же сайте через Гугл. Но уж как найдешь — красота, в большинстве случаев не просто описан способ решения, а прикреплен проект с примером.
Учитывая, что DevExpress делает инструменты для разработчиков, здесь как раз этот случай. Правда, встроенный поиск в их KB неидеален — у меня чаще получалось найти нужную информацию на их же сайте через Гугл. Но уж как найдешь — красота, в большинстве случаев не просто описан способ решения, а прикреплен проект с примером.
Скажите, а для поиска на нашем сайте вы пользуетесь search.devexpress.com?Просто он какое-то время был в бете, и может быть не очень хорошо был заметен…
Но по идее он должен давать достаточно релевантные результаты.
Но по идее он должен давать достаточно релевантные результаты.
Пользовался тем, что в Support Center предлагалось по умолчанию.
Даже сейчас сравните: в Гугле я спрашиваю «devexpress .net localization», и первая ссылка — A421, чего я и хотел.
А на вашем сайте по запросу «localization» (категорию .net я выбрал) это где-то пятое по очереди, да еще и таб надо переключить — это, по-моему, не лучшее решение.
Даже сейчас сравните: в Гугле я спрашиваю «devexpress .net localization», и первая ссылка — A421, чего я и хотел.
А на вашем сайте по запросу «localization» (категорию .net я выбрал) это где-то пятое по очереди, да еще и таб надо переключить — это, по-моему, не лучшее решение.
Надеюсь очень скоро, у нас будет обновленный поиск…
Как человек принимавший участие в разработке обоих версий поиского движка, могу сказать что есть у этих движков и преимущества по сравнению с гугл и недостатки.
Например, ваш пример.
Гугл при поиски принимает в расчет количество ссылок на документ с других сайтов. Наш же поиск, даже в теории этого сделать не может. Соотвественно, он может посчитать только релевантность документа и внутренние ссылки на него.
Но с другой стороны, гугл не знает ничего о типах наших документов — он не может отличить, например, документацию от вопроса на форуме.
Ну или например, сделанный suggestion от rejected (по логике, выше в результатах поиска должны быть именно отвеченные/реализованные suggestion).
Как человек принимавший участие в разработке обоих версий поиского движка, могу сказать что есть у этих движков и преимущества по сравнению с гугл и недостатки.
Например, ваш пример.
Гугл при поиски принимает в расчет количество ссылок на документ с других сайтов. Наш же поиск, даже в теории этого сделать не может. Соотвественно, он может посчитать только релевантность документа и внутренние ссылки на него.
Но с другой стороны, гугл не знает ничего о типах наших документов — он не может отличить, например, документацию от вопроса на форуме.
Ну или например, сделанный suggestion от rejected (по логике, выше в результатах поиска должны быть именно отвеченные/реализованные suggestion).
НЛО прилетело и опубликовало эту надпись здесь
А можно попросить Вас дать чуть больше пояснений, как реализуется система хотфиксов?
— Каждому клиенту отдельную версию?
— Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
— Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
— Проходят ли все эти сборки полное тестирование?
… и как все это поддерживается в рабочем состоянии в течение полугода до нового апдейта? :)
По своим проектам наболело.
— Каждому клиенту отдельную версию?
— Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
— Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
— Проходят ли все эти сборки полное тестирование?
… и как все это поддерживается в рабочем состоянии в течение полугода до нового апдейта? :)
По своим проектам наболело.
Для понимания картины.
Каждая мажорная версия живет в отдельной ветке в source control. После того как конкретная мажорная версия выпущена в свет, в её ветке исправляют только баги, никакого нового функционала не пишется. Все новое пишется в другой ветке.
На продукты есть unit-тесты, есть функциональные тесты. Они гоняются на серверах в автоматичесом режиме. Там же ежедневно автоматом собирается инсталляция, и прогоняются автотесты инсталляции. Если все тесты прошли успешно, эта инсталляция откладывается в отдельную папочку.
Теперь про хотфиксы.
Клиент запрашивает хотфикс на конкретный баг, закрытый со статусом Fixed. Дальше ручками, т.к. пока нет необходимости автоматизировать. Суппортист смотрит на дату закрытия бага, берёт готовую инсталляцию, собранную на день/другой позже этой даты, выкладывает её на сайт в раздел хотфиксов, даёт клиенту ссылку.
>> Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
Если речь о хотфиксах, то ему просто очередной хотфикс отдают. В нём уже оба бага исправлены. Т.е. любой хотфикс является кумулятивным. Когда в версии набирается некоторое достаточно большое кол-во поправленных багов, выпускаем публичное минорное обновление для этой версии.
>> Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
Если хотфикс уже был запрошен и выложен, просто скачивает его, в баг мы ссылку на выложенный хотфикс добавляем. Если хотфикс ещё никто не запрашивал по данному багу, то просто запрашивает хотфикс, кнопочка есть.
>> Проходят ли все эти сборки полное тестирование?
Все автотесты на этих сборках проходят успешно. Ручками хотфиксы не тестируют.
Каждая мажорная версия живет в отдельной ветке в source control. После того как конкретная мажорная версия выпущена в свет, в её ветке исправляют только баги, никакого нового функционала не пишется. Все новое пишется в другой ветке.
На продукты есть unit-тесты, есть функциональные тесты. Они гоняются на серверах в автоматичесом режиме. Там же ежедневно автоматом собирается инсталляция, и прогоняются автотесты инсталляции. Если все тесты прошли успешно, эта инсталляция откладывается в отдельную папочку.
Теперь про хотфиксы.
Клиент запрашивает хотфикс на конкретный баг, закрытый со статусом Fixed. Дальше ручками, т.к. пока нет необходимости автоматизировать. Суппортист смотрит на дату закрытия бага, берёт готовую инсталляцию, собранную на день/другой позже этой даты, выкладывает её на сайт в раздел хотфиксов, даёт клиенту ссылку.
>> Что делать, если клиент нашел сперва один баг, а потом обратился за новым?
Если речь о хотфиксах, то ему просто очередной хотфикс отдают. В нём уже оба бага исправлены. Т.е. любой хотфикс является кумулятивным. Когда в версии набирается некоторое достаточно большое кол-во поправленных багов, выпускаем публичное минорное обновление для этой версии.
>> Как решается ситуация, когда другой клиент находит баг, закрытый для предыдущего клиента?
Если хотфикс уже был запрошен и выложен, просто скачивает его, в баг мы ссылку на выложенный хотфикс добавляем. Если хотфикс ещё никто не запрашивал по данному багу, то просто запрашивает хотфикс, кнопочка есть.
>> Проходят ли все эти сборки полное тестирование?
Все автотесты на этих сборках проходят успешно. Ручками хотфиксы не тестируют.
Спасибо за подробный ответ! Спрашивал, так как надеялся увидеть чудодейственное решение которое бы позволило избежать ручного мержа багфиксов в бранч c выпущенной версией. А вдруг :)
Эта проблема стоит особенно остро, так как несколько проектов, выпускающихся в разное время, используют общий код — и хотфикс в этом коде очень трудозатратен. Обдумывая Ваш ответ, появилась идея выносить общий код из бранчей каждого проекта, надо еще обдумать) Так что вдвойне спасибо.
Эта проблема стоит особенно остро, так как несколько проектов, выпускающихся в разное время, используют общий код — и хотфикс в этом коде очень трудозатратен. Обдумывая Ваш ответ, появилась идея выносить общий код из бранчей каждого проекта, надо еще обдумать) Так что вдвойне спасибо.
> … и как все это поддерживается в рабочем состоянии в течение полугода до нового апдейта? :)
Обычно наши апдейты выходят гораздо чаще: для «живых» версий это каждый месяц или около того. А какая у вас версия? Опять же, .Net или VCL?
Обычно наши апдейты выходят гораздо чаще: для «живых» версий это каждый месяц или около того. А какая у вас версия? Опять же, .Net или VCL?
Я работал с вашими продуктами почти год. Суппорт у вас действительно неплох, чего, к сожалению, нельзя сказать о компонентах. Я использовал ASP.NET контролы и в них содержится столько багов, что я порой думал, что являюсь вашим тестеровщиком, а не пользователем. Это достаточно печально, учитывая немалую стоимость ваших компонент.
Сейчас мой знокомый использует компоненты Windows Forms и он вроде тоже не в восторге, хотя тут я как раз-таки сказать ничего не могу. Сам не использовал.
Сейчас мой знокомый использует компоненты Windows Forms и он вроде тоже не в восторге, хотя тут я как раз-таки сказать ничего не могу. Сам не использовал.
А можно по подробнее о проблемах с которыми пришлось столкнуться?
Несколько лет назад, мы постарались измениться в asp.net в лучшую сторону :) — и надеюсть с тех пор, наши контролы становятся быстрее и лучше.
Несколько лет назад, мы постарались измениться в asp.net в лучшую сторону :) — и надеюсть с тех пор, наши контролы становятся быстрее и лучше.
Я использовал контролы в течения этого года. В основном это были AspxHtmlEditor & AspxTreeList. Особенно мне запомнилась переписка с саппортом, когда вы никак не могли воспроизвести баг (тут признаю, была моя ошибка — я не правильно указал версию продукта), в процессе которой вы нашли еще одну ошибку, пытаясь повторить мои шаги.
Из проблем — совместимость с браузерами и некорректно работающий функционал при определенных сценариях.
Из проблем — совместимость с браузерами и некорректно работающий функционал при определенных сценариях.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Спасатели, вперёд!