Добавить свойство задачи "Тип" и сделать группирующие сущности для задач (категории)
Пишу два запроса в одном месте, так как применяются совместно.
Оба можно решить аналитиками или другими существующими возможностями, но все же
было бы хорошо реализовать данные фичи отдельно.
Кейсы применения:
Планфикс - багтрекер, Планфикс - система учета требований,
Планфикс - тикет-система.
Свойство "Тип" должно быть справочником, но принадлежать НЕ действию
(как аналитики), а Задаче, чтобы можно было фильтровать по нему, или делать другие действия, или визуально выделять задачу с разными типами НЕ в отчетах, а в списке Задач.
К примеру, сделали тип "Запрос фичи от клиента", потом обсудили, поменяли тип на "Фича",
в ней уже сделали подзадачи для исполнителей и т.п.
Это можно все делать и в отчетах, но отчеты - на то и отчеты, чтобы отчитываться.
Оперативная работа удобнее все же в обычном интерфейсе: посмотреть все фичи, например.
Или выделять фичи зеленым, тогда будет видно так:
**Фича**
-- задача для исполнителя1
-- задача для исполнителя2
Группирующие сущности - имеются в виду как-бы надзадачи, но без указания исполнителя,
без статуса, без даты завершения и т.п., чтобы их было видно во всех разделах: Входящие,
Исходящие, Черновики, В работе и т.п., другими словами - это категории задач.
В сложном программном продукте много подсистем и частей, и неудобно держать все фичи одним списком.
Мы счас для группировки используем Черновики без исполнителя (только менеджер видит), что
не очень удобно.
Ко всему этому еще можно сделать возможность не указывать исполнителя, но при этом задача
чтобы висела В работе (а не в Непринятых), т.к. фича от клиента, выходит, постоянно и долго висит
во входящих у менеджера, в перемешку с его собственными задачами.
Идеальный вариант:
++Система отчетов++ (категория, без исполнителя и даты, видно везде)
--**Отчет по продажам за месяц** (фича, поставлена клиентом, видно как фичу, не имеет исполнителя)
----- задача для исполнителя1 (обычная задача)
----- задача для исполнителя2 (обычная задача)
--**Отчет по движению товара**
----- задача для исполнителя1 (обычная задача)
----- задача для исполнителя2 (обычная задача)
--!!Баг: при выборе типа отчета пропадает дата!! (баг, поставлен клиентом, не имеет исполнителя)
-----при выборе типа отчета пропадает дата (задача для исполнителя, обычная)
Добавить свойство задачи "Тип" и сделать группирующие сущности для задач (категории)
-
Андрей2
- Сообщения: 0
- Зарегистрирован: 11.06.2012 14:13
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54
Про "группирующие сущности" - это частный случай кастомных полей у задач, которые появятся в ПланФиксе в начале 2012 года. Работать это будет так:
- Вы создаете в шаблоне задачи кастомное поле - например тот же самый "Тип", который может выбираться из справочника
- В списке задач настраиваете отображение этого реквизита
Насколько я понимаю, описанный кейс решится таким образом. Если нет - поправьте.
Ситуацию с "мешающими задачами" как мне кажется можно разрулить даже сейчас, с помощью небольшого лайфхака:
- Создаете "сотрудника" на которого будете вешать входящие задачи от клиентов. Это не настоящий сотрудник, а виртуал.
- В структуре компании настраиваете подчиненность виртуала менеджеру
- Менеджер принимает приходящие от клиента задачи и назначает их виртуалу, а себя удаляет из списка исполнителей).
- После этого менеджер в списке задач может видеть по своему желанию как общий список (свои+виртуала), так и только свои задачи. Ну и отдельно задачи виртуала тоже можно посмотреть через его карточку сотрудника.
- Когда задача ставится реальному исполнителю, виртуала из исполнителей удаляют.
Если я что-то не учел - напишите, подумаем еще.
- Вы создаете в шаблоне задачи кастомное поле - например тот же самый "Тип", который может выбираться из справочника
- В списке задач настраиваете отображение этого реквизита
Насколько я понимаю, описанный кейс решится таким образом. Если нет - поправьте.
Ситуацию с "мешающими задачами" как мне кажется можно разрулить даже сейчас, с помощью небольшого лайфхака:
- Создаете "сотрудника" на которого будете вешать входящие задачи от клиентов. Это не настоящий сотрудник, а виртуал.
- В структуре компании настраиваете подчиненность виртуала менеджеру
- Менеджер принимает приходящие от клиента задачи и назначает их виртуалу, а себя удаляет из списка исполнителей).
- После этого менеджер в списке задач может видеть по своему желанию как общий список (свои+виртуала), так и только свои задачи. Ну и отдельно задачи виртуала тоже можно посмотреть через его карточку сотрудника.
- Когда задача ставится реальному исполнителю, виртуала из исполнителей удаляют.
Если я что-то не учел - напишите, подумаем еще.
-
Андрей2
- Сообщения: 0
- Зарегистрирован: 11.06.2012 14:13
-
Flamingo
- Сообщения: 0
- Зарегистрирован: 11.06.2012 14:08
Очень правильная тема. Ждем-с воплощения. С виртуалом морочиться - слишком муторно. Вообще хотелось бы текущую работу над проектом не превращать в изучение системы планфикса в формате - 20% проект, 80% планфикс. Всё-таки пользователь внедряет систему не ради её изучения.
Если я правильно понимаю обсуждаемые здесь "группирующие сущности", то вот простой пример-столкновение (в простонародье - грабли):
а) мне, как менеджеру проекта, хотелось бы сгруппировать задачи внутри ПРОЕКТА в ТЕМы
б) исполнителю хотелось бы видеть просто задачи в табличном виде и ТЕМу которой она принадлежит (по типу того, как это реализовано в большинстве стандартных CMS)
Сейчас приходится создавать иерархию вида СУПЕРЗАДАЧА-ПОДЗАДАЧА-ЗАДАЧА
В результате у исполнителя в задачах появляются все три, а нужна одна. Собственно задача, а не ТЕМА к которой она принадлежит.
Возможно это как-то делается иначе, но из взгляда на карточку задачи и на карточку проекта - это неочевидно или этого вообще нет.
В результате исполнитель открывает НАДЗАДАЧУ и спрашивает "и что мне сэтим делать?"
Отвечать приходится "Принять и смотреть вложения", а вложения, при этом, в левом поле ссылкой, но не раскрывающимся списком. Получается вынужденное 'замусоривание' проекта иерархической структурой. Создавать несколько 'проектов'?... но это же костыль. Виртуализация, аналитики, и т.п. - это костыли и усложение перемещения по проекту.
Для удобства исполнителя, можно было бы не строить иерархию вообще, а вписывать в название задачи все данные о КАТЕГОРИИ (ТЕМЕ), РАЗДЕЛЕ и только после этого дописывать совственно НАЗВАНИЕ, но это убивает наглядность.
Возможно есть какой-то иной хитрый способ, простой и внятный, но - повторюсь - он не очевиден. А без этого приходится закусить губу и сказать себе "ну что ж, зато оно в остальном неплохо".
P.S. вообще, не знаю где это можно обсудить отдельно, но карточка ПРОЕКТА или ЗАДАЧИ оставляет желать более внятной картины. Ибо есть добавить ДЕЙСТВИЕ, но ДЕЙСТВИЙ нет в левом поле. Есть Настройка вида, но зачем-то болтается справа (если уж там оставлять, то не хватает пояснения Настройка вида чего?...очевидно "комментариев" и так далее. И такого довольно много по всей системе. Предлагаю разработчикам сделать какой-то форум что-ли, где будет возможно обсуждать удобство и логику UI (user interface), с примерами и скриншотами. Ибо глобальные идеи здесь на форуме - это хорошо, но как известно "Бог в деталях", впрочем как и Дьявол.
Если я правильно понимаю обсуждаемые здесь "группирующие сущности", то вот простой пример-столкновение (в простонародье - грабли):
а) мне, как менеджеру проекта, хотелось бы сгруппировать задачи внутри ПРОЕКТА в ТЕМы
б) исполнителю хотелось бы видеть просто задачи в табличном виде и ТЕМу которой она принадлежит (по типу того, как это реализовано в большинстве стандартных CMS)
Сейчас приходится создавать иерархию вида СУПЕРЗАДАЧА-ПОДЗАДАЧА-ЗАДАЧА
В результате у исполнителя в задачах появляются все три, а нужна одна. Собственно задача, а не ТЕМА к которой она принадлежит.
Возможно это как-то делается иначе, но из взгляда на карточку задачи и на карточку проекта - это неочевидно или этого вообще нет.
В результате исполнитель открывает НАДЗАДАЧУ и спрашивает "и что мне сэтим делать?"
Отвечать приходится "Принять и смотреть вложения", а вложения, при этом, в левом поле ссылкой, но не раскрывающимся списком. Получается вынужденное 'замусоривание' проекта иерархической структурой. Создавать несколько 'проектов'?... но это же костыль. Виртуализация, аналитики, и т.п. - это костыли и усложение перемещения по проекту.
Для удобства исполнителя, можно было бы не строить иерархию вообще, а вписывать в название задачи все данные о КАТЕГОРИИ (ТЕМЕ), РАЗДЕЛЕ и только после этого дописывать совственно НАЗВАНИЕ, но это убивает наглядность.
Возможно есть какой-то иной хитрый способ, простой и внятный, но - повторюсь - он не очевиден. А без этого приходится закусить губу и сказать себе "ну что ж, зато оно в остальном неплохо".
P.S. вообще, не знаю где это можно обсудить отдельно, но карточка ПРОЕКТА или ЗАДАЧИ оставляет желать более внятной картины. Ибо есть добавить ДЕЙСТВИЕ, но ДЕЙСТВИЙ нет в левом поле. Есть Настройка вида, но зачем-то болтается справа (если уж там оставлять, то не хватает пояснения Настройка вида чего?...очевидно "комментариев" и так далее. И такого довольно много по всей системе. Предлагаю разработчикам сделать какой-то форум что-ли, где будет возможно обсуждать удобство и логику UI (user interface), с примерами и скриншотами. Ибо глобальные идеи здесь на форуме - это хорошо, но как известно "Бог в деталях", впрочем как и Дьявол.
-
Андрей2
- Сообщения: 0
- Зарегистрирован: 11.06.2012 14:13
Да, именно категоризация позволит сделать так, что исполнитель видит задачи,
вложенные в категории и знает, что делать нужно задачу и завершать ее, а категория - для подсказки.
Тогда это можно будет применять и для фич: фича - это некая категория без исполнителя,
но с возможностью выполнить ее. Как-то так.
Много чего можно сделать через отчеты, аналитикой. Но в повседневной работе это неудобно.
Удобно будет вот что:
1) смотреть все заявки клиента (тип задачи - Заявка)
2) смотреть все фичи в работе (без тех задач, которые внутри)
3) при взгляде на проект целиком - видим задачи по категориям, что удобно для
анализа "леса", а не "деревьев"
И т.п., много еще применений можно найти :)
вложенные в категории и знает, что делать нужно задачу и завершать ее, а категория - для подсказки.
Тогда это можно будет применять и для фич: фича - это некая категория без исполнителя,
но с возможностью выполнить ее. Как-то так.
Много чего можно сделать через отчеты, аналитикой. Но в повседневной работе это неудобно.
Удобно будет вот что:
1) смотреть все заявки клиента (тип задачи - Заявка)
2) смотреть все фичи в работе (без тех задач, которые внутри)
3) при взгляде на проект целиком - видим задачи по категориям, что удобно для
анализа "леса", а не "деревьев"
И т.п., много еще применений можно найти :)
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
-
_Миxаил Гошкa
- Сообщения: 346
- Зарегистрирован: 11.06.2012 13:51
Заглянул в наш RoadMap. Вот что в ближайшей последовательности к реализации:
Ориентировочно, через 3 полноценных релиза мы доберемся до кастомных полей у задач и проектов на основе готового функционала справочников и переработанных деревьев списка задач.
Считаем, что реализация кастомных полей у задач + удобные фильтры по задачам полностью решат поставленный кейс.
- Новые Справочники
- Хроника
- Приоритеты задач
- Новые Чек-листы
- Кастомные поля у задач и проектов
Ориентировочно, через 3 полноценных релиза мы доберемся до кастомных полей у задач и проектов на основе готового функционала справочников и переработанных деревьев списка задач.
Считаем, что реализация кастомных полей у задач + удобные фильтры по задачам полностью решат поставленный кейс.
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54
Перечитал еще раз все это обсуждение с самого начала, на свежую голову и подумал: а не решают ли этот кейс теги "Запрос фичи от клиента", "Фича" и т.п. (если бы теги были в ПФ)?
Конечно, в комплекте с фильтрами, в которых в качестве критериев отбора могли бы использоваться теги и другие реквизиты задачи.
Конечно, в комплекте с фильтрами, в которых в качестве критериев отбора могли бы использоваться теги и другие реквизиты задачи.
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
Да, теги вполне решают.
Тогда среди множества задач можно поставить фильтр по тегу и посмотреть Фичи или Запросы.
В таком случае, остается один вопрос: с исполнителями/постановщиками. Для Фич может не быть ни постановщика, ни исполнителя,
особенно если фича большая, и задачи по ней - это подзадачи. Для Запросов клиента нет исполнителя (может не быть).
А тогда задачи висят в Непринятых, что как-то страннно, потому как фича принята и уже в работе :)
Тогда среди множества задач можно поставить фильтр по тегу и посмотреть Фичи или Запросы.
В таком случае, остается один вопрос: с исполнителями/постановщиками. Для Фич может не быть ни постановщика, ни исполнителя,
особенно если фича большая, и задачи по ней - это подзадачи. Для Запросов клиента нет исполнителя (может не быть).
А тогда задачи висят в Непринятых, что как-то страннно, потому как фича принята и уже в работе :)
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54
То, что Вы называете задачей-категорией, мне напоминает веху (milestone) - задача, которая по сути является этапом и складывается из суммы составляющих ее подзадач. В ПланФиксе их пока нет, но в рамках развития по ветке "управление проектами" мы их регулярно обсуждаем внутри команды. Надо этот вопрос помусолить в мозгу - если в этом нет противоречий, то можно реализовать вехи таким образом, чтобы они могли выполнять и функции таких вот "задач-категорий".
Вопросы, которые возникают навскидку:
- у вех, насколько я помню, нет вложенности (может и ошибаюсь), а у категорий вложенность нужна;
- нужны ли вехам/категориям в принципе исполнители.
Наверняка буду и другие.
Вопросы, которые возникают навскидку:
- у вех, насколько я помню, нет вложенности (может и ошибаюсь), а у категорий вложенность нужна;
- нужны ли вехам/категориям в принципе исполнители.
Наверняка буду и другие.
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
Вехи еще и с датой начала/окончания могут быть связаны, а категории/фичи - могут не быть.
Теоретически, можно сделать такую универсальную сущность, которую можно будет по-разному применять, и для вех, и для категоризации,
и для фич и т.п.
Вообще меня преследует такая мысль, что это все можно решить, если просто допустить возможность существования задачи без исполнителя и постановщика, и отображать такие задачи по фильтру или, допустим, только в древовидном режиме.
Если что-то еще в голову придет - напишу.
Теоретически, можно сделать такую универсальную сущность, которую можно будет по-разному применять, и для вех, и для категоризации,
и для фич и т.п.
Вообще меня преследует такая мысль, что это все можно решить, если просто допустить возможность существования задачи без исполнителя и постановщика, и отображать такие задачи по фильтру или, допустим, только в древовидном режиме.
Если что-то еще в голову придет - напишу.
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54
Про даты правильная мысль, не подумал сразу.
Задачи без исполнителя меня не смущают, а вот без постановщика пока не могу осознать - все равно ведь есть человек, который создал эту задачу, она же не берется из воздуха - называй его хоть исполнитель, хоть автор, суть не меняется.
Задачи без исполнителя меня не смущают, а вот без постановщика пока не могу осознать - все равно ведь есть человек, который создал эту задачу, она же не берется из воздуха - называй его хоть исполнитель, хоть автор, суть не меняется.
ОК, давайте думать дальше, раскусим мы этот орешек, не такой уж он и твердый.Если что-то еще в голову придет - напишу.
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
Вот еще некоторые мысли.
Допустим, для всех фич по проекту автор - клиент. Тут вроде вопросов нет, все верно.
Хотя вопрос исполнителя стоит: кого ставить? Счас мы ставим менеджера, но тогда у него во входящих много задач,
которые он на самом деле не делает (у нас для менеджера нет отдельного человека, менеджерит, скажем так, ведущий специалист,
и у него могут быть просто свои задачи).
Скажем, есть несколько частей системы, например: продажи, отчеты, поставщики.
Фич много (допустим, 100), менеджер делает группу "Проплаты оффлайн/онлайн чеков", в которой 5 фич по проплате этих чеков.
При группировке легче ориентироваться в куче фич.
Так вот: "Проплаты оффлайн/онлайн чеков", несмотря на то, что создал ее менеджер, не должна висеть у него в исходящих, это как-бы не задача, и ее не надо делать (после закрытия 5 фич там может появится еще 2, потом еще и т.п., в зависимости от требований заказчика).
Если задача в черновиках, то вроде ок, а если ее сделать активной - то она в непринятых, что несколько некорректно для категории.
Но если она в черновиках, то тогда при просмотре задач в работе ее опять же, не видно, и категорийность теряется.
Похоже на какой-то вариант типа "Показывать задачу везде, где видны ее поздадачи", как-то так.
Команда решила, какие фичи делать и какие ставить задачи, после чего тот, кто менеджерит, красиво упорядочивает это в Планфиксе.
При этом у нас он юзает закладку Задачи->Все. Он ставит задачу исполнителю: "добавить частичную оплату со счета клиента в чек", задача внутри группы "Проплаты оффлайн/онлайн чеков", при этом задачу он видит в исходящих->в работе (должен же проконтролировать), а группу не видит (если она черновик, выше описал).
Допустим, для всех фич по проекту автор - клиент. Тут вроде вопросов нет, все верно.
Хотя вопрос исполнителя стоит: кого ставить? Счас мы ставим менеджера, но тогда у него во входящих много задач,
которые он на самом деле не делает (у нас для менеджера нет отдельного человека, менеджерит, скажем так, ведущий специалист,
и у него могут быть просто свои задачи).
Скажем, есть несколько частей системы, например: продажи, отчеты, поставщики.
Фич много (допустим, 100), менеджер делает группу "Проплаты оффлайн/онлайн чеков", в которой 5 фич по проплате этих чеков.
При группировке легче ориентироваться в куче фич.
Так вот: "Проплаты оффлайн/онлайн чеков", несмотря на то, что создал ее менеджер, не должна висеть у него в исходящих, это как-бы не задача, и ее не надо делать (после закрытия 5 фич там может появится еще 2, потом еще и т.п., в зависимости от требований заказчика).
Если задача в черновиках, то вроде ок, а если ее сделать активной - то она в непринятых, что несколько некорректно для категории.
Но если она в черновиках, то тогда при просмотре задач в работе ее опять же, не видно, и категорийность теряется.
Похоже на какой-то вариант типа "Показывать задачу везде, где видны ее поздадачи", как-то так.
Команда решила, какие фичи делать и какие ставить задачи, после чего тот, кто менеджерит, красиво упорядочивает это в Планфиксе.
При этом у нас он юзает закладку Задачи->Все. Он ставит задачу исполнителю: "добавить частичную оплату со счета клиента в чек", задача внутри группы "Проплаты оффлайн/онлайн чеков", при этом задачу он видит в исходящих->в работе (должен же проконтролировать), а группу не видит (если она черновик, выше описал).
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54
По этому примеру:
предположим, что "Проплаты оффлайн/онлайн чеков" это такой тег (длинный, да - но для примера). И (опять же, предположим) в разных списках задач и т.п. есть возможность настроить видимость нужных столбцов, в том числе и столбца "Теги".
Тогда при сортировке входящих запросов на фичи от клиента менеджер делает не группы, а теги, и тегирует ими задачи. В списках задач их можно легко отсортировать по столбцу "Теги", он и выполнит роль группы. При этом "задачи-группы" не мешаются в списках и не сбивают с толку людей.
Если нужно переместить фичу из одной группы в другую, менеджер удаляет старые тег и цепляет новый.
Решается так эта задача, или есть нюансы, которых я не учел?
предположим, что "Проплаты оффлайн/онлайн чеков" это такой тег (длинный, да - но для примера). И (опять же, предположим) в разных списках задач и т.п. есть возможность настроить видимость нужных столбцов, в том числе и столбца "Теги".
Тогда при сортировке входящих запросов на фичи от клиента менеджер делает не группы, а теги, и тегирует ими задачи. В списках задач их можно легко отсортировать по столбцу "Теги", он и выполнит роль группы. При этом "задачи-группы" не мешаются в списках и не сбивают с толку людей.
Если нужно переместить фичу из одной группы в другую, менеджер удаляет старые тег и цепляет новый.
Решается так эта задача, или есть нюансы, которых я не учел?
-
Андрей Несынов
- Сообщения: 50
- Зарегистрирован: 19.06.2012 13:23
Да, по группировке задача решается отлично.
Остался теперь один вопрос:
http://forum.planfix.ru/viewtopic.php?f ... 5352#p5352
Если будет фильтр по постановщику, работающий на отрицание, то отлично: клиент ставит фичу менеджеру
(что в общем случае логично), а менеджер, чтобы видеть только свои задачи, фильтрует: "постановщик != _имя_клиента".
Остался теперь один вопрос:
http://forum.planfix.ru/viewtopic.php?f ... 5352#p5352
Если будет фильтр по постановщику, работающий на отрицание, то отлично: клиент ставит фичу менеджеру
(что в общем случае логично), а менеджер, чтобы видеть только свои задачи, фильтрует: "постановщик != _имя_клиента".
-
Dmitry Goncharenko
- Сообщения: 4127
- Зарегистрирован: 06.06.2012 13:54