Реформы в LeaderTask (или идеальный органайзер-2).

[Solaris]

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

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

[MichaelKiev]

Можно для обсуждения предложить следующие определения? :

Сущности (или объекты)
1) Задачи
2) Контакты
3) Заметки
4) Файлы

Атрибуты объектов
Свойства объектов - задаются в "категориях"
Количество свойств должно быть неограничено и определяться пользователем.
каждое свойство (атрибут) - отдельная ветка "дерева" категорий
По любому атрибуту должна быть возможность (а) отбирать, (б) сортировать и (в) группировать объекты
(ИМХО, Проекты - специальный атрибут задач, позволяющий их группировать)
Должна быть возможность присваивать объекту неограниченной количество категорий с
помощью добавляемых и настравиваемых полей.

Связи между объектами
Должна быть возможность связать между собой два любых объекта
(контакт с заметкой, файл с задачей, задачу с задачей и т.д.)
Причем для задач должна быть возможность нескольких видов связей
(а) конец одной задачи с началом другой (с задержкой и N дней, где N может быть равно или не равно 0)
(б) начало одной задачи с началом другой (с задержкой и N дней, где N может быть равно или не равно 0)
(в) конец одной задачи с концом другой (с задержкой и N дней, где N может быть равно или не равно 0)
(тогда и MS Project будет не нужен :-) )
Было бы очень здорово, если бы можно было бы связывать между собой задачи, даже если они принадлежат к разным проектам!

Визуализации
Правила представления информации на экране. (То, что в Outlook называется представлениями) определяющие
- типы визуализаций: таблица, диаграмма ганта и т.д. и т.п.б + форматы представления объектов и их атрибутов
- отбор (фильтры)
- группировку
- сортировку


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

[Doskin]

Еще, все таки «атрибут» или «свойство»? Вы сразу используете оба слова. Надо оставить одно. Мне лично все равно, какое, лишь бы мы все потом использовали только его.

В Навигаторе , ИМХО, должны быть следующие закладки
1. Задачи (задачи по проектам можно получить с помощью группировки по этому атрибуту)
2. Контакты
3. Заметки
4. Категории

Вот это не понял. Сейчас в «Навигаторе» показываются проекты, категории, контакты, периоды (и сотрудники в сетевой). Как это — сделать для задач в «Навигаторе» отдельную закладку? Что такое закладка?

«Навигатор» — окно для отображения списка атрибутов. Для задач существует свое окно в котором есть две визуализации — дерево задач и календарь.

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

Панелью называть полоску с различными командами и инструментами. Например, как сейчас «панель фильтров», где мы настраиваем фильтр. Или «панель задач», где собраны инструменты и команды для задач (создать, связи).

Тогда фраза «Выберите на панели задач в окне задач...» будет восприниматься легче, чем «Выберите на панели инструментов задачи на панели задачи...».

Еще проблема: у нас сейчас два окна для отображения атрибутов (свойств) задачи. Первое — в виде модального окна. Второе — в виде четвертого окна, которое мы называем то панелью свойств, то окно заметки, или окно комментария, или панель заметки, или панель комментария. Надо дать им четкое название. Как их называть, чтобы различать в речи?

[Do_zent]

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

В моем понимании "проект" - это и есть цель.

[Leonid]

a_d
Я понял, что это АРХИСложно. Воспринял Ваш пост спокойно и с достоинством .  Написал, скорее , чтобы не забыли о важном функционале. Я согласен ждать реализации этой надстройки после реализации революции. Хочется уверенности, что и этот этап наступит.

[Leonid]

ПО "МОЕМУ" пониманию сущностей.
Я считаю, что не только действия должны ими быть. ТО, что для, начальника действие в конце проекта- заставить руководителя филиала добиться повышения прибыли в период кризиса в 500 раз (а не в 678), то, для руководителя филиала- ЦЕЛЬ. И так происходит по всей цепочке. От побуждения верховного демиурга до элементарного движения рукой маленького подземного червячка (ну и что, что с руками...). Поэтому я поднимал ранее вопрос о целях, задачах и т.п.
Само по себе это лишь личное представление. Но, в корпоративных планах есть и основные направления, и цели, и задачи, и проекты, их реализующие. И, все ниже стоящее, может выполнять несколько вышестоящих. Поэтому, для меня эти два вопроса взаимосвязаны: уровни руппировки и множественное подчинение.
Уровни группировки дел и множественное подчинение ВВЕРХ. - как есть в проектах сейчас: один проект может выполняться разными цепочками дел, и одна цепочка может выполнять несколько проектов. ЗАМЕЧАТЕЛЬНО.
НО: Цели (как бы не тщились доказать, что место цели только внутри проекта) это ориентиры к которым проект движется. И несколько проектов могут служить реализации одной  цели. И это можно сделть штатным деревом. И ЦЕЛЬ будет вне проекта, НАД ним.
НО2: ОДИН проект, и даже один ШАГ может реализовать несколько целей. Например покупка МФУ может решить и проблему сканирования картинок их журналов, и проблему экономии места на рабочем столе, и проблему создания электронного архива документов. Можно для этих целей искусственно создать надцель. НО это будет ХИМЕРА. Такое ЧУДОВИЩЕ ФРАНКЕНШТЕЙНА долго не проживет.
Как это реализовать? Создавать надразделы в произвольном количестве Размещая их все выше и выше (задачи/проекты/ задачи/ цели/желания...) ИЛИ  придумать множественное подчинение в обе стороны. НО- это как предлагает "a_d " после революции.
 

