Как назначить пользователя в группу?

Обсуждаем TrackStudio по-русски

Как назначить пользователя в группу?

Postby ST » Wed Jul 26, 2006 4:47 pm

В интерфейсе найти трудно, в документации тоже.
Может авторы чего подскажут?

Вообще первое впечатление: гибкий продукт с ужасным юзабилити :(
ST
 
Posts: 12
Joined: Wed Jul 26, 2006 4:43 pm

Re: Как назначить пользователя в группу?

Postby admin » Wed Jul 26, 2006 10:40 pm

ST wrote:В интерфейсе найти трудно, в документации тоже.
Может авторы чего подскажут?


В документации читать нужно тут:
http://www.trackstudio.com/documentatio ... cepts.html
http://www.trackstudio.com/documentatio ... oject.html

Вообще идея такая: группа пользователя (она же status) выставляется при создании пользователя. Собственно создать пользователя не дав ему какой-то статус нельзя. Этот статус называется "собственным" и используется для случаев когда никакие другие статусы не заданы (например, для определения что пользователь может делать со своим собственным account-ом, что он может делать с задачами которые лежат на пути от корневой до разрешенных и т.п.). Это значит что в большинстве случаев можно сделать группу "user" и указывать ее при создании всех пользователей.

В отличие от других систем, в TrackStudio пользователь включается в группы не "вообще", а для каких-то конкретных задач. Например, если у нас есть иерархия задач
A
-- B
----- B1
----- B2
-- C

то пользователь может быть developer-ом для проекта B и tester-ом для проекта C (т.е. входить в разные группы для разных проектов).
Вхождение в группы наследуется - т.е. если для задачи B пользователь - тестер, то и для B1 и B2 он будет тестером.

Плюс на каждом уровне "пронаследованное" вхождение в группы можно расширять (для проекта B1 пользователь является еще и manager-ом) или переопределять (для B2 пользователь является только manager-ом).

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

Аналогичная схема для доступа к пользователям - т.е. можно указать какие пользователи могут смотреть информацию о каких отделах/пользователях и с какими правами.

Вообще советую посмотреть tutorial - там показан процесс конфигурации "с нуля":
http://www.trackstudio.com/documentation-tutorial.html
ST wrote:Вообще первое впечатление: гибкий продукт с ужасным юзабилити :(


Так, пока Вы со всем не разобрались - ОГРОМНАЯ просьба. Напишите все что кажется кривым/непонятным/некрасивым/нелогичным и т.п. "Поток сознания" - оптимально.

У нас это просто беда какая-то: пользователи которые не разобрались - уходят и от них конкретики добиться трудно, а которые разобрались - начинают думать что все более-менее логично и забывают с чем были проблемы :-)
Maxim Kramarenko (mailto: maximkr@trackstudio.com)
TrackStudio - Hierarchical Bug & Issue Tracking Software
http://www.trackstudio.com
admin
Site Admin
 
Posts: 8143
Joined: Thu Jan 01, 1970 3:00 am
Location: Smolensk, Russia

Postby ST » Mon Jul 31, 2006 4:21 pm

Основные проблемы:
- нет метафоры
- интерфейс интуитивно непонятен
- для Windows-пользователя администрирование чужеродно
- рабочее место неудобно

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

Свойства группы пользователей - шедевр. Такого развернутого на несколько экранов дерева привилегий из более чем сотни элементов я ни у кого не видел. Что мне с ним делать?

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

Если права даются на проект, зачем затевать группы и выносить их на передний план?
Хорошо, права даются на проект. Лезем в проект, правила доступа. Нет кнопки "добавить". Вообще никакой. Значит, опять в другом месте надо делать.

Система должна сама подсказывать, что делать. Происходит обратное: система дает пройти по ссылке, а там вежливо посылает нах.

Задачи-то предельно конкретные: внес ошибку, установил статус, назначил (или система сама назначила) согласно workflow, тот получил извещение, зашел в систему, начал работу по ссылке либо со всем списком.

Из демо-флешки совершенно непонятно, как Дмитрий Никитин находит назанченную ему задачу - он после логина как-то сразу попадает в список.

Ребята, я работал с TestTrack и ни разу не заглянул в manual. Видимо, вам надо посмотреть на их продукт. Все что нам там не нравится - недостаточная поддержка русского языка.
У AQdevTeam тоже все более-менее понятно.
ST
 
Posts: 12
Joined: Wed Jul 26, 2006 4:43 pm

Postby admin » Mon Jul 31, 2006 5:38 pm

ST wrote:Основные проблемы:
- нет метафоры


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

ST wrote:- интерфейс интуитивно непонятен


Мне кажется, что дело не столько в интерфейсе, сколько в концепциях. Интерфейс мы уже переписывали уже раза 3, проводили юзабилити-тестирование и т.п., но пользователи все равно жалуются на неинтуитивность.

ST wrote:- для Windows-пользователя администрирование чужеродно
- рабочее место неудобно


Возможно, это дело привычки. Но если опишите что именно чужеродно и неудобно - буду премного благодарен :-)

