Форум сервиса Планфикс

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

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

Дмитрий Гончаренко писал(а): ↑

05.08.2017 16:20

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

Дмитрий, немного другая задача, но очень похожа:

По сценарию может геренировться задача, хоть подзадача, хоть задача в другом проекте. Но по мере все большего использования ПФ возникает необходимость создавать задачи в других проектах, но оставлять своего рода связь с родительской задачей, чтобы в родительской был виден только признак завершения.
Схема такая:
Задача1.ПроектА генерирует Задачу1.ПроектБ
Но в задаче Задача1.ПроектА интресно видеть Задачу1.ПроектБ в виде простого чекбокса, чтобы когда закрылась задача ПроектеБ, этот чекбокс стал бы выполненным.

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

Одна из подзадач, которая должна генерироваться - "Создание рабочего места", но это уже в проекте "ИТ". В этой задаче полотно из 50 пунктов (задач и чекбосов) чисто для ИТшников (там даже у нас чеклист по настройке ПК в корпоративной среде включен). Остальным участникам и исполнителям задачи "Прием нового сотрудника" все это видеть не надо, да и постановщику задачи не нужно видеть внутренние подзадачи ИТ по созданию рабочего места. Потому мы уносим создание рабочего место в свой проект.
Но кадровику нужно отслеживать факт выполнения "Создания рабочего места" в своей головной задаче "Прием на работу сотрудника", наряду с остальными (Инструктаж по охране труда, медкомиссия, и т.д).

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

Это только один кейс, их много)

Пример использования:
Есть задача "Прием на работу сотрудника" со своим сценарием, допустим это проект "Персонал"

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

1. конечные цели: Проект строительства дома, Разработка сайта
2. направление деятельности: Продажи, Сервис оборудования, Найм персонала (не кадровый отдел, а в целом), Развитие компании

При таком выделении проектов решение задач не пересекает проекты, а происходит в рамках одного и того же.
На примере вашего кейса отчетливо видно что вы взяли за проект "Подразделение" и понятное дело что задача у вас может проходить насквозь через подразделения (тоже самое что Исполнители)

Например, при разделении проектов как в п.2 отдел "ИТ" увидел бы следующие задачи:

Продажи
- Заменить картридж в кабинете №3
--- Оплатить (бухгалтерии) счет на новый картридж
Найм персонала
Создать рабочее место для Иванова И.И.
Развитие компании
Заменить сервер на более мощный

Андрей Гринюк писал(а): ↑

22.04.2018 08:46

Пример использования:
Есть задача "Прием на работу сотрудника" со своим сценарием, допустим это проект "Персонал"

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

1. конечные цели: Проект строительства дома, Разработка сайта
2. направление деятельности: Продажи, Сервис оборудования, Найм персонала (не кадровый отдел, а в целом), Развитие компании

При таком выделении проектов решение задач не пересекает проекты, а происходит в рамках одного и того же.
На примере вашего кейса отчетливо видно что вы взяли за проект "Подразделение" и понятное дело что задача у вас может проходить насквозь через подразделения (тоже самое что Исполнители)

Например, при разделении проектов как в п.2 отдел "ИТ" увидел бы следующие задачи:

Продажи
- Заменить картридж в кабинете №3
--- Оплатить (бухгалтерии) счет на новый картридж
Найм персонала
Создать рабочее место для Иванова И.И.
Развитие компании
Заменить сервер на более мощный

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

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

Мы ранее пользовались Jira, там сразу много типов связей есть.
Например создаем в Задаче А связь Заблокирована к Задаче Б - соответственно в Задаче Б появляется обратная связь Б Блокирует А
Или просто линейные связи - дублирует, относится, включает.
Описание типа связи тут можно и текстовым полем оставить, чтобы каждый указывал то, что ему удобно. Или из справочника брать.
Главное чтобы
- добавив связь в одной задаче, автоматически было видно её в связанной
- видеть статус связанной задачи (цвета полагаю достаточно от самого статуса)
- видеть состояние как у чеклиста (завершена или нет)
- наименование связи конечно же (блокирует, дублирует, относится...)
- возможность отображать это поле где-то в районе текущего чеклиста задачи, а не на панели справа

Думаю такая реализация должна покрыть большинство нужд.
Смотрел в сторону текущего поля Tasks List, но оно не имеет обратной связи + как минимум надо бы причесать отображение, чтобы было как у чек-листа.

Опять же ведь внутри Планфикса принимаете заявки на саппорт, а задачи на разработку совсем в другом месте, разве не будет удобным такой список связей между запросами и задачей в разработке?

Спасибо, Сергей.

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

Уточню по последней фразе:

Опять же ведь внутри Планфикса принимаете заявки на саппорт, а задачи на разработку совсем в другом месте, разве не будет удобным такой список связей между запросами и задачей в разработке?

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

Дмитрий Гончаренко писал(а): ↑

09.12.2018 10:52

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

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

Дмитрий Гончаренко писал(а): ↑

09.12.2018 10:52

Уточню по последней фразе:

Опять же ведь внутри Планфикса принимаете заявки на саппорт, а задачи на разработку совсем в другом месте, разве не будет удобным такой список связей между запросами и задачей в разработке?

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

