Срок задачи выставляет исполнитель

[Александр Черняев]

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

Реализацию я вижу через какую нибудь галку в самой задаче или наборе статусов
"Требовать указание срока перед принятием задачи в работу"
Если галка будет в самой задаче то нужно предусмотреть возможность настроить ее в шаблоне.
 

Добавлено спустя 16 минут 2 секунды:
Вдогонку поясню почему важны адекватные сроки.
Замечено что когда твоем списке некоторое количество просроченных задач, они становятся все одинаково важны и не важны. Т.е. если есть 5 задач которые я должен сделать вчера, и в этот момент поступает новая задача со сроком "сегодня", она уже заранее обречена быть просроченной. Поэтому мне бы как исполнителю хотелось  бы предупредить постановщика что данная задача будет решена не чем раньше "после завтра". Иначе однажды понятие "срок" вообще теряет значение.
Второй сильной стороной вопроса является то, что самостоятельное выставление сроков исполнителем побуждает его более внимательно вникать в суть задачи и ответственно подходить к ее принятию. Сам назначил сроки, за язык не тянули. 

 

[Dmitry Goncharenko]

Обсудили этот вопрос в команде, предлагаемое решение наткнулось на следующие проблемы:

1. У нас есть некоторое количество мест, где происходит автопринятие задачи - там нет возможности указать дату.
2. Предлагаемый вариант конфликтует с логикой расчета даты завершения от даты принятия + длительность. Непонятно что делать в случаях такого конфликта.
3. Непонятно, кто выставляет срок, если исполнителей в задаче несколько.

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

[Александр Черняев]

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

1. Авто принятие - я с такой возможностью не знаком, предполагаю, что это связано с какими-то роботами типа автоответчика и т.п. В любом случае не вижу криминала в том, что задачи принятые "Авто" остаются без определенного срока "Дата не указана". Если этот момент беспокоит, то требовать/предлагать постановщику заполнить спец. параметр: "Срок/длительность по умолчанию для задач с автопринятием". Вообще не страшно, что такие задачи окажутся без срока. 
2.  Дата завершения = дата принятия + длительность. "Длительность" можно вычислять или обязывать вводить на этапе принятия задачи также как и "Дату завершения". Т.е. при принятии задачи исполнитель может указать на выбор один из параметров (на вкус) либо длительность либо срок. Естественно что это актуально только для тех задач, где эти параметры не потрудился установить самостоятельно постановщик задачи.
3. Если исполнителей в задаче несколько, то срок выставляет первый принявший. Поскольку у задачи уже есть срок (не важно кем определенный одним из исполнителей или постановщиком), то соответственно такая задача в определении срока уже не нуждается, поэтому следующий подключившийся уже будет возражать в комментариях к задаче, а не при принятии задачи. Вообще я лично в принципе избегаю размывать ответственность. Мне трудно представить, что у задачи может быть несколько ответственных, но если такое в природе существует, то данная логика будет удовлетворительной.

[Dmitry Goncharenko]

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

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

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

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

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

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

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

[Александр Черняев]

)) теперь я понял, что имеется ввиду под "тригером"
Мне лично страшно представить сколько может быть событий требующих определенных следствий, и сколько вариантов таких следствий возможны. А Еще страшнее представить механизм для настройки всего этого. Тут я умолкаю.
Спс.