Настройка ПланФикса: бюджет, подзадачи, проекты, аналитика

[Коняев Андрей]

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

причина:
есть проект например сайт - у него один руководитель и контролирующий с исполнителем
есть проект база учета чего нить - у этого проекта свои люди

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

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

[Dmitry Goncharenko]

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

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

[Русский Сиптх]

нет, тут задача не разделения прав. Тут разделение видимости задач для руководства.

Мне как руководителю определенных задач необходимо видеть задачи в полной их связке. В соответствии с этим можно назначать какие то сроки.
Те люди которые контролируют общий процесс разработок тоже хотят видеть задачи в полном дереве ()
При этом разработчики видят свои задачи, но им тоже периодически необходимо видеть дерево.

а вот когда происходит закрытие задач по готовности то просматривают уже в рамках только одного проекта.

надеюсь немного понятнее...
 

[Dmitry Goncharenko]

Немного понятнее, но пока не до конца :)

Мне как руководителю определенных задач необходимо видеть задачи в полной их связке. В соответствии с этим можно назначать какие то сроки.
Те люди которые контролируют общий процесс разработок тоже хотят видеть задачи в полном дереве ()
При этом разработчики видят свои задачи, но им тоже периодически необходимо видеть дерево.

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

а вот когда происходит закрытие задач по готовности то просматривают уже в рамках только одного проекта.

А вот тут совсем не понял:) Какова связь между закрытием задач по готовности и просмотром в рамках одного проекта?

[Коняев Андрей]

Да, объяснить получается пока сложно. Даже для себя самого.
попробуем еще раз разобраться в нашей структуре с примерами:
есть несколько групп проектов:

сайты
-сайт1
-сайт2
-сайт3

база данных
-общее
-интернет
-логистика

Верхний уровень это группировка в вашей системе, дальше проекты.

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

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

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

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

есть менеджеры которым необходимо видеть и оценивать работу только своего сектора. Например работ по сайтам или работ по базам данных.

и есть начальство которое хочет видеть все работы во всех разрезах:
в разрезе задач - кто вовлечен, какие проекты затронуты в реализации.
в разрезе проектов - какие объемы работ происходят в каждом секторе работ. Сколько стоит задач, сколько выполнено и сколько запланировано на выполнение.

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


как то вот так.

Добавлено спустя 20 минут 50 секунд:
И еще одно дополнение: если мы делаем разработку на одном сайте с последующем внедрением на остальных то не хочется в каждом проекте плодить по своей собственной задаче. Лучше всего создать одну задачу которая сможет пройти через все проекты насквозь.
т.е. Создаем основную задачу, а дальше подзадачами распределяем разработку и внедрение. После успешного внедрения на первом сайте формируем подзадачу на внедрение на втором и остальных сайтах. Каждая подзадача имеет свои сроки на реализацию. А стоимость реализации задачи задается в головной.

Кстати что то не заметил поля ввода стоимости разработки задач.
 

[Dmitry Goncharenko]

Насколько я понял, можно условно выявить 3 уровня менеджеров:

• имеют доступ к конкретному проекту/проектам
• имеют доступ к группам проектов "сайты" и "база данных" (в частном случае - только к одной из групп)
• руководители

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

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

Весной (скорее всего в апреле, за март не успеем) выйдет релиз, в котором у задач появятся кастомные поля. Вы сможете добавить дополнительный реквизит, характеризующий тип задачи (сайты/базы данных) и использовать его в фильтрах. Это не так привычно, как проект, но если вдуматься, то задачу решает. Ну, на мой взгляд, по крайней мере.

Есть еще один, совсем альтернативный вариант организации работы, на который меня натолкнуло Ваше упоминание про то, что разработки по каждому направлению ведет несколько компаний. Для каждой такой компании может быть создан свой аккаунт ПланФикса, со своей иерархией проектов, а кросспроектные задачи "смотрят" сразу в два аккаунта при помощи связи аккаунтов. По сути, это две независимые задачи в разных аккаунтах, которые специальным образом связаны на уровне участников, статуса и комментариев. Это позволяет задаче, к примеру, находиться в одном аккаунте в проекте "Сайт такой-то", а в другом - в проекте "Интернет". Доступ к задаче в каждом аккаунте регулируется отдельно. Пользователи другого аккаунта для текущего аккаунта являются внешними контактами, если такого пользователя-контакт уведомить при добавлении действия, оно появится в его аккаунте и он его увидит. Если не уведомить ни одного пользователя из другого аккаунта - действие останется только в задаче вашего текущего аккаунта. Это позволяет работать с задачей как бы независимо, уведомляя вторую сторону только о том, что касается ее напрямую.

Минусом этого варианта можно считать то, что руководители скорее всего смогут видеть полную картину только в рамках одного аккаунта.

Кстати что то не заметил поля ввода стоимости разработки задач.

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

[Русский Сиптх]

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

Наверно для всех реализаций необходимо ожидать кастомные поля, хотя конечно они наверно тоже не решат всех проблем...

[Dmitry Goncharenko]

А задача, которая пересекается между проектами - т.е. касается и разработки сайта и разработки по базам данных - она в чей бюджет попадает?

[Коняев Андрей]

А тут смотря какая задача. Т.е. В один момент времени одна задача может принадлежать только одному бюджету.

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

[Dmitry Goncharenko]

Посмотрите внимательно на вариант с разделением по нескольким аккаунтам по принципу 1 компания = 1 аккаунт. Мне кажется, он в том числе хорошо решает и задачу разделения бюджетов - в каждом аккаунте свой бюджет и одна задача, "смотрящая" разными боками в разные аккаунты, будет принадлежать одновременно двум бюджетам, которые не будут мешать друг другу.

[Русский Сиптх]

я вот подумал, а быть может можно эти бюджеты аналитиками разделить. Мне же потом еще закрывать помесячные бюджеты...
Пошел изучать вопрос аналитик...

[Dmitry Goncharenko]

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

[Коняев Андрей]

Аналитики действительно решают многое.
Только не хватает большей гибкости в настройках всего.

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

Еще не хватает что бы в задачах и в проектах можно было настроить какие колонки показывать. Хотелось бы функционал как в отчетах. Потому как было бы видно сразу на каких задачах заполнены аналитики, а на каких нет. Можно конечно отчетом, но опять же дополнительные действия. где какие контрагенты и так далее... кто знает как можно перевернуть если столбцы можно будет настроить. Функциональность намного расширяется.p.s.  извиняюсь что пишу все в одной теме. Но не очень вижу смысла открывать другую. А эту наверно надо переименовать в вопросы по настройкам или как то так.

[Dmitry Goncharenko]

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

Есть такое пожелание, будет реализовано в рамках доработок по аналитикам.

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

Ну вот тут смущает именно то, что когда-то надо, а когда-то не надо. Конечно, галочки могут все решить, но обилие галочек это то еще зло.

Еще не хватает что бы в задачах и в проектах можно было настроить какие колонки показывать. Хотелось бы функционал как в отчетах. Потому как было бы видно сразу на каких задачах заполнены аналитики, а на каких нет.

Это в близких планах. Правда, работать будет не совсем так, как в отчетах - просто можно будет выбрать какие-то из реквизитов задачи или проекта. Но аналитики не являются реквизитами задачи, поэтому в этом списке их точно не будет. Зато будут кастомные поля задач.