Опыт организации труда в конструкторском бюро

    Короновирус и удалёнка

    «Удалёнка» пришла в офис нашего конструкторского бюро пару лет назад по причине того, что в один прекрасный день в нашей комнатушке не осталось свободных мест. А посадить нового сотрудника под новый проект куда-то надо было. В этот момент я, как главный конструктор, принял решение освободить свой стол и отправился домой, чтобы продолжить работу на своём домашнем компьютере. Дома у меня уже давно стояла полноценная рабочая станция с двумя мониторами для работы по вечерам и выходным. Позднее мой опыт стали перенимать и другие сотрудники конструкторского бюро.

    Создание виртуальной рабочей среды

    В первую очередь было необходимо решить вопрос с общением внутри коллектива. Важным условием была необходимость организации видеоконференций с возможностью демонстрации экрана. Ведь без этого невозможно командное обсуждение 3D-моделей, чертежей, расчётов. Очевидно, что почта, WhatsApp и Telegram для этого не подходили. Можно было попробовать Skype, но как раз в это время появилась бесплатная ограниченная версия Slack и Microsoft Teams. Уже не помню, почему мы выбрали Microsoft Teams для интеграции, возможно, свою роль сыграла узнаваемость бренда Microsoft.

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

    Платформа Microsoft Teams поддерживает огромное количество плагинов. Я хочу показать тот единственный, который приобрёл наибольшую популярность у нас. Это – доски с карточками Trello.

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

    «А где хранить сами рабочие проекты?» - спросите вы. Файлы SolidWorks, КОМПАС, AutoCAD? Как обеспечить к ним совместный доступ, хранение нескольких версий, прозрачную процедуру проверки и утверждения. Решение уже давно придумано и называется оно PDM-система. Здесь я буду считать, что читатель уже знаком с этим понятием. Для тех, кто не знаком, можно сказать, что это как 1C-Бухгалтерия, только для конструкторов. Сейчас мне уже сложно представить нашу работу без PDM системы.

    SolidWorks PDM и Яндекс облако

    Для интеграции мы выбрали SolidWorks PDM, т.к. большинство проектов выполняем именно в SolidWorks.  PDM-система состоит из двух частей: клиентской и серверной. Клиентская часть PDM-системы встраивается прямо в SolidWorks и в проводник Windows. Там появляется окно, в котором можно повращать модель на базе «просмоторщика» eDrawings, а также ряд вкладок, позволяющих увидеть кто, когда и сколько делал конкретную модель или чертёж.

    Классический вариант установки PDM сервера подразумевает его установку на компьютер в офисе. Тут мы решили сделать ещё один шаг в будущее (или в настоящее…) и установить PDM сервер в облаке Яндекса. Это сразу решало несколько задач:

    • Мы избавились от всех проблем с железом. Так как организация у нас маленькая (до 10 человек), то у нас нет ни серверной, ни штатного системного администратора;

    • Мы стали независимы от арендодателя в части работоспособности линий связи, электропитания и доступа к оборудованию в выходные, праздничные дни, в период пандемии COVID-19;

    Стоит отметить, что я не являюсь профессиональным IT-специалистом и разбираюсь во всём понемногу лишь потому, что по-другому сейчас не выжить. Мой опыт показывает, что настроить аналогичную инфраструктуру для небольшой организации можно своими силами. Мною была выбрана следующая конфигурация виртуальной машины в Яндекс Cloud:

    По деньгам это вышло в 3000 руб. в месяц или 36000 руб. в год.

    Говорят, что все пользователи компьютера делятся на две категории: те, кто, делают резервные копии, и те, кто пока не делает резервные копии. В своём подходе к организации PDM сервера мы приняли за аксиому, что Яндекс потерять наши данные не может (хотя такие случаи уже происходили), а главную опасность представляют обновления PDM и обновления Windows, которые в момент могут сделать наш сервер не дееспособным. Поэтому работа была организована на двух дисках. На одном лежит непосредственно хранилище с файлами, а на другом стоит операционная система с SQL базой данных. Этот диск относительно небольшой по сравнению с хранилищем и его можно резервировать каждую ночь. Делается это путём создания снимка диска средствами самого Яндекс облака. Остановка виртуальной машины для этой процедуры не требуется.

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

    Полезным функционалом Яндекс облака оказалась возможность оперативно наращивать объём дисков виртуальный машины. Нужно лишь её остановить и рычажком в браузере докупить 10 или 20 дополнительных гигабайт дискового пространства. Для меня, конечно, остаётся вопрос, что я буду делать, когда объём данных перевалит за террабайт, т.к. хранение будет уже дорого стоить. В любом случае этот вопрос встанет не в ближайшие годы.

    На том же сервере организован Web-сервер с применением стандартной оснастки IIS от Microsoft. Действуя точно по инструкции от PDM-системы, я легко запустил Web-портал к PDM. Изначально он предназначен для работы с архивом чертежей через Web-браузер. Мы же используем его для предоставления доступа заказчикам к актуальной версии проекта. Теперь наши клиенты могут в любой момент и с любого устройства открыть трёхмерную модель изделия, повращать её и даже сделать разрез, чтобы посмотреть внутренности.

    Управление персоналом, оценка эффективности работы

    Одна из наиболее больных тем для руководителя касается контроля использования рабочего времени сотрудниками. Т.е. грубо говоря, как отследить, что сотрудник чертит, а не сидит в соцсетях. Большинство работодателей пытается применять различные системы финансовой мотивации: премии, надбавки, штрафы и т.п. В моём случае сама концепция удалённой инженерной работы подразумевает то, что рабочие часы размазаны по времени суток, а сумма рабочих часов за месяц может варьироваться в зависимости от загрузки конструкторского бюро. Отсюда вытекают следующие правила:

    1. Оплата почасовая;

    2. Стоимость часа для каждого конструктора устанавливается индивидуально и зависит от компетенций конкретного сотрудника;

    3. При распределении работ приоритет отдаётся наиболее стабильным и добросовестным сотрудникам;

    4. Отпускные выплачиваются только при наработке определённого количества часов;

    Чтобы посчитать рабочие часы, мы используем табель, сделанный в Microsoft Excel. В процессе использования он оброс встроенными макросами, которые раскрашивают строчки и блокируют записи, сделанные ранее так, чтобы не было соблазна дорисовать себе чего-нибудь за прошлую неделю, чтобы «накрутить» часы.

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

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

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

    Так же у нас есть ряд конструкторов, которых мы подключаем на деталировку больших проектов. Оплата у них рассчитывается с каждого чертёжного листа. Так как в основе PDM системы лежит SQL база данных, в которой записана вся информация по каждому файлу, то не составляет труда написать собственный SQL запрос и подсчитать, кто сколько чертежей выполнил.

    Расчёт производится в листах формата А4. Так, например, формат А3 засчитывается как два листа А4, а формат А2 – как четыре листа А4. Столбец “SheetsHighRev” учитывает чертежи, которые направлялись на проверку ведущему конструктору более трёх раз.

    А что у других?

    За годы своей профессиональной деятельности я побывал на многих больших и маленьких предприятиях нашей страны. Большинство из них тоже обзавелось мощными рабочими станциями и PDM-системами, а вот условия работы оставляют желать лучшего. Даже если у фирмы есть деньги, максимум, на что хватает фантазии у владельцев, это дешёвый евроремонт, мебель из ДСП эконом класса, и пластиковые офисные перегородки. О гибкой рабочей неделе и вкусной столовке речи даже не идёт.

    К моему сожалению, современные просторные офисы с дизайнерским ремонтом, местами для отдыха, бесплатной едой и литературой на сегодняшний день доступны только IT компаниям.

    Интернет полон рассказов об офисах Яндекса, Варгейминга, EPAM, SoftFacade в Санкт-Петербурге. Ни одного схожего по комфорту места для конструкторов я не видел, но при этом каждый работодатель жалуется на кадровый голод. В крупных городах одной зарплатой человека уже не заманишь. Хочу уже увидеть аналогичные репортажи про условия труда из конструкторских бюро Силовых машин, ОДК-Климов, концерна Алмаз-Антей, ЦКБ Малахит, ЦКБ Рубин, ЦНИИ РТК, ЦКБМ…

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

    More

    Comments 35

      +1

      "Руководящий документ" — мощная вещь, аналога которой в IT-компаниях часто нет. Насколько часто приходится его обновлять в вашей организации?

        0
        Первое время, я вносил правки каждый день. Сейчас на редактирование открываю только в связи с обновлениями софта или созданием каких-либо новых макросов, плагинов. Или, бывает, софт начинает капризничать после обновления Windows и надо написать в FAQ про лечение всплывшей проблемы.
        Взгляд на практику оформления проектов почти не меняется.
          +1
          Кстати, вопрос, почему именно документ, а не wiki-движок?
          Ведь в нем можно хранить больший объем знаний(особенности использования изделий, не очевидные вещи, типовые ошибки), комментирование и прочие плюшки условной «базы знаний».
            +3
            У меня именно те же мысли.
            И уже во второй компании реализую стандарты и базы знаний на wiki-движке.
              0
              Интересен опыт, т.к. сейчас сами ковыряем потихоньку xwiki. Поделитесь best practices или на что стоит обратить внимание.
                +3
                Кратко.
                Нужен базовый функционал вики — авторизация и механизм защиты статей от изменений (или даже механизм согласования изменений), вставка картинок из буфера обмена, возможность ссылки на локальные файлы, встраивания видео с ютуба и т.п. Mediawiki c дополнениями вполне подходит.
                Статьи делятся на четыре основные категории:
                Инструкции (краткое пошаговое руководство по конкретному действию);
                Правила (основные технические и/или организационные ограничения);
                Информация (сведения, описания, технические и/или организационные);
                Сценарии (use case в стиле Алистера Коберна. Например, «Пользователь выполняет действие в программе»).
                И соответственно максимально «схлопнуть» текстовую составляющую засчёт перекрёстных вики-ссылок.
                Выглядеть всё будет очень скучно. Везде полстранички текста или пяток пунктов с несколькими картинками. Мне как-то стало интересно и я посчитал в своём случае сколько займёт стандарт при распечатке в А4 — получилось порядка 400+ листов, без повторяющихся статей. Хотя внешне всё легко и просто.
                Но главное — оно будет работать и будет актуальным. У такого подхода есть один плюс — удобство для потребителя информации.
                Отдельный вопрос — приучить людей пользоваться ресурсом, и ни в коем случае не печатать в бумаге.
                Перед началом есть смысл продумать структуру и правила в т.ч. и именования самих статей на вики, оформление статей внутри, договориться о применяемой нотации описания процессов, категориях и т.п. Сделать небольшой стандарт по разработке стандарта.
                  0
                  Спасибо за развернутый ответ. В принципе мы к чему-то похожему и движемся, с той лишь разницей, что инструкции и СТО на бумаге все же нужны т.к. комиссии и аудиты.
                    0
                    В этом направлении тоже есть опыт. Рекомендую утверждать вики локальными нормативными актами и показывать её всем заинтересованным сторонам. Отдельные случаи, требующие на уровне законодательства бумажные носители информации, прописать и контролировать.
                      0
                      Мне на самом деле не очень понятно, как это происходит. Недостаточно же прописать в локальном акте\инструкции, потому, что первый же аудит начнет задавать провокационные вопросы вида:
                      -А как у вас разграничение прав происходит? А чем вы обеспечиваете неизменяемость и целостность данных? А нету ли там данных по 152-ФЗ(а там, как минимум будет ФИО пользователя)? А информации класс присвоен? А на основании каких документов?

                      Т.е. по сути все сведут к ISO 27001. А это во-первых стоит конских денег, а во-вторых работать под этим самым ISO сильно не комфортно.
                        0
                        Смотря какой аудит. СМК принимает такие вещи хорошо.
                        Я к тому что не стоит придумывать проблемы самому себе. Если есть практика выкладывания документов в сетевые каталоги, то и вики проблем не доставит.
                          0
                          У нас аудиторы лет 8 назад задали простой вопрос:
                          -Вы понимаете чем файл, отличается от документа? (подразумевался электронный)
                          Мы задумались, почитали, осознали и пришли к выводу, что нет у нас никаких елЕктронных документов, а файлики… ну они и в Африке файлики, никакой юр.силы не имеют и ссылаться на них нигде нельзя.

                          Поэтому, вдвойне интересен опыт не очень крупных организаций.
                  +1

                  Привет, в двух организациях занимался созданием базы знаний на Dokuwiki именно для конструкторов. Хотя сейчас бы взял Mediawiki — выглядит интереснее, возможностей побольше, есть интеграция с Libre office. Не все сотрудники могут освоить markdown.
                  В основном в wiki размещаются инструкции, текстом со скриншотами или видео. Принять wiki в качестве какого-то официального документа… Не знаю… в маленькой организации это не нужно, а в большой (с наследием из прошлого) невозможно в силу приверженности людей к другому формату официальных документов.
                  Основные проблемы при создании такого портала — это определить структуру (я организовывал разделы по продуктам pdm решение, cad решение, ecad и ТД.) и стиль статей, научить пользоваться коллег, разобрать свалку существующих данных в word, pdf, txt и постепенно переписывать их в markdown (можно использовать pandoc для этого). На наиболее частые вопросы пользователей лучше написать по статье, и отправлять их туда, через некоторое время освоят поиск и будут сначало пользоваться им, вместо обращений в поддержку. Наверное лучшей практикой будет если получится организовать чтобы пользователи сами писали статьи (не только по использованию ПО, но и по решению задач из своей профессиональной области, это ведь и есть концепция wiki), тогда это будет не просто портал с инструкциями, а некоторый процесс управления знаниями.

          +5
          А что у других?
          Божечки-кошечки, как же вы правы. Смотрю на наш офис и плачу. Да, графические станции, относительно неплохие зарплаты, но офис, социалка, отсутствие кондея, заказ мебели по пол-года (постоянная борьба с «давайте чините») и немой вопрос в глазах руководства «а чего это от нас сотрудники увольняются?»

          Причем, вот пришел ты такой к руководителю подразделения и говоришь: «чтобы потом не было больно давайте мы организуем собеседования тет-а-тет, будем агрегировать проблемы и решать их. Да просто проведем соц. опрос на тему кому чего надо?» Не провели, ничего не сделано, зато KPI и «мотивационный план». И все собеседования one-to-one начинаются после того как человек уже положил заявление.

          В общем, мое мнение — культура тянется с СССР, а не с запада, в отличии от IT. А в СССР во главе стояла не эффективность и удобство сотрудников, а план.
            0

            В чëм разрабатываете текстовые документы?

              +3
              В MS Word. Для вставки штампов разработан макрос, который пробегает по всем страницам и вставляет идеальные ГОСТовские рамочки в зависимости от формата листа и его ориентации.
              Заполнение граф реализовано через поля (переменные).
              image
              0
              А как запускаете на удалённой рабочей станции SolidWorks для разработки моделей и чертежей?
                +2
                PDM система обеспечивает только структурированное хранение данных. SolidWorks у всех работает локально.
                0
                Между прочим, интересное пересечение с недавней статьёй о структуре оплаты труда наёмных работников, в данном случае — конструкторов. habr.com/ru/post/526684

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

                Как у вас решается эта проблема?
                  +2
                  Основные конструктивные решения принимаются на стадии генерации коммерческого предложения, т.к. без этого не оценить объём работ. Любые поисковые работы всё равно ограничены «дедлайном». Если по смете заложено два дня на разработку концепции, значит через два дня мы примем лучшую из тех, что придумали. Нужно отделять инженерный труд от научно-исследовательских работ.
                    +1

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

                    0
                    Мощно.
                    А что у других?
                    И сразу захотелось у Вас работать.
                      +1
                      Как художник художнику скажу что труд проектировщиков на сегодняшний момент сильно упал в цене, соответственно, выручка тоже никакая, поэтому говорить о каких-то плюшках в офисе можно только мечтая. Где-то нет элементарных чая и кофе для сотрудников.
                      А вообще вы молодец что сумели настроить рабочую систему для удаленки!
                      Удаленка для комплексных проектировщиков, по моему мнению, подходит не очень, всё же пока еще очень много моментов на разных стадиях проектирования, которые обсуждаются с чертежами в руках. Если посмотреть на ваш пример, то в рамках небольшого чисто конструкторского бюро это работает неплохо.
                        0
                        Интересно изучить ваш руководящий документ. Если возможно, прошу поделится.
                          +3
                          Понимаю Ваш интерес, но при создании статьи я сразу составил для себя список тех вещей которыми я не поделюсь, т.к. считаю их коммерческой тайной. К ним относятся руководящие документы, оригинальные макросы, тонкие настройки ПО.
                          В руководящем документе описано всё самое спорное среди конструкторов, что плохо описано в ГОСТе:
                          • Можно-ли размещать тех. требования не над штампом, а слева от него?
                          • Стоит-ли использовать запись про неуказанные предельные отклонения или лучше поставить все отклонения прямо на размерах?
                          • Можно-ли проставлять позиции на разных видах или лучше поставить все выноски на главном виде?
                          • Что делать, если сварной шов нестандартный?
                          • Указывать-ли прокат в штампе или указывать только материал?
                          • По какому принципу раскрашивать сборки и как помечать поверхности разного назначения?
                          • Сколько и каких шайб класть под головку болта и под гайку?

                          Ответы на эти вопросы позволяют сделать все чертежи безобразно единообразными и исключить споры в коллективе на эти темы.
                            0

                            Понимаю, спасибо за ответ

                          0

                          С точки зрения резервного копирования PDM-системы зря вы надеетесь только на Яндекс. Даже более крупные и именитые облачные провайдеры теряли данные клиентов. И снапшот ни когда не будет являться полноценной резервной копией. Так как в общем-то не является полной и отдельно лежащей копией данных.


                          Представьте что выполняя какой-то очередной проект вы внезапно и по независящей от вас причине потеряли все наработки за последний месяц. Как это скажется на вашем бизнесе?


                          Если уже сложно или лень разобраться с какой-нибудь бесплатной версией Veeam Agent for Microsoft Windows или чем-то подобным. То хотя бы руками минимум раз в неделю копируйте критически важные для работы данные на локальную машину и храните хотя бы пару-тройку таких копий. Тем более объемы у вас пока не запредельные как я понял. Современные каналы интернет позволяют прокачивать такое за вполне разумное время.

                            0
                            Бесспорно, вопрос требует дальнейшей доработки. Мгновенно данные не потеряются, т.к. проекты с которыми работаем прямо сейчас кэшируются на локальные компьютеры в автономном режиме. С ними даже можно продолжать работать при отсутствии связи. Другой вопрос — насколько ценны старые проекты. К сожалению, мой опыт показывает, что обращаемся мы не более чем к 3% архивных данных.
                            0
                            Спасибо за статью.
                            А что насчёт безопасности интеллектуальных данных? Получается, что в любой момент времени каждый сотрудник имеет доступ ко всем проектам, которые он может легко сохранить и при желании (или ошибке) распространить?
                            Что насчёт лицензирования того же Solidworks — выдали всем персональные лицензии или настроили где-то сервер лицензий?
                              0
                              Каждому сотрудники открыт доступ только к тем проектам, над которыми он работает. Если кто-то испортит данные, то всё легко откатывается, т.к. PDM система позволяет сохранять все версии файла. У нас настроено хранение последних пяти версий.
                              Вопрос воровства данных сотрудниками открыт. Я не видел рабочих решений в этой области. Всегда можно на флешке или по почте забрать себе чертежи с которыми работаешь.
                                0

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

                                0
                                Тут проблема с одной стороны глубже, с другой ее преувеличивают.
                                Глубже она потому, что для того чтобы защитить такого рода данные необходимо воткнуть IDS\IPS систему, отключить флешки и запретить пронос телефона в охраняемый периметр. В общем, все то что так любят на больших гос. оборон. заводах. Вот только, все эти решения снижают КПД на порядок, увеличивают расходы и срок разработки.
                                Преувеличение же заключается в том что, допустим инженер упер проект(ы). А дальше то что с ними делать?
                                1. Проекты делаются под конкретного заказчика. Т.е. «продать» решение невозможно т.к. изготовлено под конкретные требования, конкретной организации.
                                2. Чаще всего в отрасли все плюс-минус знают решения друг-друга и себестоимость гуляет в пределах 10-15%. Причем, очень многое зависит от поставщиков — фирме А дают скидку в 10%, фирме Б нет. Зато у фирмы Б есть свое производство деталек.

                                В итоге, максимум что можно подчерпнуть из утекших данных, это какие-то «удобства» и best practies. В целом, можно заплатить денег тому же инженеру и он просто все то же самое расскажет рисуя на бумаге эскизы.

                                Большую угрозу представляет утечка не на этапе проектирования, а на этапе тендера — «За сколько там выставляются конкуренты, какие скидки им дают партнеры и на какой элементной базе будут делать.» Потому, что тогда можно идти к своим поставщикам и давить на них, снижать ЧП и т.д., и т.п.
                                0
                                Очень хочу увидеть документ по проектированию. Пытаюсь заставить своих конструкторов написать такой, говорят это невозможно. Было бы здорово получить его и показать как люди работают!
                                0

                                Отличная статья! Несколько профессиональных вопросов:


                                1. Используется ли у Вас скелетная/опорная/компоновочная геометрия?
                                2. Изделия у Вас не маленькие. Как ведёте работу. Каждый сотрудник ведёт отдельный проект? Или же, проектирование коллективное?
                                3. Все это тоже описано в Руководящем документе?
                                  0
                                  1. Не нахожу в этом смысла, так как модели параметрические. Можно моделировать сначала «на глаз», а потом корректировать, чтобы вписаться в нужные размеры.
                                  2. По всякому, зависит от сроков.
                                  3. Концептуальными проработками занимаюсь лично я и ведущие конструктора. Тут подходы и сроки никак не регламентированы. Это — изобретательство. Его в документе не пропишешь. А вот когда уже основные узлы продуманы и просчитаны можно подключать остальной коллектив на «допиливание» и выпуск КД.

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