>Посему еще один вопрос — можно ли где-то достать готовые шаблоны для SharePoint'a для системы регистрации проблем от клиентов?

...хотя бы для примера и ознакомления с SharePoint'ом.

Здравствуйте, Tremasov, Вы писали:

Не исключаю, что в Вашем случае кроме Web-клиента такой системы может понадобиться и соотв. workflow обработки чейндж реквестов (CR).

Так или иначе — одно из решений, изначально предназначенных для таких задач, как Вы описали — StarTeam.

А вот и его WorkFlow Designer (для настройки workflow "под себя" с указанием уведомлений по e-mail, изменениями таких параметров как status, responsibility, etc...), в котором открыты правила по-умолчанию для CR:


С уважением,
Сергей

СО>Не исключаю, что в Вашем случае кроме Web-клиента такой системы может понадобиться и соотв. workflow обработки чейндж реквестов (CR).

StarTeam мы уже используем, но больше как систему контроля версий и внутренней регистрации багов. Хотелось бы конечно иметь интеграцию SharePoint'a и StarTeam'а, пока не знаю в каком виде. Но главное нужен в первую очередь SharePoint именно для того, чтобы клиент сам мог через Web добавить проблему, баг-репорт или feature-request.

Здравствуйте, Tremasov, Вы писали:

T>StarTeam мы уже используем, но больше как систему контроля версий и внутренней регистрации багов. Хотелось бы конечно иметь интеграцию SharePoint'a и StarTeam'а, пока не знаю в каком виде. Но главное нужен в первую очередь SharePoint именно для того, чтобы клиент сам мог через Web добавить проблему, баг-репорт или feature-request.

Для этого и существует Web Edition Change Request Only.

Сам я в SharePoint плаваю (т.е. Starteam знаю лучше , но коллеги, делавшие www.opendotnet.ru, насколько я в курсе, решали вопросы по интеграции SharePoint и StarTeam, тем более, что Starteam WebEdition (оба варианта) реализован с использованием технологии ASP.

С уважением,
Сергей

СО>Для этого и существует Web Edition Change Request Only.

Вы это про SharePoint или про StarTeam?
Насколько я в курсе, в StarTeam'е нет фичи, чтоб клиенты могли сами вбивать описание случившихся у них проблем с программными продуктами компании.

Здравствуйте, Tremasov, Вы писали:

СО>>Для этого и существует Web Edition Change Request Only.

T>Вы это про SharePoint или про StarTeam?
T>Насколько я в курсе, в StarTeam'е нет фичи, чтоб клиенты могли сами вбивать описание случившихся у них проблем с программными продуктами компании.

StarTeam Web Edition Change Request Only — ориентирован на любых пользователей, которым a) необходимо работать через броузер б) необходимо формализованным образом доносить до компании/разработчиков/службы техподдержки запросы на изменения CR, включая отчеты об ошибках.

Этот инструмент StarTeam может являться "точкой входа" для конечных пользователей. Для его настройки есть специальный Layout Designer, который позволяет делать свои собственные формы (как по атрибутам, так и по языку).

С уважением,
Сергей

P.S. Заранее отвечаю на вопрос о локализации. Русский язык в StarTeam 6.0 на уровне _содержания_ CR (как и любых других сущностей StarTeam — задач, требований и т.п.) — поддерживается без необходимости дополнительных настроек (в 5.x надо было дополнительно настраивать WebEdition) . WebEdition пока не локализован — будет "критическая масса" запросов пользователей (в смысле "тех, кто покупал", а не "тех, кто юзает" ) мы готовы провести локализацию, т.е. перевод пользовательского интерфейса и/опционально документации.

Привет всем!

Поставил себе триал SharePoint Services V2, сижу разбираюсь. Первые впечатления приятные, но вот когда начинаешь копать глубже, возникает масса вопросов:
— можно ли разграничить доступ клиентов так, чтобы каждый клиент видел только собственные проблемы/bug репорты и
feature реквесты?
— можно ли разграничить доступ на заполнение полей? типа, скажем, клиент регистрирует проблему, затем руководитель проектов назначает ответственного за решение проблемы (т.е. заполняет столбец "Ответственное лицо") и только это ответственное лицо имеет право заполнить столбец "Решение проблемы".

Надо ли для внедрения таких фич в SharePoint что-то под него дописывать и куда в первую очередь нужно копать?

Большое спасибо!

Кстати, мы сейчас обыгрываем связку StarTeam + Wiki. Вроде бы неплохо получается. Самое вкусное в Wiki — это возможность динамического изменения структуры и содержимого страничек самими пользователями. Учитывая то, что wiki есть free, то можно и попробовать. Кроме того, очень удобно линковать к wiki-ресурсам объекты из CalberRM и Together.

C>Кстати, мы сейчас обыгрываем связку StarTeam + Wiki. Вроде бы неплохо получается. Самое вкусное в Wiki — это возможность динамического изменения структуры и содержимого страничек самими пользователями. Учитывая то, что wiki есть free, то можно и попробовать. Кроме того, очень удобно линковать к wiki-ресурсам объекты из CalberRM и Together.

А можно ссылку на Wiki pls. Этот тот Wiki, который лежит на sourceforge?

Привет всем!

