Короновирус и удалёнка
«Удалёнка» пришла в офис нашего конструкторского бюро пару лет назад по причине того, что в один прекрасный день в нашей комнатушке не осталось свободных мест. А посадить нового сотрудника под новый проект куда-то надо было. В этот момент я, как главный конструктор, принял решение освободить свой стол и отправился домой, чтобы продолжить работу на своём домашнем компьютере. Дома у меня уже давно стояла полноценная рабочая станция с двумя мониторами для работы по вечерам и выходным. Позднее мой опыт стали перенимать и другие сотрудники конструкторского бюро.
Создание виртуальной рабочей среды
В первую очередь было необходимо решить вопрос с общением внутри коллектива. Важным условием была необходимость организации видеоконференций с возможностью демонстрации экрана. Ведь без этого невозможно командное обсуждение 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-браузер. Мы же используем его для предоставления доступа заказчикам к актуальной версии проекта. Теперь наши клиенты могут в любой момент и с любого устройства открыть трёхмерную модель изделия, повращать её и даже сделать разрез, чтобы посмотреть внутренности.
Управление персоналом, оценка эффективности работы
Одна из наиболее больных тем для руководителя касается контроля использования рабочего времени сотрудниками. Т.е. грубо говоря, как отследить, что сотрудник чертит, а не сидит в соцсетях. Большинство работодателей пытается применять различные системы финансовой мотивации: премии, надбавки, штрафы и т.п. В моём случае сама концепция удалённой инженерной работы подразумевает то, что рабочие часы размазаны по времени суток, а сумма рабочих часов за месяц может варьироваться в зависимости от загрузки конструкторского бюро. Отсюда вытекают следующие правила:
Оплата почасовая;
Стоимость часа для каждого конструктора устанавливается индивидуально и зависит от компетенций конкретного сотрудника;
При распределении работ приоритет отдаётся наиболее стабильным и добросовестным сотрудникам;
Отпускные выплачиваются только при наработке определённого количества часов;
Чтобы посчитать рабочие часы, мы используем табель, сделанный в Microsoft Excel. В процессе использования он оброс встроенными макросами, которые раскрашивают строчки и блокируют записи, сделанные ранее так, чтобы не было соблазна дорисовать себе чего-нибудь за прошлую неделю, чтобы «накрутить» часы.
По окончании каждого проекта я могу получить точную сумму часов, потраченных на его выполнение, а значит и оценить реальные денежные затраты. Это, в свою очередь, позволяет оценить эффективность работы команды и найти слабых мозгом или духом инженеров.
Конечно, всё это не гарантирует, что конструктора не будут приписывать себе лишних часов, но я убеждён, что ловля блох в таких делах лишь сделает отношения в коллективе более напряжёнными, нежели повысит производительность.
Одной из частых причин потери рабочего времени является неспособность сотрудника быстро принять решение. В спорной ситуации он может начать колебаться, зарыться в книжках или завести дебаты с коллегами, поэтому очень важно закрыть все «дыры» в нормативной документации (СНиПах, ГОСТах) собственными руководящими инструкциями. Наш руководящий документ составлялся и оттачивался не один год и занимает более пятидесяти страниц текста с картинками.
Так же у нас есть ряд конструкторов, которых мы подключаем на деталировку больших проектов. Оплата у них рассчитывается с каждого чертёжного листа. Так как в основе PDM системы лежит SQL база данных, в которой записана вся информация по каждому файлу, то не составляет труда написать собственный SQL запрос и подсчитать, кто сколько чертежей выполнил.
Расчёт производится в листах формата А4. Так, например, формат А3 засчитывается как два листа А4, а формат А2 – как четыре листа А4. Столбец “SheetsHighRev” учитывает чертежи, которые направлялись на проверку ведущему конструктору более трёх раз.
А что у других?
За годы своей профессиональной деятельности я побывал на многих больших и маленьких предприятиях нашей страны. Большинство из них тоже обзавелось мощными рабочими станциями и PDM-системами, а вот условия работы оставляют желать лучшего. Даже если у фирмы есть деньги, максимум, на что хватает фантазии у владельцев, это дешёвый евроремонт, мебель из ДСП эконом класса, и пластиковые офисные перегородки. О гибкой рабочей неделе и вкусной столовке речи даже не идёт.
К моему сожалению, современные просторные офисы с дизайнерским ремонтом, местами для отдыха, бесплатной едой и литературой на сегодняшний день доступны только IT компаниям.
Интернет полон рассказов об офисах Яндекса, Варгейминга, EPAM, SoftFacade в Санкт-Петербурге. Ни одного схожего по комфорту места для конструкторов я не видел, но при этом каждый работодатель жалуется на кадровый голод. В крупных городах одной зарплатой человека уже не заманишь. Хочу уже увидеть аналогичные репортажи про условия труда из конструкторских бюро Силовых машин, ОДК-Климов, концерна Алмаз-Антей, ЦКБ Малахит, ЦКБ Рубин, ЦНИИ РТК, ЦКБМ…
zloddey
"Руководящий документ" — мощная вещь, аналога которой в IT-компаниях часто нет. Насколько часто приходится его обновлять в вашей организации?
volkov-kb Автор
Первое время, я вносил правки каждый день. Сейчас на редактирование открываю только в связи с обновлениями софта или созданием каких-либо новых макросов, плагинов. Или, бывает, софт начинает капризничать после обновления Windows и надо написать в FAQ про лечение всплывшей проблемы.
Взгляд на практику оформления проектов почти не меняется.
NAI
Кстати, вопрос, почему именно документ, а не wiki-движок?
Ведь в нем можно хранить больший объем знаний(особенности использования изделий, не очевидные вещи, типовые ошибки), комментирование и прочие плюшки условной «базы знаний».
Rannaev
У меня именно те же мысли.
И уже во второй компании реализую стандарты и базы знаний на wiki-движке.
NAI
Интересен опыт, т.к. сейчас сами ковыряем потихоньку xwiki. Поделитесь best practices или на что стоит обратить внимание.
Rannaev
Кратко.
Нужен базовый функционал вики — авторизация и механизм защиты статей от изменений (или даже механизм согласования изменений), вставка картинок из буфера обмена, возможность ссылки на локальные файлы, встраивания видео с ютуба и т.п. Mediawiki c дополнениями вполне подходит.
Статьи делятся на четыре основные категории:
Инструкции (краткое пошаговое руководство по конкретному действию);
Правила (основные технические и/или организационные ограничения);
Информация (сведения, описания, технические и/или организационные);
Сценарии (use case в стиле Алистера Коберна. Например, «Пользователь выполняет действие в программе»).
И соответственно максимально «схлопнуть» текстовую составляющую засчёт перекрёстных вики-ссылок.
Выглядеть всё будет очень скучно. Везде полстранички текста или пяток пунктов с несколькими картинками. Мне как-то стало интересно и я посчитал в своём случае сколько займёт стандарт при распечатке в А4 — получилось порядка 400+ листов, без повторяющихся статей. Хотя внешне всё легко и просто.
Но главное — оно будет работать и будет актуальным. У такого подхода есть один плюс — удобство для потребителя информации.
Отдельный вопрос — приучить людей пользоваться ресурсом, и ни в коем случае не печатать в бумаге.
Перед началом есть смысл продумать структуру и правила в т.ч. и именования самих статей на вики, оформление статей внутри, договориться о применяемой нотации описания процессов, категориях и т.п. Сделать небольшой стандарт по разработке стандарта.
NAI
Спасибо за развернутый ответ. В принципе мы к чему-то похожему и движемся, с той лишь разницей, что инструкции и СТО на бумаге все же нужны т.к. комиссии и аудиты.
Rannaev
В этом направлении тоже есть опыт. Рекомендую утверждать вики локальными нормативными актами и показывать её всем заинтересованным сторонам. Отдельные случаи, требующие на уровне законодательства бумажные носители информации, прописать и контролировать.
NAI
Мне на самом деле не очень понятно, как это происходит. Недостаточно же прописать в локальном акте\инструкции, потому, что первый же аудит начнет задавать провокационные вопросы вида:
-А как у вас разграничение прав происходит? А чем вы обеспечиваете неизменяемость и целостность данных? А нету ли там данных по 152-ФЗ(а там, как минимум будет ФИО пользователя)? А информации класс присвоен? А на основании каких документов?
Т.е. по сути все сведут к ISO 27001. А это во-первых стоит конских денег, а во-вторых работать под этим самым ISO сильно не комфортно.
Rannaev
Смотря какой аудит. СМК принимает такие вещи хорошо.
Я к тому что не стоит придумывать проблемы самому себе. Если есть практика выкладывания документов в сетевые каталоги, то и вики проблем не доставит.
NAI
У нас аудиторы лет 8 назад задали простой вопрос:
-Вы понимаете чем файл, отличается от документа? (подразумевался электронный)
Мы задумались, почитали, осознали и пришли к выводу, что нет у нас никаких елЕктронных документов, а файлики… ну они и в Африке файлики, никакой юр.силы не имеют и ссылаться на них нигде нельзя.
Поэтому, вдвойне интересен опыт не очень крупных организаций.
surname
Привет, в двух организациях занимался созданием базы знаний на Dokuwiki именно для конструкторов. Хотя сейчас бы взял Mediawiki — выглядит интереснее, возможностей побольше, есть интеграция с Libre office. Не все сотрудники могут освоить markdown.
В основном в wiki размещаются инструкции, текстом со скриншотами или видео. Принять wiki в качестве какого-то официального документа… Не знаю… в маленькой организации это не нужно, а в большой (с наследием из прошлого) невозможно в силу приверженности людей к другому формату официальных документов.
Основные проблемы при создании такого портала — это определить структуру (я организовывал разделы по продуктам pdm решение, cad решение, ecad и ТД.) и стиль статей, научить пользоваться коллег, разобрать свалку существующих данных в word, pdf, txt и постепенно переписывать их в markdown (можно использовать pandoc для этого). На наиболее частые вопросы пользователей лучше написать по статье, и отправлять их туда, через некоторое время освоят поиск и будут сначало пользоваться им, вместо обращений в поддержку. Наверное лучшей практикой будет если получится организовать чтобы пользователи сами писали статьи (не только по использованию ПО, но и по решению задач из своей профессиональной области, это ведь и есть концепция wiki), тогда это будет не просто портал с инструкциями, а некоторый процесс управления знаниями.