Спасибо Дмитрий, я знаю. Я тут имел ввиду что заявки/обращения клиентов (не важно что это - помощь / баг / улучшение) и задачи для разработчиков, связанные с этим - это две отдельных задачи и вот тут возникает связь между ними, которую так-же можно хранить в данном поле. А далее тут придумать много что можно, можно и автоматическим сценарием отправлять оповещения в задачи и статус у них менять...
Опять же если смотреть широко, как предлагали выше, что связи могут быть между задачами в разных проектах, то наверно сценарии сразу реализовать не получится, т.к. могут быть ограничения по правам доступа к связанным задачам/проектам, но даже обычная связь со статусом и пометкой выполнения может сильно помогать.
Не всегда получается увязывать задачи в дочерние, бывает что просто часть фукнкционала пересекается, но задачи разные, бывают от разных людей задачи и даже в разных проектах.

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

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

В общем ждем результатов обсуждения этой фичи внутри вашей команды )))

Спасибо, Сергей!

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

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

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

Дмитрий Гончаренко писал(а): ↑

09.12.2018 20:10

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

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

Да, вы правы Дмитрий и спасибо за идею! В ряде случаев достаточно просто добавить чеклист в одной задаче и все связи и мой пример действительно хорошо ложится под такое решение.
Так-же тут можно пойти дальше и расширить, например если связи не прямые, то вложенные чеклисты
- Блокирует задачи:
-- https://.....
-- https://.....
- Связан с задачами:
-- https://.....
....

Но такой подход имеет прямые недостатки
1) Если нам важно человеческое название видеть + статус связанной задачи + статус выполнения (а может и еще что-то) - это очень много дополнительных действий и внимания. Т.е. при создании все эти свойства нужно руками заполнить в чеклист, а потом в каждой задаче придется отслеживать изменения и обновлять каждый пункт (Статус, Статус выполнения...) - все это будет отнимать много времени и внимания
2) Визуально чеклист не позволяет вставить html, подсветить цветом... - хуже будет восприниматься информация + более громоздкий (отдельно название, отдельно ссылка, отдельно статус....)
3) Нет обратной связи у задач - т.е. по сути каждый пункт нужно заполнять и там и там, а это еще больше увеличивает необходимое время и внимание к таким вещам

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

Согласен, Сергей.

Все же если бы можно было бы создавать подзадачу в другом проекте это было бы на много удобней.
Вы говорите, что обходитесь ссылками на задачи источники, например ситуация:
1. Запрос от клиента прилетает всегда в проект "1 линия поддержки".
2. По запросу понятно, что нужно дорабатывать отдельный модуль системы, для развития которого, создан отдельный проект.
Было бы логично, закончить обсуждение задачи в исходном запросе (задача проекта 1)
Затем создать подзадачу разработчику уже в проекте 2 - двумя кликами (создать подзадачу и изменить проект).
Однако по вашей методике, нам придется:
1. Скопировать ссылку на задачу исходного запроса
2. Перейти в проект 2 и создать там новую задачу.
3. Вставить куда-нибудь скопированную ссылку на исходную задачу
4. Сохранить новую задачи и скопировать ссылку на нее.
5. Вернуться в исходную задачу и добавить в нее пункт чеклиста, в который вставить скопированную ссылку второй задачи.
The End
И соблюдение этого ритуала нужно будет не только помнить, но и требовать делать это от сотрудников.
Очевидно, что кто-то и часто будет забывать это делать.
Не вижу каких-то непреодолимых препятствий, чтобы просто разрешить делать подзадачи в другом проекте.
Проект это ведь условность, это аналитический группирующий признак, с чем связан подобный запрет?

Дмитрий Гончаренко писал(а): ↑

05.08.2017 16:20

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

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

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

Согласен с обоими предложениями:
1) Подзадачи могут быть в других проектах. Из-за того что это сейчас не так нам пришлось отказаться от проектов вообще.
2) Дополнительно к полю Набор задач нужен еще список Отношения в котором будут выводится все ссылки на текущую задачу.
Желательно не в правом меню, а поближе к задаче — как подзадачи сейчас. Также у связей в полях Набор задач должна быть возможность задать имена, поименовать.
Аналогичные возможности должны быть и в контактах: поля на кого ссылается данный контакт и список кто ссылается на этот контакт с указанием имен связи.

Также эта тема подробно обсуждалась здесь:
viewtopic.php?f=28&t=4952&p=27308#p27308

Заинтересованным лицам предлагаю и там тоже отписаться со своими мыслями.

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

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

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

А начинать надо с процесса. В каком процессе участвует задача. Потом уже, в каком она проекте.

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

Но если посмотреть на это с точки зрения процесса — то вся эта кучка задач, по сути, находится в одном проекте — назовём его условно «удовлетворение потребности клиента», а вот процессы у них разные.

А кому и что видеть и как отслеживать — настраивается планировщиками.

Так что со вчерашнего дня внезапно стала адептом того, что не надо ничего усложнять, не надо подзадач в других проектах. Проект один — процессы разные.

