Pull to refresh

Comments 35

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

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

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

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

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

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

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

В общем, мое мнение — культура тянется с СССР, а не с запада, в отличии от IT. А в СССР во главе стояла не эффективность и удобство сотрудников, а план.
В MS Word. Для вставки штампов разработан макрос, который пробегает по всем страницам и вставляет идеальные ГОСТовские рамочки в зависимости от формата листа и его ориентации.
Заполнение граф реализовано через поля (переменные).
image
А как запускаете на удалённой рабочей станции SolidWorks для разработки моделей и чертежей?
PDM система обеспечивает только структурированное хранение данных. SolidWorks у всех работает локально.
UFO just landed and posted this here
Основные конструктивные решения принимаются на стадии генерации коммерческого предложения, т.к. без этого не оценить объём работ. Любые поисковые работы всё равно ограничены «дедлайном». Если по смете заложено два дня на разработку концепции, значит через два дня мы примем лучшую из тех, что придумали. Нужно отделять инженерный труд от научно-исследовательских работ.

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

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

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

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


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


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

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

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

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

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

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

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


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

Articles