Главное сейчас, что эти объекты взаимно обратимы в разных условиях. Поэтому проект и цель, к примеру, НЕЛЬЗЯ СЧИТАТЬ ПРИЗНАКОМ. Ваша семья не признак. Принадлежность к семье может быть признаком. Для Рода, семья такая-же сущность и действующая единица как и человек. Иначе мы вообще все дерево задач будем решать через признаки. Принадлежность задачи А к задаче В это признак задачи А. Значит задача В это ПРИЗНАК.
 А характеристики - это нечто совсем другое. Причем дерево характеристик обещает стать не менее сложным и проблемным, чем дерево сущностей. Отсюда и до X-in-1 объектов недалеко... Сумбурно...Задавайте вопросы

[Solaris]

...Главное сейчас, что эти объекты взаимно обратимы в разных условиях. Поэтому проект и цель, к примеру, НЕЛЬЗЯ СЧИТАТЬ ПРИЗНАКОМ. Ваша семья не признак. Принадлежность к семье может быть признаком. Для Рода, семья такая-же сущность и действующая единица как и человек. Иначе мы вообще все дерево задач будем решать через признаки. Принадлежность задачи А к задаче В это признак задачи А. Значит задача В это ПРИЗНАК.
 А характеристики - это нечто совсем другое. Причем дерево характеристик обещает стать не менее сложным и проблемным, чем дерево сущностей. Отсюда и до X-in-1 объектов недалеко... Сумбурно...Задавайте вопросы

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

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

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

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

То есть, дело в разном уровне абстракции.

Интересно, как разработчики смогут это все реализовать?

Leonid, спрашивайте еще!

Картинка - на память.  Авторство - не мое. По требованию автора могу удалить. На компе валяется давно, сейчас в нете найти не смог, раскопал свой архив. Уж больно тема про "семью" потешила...

[Leonid]

ДА,ДА,ДА!!!.

И, про червячков с Боссами и древовидную структуру очень верно.

И очень интересно сказано про связи. Как раз развитие связей в самых разных вариантах будет (ИМХО) делом первостепенной важности после революции.
Это именно позволит малой  кровью реализовать и множественное родительство  .

[MichaelKiev]

А где можно увидеть все идеи "революции" кратко.. собранные вместе, а не разбросанные по десяткам топиков? :-)

[Alexxa]

А где можно увидеть все идеи "революции" кратко.. собранные вместе, а не разбросанные по десяткам топиков? :-)

Здесь. В первых 1-2 страницах.

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

[notactic]

Есть интересные мысли.. но огромная просьба революцию проводить эволюционно 

[Solaris]

Сначала написал это в другом разделе, но подумал, что здесь это уместнее...

У меня есть задача, которая начинается в 23:30 и заканчивается в 00:30. Программа наотрез отказывается создавать такую задачу. Как же все таки ее создать?
PS: дату в таком виде не дает ввести. В первом окошке дает, а во втором не дает  Т.е. ввожу во втором и он в первом обнуляет до 00:00.

Вот оно! То о чем так долго спорили!
Даже меня убедили. Частично.
И вот в чем: дата начала и дата окончания нужны. Но не совсем так, как это представляется.
Задача не имеет длительности. Длительность имеет событие. Событие - это процесс работы над задачей. Процесс работы над задачей можно планировать с утра и до обеда. Саму задачу нельзя запланировать на такой же протяженный отрезок.

Поскольку разработчики сами в явной форме нигде не выразили, чем же они руководствовались, когда убрали дату начала и дату окончания и оставили просто срок, вероятно, они и сами до конца не смогли для себя это сформулировать.
Но вот этот пример все ставит на свои места.
Задача - это что-то вроде поручения подчиненному: сделать к такому-то числу. Нормальный руководитель не лезет глубже. Что сделать и к какому сроку. Все. Когда начать, когда сделать перерыв...

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

