Хабрахабр / Комментарии к посту «Способ организации проектных директорий и файлов» в блоге «Управление проектами»

14.01.2010 17:36:09 safright

safright — Thu, 14 Jan 2010 17:36:09 GMT

Всегда пожалуйста.

Сейчас я, в общем, и не преследую цели «пересадить» всех на онтологии и интеллектуальное ПО. Скорее есть потребность создать некий «информационный шум», рекламу технологии — чтобы когда инструментальные средства появились (а это произойдет весьма скоро — базовые технологии уже есть, ПО из смежных областей так же появляются, так что дело за командой, которая сможет это реализовать и широко заявить об успехе) — достаточное количество разработчиков уже было в курсе, что есть такая штука и как ей можно воспользоваться.

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

14.01.2010 14:26:29 pcmaniac

pcmaniac — Thu, 14 Jan 2010 14:26:29 GMT

После того, как в одной организации регулярно приходилось определять какой документ является актуальным: New, New2, Final или Reviewed, ваш вариант мне кажется очень удобным)

14.01.2010 07:42:47 creadone

creadone — Thu, 14 Jan 2010 07:42:47 GMT

Спасибо за развернутое описание. Вот Вы и ответили на вопрос «почему нет».

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

13.01.2010 22:50:26 creadone

creadone — Wed, 13 Jan 2010 22:50:26 GMT

Нотариально заверить не успел.

А теперь расскажите почему схема ограниченная, запутанная и вредная?

13.01.2010 17:37:06 podluzny

podluzny — Wed, 13 Jan 2010 17:37:06 GMT

Ограниченная, запутанная система классификации документов. Я бы даже добавил — вредная.
Может я конечно ошибаюсь, но очень бы хотелось увидеть скриншот папки, где такие документы лежат.

13.01.2010 17:09:55 safright

safright — Wed, 13 Jan 2010 17:09:55 GMT

не, описание предметной области, в 90% случаев, не представляет большой проблемы. Более того, удачная онтология во многом повторяет термины, используемые людьми для работы в предметной области. То есть если ты знаешь свою работу — значит ты знаешь ее онтологию.

Сейчас сложностей вижу 3:
1. нет правильных инструментальных средств для внедрения онтологий в проекты. Есть замечательные «обычные» IDE, есть неплохие редакторы онтологий — но нет инструментов, которые бы объединяли их качества;
2. нет хороших метамоделей (они ж онтологии верхнего уровня — наиболее абстрактные модели, на основе которых можно строить более детальные прикладные онтологии) — идеи классов и объектов, в свое время, совершили неплохую революцию, но сейчас, ИМХО, это все более превращается в балласт (не верите? Тогда скажите, в скольки проектах вам приходилось использовать все диаграммы UML 2.0)
3. самое главное — пока мало людей, которые понимали бы неизбежность этого пути. То есть вот так вот фатально — нету больше альтернатив, а которые есть — все так или иначе сводятся к онтологиям. В свое время, ООП сделали психологи. Сейчас концепцию программирования сделают философы.

13.01.2010 16:59:39 safright

safright — Wed, 13 Jan 2010 16:59:39 GMT

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

13.01.2010 16:55:45 ded_Sergei

ded_Sergei — Wed, 13 Jan 2010 16:55:45 GMT

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

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

В свое время активно экспериментировали с wiki Confluence. Было описание проекта в wiki формате, к нему прикладывались файлы проекта через webdav. Активно использовалось тегирование для описание самого проекта.

13.01.2010 16:50:25 safright

safright — Wed, 13 Jan 2010 16:50:25 GMT

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

Предполагаемый профит от внедрения системы на основе знаний:
1. возможность _формально_ описать действия пользователей, операторов ТП, и вообще всех, кто имеет отношение к ситуации;
2. из (1) следует, что можно так же модернизировать ПО обмена сообщениями — заменив иногда довольно толстые и запутанные инструкции по заполнению тикетов (случай для примера: у провайдера есть программа размещения wi-fi точек у желающих, в том числе физ.лиц. В случае проблем на точке в тикет приходится включать массу инфы о контактах держателя и о самой точке — и это кроме инфы о проблеме абонента). Прямой профит от этого: сокращение действий операторов и большинства персонала по обработке тикетов, возможность напрямую связать действия с информацией из тикета (опять же пример, немного абстрактный — при обнаружении невыдачи IP проводятся некоторые рутинные действия — которые можно автоматизировать).
3. мелочь, а приятно — в ряде случаев, поверх собственно онтологии можно повесить экспертную систему. Это и подсказка ТП в сложных случаях, и возможность удаленной помощи абонентам (нет ведь ничего сложного создать облегченную версию базы знаний по самым частым случаям и раздавать их при подключении и просто желающим).

