Стадии проекта.

[Олег Кузьмин]

У нас в компании все проекты могут находиться в 4х стадиях (на самом деле в 5, но это не важно :) ):
- проектирование;
- монтаж;
- пусконаладка;
- сервис.
Соответственно мне бы хотелось видеть в какой стадии в данный момент находится каждый из проектов. Чтобы понимать нагрузку соответствующих отделов, да и в целом, информация нужная для планирования и аналитики.
Я попытался решить эту задачу с помощью "группы проектов", создав соответствующие группы. Но это по многим причинам неудобно. Главная причина - проект может находится сразу в нескольких стадиях (зачастую проектирование длится уже когда во всю идёт монтаж, и пусконаладка иногда начинается когда монтажные работы еще не завершены. В самых запущенных случаях все 4 стадии идут одновременно :) ). А средствами планфикса я не могу назначить один проект в несколько групп.
Как мне решить мою задачу? 

[Dmitry Goncharenko]

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

[Олег]

А что такое "этап", в терминах планфикса? Просто "надзадача" или какая-то иная сущность? 
P.s.: очень порадовался появлению кастомных статусов. Но почему они доступны только для задач? Планируются ли кастомные статусы для проектов?

[Dmitry Goncharenko]

А что такое "этап", в терминах планфикса? Просто "надзадача" или какая-то иная сущность? 

Просто надзадача.

P.s.: очень порадовался появлению кастомных статусов. Но почему они доступны только для задач? Планируются ли кастомные статусы для проектов?

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

[Олег]

Смотрите мой первоначальный вопрос (Олег Кузьмин и просто Олег это всё я :) ). 
Плодить надзадачи - для нас плохой вариант. Потому что надзадача это тоже задача, которая висит на сотруднике незакрытым ярмом. Поясню что я имею в виду.
Мы так привыкли, что для нас "задача", это какое-то конкретное действие: позвонить, отправить мыло, согласовать с Заказчиком, рассчитать узел и т.д. Т.е. обычно как: я открываю список задач в планфиксе (или другой CRM) и начинаю подряд всё выполнять, пока не закончатся задачи. А наткнувшись на задачу (надзадачу, ака "этап"), к примеру, "монтаж" - я впадаю в ступор :) Т.к. выполнить эту задачу не могу и никаких активных действий она от меня не требует. Монтаж на объектах у нас может длиться и полгода, и год... В редких случаях и дольше :) Задачи относящиеся к "этапу" монтаж, я буду ставить и выполнять: согласовать перенос розетки, договориться с рабочими о проделке нового отверстия, завести на объект кабель, и т.д. Но сам этап "монтаж" мне не нужен в списке задач. У нас единовременно в работе более 50 объектов (и надеюсь количество будет расти :) ). Зачем мне 50 задач/надзадач в списке задач, которые при этом не требуют от меня никакого действия? О том, что на объекте идёт монтаж я и так знаю. Для этого мне достаточно перевести его в кастомный статус "монтаж" :) Ну или как сейчас - просто перенести его в группу проектов "монтаж". Хотя ни то ни другое неудобно, т.к. как я и написал в первом посте - в реальности проект может находится сразу в нескольких стадиях/статусах/этапах...
Так же при построении отчётов, каждый этап/надзадача считается за задачу, и совсем непонятно то ли сотрудник загружен подзавязку и у него 50 задач висит которые ему надо выполнить, то ли это просто 50 "этапов" на нём висит по разным проектам, а сотрудник бездельничает...

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

[Dmitry Goncharenko]

надзадача это тоже задача, которая висит на сотруднике незакрытым ярмом.

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

Мне кажется, что дерево - это еще один плюс использования именно надзадач-этапов:

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

 

[Олег]

Я попытался создать задачу без исполнителя - у меня не получилось. Только сейчас заметил ОТДЕЛЬНУЮ кнопку "создать без исполнителя" %) 

[Dmitry Goncharenko]

Да, там квест с этой кнопкой, не все проходят с первого раза :)

[Олег]

Еще бы задачи без исполнителя не считались в счётчике задач в списке проектов ;)  И было бы вообще нам счастье :)

[Dmitry Goncharenko]

Не, нельзя их не считать - они все-таки задачи, обидятся еще :)
 

[Олег]

Какие же они задачи, если они ЭТАПЫ :))

[Dmitry Goncharenko]

Ну да, правильно - пусть верят, лучше работать будут :)

[Ринат Разифович Абдуллин]

Только задаче несколько надзадач все равно не назначить (чтобы отразить, что она в нескольких этапах одновременно). м?

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

[Олег]

Ринат +1 :)
Теги - максимально универсальная сущность :) Совсем отказываться от сущности "проект" не стоит (к ней привязаны многие интересные фишки), но введение тегов решит множество задач и проблем.

[Ринат Разифович Абдуллин]

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

Добавлено спустя 1 минуту 56 секунд:
Олег, проекты это же частный случай тегов; менее гибкий инструмент. Не вижу его преимуществ перед тегами

Добавлено спустя 16 минут 12 секунд:
Опять увлекся темой )
Вот, например, как в Evernote (программа для создания заметок - блокнот) реализованы теги. Каждой заметке можно присвоить любое количество любых тегов. Позволяет группировать, фильтровать, структурировать заметки как угодно -  удобно. Количество уровней вложенности тегов вроде не ограничено

[Dmitry Goncharenko]

Теги в системах коллективного пользования имеют ряд ограничений, которые не приходят в голову сразу, но очень больно потом бьют в работе. Главное из них: люди по-разному видят таксономию работы в системе. Говоря по-простому, разные люди придумывают разные теги - даже если ты сделал тег "Задачи УК", рядом через какое-то время появится тег "Задача УК" или "Управление" или "Управленческие задачи" или... как именно стукнет в голову коллеге - никто не знает.

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

Есть и другие проблемы идеологического плана, например: кто должен иметь право установки тегов? Очень непростой вопрос, на самом деле, особенно если навесить на теги доступ, как предлагает Ринат.

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

[Ринат Разифович Абдуллин]

О таксономии я как-то не подумал )

[Олег]

Нет, проект это слишком отдельная и явная сущность, на уровне тегов это не решить.
Таксономию можно победить, жёстко регламентирую списки разрешённых тегов. Можно назвать их не тегами, а кастомными статусами :) Только желательно чтобы этих статусов было больше чем один. Чтобы по ним можно было группировать, фильтровать, и т.д.
Я за теги! Или дополнительные кастомные статусы! И дайте дополнительные статусы проектам :)

[Ринат Разифович Абдуллин]

Не просто тут найти правильный путь

[Дмитрий Бабенко]

Коллеги, активно поддерживаю данный пост.
Ранее также создавал и свой - их можно мерджить viewtopic.php?f=22&t=3740.

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

Заранее спасибо!

[Вячеслав Красовский]

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