А теперь внимание! Легкая шизофрения: мы начальник и мы подчиненный попеременно!
Итак, мы - начальник. Со стороны начальника: нужны ли дата начала или дата окончания задачи? Нужна ли длительность? Отвечаю: длительность нужна, чтобы определять общую загрузку подчиненных и распределять задачи между ними равномерно. Или видеть, насколько больше нагружены "рабочие лошадки", чем будущие генералы. А вот расписание работы начальника мало интересует.
Поэтому на стадии постановки задачи нет нужды в том, чтобы определять начало, окончание и проч.

А теперь власть над нашей личностью переходит к подчиненному, которому надлежит выполнять поставленную задачу. То есть, мы - подчиненный. И перечисленных выше параметров становится явно недостаточно. Нам нужно спланировать задачу в другой плоскости. Для этого нужна кнопка "распланировать работу над задачей" (или "создать событие" или еще что-нибудь). После этого открывается новая вкладка, где есть время начала, время окончания и другие параметры. Или галочка в чек-боксе делает активными дополнительные поля. Больше того, по-видимому, необходимо предоставить пользователю возможность назначать сколько угодно отрезков начало-окончание, разделив слона на кусочки.
И вот на основании таких кусочков уже автоматически будут генерироваться "события" - календарные отрезки. Представляется, что до того у пользователя должна быть возможность выбирать, отображать ли задачу в календаре. Тоже через чек-бокс. Поставили галочку - отображается в календаре, не поставили - не отображается. А вот события уже нужны именно в календаре. У них нет другого смысла. Они не нужны в списке задач. Там они лишние. Тут как бы все решается само, выбор пункта "распланировать работу над задачей" означает, что мы хотим "размазать" задачу по календарю.
Вопрос только в наглядности планирования задачи таким образом. Мне представляется, что для этого хорошо подходит только Гантт. Так мы можем видеть, сколько отрезков приходится на определенный день и перераспределять отрезки задачи по дням. В календаре хорошо просматривать только получившийся результат - чем мы будем заниматься в определенный день. Там уже можно и часы с минутами конкретизировать.
То есть, для календарного планирования, события, созданные из задач, но такие события не нужны для управления задачами. Проставление галочки в чек-боксе также будет создавать событие, не имеющее длительности. "Висящее" над днем событие, не привязанное ко времени дня.

Резюме: Задача и событие, созданное на основании этой задачи, - это две ипостаси одной сущности. Иными словами, это вид одной сущности в разных проекциях. Но для целей ЛТ, думаю, их следует рассматривать как отдельные сущности, сохраняющие между собой связь. Задача - это точка, местоположение которой определяется точкой. Событие - это отрезок в календаре. Задачу можно считать выполненной. Событие - оно или случилось, или нет. Его нельзя выполнить. Можно только прекратить напоминание о нем. События отображаются в одном списке, задачи - в другом. Связь задачи с породившим их событием должна сохраняться, чтобы иметь возможность переходить от одного к другому и обратно. Могут быть задачи, не связанные с событиями, и события, не имеющие родительской задачи. Они, скорее, будут просто привязаны к проекту. Хотя, насчет списков, может я и не прав. Список сущностей может быть один, просто по революционной логике выборку можно делать по разным признакам. И если будет выбрано отображение по проектам, то получится, что задача является родительской сущностью по отношению к порожденным ею событиям. А можно эти события и отфильтровать.
Главным считаю разделить видение задачи со стороны начальника (постановщика задачи, вид сверху, точка) и со стороны подчиненного (исполнителя, вид в профиль, глубина). Психологически неправильно размещать параметры, задаваемые начальником и подчиненным рядом, на одной вкладке. Как минимум необходимо создать чек-бокс "распланировать работу над задачей" (типа "отображать в календаре"), после проставления галочки в котором появится возможность задавать все дополнительные параметры. Это как сетевая версия, и отношения начальник-подчиненный.
Интересно, заявит ли кто-то, что при постановке задачи в сетевой версии также крайне необходимы параметры типа "дата начала/дата окончания"? Если нет, то изложенная логика является правильной, а те, кто настаивает на заполнении соответствующих свойств задачи, не разделяют эти два способа видения задачи.

P.S. Разработчики проявили некоторую непоследовательность в версии 6.7.х, указав в поле "срок" только одну дату, но разрешив указывать время начала и время окончания. Если быть последовательными, то срок - это точка, а не отрезок. А при текущем способе назначения срока получается, что это все-таки отрезок - но куцый. Всегда не выходящий за пределы этих суток. А это мне кажется рудиментом. Вопрос, поставленный masterlex мне кажется, вполне правильным, а вот ответ - иррациональным. Как я указал в начале поста, разработчики сами плоха представляют, что значит срок. Может, то, что я написал поможет нам всем продвинуться к революции?
Вывод - в версии 6.7.х поле указания часов нужно привести в соответствие с логикой вкладки, оставив только одно окошко для указания часов, минут и секунд. Однако зачем такая точность? (я про секунды)

[Leonid]