Я вообще поклонник идеи онтологий в «малых формах», наподобие системы тикетов или ежедневников — где внедрение интеллектуальных систем сдерживается не сложностью предметной области (хотя большая сложность скорее стимулирует использование онтологий — для примера можно поглядеть на современные САПР), а лишь отсутствием подходящих инструментов и небольшой известностью самой концепции.

13.01.2010 16:13:55 creadone

creadone — Wed, 13 Jan 2010 16:13:55 GMT

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

Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.

13.01.2010 15:38:13 safright

safright — Wed, 13 Jan 2010 15:38:13 GMT

В русской википедии, как часто бывает, наплыв «умников», которым лишь бы свою крутизну показать, а насколько понятно непосвященному человеку — начхать…

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

WinFS умерла не родившись — ну и фиг с ней. Да, там были элементы системы знаний. Впрочем, зная логику и манеру ведения бизнеса M$ можно сказать, что была бы она предельно казуальной и кривоватой… например, поддерживала бы только «предустановленную» онтологию — что не то чтобы плохо, но и хорошего в том мало.

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

13.01.2010 14:51:31 belnetmon

belnetmon — Wed, 13 Jan 2010 14:51:31 GMT

+сто
И в именах точки использовать совершенно ненужно

13.01.2010 12:31:31 ded_Sergei

ded_Sergei — Wed, 13 Jan 2010 12:31:31 GMT

«Онтологии форева»… это что имеется ввиду? Я ради интереса решил освежить свои знания статейкой в википедии.

Формально онтология определяется как O = , где
* X — конечное множество понятий предметной области,
* R — конечное множество отношений между понятиями,
* F — конечное множество функций интерпретации.

Не совсем понял как это будет выглядеть реализация на практике хранения кучи проектных документов (WinFS рулит?? Wiki подобная система с кучей тегов?) Или это было философское отступление, не все же про работу говорить?

13.01.2010 11:48:55 creadone

creadone — Wed, 13 Jan 2010 11:48:55 GMT

Это клуб для общения дизайнеров интерфейсов и юзабилити-специалистов. Пока что это обычное комьюнити как ru_ucd, только закрытое. Членство модерирует создатель.

13.01.2010 11:40:39 phillennium

phillennium — Wed, 13 Jan 2010 11:40:39 GMT

Извините, дурацкий вопрос: а что такое Useful Club?

13.01.2010 08:39:13 ZotovSergey

ZotovSergey — Wed, 13 Jan 2010 08:39:13 GMT

Для информации, как мы действуем в конструкторском бюро.

Длинные названия, да еще фиксирующие стадии, — не даем.

1. Папка ABC — по заказчику
2. Следующий уровень — папка var-2009-12-23 (как пример) — для отсечения состояния логичного этапа (периодичность и несколко дней и несколько недель — определяется важностью изменений).
3. Во вложенных в var-… папках — разнородная информация, поэтому в обозначениях системы нет (это и папки по поставщикам и папки по узлам).

При таком подходе:
1. минус — в разных папках var-… могут лежать одинаковые файлы (после сдачи проекта — часть папок var-… удаляем, оставляя с наиболее интересными решениями).
2. плюс — каждая такая папка может послужить заготовкой для другого проекта.

13.01.2010 08:38:45 garex

garex — Wed, 13 Jan 2010 08:38:45 GMT

Что сильно напоминает ГОСТ, тока там названия сущностей другие.

Если с рос. заказчиками работать, то как тогда лучше сделать?

По-мойму если в момент Presale выслать документ с таким шифром, но русским, то впечатление будет солидное.

13.01.2010 07:45:53 spxnezzar

spxnezzar — Wed, 13 Jan 2010 07:45:53 GMT

А мы еще дату добавляли в конце, причем дата в обратном порядке (ГГ ММ ДД), для того что бы при сортировке хронология сохранялась. Или же наоборот дату в начало, если в паке документы одного типа, но с разными названиями.

12.01.2010 06:57:32 camelos

camelos — Tue, 12 Jan 2010 06:57:32 GMT

Мажорная версия
Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику.
А вот это очень интересно. У нас несколько иная схема: Мажор-Минор-Билд. Но Ваша идея инкрементирования мажора очень интересна. Спасибо!

12.01.2010 04:14:05 creadone

creadone — Tue, 12 Jan 2010 04:14:05 GMT

Точно! Как колбаса и велосипедная рама.

Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)

12.01.2010 03:23:26 safright

safright — Tue, 12 Jan 2010 03:23:26 GMT

папки маздай, онтологии форева!

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

12.01.2010 02:03:52 dug

dug — Tue, 12 Jan 2010 02:03:52 GMT

А шифр очень похож на ваш. И Шифр и название файла печатаются на каждом листе документа, так что найти электронную версию не составляет труда.

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

12.01.2010 02:00:42 dug

dug — Tue, 12 Jan 2010 02:00:42 GMT

Мы разделяем шифр документа и название файла. Название файла имеет вид вроде такого

код. наименование документа (версия).doc