ST wrote:Открывая на рабочем месте экран пользователь прежде всего ожидает там увидеть список проблем, с которыми ему надо работать.
Вместо этого показывается список проектов.


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

ST wrote:Свойства группы пользователей - шедевр. Такого развернутого на несколько экранов дерева привилегий из более чем сотни элементов я ни у кого не видел. Что мне с ним делать?


Там все довольно тривиально, нужно только присмотреться :-) Права там делятся на 2 группы - видимость/редактируемость стандартных полей (типа viewTaskBudget) и доступность элементов интерфейса по принципу - одно "право" на каждый элемент меню, закладку, кнопку. Организация в дерево отражает чисто интерфейсные зависимости - скажем, нельзя создавать отчет если нельзя смотреть список отчетов (т.к. кнопки Create просто негде находится). Это позволяет не думать - не забыл ли я еще каких прав дать что выполнить вот это действие и сразу очевидно какие дополнительно права получит пользователь, если Вы дадите ему право удалять отчеты, например. Как это можно дополнительно документировать - я не знаю.

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


Но в TrackStudio пользователь включается в группу не "вообще", а для конкретной задачи (проекта). Поэтому порядок другой - открываем проект и указываем какие пользователи входят в какую группу для этого проекта.

ST wrote:Если права даются на проект, зачем затевать группы и выносить их на передний план?
Система должна сама подсказывать, что делать.


Потому что на проект даются не права ("можно удалять сообщения"), а группы ("для данного проекта пользователь smith является тестером").

ST wrote:Задачи-то предельно конкретные: внес ошибку, установил статус, назначил (или система сама назначила) согласно workflow, тот получил извещение, зашел в систему, начал работу по ссылке либо со всем списком.

Из демо-флешки совершенно непонятно, как Дмитрий Никитин находит назанченную ему задачу - он после логина как-то сразу попадает в список.


Да, это фильтры. Там можно что угодно выводить сразу после логина. Например, "список "моих" задач по которым дидлайн через неделю, начальство дважды спрашивало о состоянии дел, а я ничего не делал уже 3 дня". А потом на основе этого фильтра можно построить отчет, можно раз в день получать список таких задач по e-mail, можно даже указать что извещение по e-mail при изменении таких задач нужно получать особое.

ST wrote:Ребята, я работал с TestTrack и ни разу не заглянул в manual. Видимо, вам надо посмотреть на их продукт. Все что нам там не нравится - недостаточная поддержка русского языка.
У AQdevTeam тоже все более-менее понятно.


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

Но есть еще Serena TeamTrack - весьма гибкая система (например, есть наследование workflow). Имеет документацию 1000+ страниц и стоит от $1000 за named user. Есть IBM ClearQuest - тоже система очень гибкая, еще более дорогая, хотя и немного устаревшая.