Очень интересно. И, может быть  правильно. НО, надо свыкнуться с таким видением. тем не менее +1.

[Leonid]

Насчет отображения в календаре. Была еще и идея отображать в ТОДО (галочку ставить). Тогда мы получим основные разделы:
1.Постановка задачи (что то вроде разделов в Ачеив Планнер и в МЛО, где первоначально все планы создаются и все задачи куда сбрасываются. "ИН" мозгового штурма )
2.ТОДО
3.ГАННТТ
4.Календарь

[MichaelKiev]

А теперь внимание! Легкая шизофрения: мы начальник и мы подчиненный попеременно!
Итак, мы - начальник. Со стороны начальника: нужны ли дата начала или дата окончания задачи? Нужна ли длительность?

Согласен практически со всем. Но в нашем мире имен и форм как всегда различия во взглядах проистекаеют большей частью из-за различия в толковании терминов
Microsoft не зря разделило Outlook (планировщик\аутлайнер) и Project (систему управления проектами).
Мы жу пытаемся объеденить вместе ".. коня и трепетную лань.." (с) - аутлайнер и управление проектами в одном софте.
Я только "за"! Но под силу ли это разработчикам?

Теперь о терминах:
Если мы пытаемся сделать из LT систему управления проектами - предлагаю использовать использовать терминологию управления проектами.
Как рекомендовали еще древние китайцы - планировать нужно с конца (и "правильные" project-менеджеры так и делают )
Возвращаясь к примеру Solaris-а:
То, что ставит начальник перед подчиненным - это цель проекта (= конечный "майлстоун"). Например: "хочу к 20.12.хххх иметь бюджет на следующий год"
Подчиненный же получив эту цель разворачивает ее от конца к началу - для того чтобы положить бюджет начальнику на стол нужно ААА,
чтобы получить ААА нужно БББ, чтобы получить БББ нужно ВВВ .. и так к начальной точке...

Итак сверим термины:
(а) то, что ставит начальник подчиненному:
      у Solaris-а -  задача.     В терминологии project-menagment - цель или конечная веха (final milestone = задача с нулевой длительностью). У вехи есть только СРОК!
(б) то, во что подчиненный разворачивает приказ начальника
      у Solaris-а - события.   В терминологии project-menagment - задачи. У задачи есть  ТРУДОЕМКОСТЬ. Длительность и сроки начала и конца задачи -  лишь производные от трудоемкости, но об этом ниже.

Согласно тому же project-management: основным свойством задачи есть не "длительность", а "трудоемкость".
различие между этими понятиями очень важно!
Допустим у задачи (группы задач)  "подготовка бюджета" трудоемкость 40 часов. Это значит, что один человек не отвлекаясь ни на что  сделает бюджет за 40 часов
(или считая, что рабочий день = 8 часов - то за 5 дней).
Если же процесс подготовки можно распараллелить и вовлечь двух человек - то длительность этой задачи будет 2,5 дня
Если же один человек сможет уделять подготовке бюджета 50% времени кадый день, то длительность задачи станет 10 дней.

Предлагаю, помятую слова одного умного монаха, - "не плодить сущности без нужды" , а использовать терминологию project-management
1) То, что ставит начальник подчиненному - ЦЕЛЬ. (=конечная веха, = final milestone). Это просто задача без длительности. с одним только сроком выполнения.
2) То. что ставит подчиненный сам себе (исходя из цели начальника) - это ЗАДАЧИ. Задачи имеют ТРУДОЕМКОСТЬ.
ДЛИТЕЛЬНОСТЬ задачи зависит от трудоемкости и производительности ресурсов.
ДЛИТЕЛЬНОСТЬ = ТРУДОЕМКОСТЬ \ ПРОИЗВОДИТЕЛЬНОСТЬ.
СРОКИ начала и окончания задачи есть производные от ее ДЛИТЕЛЬНОСТИ (мы можем рассчитать длительность а затем "таскать" задачку по диаграмме Ганта тем самым задавая даты ее начала и окончания)

Резюме:
1) Существует острейшая необходимость составить глоссарий проекта! И при постановке задач, обсуждении функциональностей и т.д. и т.п.  - пользоваться только терминами ГЛОССАРИЯ. (иначе будет путинаца и непонимание друг друга ). Кто возьмется его составить и потом поддерживать в актуальном состоянии?
2) Требования к функционалу "продвинутых пользователей" все больше и больше двигают LT от простого PIM к системе управления проектами (набодобии
MS Project, Spider, Primavera и пр.). Это конечно хорошо - но под силу ли это разработчикам? Сложность задачи по созданию PIM на порядок меньше, чем
сложность задачи по созданию полноценной системы управления проектами (чтобы косвенно это оценить - сравните стоимость хорошего PIM-а и
хорошей системы управления проектами. Думаю что разница будет отличаться даже не на порядок а на пару порядков :-))