Рассчет сроков задачи

[Юрий]

Когда я указываю дату начала и длительность задачи, дедлайн рассчитывается по формуле
дата начала + длительность в календарных днях? Правильно понимаю? Как настроить рассчет дедлайнов с учетом рабочих дней.

[Антон Владимирович Кострубин]

Аналогичный вопрос и у меня.

[Dmitry Goncharenko]

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

[Юрий]

>у меня возникает вопрос как система должна себя вести, если у задачи 2 исполнителя с разным графиком работы

Порассуждаем. У семи нянек дитя не кормлено. Один из нескольких исполнителей должен быть главным - выбираем его график. Или же считать по графику постановщика. Пожалуй второй подход вернее. График работы над задачей один и как в него укладываются графики различных исполнителей -- головная боль постановщика. Ведь именно он отвечает за результат?

[Dmitry Goncharenko]

По графику постановщика, на мой взгляд, совсем неправильно - он вообще не обязан совпадать с графиками исполнителей, а работать-то им, а не ему.

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

[Юрий]

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

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

[Dmitry Goncharenko]

Для того, чтобы запланировать какие-то изменения в функционале, нам нужно быть уверенными, что:

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

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

Предлагаемый Вами вариант

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

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

В итоге: недовольство системой, сообщения об ошибках, нагрузка на техподдержку и прочие неприятности. И все по нашей вине - мы допустили неочевидное поведение системы. Как говорил Лёлик, "на это я пойтить не могу" :) Так что нужен вариант, который будет работать очевидно во всех случаях.
 

[Юрий]

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

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

[Dmitry Goncharenko]

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

 

[Антон Владимирович Кострубин]

Дмитрий, все намного проще.
Вы почему-то объединяете ДВА необъединяемых параметра Количество исполнителей и Рабочие дни.
Давайте посмотрим со стороны договора — между Заказчиком и Исполнителем.
И будем исходить из - того, что нам нужно соблюдать сроки исполнения своих обязательств как Исполнитель.
В договорах как правило все считается в Банковских днях - это рабочие дни, как правило 5 дней с понедельника - по пятницу + официальные праздники. Если смотреть с такой позиции, тогда реализация механизма контроля сроков сводится к простому.
Этот несложный функционал, значительно бы помог в планировании времени и сделал систему ПланФикс еще более востребованной.
 

[Dmitry Goncharenko]

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

[Антон Владимирович Кострубин]

Дмитрий, случай достаточно распространенный.
И вы опять путаете роль Исполнителя по договору и роль Исполнителя по заданию. Если компания зарегистрирована в РФ, то и работает по законам РФ со всеми вытекающими.
В контракте не может быть два исполнителя. только между государствами могут быть трехсторонние и более соглашения.
Вы суть уловите, что смотрим со стороны — Исполнителя Договора. Речь идет о контроле СРОКА выполнения работы, в независимости от количества исполнителей. Рабочие дни ИСПОЛНИТЕЛЯ ЗАДАЧИ нас не интересуют.

Такой механизм прост и удобен - т.к. все работают по одному календарю и 1 января - у всех 1 января.
Но рабочее оно или нет - нас тоже не интересует, т.к. мы опираемся на законодательство РФ.
Если же необходим более широкий функционал, тогда надо делать трудовой календарь. 

[Dmitry Goncharenko]

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

Чего не учитывает Ваш вариант:

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

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

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

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

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