Кто-нибудь видел/юзал это решение: здесь?
На первый взгляд вроде бы понавороченнее, чем SharePoint, и меньше напильником работать надо.

Привет всем!

Кто знает, позволяет ли SharePoint SDK ловить ивенты об создании ячеек в списках?

Здравствуйте, Tremasov, Вы писали:

T>Привет всем!

T>Кто какие средства посоветует для subj?
T>Сейчас у нас все это работает через e-mail support@, но уже достало разгребать кучу писем и перенаправлять ее разработчикам, затем принимать от них ответ и отсылать обратно клиенту (может кто-то поделится своим подходом в этом месте).
T>Хочу сделать регистрацию багов и реквестов на расширение функциональности через Web, где клиенты смогут вводить свои проблемы и видеть ответы разработчиков на той же странице. Есть еще вариант с newsgroup'ами, но дело в том, что неадванцнутый клиент хрен до них доберется, плюс сложно проконтролировать что на жалобу клиента дан ответ.

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

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

Плох обычный форум тем, что получается бардак.
Резюме по проблеме должен дать только один ответственный за выяснение проблемы разработчик.
Плюс одни клиенты/партнеры не должны касаться проблем других и т.п. На это есть много причин.

Здравствуйте, Tremasov, Вы писали:

T>Привет всем!

T>Кто какие средства посоветует для subj?
T>Сейчас у нас все это работает через e-mail support@, но уже достало разгребать кучу писем и перенаправлять ее разработчикам, затем принимать от них ответ и отсылать обратно клиенту (может кто-то поделится своим подходом в этом месте).
T>Хочу сделать регистрацию багов и реквестов на расширение функциональности через Web, где клиенты смогут вводить свои проблемы и видеть ответы разработчиков на той же странице. Есть еще вариант с newsgroup'ами, но дело в том, что неадванцнутый клиент хрен до них доберется, плюс сложно проконтролировать что на жалобу клиента дан ответ.

Попробуй погуглить (или фруглить) слово HelpDesk, customer self-service и т.п. Такие системы (как опен соурс так и коммерческие) существуют и как-раз для того и предназначены. Кроме того там бывает встроенная knowledge base, форум и т.п. Теоретически напильник к таким (по-крайней мере коммерческим) системам не нужен

Здравствуйте, Tremasov, Вы писали:


T>Плох обычный форум тем, что получается бардак.
T>Резюме по проблеме должен дать только один ответственный за выяснение проблемы разработчик.
T>Плюс одни клиенты/партнеры не должны касаться проблем других и т.п. На это есть много причин.

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

Здравствуйте, mselez, Вы писали:

M>Здравствуйте, Tremasov, Вы писали:

M>У клиентов и с пользованием форумом проблемы бывают, не говоря уже о более сложных системах. И назначить ответственного за выяснение проблемы разработчика наверное должен человек, а не машина. А дальше — права доступа. Но, конечно, все зависит от конкретной ситуации, может и бардак получится.

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

M>У клиентов и с пользованием форумом проблемы бывают, не говоря уже о более сложных системах. И назначить ответственного за выяснение проблемы разработчика наверное должен человек, а не машина. А дальше — права доступа. Но, конечно, все зависит от конкретной ситуации, может и бардак получится.

Назначать ответственного будет руководитель проектов.
Есс-но система может предложить ответственного "по-умолчанию" — главного разработчика продукта, по которому поступила жалоба.

AS>Попробуй погуглить (или фруглить) слово HelpDesk, customer self-service и т.п. Такие системы (как опен соурс так и коммерческие) существуют и как-раз для того и предназначены. Кроме того там бывает встроенная knowledge base, форум и т.п. Теоретически напильник к таким (по-крайней мере коммерческим) системам не нужен

Сколько неглядел готовых таких систем — везде надо работать напильником, причем во многих довольно сильно. А многие работать напильником вообще не позволяют. У опенсорсных основной критический недостаток — ужаснейший ГУЙ.
Пока ИМХО SharePoint Services — то, что доктор прописал. Правда есть там недостатки свои тоже (никак пока не нашел как скрывать от юзверей разные менюхи типа "Создать", "Настройка", не работая большим напильником), но критических пока не нашел.

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

Не спорю — думаю есть в этом свое разумное зерно.
В принципе неплохо, если сидит девочка/мальчик и умеет красиво переоформить ответ, исправив стилистические и грамматические ошибки. Но тут есть другая проблема — эта девочка/мальчик должны владеть всеми продуктами чуть-ли не досконально, чтобы суметь перефразировать/отредактировать ответ, не меняя его смысла. У нас сейчас есть люди, принимающие жалобы по телефону (есть такие клиенты, которым так удобнее, чем писать на support@), которые затем бегут к установщикам/разработчикам для выяснения проблемы и дают потом ответ клиентам. Так вот скажу вам эти люди _СИЛЬНО_ вспотыкаются на технических вопросах и не всегда способны дать ответ клиенту сами — приходится отвечать разработчику либо руководителю проектов.

AS>Попробуй погуглить (или фруглить) слово HelpDesk, customer self-service и т.п.

Спасибо! Прогуглив HelpDesk нарвался на helpdesk.com — тут список вендоров таких систем.