Сроки

[Solaris]

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

Извините, немного отвлекусь: дохлый он сейчас, не пользуюсь - и потому, наверное, эту часть программы не люблю и игнорирую. Допускаю, что кому-то календарь как часть программы важен. И кому-то (увы, не мне) видеть автоматически сгенерированный календарь приятно. Увы, мне это не подходит: жесткими и привязанными ко времени "событиями" календарь наполняется часто и без тех задач, что в ЛТ, поэтому наполнять его еще и этими задачами заранее крайне нерационально, лишает гибкости и маневренности. Скорее, исхожу из сроков вызревающих задач и свободных промежутков в календаре. Поэтому иногда задачи выполняются в горящем режиме, иногда - заблаговременно. Чтобы совсем уж не работать в режиме аврала, ставлю в календаре напоминалки - чтобы не забыть про вызревающие задачи. Использую для этого календарь Outlookа. Готов бы был от него отказаться, но пока равной по функционалу программы не нашел (в первую очередь - синхронизация, во вторую - выделение цветом событий определенной категории).

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

   Когда было предложено отозваться на предложенные реформы как можно скорее - это правильно. Неправильно быстро приступать к реализации. Я понимаю, что это решение в недрах Алмезы зрело долго - со времени злосчастного сокращения и поспешного восстановления сроков. Узнали мы о нем только сейчас.  Я думаю, что существующее положение тормозит развитие фильтров. Но я также понимаю, что предложение сыроватое. Сейчас сроки не вызывают никаких серьезных нареканий. Народ не возмущается. Стоит ли спешить?
   Может, стоит для начала озвучить проблему, которую мы решаем? Какие функции мы пытаемся реализовать таким образом? В чем проблема с их реализацией в текущем состоянии? Как связана эта функция со сроками? Ведь не сроки же ради сроков?

    Повторюсь: СЕЙЧАС на сроки никто не жалуется. Если это запоздалая реакция на прошлогоднюю бурю, то она может вызвать новый ураган. СтОит ли?

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

   Может, трогать что-либо стоит только тогда, когда будет несколько - как минимум три - варианта решения?
Пусть пользователи проголосуют. А то в прошлом году был реализован один вариант. Откатились назад, но не совсем назад - непонятно, куда. Затем выработали второй вариант. Сейчас попробуем, а потом будем снова зализывать раны?
Может, не обязательно "накрывать" пользовательские данные? Развитие не обязательно должно идти по пути "до основанья, а затем..."  Как минимум не согласен с необходимостью заново редактировать несколько сотен задач разной важности и назначать всем сроки.


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

[SAM]

  Повторюсь: СЕЙЧАС на сроки никто не жалуется.

Говорю за себя.Свое мнение о сроках выразил когда они появились.Все впустую...
Сижу на 6.6.7, работаю и жду когда разработчики составят для себя понятную картину работы с ЛТ. Думаю я не один такой, раз не жалуются.

[zitz]

Здесь уже прозвучало, но, по-моему, как-то невнятно: а как при такой реформе быть с проектами (точнее, предстоящей их реформой)? Ведь в перспективе их планируется приравнять к задачам. Раз - и задача становится проектом. Два - и проект становится задачей.

Это решение еще не принято, оно прорабатывается. Пока проекты меняться не будут, и  данные изменения их не затронут. Нужно всё делать по порядку.

Сейчас сроки не вызывают никаких серьезных нареканий. Народ не возмущается. Стоит ли спешить?

Текущая ситуация такая - все жалуются на сроки, кто-то из-за этого использует старую версию 6.6.7 и говорит чтобы всё вернули на место, новые пользователи говорят уберите лишние даты - совершенно не разобраться. Причем не только на форуме - нам пишут на почту, звонят и говорят при личных встречах. Причем не только из России, но и другие страны, например можете почитать что пишут здесь http://www.todoforum.com/
По этому проблема, как говорится на лицо

Пляска, я так понимаю, идет вокруг календаря.

Именно так.

Как минимум не согласен с необходимостью заново редактировать несколько сотен задач разной важности и назначать всем сроки.

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

[biblioman]

Текущая ситуация такая - все жалуются на сроки, кто-то из-за этого использует старую версию 6.6.7 и говорит чтобы всё вернули на место, новые пользователи говорят уберите лишние даты - совершенно не разобраться. Причем не только на форуме - нам пишут на почту, звонят и говорят при личных встречах. Причем не только из России, но и другие страны, например можете почитать что пишут здесь http://www.todoforum.com/
По этому проблема, как говорится на лицо