Я бы сказал что суть TrackStudio как проекта - это попытка сделать доступной гибкость систем класса ClearQuest/TeamTrack для небольших компаний.
Maxim Kramarenko (mailto: maximkr@trackstudio.com)
TrackStudio - Hierarchical Bug & Issue Tracking Software
http://www.trackstudio.com
admin
Site Admin
 
Posts: 8143
Joined: Thu Jan 01, 1970 3:00 am
Location: Smolensk, Russia

Postby ST » Mon Jul 31, 2006 7:16 pm

Ребята, не надо меня агитировать за объектно-ориентированный подход :) Это не метафора.
Подобную "гибкую" систему для ERP-задач мы делали лет 10 назад с метафорой "Папка-документ", вот здесь скриншоты, если интересно.

Но дело в том, что гибкость хороша для промежуточного звена - внедренцев.
Конечно, я посижу пару дней, пойму внутреннюю логику, так как системное образование и опыт разработки имеется.
А у вас зачастую приходит клиент с конкретной проблемой. Начинает тыкаться и ничего не понимает. Ему все эти гибкости не нужны.
Отсюда и уход клиентов.
Значит неправильно позиционируете товар.
Если конкурент монстрам, значит надо сразу об этом информировать потенциальных клиентов, которые ищут что-то полегче "поставил и заработало".
Но поскольку у вас все типа гибко, то никто не мешает создавать жесткие конфигурации для таких клиентов и играть в другом сегменте, благо цена позволяет.
Либо некая лайт-версия с предустановленным функционалом.
ST
 
Posts: 12
Joined: Wed Jul 26, 2006 4:43 pm

Postby admin » Mon Jul 31, 2006 7:55 pm

ST wrote:Ребята, не надо меня агитировать за объектно-ориентированный подход :) Это не метафора.
Подобную "гибкую" систему для ERP-задач мы делали лет 10 назад с метафорой "Папка-документ", вот здесь скриншоты, если интересно.


Да, чувствуется что-то очень знакомое и родное :-) Правда у нас не "папка-документ", а "папка-это-и-есть-документ", но это уже детали.

ST wrote:Но дело в том, что гибкость хороша для промежуточного звена - внедренцев.
Конечно, я посижу пару дней, пойму внутреннюю логику, так как системное образование и опыт разработки имеется.
А у вас зачастую приходит клиент с конкретной проблемой. Начинает тыкаться и ничего не понимает. Ему все эти гибкости не нужны.
Отсюда и уход клиентов.


Я могу согласится со всем, кроме "Ему все эти гибкости не нужны". Вот, возьмем, например Atlassian JIRA - не самая плохая система. У них есть список популярных feature requests, так там огромное количество популярных request-ов висит годами, их постоянно пинают пользователи, но сделать что они хотят в рамках используемой модели им в самом деле сложно. При этом в TrackStudio большая часть того что хотят пользователи реализована давно и без особых усилий.

См тут:
http://www.trackstudio.ru/products-comparison.html

Несколько раз видел картину - приходит к нам пользователь, смотрит, не может за 2 дня все настроить, быстро настраивает JIRA и покупает ее. А потом долго пинает их в форуме что у них того нет и сего нет, прилаживает фиксы и патчи чтоб реализовать какую-нибудь относительно простую функциональность и т.п.


ST wrote:Значит неправильно позиционируете товар.
Если конкурент монстрам, значит надо сразу об этом информировать потенциальных клиентов, которые ищут что-то полегче "поставил и заработало".


Да, мы примерно в этом направлении и рекламируем. Та же подборка отзывов на титульной странице - "и штаны стирает, и блины печет, и стоит недорого".

ST wrote:Но поскольку у вас все типа гибко, то никто не мешает создавать жесткие конфигурации для таких клиентов и играть в другом сегменте, благо цена позволяет.


