Обсуждение

А еще надо будет на Орглане написать процесс внедрения такой системы в организации и процесс администрирования организации администратором с помощью этой системы.

Программу внедрения, ибо уж точно не процесс. А насчет администрирования -- это можно уже подумать, есть ли тут процесс, или "кубарем" ;) Но я бы не столько к самоописанию сейчас стремился (хотя это обязательно, конечно), сколько к типовым случаям с agile-GTD-поручениями, классическими процессами из заводских ERP, и проектами типа строек.

Про меня не забывай. Мы вполне себе целевой клиент, хоть нас и не 10000 человек. Достаточно большой класс клиентов - небольшие компании, входящие в стадию быстрого роста и формализации/структурирования/упорядочивания деятельности. Мы и сами такие, и клиентов таких ищем, и внедряем им то, чем сами пользуемся.

ЗЫ. А насчет процесса администрирования - кубарем / не кубарем - я уже писал про это: http://meatreach.livejournal.com/132010.html Есть процесс, есть. :)

Довольно сложная система получается. Не прихолят в голову аналоги (и базы, и application, и 3D virtual worlds, ontology, simulation, CSCW и т.д - все в одном) Насколько сложность системы соответствует задаче?

Почему сложная система? Как раз этот постинг четко делит всю систему на как минимум три слоя. В одном слое мы разговариваем только про 3D (это синхронная коллаборация, и много меньше -- CSCW с очень туманной областью применения). В другом слое мы разговариваем про application, интерфейсы, внедрение софта и все то, что обычно связывается с IT. В третьем слое мы разговариваем про онтологию, учет, самые разные модели, организационные философии и прочая и прочая (база и средства задания ее схемы используются тут как инструмент, чтобы эти разговоры не подвисали в воздухе. Просто "доска, мел, тряпка"). Система становится сразу обозримой, хотя дьявол наверняка будет кусать через границы этих искуственных слоев. Но на то и задача архитектора, чтобы он кусался менее больно. Это все оказывается не так сложно, если хорошо размышлять. Мне кажется, объем кода будет подозрительно маленьким для подобной системы. Вот консалтинг по внедрению будет немаленьким, так он в любом случае тяжел и сложен. Главные проблемы будут в технологизации образовательной практики по приобретению новых организационных компетенций (включая умение работать с новым софтом как их небольшую часть) сотрудниками и администраторами. Вот попробуйте объяснить нынешним финансистам throughput accounting, даже если в кармане у вас есть шикарный опен сорс софт, его поддерживающий...

Ну, тогда через некоторое (все более и более обозримое) время будем на вас тренироваться :)

На ум сразу приходит Lotus Notes, но это такой монстр, умеет много чего, но обычным пользователям не нравится(как показывает практика).

Хороший пример. Но замечу, что именно на Lotus Notes удавалось внедрять большие безбумажные документообороты. На других системах масштабные проекты внедрения имеют много меньший успех (т.е. внедряются, но затем не используются ;) Но Lotus Notes -- это уже немного прошлое поколение. Сейчас можно то же самое делать по-другому, попроще. К тому же на каждого пользователя совершенно незачем вываливать все возможности системы. Не смотрите же вы по телевизору 100 программ одновременно. Просто перещелкиваете каналы.

Про: "Урезанность по возможностям -- это не столько упрек, сколько сожаление: добавка произвольного числа классификаторов/иерархий позволяет произвольным образом наращивать выразительность системы, но это в TrackStudio, похоже, не реализовано даже на уровне движка (я рад был бы ошибиться)." В самом деле, иерархия одна, т.е. каждая задача имеет только один parent task. Есть workaround - из корневой задачи могут начинаться несколько иерархий классификаторов (Customers, Products), конкретные задачи могут лежать где-нибудь отдельно и за счет кастом-полей типа Task привязываться к узлам этих классификаторов. Узлы потом про эти привязки будут помнить, а пользователь сможет быстро найти задачи, относящиеся к данному клиенту или продукту. Минусы такого подхода: 1) Связи не "понимают" иерархию, т.е. если задачу привязать к Product A, то просматривая подзадачи Product A нельзя будет найти задачи, которые ссылаются именно на Product A. Решается не очень сложным скриптом, который перебирает вышестоящие задачи и собирает их ссылки. 2) Список задач, ссылающихся на данную - это просто список, без возможности фильтрации или произвольной сортировки. Т.е. проблема теоретически решается, но для большого количества задач пользоваться этим будет неудобно.

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

Да, конечно -- интерфейсы между слоями. Правильно.

Нет, у вас еще есть иерархия users -- они ведь тоже входят в онтологию! А еще есть workflow (плоский их список, или тоже иерархия)? Если покопаться, то и еще много можно найти -- я про все такие сущности, а не только про "главную". И вопрос в сторону: с JIRA у вас сравнение есть. А вот с motiw?

Для workflow (и остальных объектов) у нас и не иерархия, и не плоский список :-) Workflow не имеют своей иерархии (например, нельзя определить workflow B как workflow A + еще 2 состояния и 3 перехода), но они привязываются к ирерархии задач. Если workflow было определено для корневой задачи - оно будет доступно во всем приложении, если для задачи X - будет доступно только для этой задачи и подзадач. Аналогично с категориями задач, правилами доступа, отчетами, фильтрами, правилами подписки по e-mail - все это привязывается к какой-либо задаче, действует на подзадачи или доступно в них и невидимо для задач в других ветках. Есть еще одна группа объектов - группы пользователей, фильтры для пользователей, скрипты, шаблоны e-mail, - они привязываются к иерархии пользователей. Т.е. если группа X объявлена для пользователя john smith, то использовать ее можно только для подчиненных этого john smith, для его "братьев" она будет недоступна. Т.е. глобального списка workflow, категорий или чего-то еще нет - все кроме задачи и пользователя привязано к какому-то уровню иерархии задач или пользователей и доступно только для подчиненных пользователей или подзадач. Это в свое время было сделано для "виртуализации" issue tracking-а - в рамках одной системы можно завести несколько непересекающихся конфигураций, для каждой из них назначить managed администратора, который может настроить все для своей группы и проекта, но ничего больше не увидит. Причем это может быть рекурсивный процесс - этот managed администратор может создать еще одного managed administrator-а, выделить ему свою песочницу и дать полный доступ к админским функциям. В мире операционных систем наиболее близкая аналогия - это ОС, на которой запущена vmware, на которой запущена vmware,... Раньше у нас была своя иерархия для групп пользователей, но у нас и пользователей от этого крыша ехала и в 3.5.4 (кажется) мы эту фичу вырезали. По поводу motiw - толком не смотрели, демку я скачивал, доки читал, но ключик они по e-mail не прислали и я забил. А что - правда интересная система ?