Способ организации проектных директорий и файлов

    Достаточно часто поднимается вопрос о том, кто и как называет организовывает файлы (речь идет не о системах хранения версий, а именно о способе организации файлов и директорий). Или не называет, а хранит как придется. Буквально вчера коллега в Useful Сlub задал аналогичный вопрос. Я, пожалуй, зафиксирую свой ответ и здесь, вдруг кому-то еще наш способ поможет сэкономить время.
    Тут еще важно понимать вот что — это ваша внутренняя нотация, заказчику по большому счету все равно какое название у файла. Поэтому организация должна быть такой, как удобно вам и вашим коллегам.

    Мы используем вот такой формат: ABC.Phase.SubLabel.State.0.01.doc, где:
    1. ABC
      Код проекта для учета логов внутри компании и тикетов по проекту. Также используется в письмах, отчетах и любых других местах, где упоминается проект, чтобы настраивать фильтры. Генерируется по буквам под ударением. Пример: проект имеет название «Ozon», значит его код будет OZN.

    2. Phase
      Текущая фаза проекта. Основные фазы и типы документов регламентированы, но в зависимости от проекта их набор может меняться. Общий список фаз таков:
      • Presale
        Содержит все возможные данные, выясненные в ходе предпродажной подготовки: презентации, контакты стейкхолдеров, клиентские брифы, рекламные материалы и всякое такое.

      • Research
        Исследования рынка, предметной области, устоявшихся практик, конкурентов;

      • Analysis
        Данные обследования компании: цели и задачи, пользовательские классы, структура компании, бизнес-модель и внутренние/внешние процессы, требования к системе и все такое.

      • Concept
        Концептуальное видение проекта: wireframes, ИА, сценарии, персонажи, перечень и краткое описание функционала;

      • Project
        Непосредственно постановка задачи на разработку, дизайн, тестирование, контент, интеграцию;

      • WBS
        Декомпозиция работ по проекту;
    3. SubLabel
      Название части фазы. Например, если текущая фаза Analysis, то SubLabel может быть указанием на содержание: Rival, UserClasses, Scope.

    4. State
      Текущий статус фазы. Бывает двух видов: draft или stable. Влияет на использование документа внутри компании. Наружу (клиенту) отдается только stable, из него же и вытекает следующая фаза. Draft — это промежуточный результат, который циркулирует только между проектировщиками и менеджерами.

    5. Мажорная версия
      Отвечает на вопрос: сколько раз документ был направлен на утверждение заказчику. Если цифра больше 3-5, то обычно это означает, что кто-то лажает на проекте: плохо проведена предыдущая фаза и данные не полные, менеджер не справляется с маршрутизацией задач, проектировщик плохо спроектировал функционал, что вызвало дополнительные вопросы и, как следствие, еще несколько циклов. Версия всегда устанавливается менеджером.

    6. Минорная версия
      Количество изменений, внесенных в проект. Используется только внутри проектировщиков: например, для проверки качества документации, прототипов. Если результат получился не полным (что-то упустили), то инкрементируется минорная версия и документ отправляется на доработку. Устанавливается только проектировщиком или руководителем отдела проектирования.
    Директории называем по текущей фазе. Прототипы по схожему принципу: ABC.Concept.Prototype.Stable.0.01 или ABC.Project.Prototype.Draft.0.01

    Наша схема, на первый взгляд, выглядит немного монструозно, но она логична, читаема и, что самое важное — проверена годами.

    Similar posts

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 23

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

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

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

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

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

          Я не пытался решить задачу организации информации. Речь о презентации формата и удобства его использования в рамках конкретного процесса. Файлы и папки в этом топике не более чем сущности, посредством которых представлен формат. Но за активность спасибо :)
            +2
            «Онтологии форева»… это что имеется ввиду? Я ради интереса решил освежить свои знания статейкой в википедии.
            Формально онтология определяется как O = <X,R,F>, где
            * X — конечное множество понятий предметной области,
            * R — конечное множество отношений между понятиями,
            * F — конечное множество функций интерпретации.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

                  По-мойму если в момент Presale выслать документ с таким шифром, но русским, то впечатление будет солидное.
                  • UFO just landed and posted this here
                      0
                      Извините, дурацкий вопрос: а что такое Useful Club?
                        0
                        Это клуб для общения дизайнеров интерфейсов и юзабилити-специалистов. Пока что это обычное комьюнити как ru_ucd, только закрытое. Членство модерирует создатель.
                        –1
                        Ограниченная, запутанная система классификации документов. Я бы даже добавил — вредная.
                        Может я конечно ошибаюсь, но очень бы хотелось увидеть скриншот папки, где такие документы лежат.
                          +1
                          Нотариально заверить не успел.



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

                        Only users with full accounts can post comments. Log in, please.