Просмотр сообщений

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


Сообщения - Solaris

Страницы: [1] 2 3 4 5 6 ... 15
1
Новости / Re: LeaderTask 6.9.3.1
« : 06 Августа 2010, 00:32:05 »
Вы можете не использовать почтовый клиент, если считаете что у вас в нем нет необходимости. Если он вам мешает, можете просто крыть его из навигатора.

В самом деле, кройте из навигатора, нечего тут (на форуме) флудить   :P
Оговорки прямо-таки по дедушке Фрейду  :'

2
Новости / Re: LeaderTask 6.8.9.6
« : 21 Апреля 2010, 19:59:43 »
А есть хотя бы примерные сроки выхода версии 7.х?

Извините, я что-то пропустил? Версия 7.х означает определенный прорыв в развитии?
Мне просто кажется, что не в номерах дело, а в функционале. Изменение нумерации - вещь сугубо субъективная. Например, как заявлено в анонсе, в данной версии просто добавлена автоматическая проверка обновлений. Извините, конечно, это удобно и все такое, но функционал никак от этого не изменился. Это значит, что программа будет жрать трафик по своему усмотрению, не дожидаясь команды пользователя. Так что версия 7.х - это всего лишь магия цифр. Психологический барьер. Кому-то после него может стать комфортнее. А мне главное, чтобы все работало. Поэтому вопрос такой: когда ждать Гантта?

3
Новости / Re: LeaderTask 6.8.8
« : 12 Марта 2010, 18:44:09 »
А вот и ответ всем нам, кто кричал: "Дайте такую-то функцию!"
Сам, конечно, написать ничего не смогу, но надеюсь на более головатых коллег. Теперь грань между "мы" и "вы" несколько поистерлась. Ура, товарищи!

4
Плюс Малышу.

Думаю, нелишним будет поле "бюджет". Причем бюджет группы задач (например, проекта) может рассчитываться как бюджет совокупности задач. Или задаваться принудительно, и тогда через дробь будет показана разница между бюджетом проекта и совокупности задач. По факту можно будет считать статистику (если задачам присваивать бюджет при создании, а бюджет проекта пересчитать ретроспективно)

Но смысл бюджета можно было бы оставить открытым. Для кого-то - это деньги *bb*, для кого-то - время *ba*.
Просто значение должно быть числовым, а значение числа пусть каждый определяет для себя сам.

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

5
Тестирование / Re: Сроки
« : 10 Февраля 2010, 03:16:39 »
Здесь уже прозвучало, но, по-моему, как-то невнятно: а как при такой реформе быть с проектами (точнее, предстоящей их реформой)? Ведь в перспективе их планируется приравнять к задачам. Раз - и задача становится проектом. Два - и проект становится задачей.
Это решение еще не принято, оно прорабатывается. Пока проекты меняться не будут, и  данные изменения их не затронут. Нужно всё делать по порядку.

   Конечно, СЕЙЧАС не затронут. А как ПОТОМ?
   Получается, как про Ежи и Петруччо: Ежи пошел на север, а Петруччо - на запад. Там они и встретились - ПРЯМО в ЦЕНТРЕ...
   Каково будет потом, когда начнется (или не начнется?) реформирование проектов? Что мы будем потом делать? Снова привыкать к новым срокам? Снова терять данные, ручками набивать?
   Не лучше проверять задачу на экологичность - в том числе и по отношению к другим запланированным изменениям?
   Складывается представление, что нет целостного представления о будущем программы.
   Знаете, ремонт - это состояние души, именно поэтомй его как правило никто не может закончить. Я ремонт в квартире закончил только потому, что сначала не пожалел 150 баксов и заказал очень простенький дизайн. И я всегда знал, какой результат хочу получить в конце. Даже если что-то со временем и переставало отвечать новым реалиям, то, по крайней мере, я не начинал все крушить, потому что не подумал, куда ставить стиралку и уже воткнул кабинку. Сразу описал, все что хочу иметь в квартире - и вуаля. Кондиционера тогда не хотел - вот и некуда его ставить. Но ради этого стены ломать снова не стану.
   Кстати, я погорячился, когда сказал, что ремонт закончил. Нет, он уже идет около четырех лет, но глобальное все было сделано в первые месяцы, а теперь просто постепенно подбирается то диван, то светильник, то какая-нибудь мебель заказывается. Но все - исходя из первоначальных представлений. Детей, правда, за это время стало аж двое, на них мы обстановку не рассчитывали, но это уже детали...
   Короче, на своем примере демонстрирую давно избитую истину - начинать надо с предельно четкого представления результата. Визуализировать почти до осязательных ощущений. И только потом начинать крушить и строить заново.
Иначе ремонт будет вечным. То печка не поместиться, то спать придется стоя.

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


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

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

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

Радует, что "в большинстве". А вот у нас выборы прошли, у Януковича тоже вроде как большинство. На 4% больше, чем у Юльки.

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

6
Тестирование / Re: Сроки
« : 08 Февраля 2010, 01:11:26 »
Здесь уже прозвучало, но, по-моему, как-то невнятно: а как при такой реформе быть с проектами (точнее, предстоящей их реформой)? Ведь в перспективе их планируется приравнять к задачам. Раз - и задача становится проектом. Два - и проект становится задачей. Пляска, я так понимаю, идет вокруг календаря.

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

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

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

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

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

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


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

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

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

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

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

10
Так же проблему решила бы возможность наложения фильтров с опцией "скрыть по фильтру", о которой еще в 1917 говорил Владимир Ильич, если я ничего не путаю.  :D
Плюс в репу. Такой фильтр очень нужен. Фактически, это возвращение тех же кнопок "скрыть/показать задачи, заметки, ссылки" (если помните  *bt* ), но на новом эволюционном этапе развития.

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

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

Цитировать
Существует острейшая необходимость составить глоссарий проекта! И при постановке задач, обсуждении функциональностей и т.д. и т.п.  - пользоваться только терминами ГЛОССАРИЯ. (иначе будет путинаца и непонимание друг друга Улыбающийся). Кто возьмется его составить и потом поддерживать в актуальном состоянии?

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

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

13
Знаете, как в том анекдоте про поручика Ржевского "музыкой навеяло"?
Что мне навеяло этим постом, можете взглянуть здесь.
http://forum.leadertask.ru/index.php/topic,3582.msg29090.html#msg29090

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Страницы: [1] 2 3 4 5 6 ... 15