Пляска, я так понимаю, идет вокруг календаря.

Именно так.

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

[biblioman]

Как минимум не согласен с необходимостью заново редактировать несколько сотен задач разной важности и назначать всем сроки.

Во первых - если всё устраивает в текущей работе то не нужно обновляться на новую версию, этого никто не требует.

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

[NA]

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

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

[zitz]

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

Основное - это сложность установки и работы с такого видами дат. У большинства задач вся работа с датами укладывается в следующее - "это я буду делать во вторник".
Второе - в календаре всё равно не посмотреть это время.
Рассмотрим длинную задачу с понедельника по пятницу. Зачем у понедельника время начала? Разве что зафиксировать "дату создания" так? Время в пятнице - это дедлайн.
Опять же нужно брать реальные задачи и смотреть как это сейчас применяется на практике, а не фантазировать.
Из приведенных выше "фантазий" - "Клиенту сказали подойти послезавтра в 15-00" - это отдельная подзадача встреча с клиентом и сдача проекта, и гораздо удобнее сделать это именно так, а не "Заказ с 1 февраля, по 3 февраля 15-00"

Скажем, "Срок" на "Дата оповещения". Смыслово будет разделено, и останется нынешняя гибкость.

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

[NA]

Насчет большинства и отдельной задачи "Встреча", "Сдача" согласен полностью.

А в терминологии программы тогда и получим естественную миграцию:
"Даты начала и завершения" -> "Срок"
"Срок" -> "Дата оповещения"

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

[biblioman]

Скажем, "Срок" на "Дата оповещения". Смыслово будет разделено, и останется нынешняя гибкость.

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

Хотя ответов на свои вопросы (см. выше) не получаю, дискуссия становится все увлекательнее.

Особенно интересно: "терминология программы" хоть как-то соотносится с терминологией "предметной области" (т.е. реальности--планирования, тайм-менеджмента, русского языка)? Уже спрашивал, но, хорошо, спрошу еще раз: можно ли узнать определение термина "срок" в рамках "терминологии LT"?

По словарю Ожегова:
СРОК, -а (-у), муж.
1. Определённый промежуток времени. На короткий с. По истечении срока. В установленные сроки. Обмундирование первого срока службы (носится первый срок, установленный для пользования).
2. Момент наступления, исполнения чего-н. Пропустить с. платежа. Представить работу в с.

А в LT? Все-таки deadline, время сдачи результата (и тогда, мне кажется, нет вариантов: "момент")? Или период работы, выполнения задачи (т.е некий промежуток, маркируемый как busy)? Но тогда что такое "длительность"? Неужели это праздный вопрос?! По сути, предполагается, что функционал "длительность" (нынешнее время начала и окончания работы над задачей) будет реализован через группу атрибутов "срок"--а хорошо ли и правильно ли так насиловать русский язык при переводе его в "терминологию программы"?

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

[bad1dab]

Сегодняшний функционал сроков меня в общем-то устраивает.

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

[Alexxa]

Новый срок будет иметь:  
- Дата начала
- и__: время в дне, например с 10:00 по 11:00

Можно поставить срок у задачи, например, 8 февраля 2010 года - тогда она отобразится в календаре вверху в области "на весь день" 8-ого февраля.

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

Убрал из цитаты все лишнее. Оставил только то, что не могу полностью понять (сорри, если отвечали ранее и я пропустил ответ).

Логика понравилась, и, кажется именно так и следовало бы реализовать сроки изначально (не забыв предварительно обсудить, как сейчас ). Попробовал "прикинуть" разные модели ТМ, пока не нашел изьянов для простых подходов. Любители наметить 1-5 сроков: "дата обдумывания","дата начала","дата реализации","редлайн","дедлайн","хренлайн" и проч. - отправляются совершенствовать свои системы ТМ до простейших (и в данном случае более эффективных) моделей.

Есть только одно пожелание, которое прошу в случае доработки сроков реализовать в предложенном виде без изменений: Для задач, которые являются "многодневными" добавить возможность копировать ctrl+мышка из области "над календарем" в почасовой график.

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


Смущает почему:

Можно поставить срок у задачи, например, 8 февраля 2010 года с 10:00 по 11:00 - тогда она отобразится в календаре в почасовой шкале 8-ого февраля на своё время.

но

Нельзя установить дата начала 8 февраля в 10:00, а дату конца 10 февраля в 11:00.

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

[biblioman]

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