Да, мы думаем в этом направлении, но такие специализированные конфигурации нужно по-другому рекламировать и продавать - это будут маленькие затраты на разработку и большие на продвижение.
Maxim Kramarenko (mailto: maximkr@trackstudio.com)
TrackStudio - Hierarchical Bug & Issue Tracking Software
http://www.trackstudio.com
admin
Site Admin
 
Posts: 8143
Joined: Thu Jan 01, 1970 3:00 am
Location: Smolensk, Russia

Postby ST » Tue Aug 01, 2006 10:39 am

admin wrote:Да, мы думаем в этом направлении, но такие специализированные конфигурации нужно по-другому рекламировать и продавать - это будут маленькие затраты на разработку и большие на продвижение.

Затраты в любом случае будут немаленькие.
Такой продукт без консалтинга и внедренцев (т.е. нужно создавать сеть партнеров) в массы не двинуть, это как 2х2=4 :)
ST
 
Posts: 12
Joined: Wed Jul 26, 2006 4:43 pm

Postby mvasenkov » Tue Aug 01, 2006 11:13 am

По сути, это два разных сегмента: простые, понятные багтрекилки и гибкие, сложные системы управления issues (по нашему пусть будут задачи).
Они настолько разные, что проще 2 разных продукта делать. Еще лучше - окучивать какой-то один сегмент.
Согласен, тем, кому нужны сложные багтрекилки, им также часто нужен и консалтинг, и заточка, и внедрение, и вылет к клиенту для демонстрации совету директоров.

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

Юзабилити - это проблема, да. Лично мне бы хотелось иметь отдельные интерфейсы, заточенные под конкретные роли: интерфейс администратора, "забивальщика задач", менеджера проекта (человека, который задачи распределяет по исполнителям, если такая роль есть), исполнителя и наблюдателя.
Возможно, к этому мы и прийдем. Планы на интерфейс внешнего наблюдателя есть в 4-й версии.
Skype (RU): max.vasenkov
Email/Jabber: max.vasenkov@gmail.com
twitter: @winzard
mvasenkov
TrackStudio Support
 
Posts: 374
Joined: Tue Jan 14, 2003 5:57 pm
Location: Smolensk

Postby ST » Tue Aug 01, 2006 4:24 pm

Предложение по ходу пьесы.
Группы - это, на самом деле, не группы, а роли.
Очень неплохо бы их переименовать.
Тогда атрибутом пользователя будет не "Группа", а "Роль в проекте по умолчанию".
Задачи в дереве не надо показывать, видимо, нужна опция для категории "Показывать в дереве"
ST
 
Posts: 12
Joined: Wed Jul 26, 2006 4:43 pm

Postby mvasenkov » Tue Aug 01, 2006 4:34 pm

ST wrote:Предложение по ходу пьесы.
Группы - это, на самом деле, не группы, а роли.
Очень неплохо бы их переименовать.
Тогда атрибутом пользователя будет не "Группа", а "Роль в проекте по умолчанию".
Задачи в дереве не надо показывать, видимо, нужна опция для категории "Показывать в дереве"


Они и были роли :) Это их в 3.5, кажется, переименовали. Я сейчас буду делать разбивку этих ролей на несколько "тематических" страниц. Т.е. флажки, которые относятся к полям, будут на своих страницах, права на операции над пользователями - на своих, над задачами - на своих.
По идее, в "урезанных" ролях, где не нужно будет управлять пользователями, например, не будет и соответствующих закладок.
Также, думаю, нужно избавиться от написания прав в духе "viewTaskFilter" - оставить только описания - "Просмотр фильтров для задач", например.
Skype (RU): max.vasenkov
Email/Jabber: max.vasenkov@gmail.com
twitter: @winzard
mvasenkov
TrackStudio Support
 
Posts: 374
Joined: Tue Jan 14, 2003 5:57 pm
Location: Smolensk

Next

Return to TrackStudio Support [Russian]

Who is online

Users browsing this forum: No registered users and 5 guests