Достаточно часто поднимается вопрос о том, кто и как называет организовывает файлы (речь идет не о системах хранения версий, а именно о способе организации файлов и директорий). Или не называет, а хранит как придется. Буквально вчера коллега в Useful Сlub задал аналогичный вопрос. Я, пожалуй, зафиксирую свой ответ и здесь, вдруг кому-то еще наш способ поможет сэкономить время.
Тут еще важно понимать вот что — это ваша внутренняя нотация, заказчику по большому счету все равно какое название у файла. Поэтому организация должна быть такой, как удобно вам и вашим коллегам.
Мы используем вот такой формат: ABC.Phase.SubLabel.State.0.01.doc, где:
- ABC
Код проекта для учета логов внутри компании и тикетов по проекту. Также используется в письмах, отчетах и любых других местах, где упоминается проект, чтобы настраивать фильтры. Генерируется по буквам под ударением. Пример: проект имеет название «Ozon», значит его код будет OZN.
- Phase
Текущая фаза проекта. Основные фазы и типы документов регламентированы, но в зависимости от проекта их набор может меняться. Общий список фаз таков:
- Presale
Содержит все возможные данные, выясненные в ходе предпродажной подготовки: презентации, контакты стейкхолдеров, клиентские брифы, рекламные материалы и всякое такое.
- Research
Исследования рынка, предметной области, устоявшихся практик, конкурентов;
- Analysis
Данные обследования компании: цели и задачи, пользовательские классы, структура компании, бизнес-модель и внутренние/внешние процессы, требования к системе и все такое.
- Concept
Концептуальное видение проекта: wireframes, ИА, сценарии, персонажи, перечень и краткое описание функционала;
- Project
Непосредственно постановка задачи на разработку, дизайн, тестирование, контент, интеграцию;
- WBS
Декомпозиция работ по проекту;
- SubLabel
Название части фазы. Например, если текущая фаза Analysis, то SubLabel может быть указанием на содержание: Rival, UserClasses, Scope.
- State
Текущий статус фазы. Бывает двух видов: draft или stable. Влияет на использование документа внутри компании. Наружу (клиенту) отдается только stable, из него же и вытекает следующая фаза. Draft — это промежуточный результат, который циркулирует только между проектировщиками и менеджерами.
- Мажорная версия
Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику. Если цифра больше 3-5, то обычно это означает, что кто-то лажает на проекте: плохо проведена предыдущая фаза и данные не полные, менеджер не справляется с маршрутизацией задач, проектировщик плохо спроектировал функционал, что вызвало дополнительные вопросы и, как следствие, еще несколько циклов. Версия всегда устанавливается менеджером.
- Минорная версия
Количество изменений, внесенных в проект. Используется только внутри проектировщиков: например, для проверки качества документации, прототипов. Если результат получился не полным (что-то упустили), то инкрементируется минорная версия и документ отправляется на доработку. Устанавливается только проектировщиком или руководителем отдела проектирования.
Директории называем по текущей фазе. Прототипы по схожему принципу: ABC.Concept.Prototype.Stable.0.01 или ABC.Project.Prototype.Draft.0.01
Наша схема, на первый взгляд, выглядит немного монструозно, но она логична, читаема и, что самое важное — проверена годами.
комментарии (23)
код. наименование документа (версия).doc
В структуре каталогов, как правило, предусмотрен ещё каталог для зафиксированных (утверждённых сторонами) версий, ну и специфические усложнения ещё. А так да, по этапам проекта тоже.
На примере таких случаев (если умными словами — когда нужно упорядочивать по многим дискретным параметрам) видно, насколько папки, допускающие только один уровень упорядочивания (собственно, вложенность, она ж простая композиция) неудобны.
Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)
Не совсем понял как это будет выглядеть реализация на практике хранения кучи проектных документов (WinFS рулит?? Wiki подобная система с кучей тегов?) Или это было философское отступление, не все же про работу говорить?
Если наиболее кратко: онтология — это формальное описание предметной области. В чем польза? Вместо того, чтобы закидывать знания в некую запись (в данном примере — порядок неких кодовых символов и цифирок задают знания о версии и параметрах готовности проекта), которую, при автоматизации, нужно парсить и записывать в нужном формате — хранить сами знания. Тогда над этими формализованными знаниями можно организовывать полезные действия (интерпретации, если пользоваться «умными» словами). Например, анализ чего-нибудь-полезного в зависимости от фазы проекта в «линейной», предложенной автором топика, форме проводить уже не слишком удобно — нужно парсить строчку и только после этого с инфой работать.
WinFS умерла не родившись — ну и фиг с ней. Да, там были элементы системы знаний. Впрочем, зная логику и манеру ведения бизнеса M$ можно сказать, что была бы она предельно казуальной и кривоватой… например, поддерживала бы только «предустановленную» онтологию — что не то чтобы плохо, но и хорошего в том мало.
Вики к онтологиям вообще отношения не имеет — это система на основе гипертекста и обычного текстового поиска, весь смысл туда заносят люди.
Я, конечно же, за светлое будущее. Но исключительно ради его практических плюсов, а не абстрактного блага.
В большинстве провайдеров для учета звонков и составления тикетов используются самые обычные записи разговоров (впрочем, полезные во многих случаях, не только в технических вопросах) и текстовые блоки с пометкой приоритетов.
Предполагаемый профит от внедрения системы на основе знаний:
1. возможность _формально_ описать действия пользователей, операторов ТП, и вообще всех, кто имеет отношение к ситуации;
2. из (1) следует, что можно так же модернизировать ПО обмена сообщениями — заменив иногда довольно толстые и запутанные инструкции по заполнению тикетов (случай для примера: у провайдера есть программа размещения wi-fi точек у желающих, в том числе физ.лиц. В случае проблем на точке в тикет приходится включать массу инфы о контактах держателя и о самой точке — и это кроме инфы о проблеме абонента). Прямой профит от этого: сокращение действий операторов и большинства персонала по обработке тикетов, возможность напрямую связать действия с информацией из тикета (опять же пример, немного абстрактный — при обнаружении невыдачи IP проводятся некоторые рутинные действия — которые можно автоматизировать).
3. мелочь, а приятно — в ряде случаев, поверх собственно онтологии можно повесить экспертную систему. Это и подсказка ТП в сложных случаях, и возможность удаленной помощи абонентам (нет ведь ничего сложного создать облегченную версию базы знаний по самым частым случаям и раздавать их при подключении и просто желающим).
Я вообще поклонник идеи онтологий в «малых формах», наподобие системы тикетов или ежедневников — где внедрение интеллектуальных систем сдерживается не сложностью предметной области (хотя большая сложность скорее стимулирует использование онтологий — для примера можно поглядеть на современные САПР), а лишь отсутствием подходящих инструментов и небольшой известностью самой концепции.
У нас хранение документов осуществляется примерно так же, как описано в статье. Но с гораздо меньшей детализацией, здесь есть реально полезные мысли, за что особая благодарность автору.
В свое время активно экспериментировали с wiki Confluence. Было описание проекта в wiki формате, к нему прикладывались файлы проекта через webdav. Активно использовалось тегирование для описание самого проекта.
Сейчас сложностей вижу 3:
1. нет правильных инструментальных средств для внедрения онтологий в проекты. Есть замечательные «обычные» IDE, есть неплохие редакторы онтологий — но нет инструментов, которые бы объединяли их качества;
2. нет хороших метамоделей (они ж онтологии верхнего уровня — наиболее абстрактные модели, на основе которых можно строить более детальные прикладные онтологии) — идеи классов и объектов, в свое время, совершили неплохую революцию, но сейчас, ИМХО, это все более превращается в балласт (не верите? Тогда скажите, в скольки проектах вам приходилось использовать все диаграммы UML 2.0)
3. самое главное — пока мало людей, которые понимали бы неизбежность этого пути. То есть вот так вот фатально — нету больше альтернатив, а которые есть — все так или иначе сводятся к онтологиям. В свое время, ООП сделали психологи. Сейчас концепцию программирования сделают философы.
Понимаете, внедрять нужно то, что гарантированно будет работать и помогать. Причем стоимость владения таким решением должна должна быть как минимум не больше того, что я привел в посте. Ну или плюсы должны очень сильно перевешивать. Поэтому «онтологии форева!», но «папки пока не маздай» :)
Сейчас я, в общем, и не преследую цели «пересадить» всех на онтологии и интеллектуальное ПО. Скорее есть потребность создать некий «информационный шум», рекламу технологии — чтобы когда инструментальные средства появились (а это произойдет весьма скоро — базовые технологии уже есть, ПО из смежных областей так же появляются, так что дело за командой, которая сможет это реализовать и широко заявить об успехе) — достаточное количество разработчиков уже было в курсе, что есть такая штука и как ей можно воспользоваться.
Еще раз подчеркну — новый подход будет развиваться по-взрывному. В отличие от ООП, который развивался сравнительно равномерно, в онтологиях возможно широкое использование предыдущего опыта и наработок.
Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику.
А вот это очень интересно. У нас несколько иная схема: Мажор-Минор-Билд. Но Ваша идея инкрементирования мажора очень интересна. Спасибо!
И в именах точки использовать совершенно ненужно
Если с рос. заказчиками работать, то как тогда лучше сделать?
По-мойму если в момент Presale выслать документ с таким шифром, но русским, то впечатление будет солидное.
Длинные названия, да еще фиксирующие стадии, — не даем.
1. Папка ABC — по заказчику
2. Следующий уровень — папка var-2009-12-23 (как пример) — для отсечения состояния логичного этапа (периодичность и несколко дней и несколько недель — определяется важностью изменений).
3. Во вложенных в var-… папках — разнородная информация, поэтому в обозначениях системы нет (это и папки по поставщикам и папки по узлам).
При таком подходе:
1. минус — в разных папках var-… могут лежать одинаковые файлы (после сдачи проекта — часть папок var-… удаляем, оставляя с наиболее интересными решениями).
2. плюс — каждая такая папка может послужить заготовкой для другого проекта.
Может я конечно ошибаюсь, но очень бы хотелось увидеть скриншот папки, где такие документы лежат.
А теперь расскажите почему схема ограниченная, запутанная и вредная?