Основное - это сложность установки и работы с такого видами дат. У большинства задач вся работа с датами укладывается в следующее - "это я буду делать во вторник".
Второе - в календаре всё равно не посмотреть это время.
Рассмотрим длинную задачу с понедельника по пятницу. Зачем у понедельника время начала? Разве что зафиксировать "дату создания" так? Время в пятнице - это дедлайн.
Опять же нужно брать реальные задачи и смотреть как это сейчас применяется на практике, а не фантазировать.
Из приведенных выше "фантазий" - "Клиенту сказали подойти послезавтра в 15-00" - это отдельная подзадача встреча с клиентом и сдача проекта, и гораздо удобнее сделать это именно так, а не "Заказ с 1 февраля, по 3 февраля 15-00"

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

про "зафиксировать 'дату создания'"--просто ничего не понял...

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

почему время на задачу, в принципе, не может быть: "понедельник 12:00--вторник 16:00"?! ведь это корректное описание. чем оно противоречит концепции TM? надо понимать также, что если я НЕ УКАЗАЛ точного времени (а только дату), то и это тоже--данные, их можно интерпретировать, в том числе и при отображении задачи в календаре или где бы то ни было... но отображение и ввод данных--это вовсе не то же самое, что сами данные и их внутренняя структура.

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

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

может быть, мы все-таки создадим на форуме раздел "стратегии"?

[biblioman]

Есть только одно пожелание, которое прошу в случае доработки сроков реализовать в предложенном виде без изменений: Для задач, которые являются "многодневными" добавить возможность копировать ctrl+мышка из области "над календарем" в почасовой график.

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


Смущает почему:

Можно поставить срок у задачи, например, 8 февраля 2010 года с 10:00 по 11:00 - тогда она отобразится в календаре в почасовой шкале 8-ого февраля на своё время.

но

Нельзя установить дата начала 8 февраля в 10:00, а дату конца 10 февраля в 11:00.

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

Предложение по работе с Ctrl в календаре звучит роскошно. Браво!

Насчет "сложностей в формате базы"--разве в этом конкретном случае, вообще, могут возникнуть какие-то сложности с форматом или набором полей БД?..

[Doskin]

Решил вот здесь побеседовать сам с собой. Может кто присоединится?
http://www.timedriver.ru/index.php/topic,4660.0.html

[zitz]

По словарю Ожегова:
СРОК, -а (-у), муж.
1. Определённый промежуток времени. На короткий с. По истечении срока. В установленные сроки. Обмундирование первого срока службы (носится первый срок, установленный для пользования).

Вот это.

А в LT? Все-таки deadline, время сдачи результата (и тогда, мне кажется, нет вариантов: "момент")? Или период работы, выполнения задачи (т.е некий промежуток, маркируемый как busy)?

Это тот промежуток времени в который нужно заниматься задачей.

Но тогда что такое "длительность"?

"Длительность" - это длительность срока. Например задача длится с 8:00 до 10:00, соответственно у неё длительность 120 минут.

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

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

Хотя ответов на свои вопросы (см. выше) не получаю, дискуссия становится все увлекательнее.

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

Нельзя будет установить дату конца в неизвестно, а дату начала какую нибудь дату.

Убрал из цитаты все лишнее. Оставил только то, что не могу полностью понять

Имеется ввиду что больше не будет задач растянутых в бесконечность.

почему время на задачу, в принципе, не может быть: "понедельник 12:00--вторник 16:00"?! ведь это корректное описание. чем оно противоречит концепции TM?

У вас в LeaderTask есть такие задачи? Приведите пример из своей базы.
Ответ вида:
"Я веду записи вот так (тут задача с подзадачами из вашей базы), в новой версии я так не смогу, потому что... и в итоге потеряю то-то..."
Концепции ТМ ничего не противоречит записывать всю информацию в блокноте текстом в наименовании самой задачи, это совершенно не значит что из LeaderTask'a нужно делать теперь текстовый редактор.
Поля должны быть наполнены функционалом, в данном случае функционально сроки связаны с:
- фильтрацией
- просроченными задачами
- столбцами срок и до срока
- календарём
- повторами
- напоминаниями
Вопрос - если время конца многодневной задачи ни на что не влияет, то почему бы тогда не занести его в наименование или сделать подзадачу которую видно в календаре, вместо того чтобы усложнять жизнь пользователям которым это вообще не нужно, ради двух задач из 1000?
Сложность БД или реализации тут не причем. Очень легко сделать супер-пупер сложную программу в которой фиг кто разберется, пятьсот опций, куча параметров, куча кнопок, галочек - зато какая гибкость! Еще давайте у задачи добавим чтобы можно было сделать кучу родителей у задачи, вот будет здорово! Кому нужна такая гибкость?