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

Доброго времени суток, коллеги!

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

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

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

- Привязывать загрузку ресурсов к задачам, отслеживать недогруз/перегруз ресурса
- Процент выполнения проекта исходя из процента выполнения этапов проекта. На языке планфикса уровни сверху-вниз: Проект (= Проект) - Задача (= Этап) - Подзадача (= задача этапа). То есть, если у Задачи есть 3 подзадачи, 2 из которых выполнены на 100%, то родительская задача имеет процент выполнения 66.
- Иметь дашборд с ключевыми показателями проекта, а-ля рабочий стол с виджетами. В проектной деятельности нужно держать руку на пульсе и постоянно мониторить план/факт будь загрузки ресурсов либо выполнения Этапов или Задач проекта.

Какие на сегодняшний день нужно подставить костыли, чтобы закрыть эти потребности? Может быть есть хорошие новости относительно будущего функционала, который позволит реализовать эти кейсы более стройно?

Ответ Дмитрия Гончаренко:

Павел, здравствуйте!
Для привязки любых нужных данных к задачам (ресурсы, процент выполнения и т.п.) служат кастомные поля и аналитики. Возможны разные подходы, ПланФикс в этом плане предоставляет широкое поле для реализации своих идей и наработок, но, как правило, затрачиваемые ресурсы учитываются в виде аналитик (их удобно накапливать в ходе работы по здачам, см. например Учет доходов и расходов https://planfix.ru/docs/Учет_доходов_и_расходов или
Учет рабочего времени https://planfix.ru/docs/Учет_рабочего_времени).

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

Чего в ПланФиксе пока нет, так это дашбордов со сводными данными по проектам (при том, что по задачам он есть и очень гибкий). Обсуждались планировщики по проектам, которые могли бы выступать в роли таких дашбордов, но пока вопрос ощутимо не продвинулся. Основная причина - малое количество заявок на этот функционал и отсутствие понимания, как это могло бы выглядеть и работать. Чем больше будет клиентов, ориентированных на проектную работу, которым будет недоставать таких дашбордов, тем ближе они будут к реализации. Собирать единомышленников удобнее всего на форуме https://forum.planfix.ru/ - там запросы, кейсы и прочие данные накапливаются и становятся основой для будущих доработок.

Начнем по порядку с задач.
1. Отслеживать ключевые метрики проекта, которые автоматически собираются и считаются по всем уровням вложенности задач
2. Дашборд с этими метриками

Задача 1.
В проектной деятельности (проектирование, строительство и прочее) очень важно держать руку на пульсе и вовремя как отслеживать изменения по времени, по ресурсам, так и прогнозировать такие изменения. Важнейшей методикой является методика освоенного объема в оперативном управлении проектами. Она заключается в том, чтобы постоянно иметь возможность сверить текущие ВРЕМЯ, ДЕНЬГИ, РЕСУРСЫ с плановыми и при необходимости, принять оперативные меры. Задач и зависимостей огромное количество, поэтому особенно важно иметь автоматизированный инструмент.

Как это работает.
1. В начале проекта составляется весь объем работ (WBS). Иерархия должна иметь такую глубину, чтобы иметь возможность контролировать каждую задачу.
2. Каждая задача имеет свой вес в объеме задач-соседей на том же уровне (далее приведу пример). Сейчас можно использовать кастомное поле
3. Каждая задача должна иметь свой актуальный статус завершения, измеряемый в процентах. Скажем если задача имеет статус Новая, то ее статус 0%, если по задаче закончил работу первый исполнитель, то он переводит ее в статус Выполнена, и при нажатии на кнопку срабатывает сценарий, по которому значение поле статуса меняется, скажем на 70%, далее задача проверяется двумя людьми. Если пройдена одна проверка, то процент - 80, если обе проверки - 100%
4. Каждая надзадача должна собирать вычисляемые значения подзадач (произведение веса задачи на ее процент завершения)

Например:

ПРОЕКТ

10 Задача А (вес 0,4)
10 10 Подзадача 1 (вес 0,25, завершена на 50%)
10 20 Подзадача 2 (вес 0,25, завершена на 75%)
10 30 Подзадача 3 (вес 0,25, не начата, 0%)
10 40 Подзадача 4 (вес 0,25, завершена на 30%)

20 Задача В (вес 0,6)
10 10 Подзадача 1 (вес 0,7, завершена на 50%)
10 20 Подзадача 2 (вес 0,3, завершена на 75%)

Математика элементарная. Зная вес и процент завершения каждой задачи, определяем процент завершения надзадачи и всего проекта.
Для задачи А процент завершения равен 38,75% (0,25х50 + 0,25х75 + 0,25х0 + 0,25х30 = 12,5 + 18,75 + 0 + 7,5)
Для задачи В процент завершения равен 57,5%

Для проекта процент завершения является суммой процента завершения всех задач, в него входящих, то есть
0,4х38,75 + 0,6х57,5 = 15,5 + 34,5 = 50%

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

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

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

Что скажете?

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

Как это часто бывает, правильная постановка задачи содержит в себе решение (ну или хотя бы его зерно). Я вижу его так:

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

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

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

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

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

Дмитрий, добрый день!

Отличные новости насчет пункта 1!
Вот после вашего сообщения как раз попробовал
http://joxi.ru/l2ZL5q6twokjwr

Очень наглядный пример как раз того, о чем вы писали в Вконтакте. По среднему арифметическому ни в коем случае нельзя проводить контроль. Слева среднее арифметическое по процентам (я сознательно его поставил), справа - честные проценты с учетом веса задач.

Процент определяем именно сценариями. У нас довольно сложные процессы.

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


Имеются статусы, которые соответствуют проценту завершения. Их на самом деле больше, я упрощу
Новая - 0%
Моделирование завершено - 70%
Нужна доработка - 70%
Пройдена проверка 1/2 - 80%
Пройдены все проверки - 100%

Соответственно при изменении статуса меняется значение кастомного поля "процент завершения". Вес задачи остается неизменным. Хочу отметить, что такая методология работает исключительно в том случае, когда весь объем работ определен и разбит на части.

Было бы здорово, если в планировщике иметь возможность добавить в карточки задач необходимые метрики. Получился бы Дашборд 1.0 =)

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

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

Ольга Скрылева писал(а): ↑

08.03.2020 00:12

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

Ольга, добрый день. Этот форму как раз и помогает собирать "различные подходы к организации процессов" и на основе их дорабатывать инструмент. Вряд ли команда ПФ в реалиях сегодняшнего дня будет тратить ресурс на подсматривание "у коллег", уверен что у них в заделе очень много задач на развитие. Чем больше примеров с подробным описанием логики мы с вами им накидаем в форуме (а на примере этого поста как раз и показан грамотное разъяснение логики), тем выше вероятность что команда ПФ этим заинтересуется и будет больше внимание уделять более проработанным вопросам.