Все дело в том что проект в планфикс уже не совсем проект в общепринятом смысле. В обще принятом смысле проект это совокупность мероприятий ограниченных по времени и ресурсам нацеленных на достижение конкретного результата. Например построить микрорайон это проект с понятным результатом, ограниченный во времени и ресурсах.
В планфиксе проект используется не совсем по назначению иначе бы применимость планфикса сильно сузилась.
В планфиксе проект - больше похоже на "направление деятельности", направление без определенного конца, т.е. обслуживание клиента это направление деятельности, которое приносит доход и т.п. у нас нет конкретной цели по достижению которой обслуживание можно назвать законченным. При этом если у клиента несколько объектов для обслуживания то резонно создать по каждому отдельный проект. Таким образом проект в смысле Планфикса это уже просто некий общий признак по которому можно собрать задачи относящиеся к обще теме, при этом задачи из одного процесса, направления, темы могут нуждаться в исполнении задач в параллельной теме.
Например мы обслуживаем объект заказчика, и нужно выполнить определенные работы, однако для их выполнения нам потребуется закупить специальное оборудование, которое в дальнейшем будет использоваться и на других объектах (проектах) тоже. В данном случае мы имеем две задачи в разных проектах
1. Выполнить работы - в проекте "обслуживание объекта"
2. Закупить оборудование - в проекте "Обеспечение"
И эти задачи нужно связать, при этом так чтобы связь эта была наглядной и не потерялась.

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

+1Подзадачи могут быть в других проектах.
Из-за невозможности этого иногда приходится отказаться от проектов в принципе. Честно говоря, проекты "обиженные" какие то в ПФ. Хочется больше их применять, использовать, но постоянно натыкаешься на ограничения.

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

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

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

Выходом реально являются различные кастомные поля (метки). И вот как раз «метка» на равно с «задача», «аналитика» как раз отдельная сущность по сути «проект».
В том числе с ограничением видимости …

Андрей писал(а): ↑

22.05.2022 17:42

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

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

Андрей, немного поспорю с вами про сущность проект. Как раз в ПланФикс он четко отражает его классическое определение (я приведу свое понимание этого понятия): "деятельность (действия, мероприятия) ограниченная во времени и в ресурсах для создания уникального продукта/услуги".
Если в рамках проекта-сделки нужно "развернуть демосреду", то логично что это "задача" выполняется в рамках именного этого проекта поскольку данная "задача" (а она может быть и подзадачей) влияет на ресурсы проекта, имеет свою расходную составляющую (например оплата исполнителю за выполненную задачу), влияет на время исполнения всего проекта.

Многие используют в ПланФикс проекты как отделы, но по классике это не совсем правильно.
То что по сути это мега надзадача - соглашусь. Но у проекта есть ряд особенностей которые недоступны в задачах:
- наследование прав доступа для ролевых полей (Участники, Аудиторы, Исполнители);
- автоматические отбор задач в планировщиках при перемещении по проектам (в том числе при работе с иерархией проекта).

Подниму-ка древнюю тему.

Поглядел видео Проекты для торговой компании (На конкретных примерах рассказываем, как выстроить удобную структуру проектов для своей компании), представленное в "Справочном центре" на странице Для чего нужен проект?, где рассматривается вариант использование проектов в качестве контейнеров по подразделениям и направлениям работы.

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

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

Например, есть проект "Счета на оплату". Очевидно (разве может быть иначе?), что работа с конкретным счётом — это не что-то самодостаточное, а вспомогательная задача (подзадача!) в рамках какой-то практической задачи из другого проекта. Точно так же, большинство задач в проекте "Текущие задачи Техслужбы" де-факто будут, опять же, подзадачами обеспечения в рамках задач в других проектах.
Но ведь подзадачи не могут находиться в других проектах.
Каким же образом в предлагаемом примере технически отражается связь между такими задачами и подзадачами? Подразумевается и держится в голове сотрудников? Просто вписывается в описаниях или комментариях к задачам?

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

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

Например, есть проект "Счета на оплату". Очевидно (разве может быть иначе?), что работа с конкретным счётом — это не что-то самодостаточное, а вспомогательная задача (подзадача!) в рамках какой-то практической задачи из другого проекта. Точно так же, большинство задач в проекте "Текущие задачи Техслужбы" де-факто будут, опять же, подзадачами обеспечения в рамках задач в других проектах.
Но ведь подзадачи не могут находиться в других проектах.

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

Илья, мне Ваша критическая позиция понятна. И она верна и логична в случае классического проектного подхода.

Но я выше изложил не свои собственные соображения, а то, что описано в указанной статье Справочного центра "Для чего нужен проект?" о втором способе использования.

Проект в ПланФиксе можно использовать как минимум двумя способами:

• как классический проект, принятый в проектном менеджменте

• как удобное средство объединения типовых бизнес-задач

Так что, да, речь не о классическом проектном подходе, а именно о "папочном", но его предлагает использовать официальная Справка. С другой стороны, доступных инструментов для реализации такого "папочного" подхода (прежде всего, какой-то удобной "не костыльной" механики связей между задачами в разных проектах) в системе не наблюдается. Именно поэтому я высказал своё удивление.