Можно как то сделать что бы подзадачу можно было бы назначить в другой проект, но при этом она осталась бы связана с основной задачей.
причина:
есть проект например сайт - у него один руководитель и контролирующий с исполнителем
есть проект база учета чего нить - у этого проекта свои люди
ставится задача вытаскивать информацию из базы и отображать на сайте.
источник основной задачи это сайт, дальше идут подзадачи:
на сайте необходимо сделать функционал для приема информации
на базе надо сделать функционал по отправке информации
на сайте делаем отображение полученного
каждая из этих подзадач связана с предыдущей и выполняется после завершения предыдущей.
но вот назначить надо в разные проекты: первую и последнюю в проект сайтов, а последнюю в проект базы.
ответственные за контроль полного объема видит все и связанные задачи. Исполнитель соответственно видит свое...
Настройка ПланФикса: бюджет, подзадачи, проекты, аналитика
-
- Сообщения: 6
- Зарегистрирован: 22.02.2014 17:02
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
В чистом виде такой возможности нет, но есть ощущение, что для решения описанной ситуации оно и не нужно - если я правильно понял задачу, конечно. В ПланФиксе права доступа определяются на уровне задачи, а не на уровне проекта. Поэтому можно держать задачи в одном проекте (или вовсе без проекта) - все равно их увидят только те, кому это положено, исходя из структуры прав доступа.
Если я понял неправильно и разделять задачи по разным проектам нужно нет для того, чтобы разделить доступ к ним - поправьте меня, подумаем дальше.
Если я понял неправильно и разделять задачи по разным проектам нужно нет для того, чтобы разделить доступ к ним - поправьте меня, подумаем дальше.
-
- Сообщения: 3
- Зарегистрирован: 24.02.2014 16:14
нет, тут задача не разделения прав. Тут разделение видимости задач для руководства.
Мне как руководителю определенных задач необходимо видеть задачи в полной их связке. В соответствии с этим можно назначать какие то сроки.
Те люди которые контролируют общий процесс разработок тоже хотят видеть задачи в полном дереве ()
При этом разработчики видят свои задачи, но им тоже периодически необходимо видеть дерево.
а вот когда происходит закрытие задач по готовности то просматривают уже в рамках только одного проекта.
надеюсь немного понятнее...
Мне как руководителю определенных задач необходимо видеть задачи в полной их связке. В соответствии с этим можно назначать какие то сроки.
Те люди которые контролируют общий процесс разработок тоже хотят видеть задачи в полном дереве ()
При этом разработчики видят свои задачи, но им тоже периодически необходимо видеть дерево.
а вот когда происходит закрытие задач по готовности то просматривают уже в рамках только одного проекта.
надеюсь немного понятнее...
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
Немного понятнее, но пока не до конца :)
Все, от руководителя до разработчика, будут видеть задачи в дереве, если будут иметь к ним доступ. Если, к примеру, не дать разработчику доступ к задачам верхнего уровня, то он их и не увидит. Проекты, в которых находятся задачи, тут вроде бы особо и ни при чем (может, я опять что-то недопонял).Мне как руководителю определенных задач необходимо видеть задачи в полной их связке. В соответствии с этим можно назначать какие то сроки.
Те люди которые контролируют общий процесс разработок тоже хотят видеть задачи в полном дереве ()
При этом разработчики видят свои задачи, но им тоже периодически необходимо видеть дерево.
А вот тут совсем не понял:) Какова связь между закрытием задач по готовности и просмотром в рамках одного проекта?а вот когда происходит закрытие задач по готовности то просматривают уже в рамках только одного проекта.
-
- Сообщения: 6
- Зарегистрирован: 22.02.2014 17:02
Да, объяснить получается пока сложно. Даже для себя самого.
попробуем еще раз разобраться в нашей структуре с примерами:
есть несколько групп проектов:
сайты
-сайт1
-сайт2
-сайт3
база данных
-общее
-интернет
-логистика
Верхний уровень это группировка в вашей системе, дальше проекты.
разработки по каждому направлению ведет несколько компаний. Отслеживанием работ по проектам занимаются как менеджеры конкретного проекта так и менеджеры групп.
так например у каждого сайта есть свой менеджер который ставит и отслеживает ситуацию по задачам и есть общий менеджер который отслеживает все задачи сайтов и занимается связью работ между сайтами и работами в базе данных.
у базы данных у каждого проекта есть свой менеджер который занимается постановкой и отслеживанием задач.
при этом есть задачи которые плавно перетекают при реализации из одного проекта в другой. Соответсвенно некоторые менеджеры берут на себя постановку и отслеживание задач в нескольких проектах сразу.
для таких менеджеров необходимо видеть всю задачу с подзадачами в комплексе, но при этом он должен видеть и понимать что часть задач находится в области разработки сайтов, часть в разработки базы данных.
есть менеджеры которым необходимо видеть и оценивать работу только своего сектора. Например работ по сайтам или работ по базам данных.
и есть начальство которое хочет видеть все работы во всех разрезах:
в разрезе задач - кто вовлечен, какие проекты затронуты в реализации.
в разрезе проектов - какие объемы работ происходят в каждом секторе работ. Сколько стоит задач, сколько выполнено и сколько запланировано на выполнение.
возможно это можно было бы разделить контрагентами в поставленных задачах, но тогда надо видеть сколько и каких задач висит на каждом контрагенте, понимать загрузку каждого контрагента.
как то вот так.
Добавлено спустя 20 минут 50 секунд:
И еще одно дополнение: если мы делаем разработку на одном сайте с последующем внедрением на остальных то не хочется в каждом проекте плодить по своей собственной задаче. Лучше всего создать одну задачу которая сможет пройти через все проекты насквозь.
т.е. Создаем основную задачу, а дальше подзадачами распределяем разработку и внедрение. После успешного внедрения на первом сайте формируем подзадачу на внедрение на втором и остальных сайтах. Каждая подзадача имеет свои сроки на реализацию. А стоимость реализации задачи задается в головной.
Кстати что то не заметил поля ввода стоимости разработки задач.
попробуем еще раз разобраться в нашей структуре с примерами:
есть несколько групп проектов:
сайты
-сайт1
-сайт2
-сайт3
база данных
-общее
-интернет
-логистика
Верхний уровень это группировка в вашей системе, дальше проекты.
разработки по каждому направлению ведет несколько компаний. Отслеживанием работ по проектам занимаются как менеджеры конкретного проекта так и менеджеры групп.
так например у каждого сайта есть свой менеджер который ставит и отслеживает ситуацию по задачам и есть общий менеджер который отслеживает все задачи сайтов и занимается связью работ между сайтами и работами в базе данных.
у базы данных у каждого проекта есть свой менеджер который занимается постановкой и отслеживанием задач.
при этом есть задачи которые плавно перетекают при реализации из одного проекта в другой. Соответсвенно некоторые менеджеры берут на себя постановку и отслеживание задач в нескольких проектах сразу.
для таких менеджеров необходимо видеть всю задачу с подзадачами в комплексе, но при этом он должен видеть и понимать что часть задач находится в области разработки сайтов, часть в разработки базы данных.
есть менеджеры которым необходимо видеть и оценивать работу только своего сектора. Например работ по сайтам или работ по базам данных.
и есть начальство которое хочет видеть все работы во всех разрезах:
в разрезе задач - кто вовлечен, какие проекты затронуты в реализации.
в разрезе проектов - какие объемы работ происходят в каждом секторе работ. Сколько стоит задач, сколько выполнено и сколько запланировано на выполнение.
возможно это можно было бы разделить контрагентами в поставленных задачах, но тогда надо видеть сколько и каких задач висит на каждом контрагенте, понимать загрузку каждого контрагента.
как то вот так.
Добавлено спустя 20 минут 50 секунд:
И еще одно дополнение: если мы делаем разработку на одном сайте с последующем внедрением на остальных то не хочется в каждом проекте плодить по своей собственной задаче. Лучше всего создать одну задачу которая сможет пройти через все проекты насквозь.
т.е. Создаем основную задачу, а дальше подзадачами распределяем разработку и внедрение. После успешного внедрения на первом сайте формируем подзадачу на внедрение на втором и остальных сайтах. Каждая подзадача имеет свои сроки на реализацию. А стоимость реализации задачи задается в головной.
Кстати что то не заметил поля ввода стоимости разработки задач.
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
Насколько я понял, можно условно выявить 3 уровня менеджеров:
При этом задачи по-прежнему могут находиться только в одном проекте. Я понимаю, что в некоторых случаях необходимо фильтровать задачи по какому-то признаку, а проект просто кажется очевидным для этой цели инструментом, но на текущий момент есть жесткое ограничение в один проект для одной задачи, и использовать реквизит "проект" для организации такой матричной структуры не получится.
Весной (скорее всего в апреле, за март не успеем) выйдет релиз, в котором у задач появятся кастомные поля. Вы сможете добавить дополнительный реквизит, характеризующий тип задачи (сайты/базы данных) и использовать его в фильтрах. Это не так привычно, как проект, но если вдуматься, то задачу решает. Ну, на мой взгляд, по крайней мере.
Есть еще один, совсем альтернативный вариант организации работы, на который меня натолкнуло Ваше упоминание про то, что разработки по каждому направлению ведет несколько компаний. Для каждой такой компании может быть создан свой аккаунт ПланФикса, со своей иерархией проектов, а кросспроектные задачи "смотрят" сразу в два аккаунта при помощи связи аккаунтов. По сути, это две независимые задачи в разных аккаунтах, которые специальным образом связаны на уровне участников, статуса и комментариев. Это позволяет задаче, к примеру, находиться в одном аккаунте в проекте "Сайт такой-то", а в другом - в проекте "Интернет". Доступ к задаче в каждом аккаунте регулируется отдельно. Пользователи другого аккаунта для текущего аккаунта являются внешними контактами, если такого пользователя-контакт уведомить при добавлении действия, оно появится в его аккаунте и он его увидит. Если не уведомить ни одного пользователя из другого аккаунта - действие останется только в задаче вашего текущего аккаунта. Это позволяет работать с задачей как бы независимо, уведомляя вторую сторону только о том, что касается ее напрямую.
Минусом этого варианта можно считать то, что руководители скорее всего смогут видеть полную картину только в рамках одного аккаунта.
- имеют доступ к конкретному проекту/проектам
- имеют доступ к группам проектов "сайты" и "база данных" (в частном случае - только к одной из групп)
- руководители
При этом задачи по-прежнему могут находиться только в одном проекте. Я понимаю, что в некоторых случаях необходимо фильтровать задачи по какому-то признаку, а проект просто кажется очевидным для этой цели инструментом, но на текущий момент есть жесткое ограничение в один проект для одной задачи, и использовать реквизит "проект" для организации такой матричной структуры не получится.
Весной (скорее всего в апреле, за март не успеем) выйдет релиз, в котором у задач появятся кастомные поля. Вы сможете добавить дополнительный реквизит, характеризующий тип задачи (сайты/базы данных) и использовать его в фильтрах. Это не так привычно, как проект, но если вдуматься, то задачу решает. Ну, на мой взгляд, по крайней мере.
Есть еще один, совсем альтернативный вариант организации работы, на который меня натолкнуло Ваше упоминание про то, что разработки по каждому направлению ведет несколько компаний. Для каждой такой компании может быть создан свой аккаунт ПланФикса, со своей иерархией проектов, а кросспроектные задачи "смотрят" сразу в два аккаунта при помощи связи аккаунтов. По сути, это две независимые задачи в разных аккаунтах, которые специальным образом связаны на уровне участников, статуса и комментариев. Это позволяет задаче, к примеру, находиться в одном аккаунте в проекте "Сайт такой-то", а в другом - в проекте "Интернет". Доступ к задаче в каждом аккаунте регулируется отдельно. Пользователи другого аккаунта для текущего аккаунта являются внешними контактами, если такого пользователя-контакт уведомить при добавлении действия, оно появится в его аккаунте и он его увидит. Если не уведомить ни одного пользователя из другого аккаунта - действие останется только в задаче вашего текущего аккаунта. Это позволяет работать с задачей как бы независимо, уведомляя вторую сторону только о том, что касается ее напрямую.
Минусом этого варианта можно считать то, что руководители скорее всего смогут видеть полную картину только в рамках одного аккаунта.
Сейчас для этой цели можно использовать аналитики. После появления кастомных полей, можно будет сделать поле для стоимости прямо в карточке задачи.Кстати что то не заметил поля ввода стоимости разработки задач.
-
- Сообщения: 3
- Зарегистрирован: 24.02.2014 16:14
так, после анализа нашей структуры было выявлено еще зачем у нас используются разные проекты и задачи прыгают из одного проекта в другой:
Это разные бюджеты на разработки - т.е. на каждый сайт свой бюджет и разработки по базам данных находятся каждый в своем бюджете.
Наверно для всех реализаций необходимо ожидать кастомные поля, хотя конечно они наверно тоже не решат всех проблем...
Это разные бюджеты на разработки - т.е. на каждый сайт свой бюджет и разработки по базам данных находятся каждый в своем бюджете.
Наверно для всех реализаций необходимо ожидать кастомные поля, хотя конечно они наверно тоже не решат всех проблем...
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 6
- Зарегистрирован: 22.02.2014 17:02
А тут смотря какая задача. Т.е. В один момент времени одна задача может принадлежать только одному бюджету.
Если есть задача которая включает разработку по сайту 1 и по базе данных то это две задачи взаимосвязанные между собой, но принадлежат они разным бюджетам. Те задачи которые относятся к сайту будут в бюджете сайта, а разработки по базе будут в бюджете баз.
Если есть задача которая включает разработку по сайту 1 и по базе данных то это две задачи взаимосвязанные между собой, но принадлежат они разным бюджетам. Те задачи которые относятся к сайту будут в бюджете сайта, а разработки по базе будут в бюджете баз.
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
Посмотрите внимательно на вариант с разделением по нескольким аккаунтам по принципу 1 компания = 1 аккаунт. Мне кажется, он в том числе хорошо решает и задачу разделения бюджетов - в каждом аккаунте свой бюджет и одна задача, "смотрящая" разными боками в разные аккаунты, будет принадлежать одновременно двум бюджетам, которые не будут мешать друг другу.
-
- Сообщения: 3
- Зарегистрирован: 24.02.2014 16:14
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
-
- Сообщения: 5
- Зарегистрирован: 26.02.2014 23:37
Аналитики действительно решают многое.
Только не хватает большей гибкости в настройках всего.
Например я могу выбрать контрагента, но не могу отметить что бы показывалось дополнительное поле которое в контрагенте я ввел.
Можно конечно создать справочник дублирующий контрагентов, но как то это не так...
еще в аналитиках можно было бы заполнять автоматом поле контрагента из задачи, при условии конечно что оно заполнено в задаче. правда делать это необходимо по некой галочке заполнять или не заполнять.
Еще не хватает что бы в задачах и в проектах можно было настроить какие колонки показывать. Хотелось бы функционал как в отчетах. Потому как было бы видно сразу на каких задачах заполнены аналитики, а на каких нет. Можно конечно отчетом, но опять же дополнительные действия. где какие контрагенты и так далее... кто знает как можно перевернуть если столбцы можно будет настроить. Функциональность намного расширяется.p.s. извиняюсь что пишу все в одной теме. Но не очень вижу смысла открывать другую. А эту наверно надо переименовать в вопросы по настройкам или как то так.
Только не хватает большей гибкости в настройках всего.
Например я могу выбрать контрагента, но не могу отметить что бы показывалось дополнительное поле которое в контрагенте я ввел.
Можно конечно создать справочник дублирующий контрагентов, но как то это не так...
еще в аналитиках можно было бы заполнять автоматом поле контрагента из задачи, при условии конечно что оно заполнено в задаче. правда делать это необходимо по некой галочке заполнять или не заполнять.
Еще не хватает что бы в задачах и в проектах можно было настроить какие колонки показывать. Хотелось бы функционал как в отчетах. Потому как было бы видно сразу на каких задачах заполнены аналитики, а на каких нет. Можно конечно отчетом, но опять же дополнительные действия. где какие контрагенты и так далее... кто знает как можно перевернуть если столбцы можно будет настроить. Функциональность намного расширяется.p.s. извиняюсь что пишу все в одной теме. Но не очень вижу смысла открывать другую. А эту наверно надо переименовать в вопросы по настройкам или как то так.
-
- Сообщения: 4123
- Зарегистрирован: 06.06.2012 13:54
Есть такое пожелание, будет реализовано в рамках доработок по аналитикам.Например я могу выбрать контрагента, но не могу отметить что бы показывалось дополнительное поле которое в контрагенте я ввел.
Ну вот тут смущает именно то, что когда-то надо, а когда-то не надо. Конечно, галочки могут все решить, но обилие галочек это то еще зло.еще в аналитиках можно было бы заполнять автоматом поле контрагента из задачи, при условии конечно что оно заполнено в задаче. правда делать это необходимо по некой галочке заполнять или не заполнять.
Это в близких планах. Правда, работать будет не совсем так, как в отчетах - просто можно будет выбрать какие-то из реквизитов задачи или проекта. Но аналитики не являются реквизитами задачи, поэтому в этом списке их точно не будет. Зато будут кастомные поля задач.Еще не хватает что бы в задачах и в проектах можно было настроить какие колонки показывать. Хотелось бы функционал как в отчетах. Потому как было бы видно сразу на каких задачах заполнены аналитики, а на каких нет.