А что делать, если полость рта сканируют для зуботехников, а "вчерашние водопроводчики" используют CAD-системы и ERP/PLM/PDM-продукты, чтобы экономически обосновано выбирать размер трубы, ну или они же "вошли вайти"?
Это всё уже IT и это надо понимать, а рисовать свои границы только для гребцов на галерах в корпоративном секторе и нехотя добавлять тестирование максимум, то это окостенение и приближение к так называемым совкам, у которых так же "раньше было лучше".
Я инженер-конструктор компании BIMeister и при этом успеваю доучиваться в Московском Политехническом Университете на факультете машиностроения.
Вот почему люди называют себя инженерами без высшего техн.образования или хотя бы имея профтех образование в соответствующей должности с минимально необходимым стажом? Отсутствие понимания своей профессии с первых строк.
Наш отдел разрабатывает высокодетализированные 3D модели
Что такое "высокодетализированные 3Д модели"? Хочется пожелать вам всегда пользоваться, например, ПЭТ-бутылками с аннотационной резьбой без её реального исполнения в реальной бутылке. Возможно, что тогда появится понимание о "высокой" детализации. Про шагрень корпуса даже не будем начинать разговор. Оно конечно к специфике производства относится, но раз потом пытаются скрестить СПДС с ЕСКД+ЕСТД, то информационная модель должна быть полной.
А ничего, что этапы разработки продукта в машиностроении совершенно иные, нежели в СПДС? И БИМ прежде всего нужен для объединения различных разделов, на которыми работают множество отдельных компаний, чтобы избежать пересечения, например, чтобы труба канализации не прошла через вентиляцию.
CAM (Computer-aided manufacturing) – прописывания алгоритма действий станков с ЧПУ.
CAM – прописать последовательность выполнения процессов для создания стула.
А если стул создаётся без станков с ЧПУ, то будет ли прописана "последовательность выполнения процессов для создания стула"? И в этом ли задача САМ-системы? А нормы, критерии качества и т.д. где описываются? САМ-система перепутана с технологической документацией, маршрутными картами и кучей остальных вещей, в том числе и MES, и ERP, забыты классы PDM и PLM.
И сушка дерева для стула куда записывается или игнорируется? Если игнорируется, то это уже не проект!
Лишь редкий представитель инженера, но опытный человек в своём деле, предпочитает бумажные чертежи электронным.
Представитель с действующей доверенностью от инженера... :) Инженеры предпочитают 3Д-модели уже давно. Посмотрите на корпус своей мышки, уверен, что чертёж вам сильно не поможет для её литья, инженеры прессформ потребуют 3Д-модель и такое положение дел уже всю вашу жизнь. В конце 90-х прессформстроение крепко перебралось на 3Д-модели, чертежи служили лишь добавочной информацией, ну или аналогом атрибутов к 3Д-модели.
Моё видение такое: BIM — это информационная модель объекта с использованием цифровых данных.
"информационная модель объекта с использованием цифровых данных - это ЭМИ (по ГОСТу) с учётом того, что есть полная информация о геометрии, иначе это никому не нужно в машиностроении. То, что у вас КПП зеленого цвета без информации о размерах, может быть интересно только мифической блондинке.
Так нужно ли внедрять САПР и BIM технологии при проектировании механизмов? Однозначно, да.
БИМ, однозначно, нет, а вот САПР с атрибутами в 3Д-модели, да, но с ограничениями. Сопроводительная информация в 3Д-модели уже появилась достаточно давно, многие отверстия раскрашивали разными цветами под соответствующий допуск. Нужна ли излишняя информация - конечно же нет, хранение и транспортировка больших объёмов информации = излишним затратам.
Постоянно в тексте идёт путаница между моделированием и проектированием.
А ещё такой тип руководителей с "засученными рукавами" очень любит подходить к станку, и весело отработав на нём 10 минут, любит потом доказывать подчинённым, что так надо работать целый день, а сам выручку подсчитывает на калькуляторе.
Обычно в таких ситуациях я предлагаю следующий эксперимент: пробежать себе стометровку на время, а ему (руководителю мечтающему с калькулятором) 10 км с той же эффективностью.
П.С. вы рассуждаете с позиции подчинённого и желаете видеть грубые ошибки руководителя. Крайне не советую начинающим руководителям так поступать.
Третья ошибка уже состоит в том, чтобы быть своим "в доску" среди подчинённых.
Когда СЕО моет окна, то это одна из грубейших ошибок в руководстве компаний, ведь стоимость мойки одного окна может компании обойтись стократно обычной его цене.
Я лишь о том, что использование труда того, кто более квалифицирован на низком уровне очень плохая затея кроме случаев каких-то пиарных манипуляций коллективом.
Не волнуйтесь так, скорее воспринимайте это исключением для первой фазы нового проекта. И именно в первой фазе руководителю приходится самолично разбираться и вникать в проблемы запуска, например, в случае старапа. Но это фаза не может длится вечно, вернее, даже долго.
Конечно во второй фазе выполнение работы подчинённого - это грубейшая ошибка руководителя. Но надо отметить, что даже самый крутой специалист, когда идёт в руководители, то неизбежно жертвует своим внутренним специалистом и его развитием, поэтому не всем подходит дальнейший подъём.
Интересно почему на картинке только две линии событий, а нет третьей, где уже за рулём грузовика инженер, который перевозит эту глыбу, без начальника и коллег/рабов?
SpiderEkb , я это в общем и имел в виду, как говорится, ГППС. Романтики с начала 90-х к концу 90-х хлебнули даже снижение оценки своего труда, админы многие теряли работы, пытались пробиться в программеры и т.д. Это сейчас ребрендинг под девопсов поднимает оценку их труда.
Но меня больше всего волнует, что многие считают, что айтишники - это прямо какие-то великие стратеги, поэтому достойны огромной оплаты. Давайте скажем честно, в это время многим из АйТи повезло, что попали в струю. Но и этим приходится расплачиваться, когда движуха с оплатой привлекает остальной люд. И мы даже не можем их винить за это. Се ля ви!
Возможно, но вы смотрите только регионально. Мы же говорим о взлёте языка, а там на мировых "затворках" пока поиск джавистов живее всех живых. Легаси ещё на Делфи существует, но вайтишники уже не пополняют ряды, поэтому и дефицит на программеров тут никуда не делся.
Мне не совсем понятно почему вы решили микросервисы ставить против Джавы, да и в общем, разговор не только про неё, мне так C# более по душе. И волна перехода на микросервисы уже не так сильно набирает обороты, не всё так радужно оказалось с ними. Но где тут затесаться новому ЯП-у?
Касаемо ООП в ТП, то Делфи бы не взлетел, если так прекрасно было бы с ООП у Паскакаля. Да, какие-то фичи были реализованы, но не полностью вся концепция, да и на 7.0-версии ничего толком не поменялось, после которой "ждун" скончался. Это я вам из личного опыта озвучиваю, а не по рассказам. Я прекрасно помню DOS, тогда "окна" были лишь графической оболочкой до 95-й версии. Но тогда пользователи были другого покроя и каждый второй лично редактировал config.sys и autoexec.bat, чтобы память освободить. Сейчас тренда изучения языков программирования низкого уровня я не вижу. За счёт чего должны слететь монстры высокого уровня - непонятно.
Для новичков ничего лучшего курса на Ютрубе от Наиля Алишева не встречал по теме Джавы и на русском языке.
А указанная книга действительно очень специфичная, но кому-то может и зайти.
П.С. А вообще желание изучить язык программирования не сможет испортить неудачная книга, иначе это было всего лишь фикс-идея, лучше это понять заранее, а не связав с этим всю жизнь, потратив многие года.
Очень странно слышать, что конструктор что-то должен, когда от конечного выхлопа он ничего не получает, стандартами не регламентированы его доп.действия, за которые он ещё и "получить от начальства на пироги" может, как за отвлечение от основной оперативной деятельности.
А что делать, если КБ работает как исключительно отдельная компания и всех нюансов технологии, где планируется производить изделие, он знать не может априори?!
Зачем вы на конструктора вешаете лишние обязанности?
Ведение проекта по продукту - это продакт-менеджер. Там даже "начальник КБ/главный конструктор" не при делах, поскольку последний отвечает лишь за свои Этапы Разработки (как минимум ГОСТ регламентирует для РФ и РБ).
Развитие и оптимизация - это развивающая деятельность. Выделение на неё ресурса правильной команды - это обязанность управленцев, а не ИТР-ов. Более того, оптимизацию изготовления необходимо прорабатывать с отделом главного технолога, а это уже регулирование между отделами и происходить должно на соответствующем уровне.
Всё, что может сделать конструктор, так это подать заявку на рациональное предложение. Но если нет никакого премирования, то это опять не ошибка конструктора, что он в нерабочее время бесплатно должен работать, наоборот, он должен свято блюсти work-life баланс ради своего хорошего самочувствия и производительности.
Ещё раз, "расшифровать и понять" - это не задача каждого из исполнителей. Да и не полная эта задача, как минимум ещё предложить решение остаётся со всеми граничными условиями.
И с последним много нюансов бывает у заказчика, очевидное для вас, может быть совсем неочевидным для него, а ещё моральные стороны вопроса при решении, сроки и т.п.
Понять очень сложно, если вы не считаете что-то проблемой или минимум её надуманность не вызывает у вас сомнений, а брать заказы нужно.
Достаточно часто встречает ситуация, когда принесенная проблема заказчиком вовсе не проблема, зато реальная проблема стоит рядом. Вот в последнем и надо переубедить заказчика, выставить перед ним цепь взаимосвязей. И как правило, при этом ты выяснишь, что заказчик может оказаться неадекватным идиотом. И будешь реализовывать его полурешение, которое с заранее известным результатом не поможет его проблеме. Но вникать в тонскости своего же бизнес-процесса он не захочет, чтобы говорить с тобой предметно. Такое встречается сплошь и рядом. Увы! Хотя конечно не с каждым первым. Но это видео как раз про этих вторых.
Вот мы и вошли в прямую рекурсию, что даже для оценки консалтинговых услуг нужны собственные компетенции.
Бизнес может и наелся "консалтингом", но он сам всегда хотел подешевле, а хорошее дешево стоить не может, в отличии от плохого, которое от цены не зависит. Сам бизнес не вырастил "культуру имени" или авторитетности, если хотите, поэтому и платить за неё не согласен.
П.С. 1-2 готовых спецов сейчас не найти, спрос намного шире. Много вы конструкторов знаете с пониманием литья под давление и штамповки?
В том и дело, что понятие "инженер" было давно и долго унижаемо, куда выгоднее идти в менеджеры или вайтишником. В результате, есть целое поколение недоинженеров, среди которого лишь редкие кадры представляют ценность, но они все заняты и к ним уже не пробиться со своими бизнес-идеями.
А у того же конструктора прессформ, как у хирурга, на становлении есть своё кладбище прессформ, которое намного дороже суммы его зарплат в этот период становления, поэтому никто в это вкладываться не хочет.
Вам никогда не приходилось писать часть приложения, когда общую решаемую проблему бизнеса вам не только не рассказали, но и категорически отказываются это делать сейчас и в будущем?
И нет, не задача всех присутствующих сторон исполнителя понять проблему. Иногда это невозможно в силу специфики задач. Рамки ответственности должны быть описаны в твоём контракте. Задача исполнителей сделать свой бизнес прибыльным даже решая несуществующие проблемы, иногда их придумывать самим и возглавлять тренды.
Понять проблему - это не задача эксперта. Эксперт предоставляет экспертную оценку, а не анализ проблем клиента. Иначе чем тогда занимает бизнес-аналитик? У вас ПМ - это продакт-менеджер или проджект-менеджер? Задачи и методы у последних тоже разные.
Вот вы и смогли разделить понятия верификации (выполнение формальных требований) и валидации (выполнение довольства продукцией). А следовательно и отличие QC (в первом варианте) от QA.
А что делать, если полость рта сканируют для зуботехников, а "вчерашние водопроводчики" используют CAD-системы и ERP/PLM/PDM-продукты, чтобы экономически обосновано выбирать размер трубы, ну или они же "вошли вайти"?
Это всё уже IT и это надо понимать, а рисовать свои границы только для гребцов на галерах в корпоративном секторе и нехотя добавлять тестирование максимум, то это окостенение и приближение к так называемым совкам, у которых так же "раньше было лучше".
Вот почему люди называют себя инженерами без высшего техн.образования или хотя бы имея профтех образование в соответствующей должности с минимально необходимым стажом? Отсутствие понимания своей профессии с первых строк.
Что такое "высокодетализированные 3Д модели"? Хочется пожелать вам всегда пользоваться, например, ПЭТ-бутылками с аннотационной резьбой без её реального исполнения в реальной бутылке. Возможно, что тогда появится понимание о "высокой" детализации. Про шагрень корпуса даже не будем начинать разговор. Оно конечно к специфике производства относится, но раз потом пытаются скрестить СПДС с ЕСКД+ЕСТД, то информационная модель должна быть полной.
А ничего, что этапы разработки продукта в машиностроении совершенно иные, нежели в СПДС? И БИМ прежде всего нужен для объединения различных разделов, на которыми работают множество отдельных компаний, чтобы избежать пересечения, например, чтобы труба канализации не прошла через вентиляцию.
CAM (Computer-aided manufacturing) – прописывания алгоритма действий станков с ЧПУ.
CAM – прописать последовательность выполнения процессов для создания стула.
А если стул создаётся без станков с ЧПУ, то будет ли прописана "последовательность выполнения процессов для создания стула"? И в этом ли задача САМ-системы? А нормы, критерии качества и т.д. где описываются? САМ-система перепутана с технологической документацией, маршрутными картами и кучей остальных вещей, в том числе и MES, и ERP, забыты классы PDM и PLM.
И сушка дерева для стула куда записывается или игнорируется? Если игнорируется, то это уже не проект!
Представитель с действующей доверенностью от инженера... :) Инженеры предпочитают 3Д-модели уже давно. Посмотрите на корпус своей мышки, уверен, что чертёж вам сильно не поможет для её литья, инженеры прессформ потребуют 3Д-модель и такое положение дел уже всю вашу жизнь. В конце 90-х прессформстроение крепко перебралось на 3Д-модели, чертежи служили лишь добавочной информацией, ну или аналогом атрибутов к 3Д-модели.
"информационная модель объекта с использованием цифровых данных - это ЭМИ (по ГОСТу) с учётом того, что есть полная информация о геометрии, иначе это никому не нужно в машиностроении. То, что у вас КПП зеленого цвета без информации о размерах, может быть интересно только мифической блондинке.
БИМ, однозначно, нет, а вот САПР с атрибутами в 3Д-модели, да, но с ограничениями. Сопроводительная информация в 3Д-модели уже появилась достаточно давно, многие отверстия раскрашивали разными цветами под соответствующий допуск. Нужна ли излишняя информация - конечно же нет, хранение и транспортировка больших объёмов информации = излишним затратам.
Постоянно в тексте идёт путаница между моделированием и проектированием.
А ещё такой тип руководителей с "засученными рукавами" очень любит подходить к станку, и весело отработав на нём 10 минут, любит потом доказывать подчинённым, что так надо работать целый день, а сам выручку подсчитывает на калькуляторе.
Обычно в таких ситуациях я предлагаю следующий эксперимент: пробежать себе стометровку на время, а ему (руководителю мечтающему с калькулятором) 10 км с той же эффективностью.
П.С. вы рассуждаете с позиции подчинённого и желаете видеть грубые ошибки руководителя. Крайне не советую начинающим руководителям так поступать.
Третья ошибка уже состоит в том, чтобы быть своим "в доску" среди подчинённых.
Когда СЕО моет окна, то это одна из грубейших ошибок в руководстве компаний, ведь стоимость мойки одного окна может компании обойтись стократно обычной его цене.
Я лишь о том, что использование труда того, кто более квалифицирован на низком уровне очень плохая затея кроме случаев каких-то пиарных манипуляций коллективом.
Не волнуйтесь так, скорее воспринимайте это исключением для первой фазы нового проекта. И именно в первой фазе руководителю приходится самолично разбираться и вникать в проблемы запуска, например, в случае старапа. Но это фаза не может длится вечно, вернее, даже долго.
Конечно во второй фазе выполнение работы подчинённого - это грубейшая ошибка руководителя. Но надо отметить, что даже самый крутой специалист, когда идёт в руководители, то неизбежно жертвует своим внутренним специалистом и его развитием, поэтому не всем подходит дальнейший подъём.
Нет. А вы тот, кто инженерный состав садит за руль для рейса между базами?
Интересно почему на картинке только две линии событий, а нет третьей, где уже за рулём грузовика инженер, который перевозит эту глыбу, без начальника и коллег/рабов?
SpiderEkb , я это в общем и имел в виду, как говорится, ГППС. Романтики с начала 90-х к концу 90-х хлебнули даже снижение оценки своего труда, админы многие теряли работы, пытались пробиться в программеры и т.д. Это сейчас ребрендинг под девопсов поднимает оценку их труда.
Но меня больше всего волнует, что многие считают, что айтишники - это прямо какие-то великие стратеги, поэтому достойны огромной оплаты. Давайте скажем честно, в это время многим из АйТи повезло, что попали в струю. Но и этим приходится расплачиваться, когда движуха с оплатой привлекает остальной люд. И мы даже не можем их винить за это. Се ля ви!
Нет такого одного единственного Ассемблера. Изучение было и раньше, но тренд где?
Ну и Тиобе, такое себе... может на SO посмотреть или на PyPL?
Возможно, но вы смотрите только регионально. Мы же говорим о взлёте языка, а там на мировых "затворках" пока поиск джавистов живее всех живых. Легаси ещё на Делфи существует, но вайтишники уже не пополняют ряды, поэтому и дефицит на программеров тут никуда не делся.
Мне не совсем понятно почему вы решили микросервисы ставить против Джавы, да и в общем, разговор не только про неё, мне так C# более по душе. И волна перехода на микросервисы уже не так сильно набирает обороты, не всё так радужно оказалось с ними. Но где тут затесаться новому ЯП-у?
Касаемо ООП в ТП, то Делфи бы не взлетел, если так прекрасно было бы с ООП у Паскакаля. Да, какие-то фичи были реализованы, но не полностью вся концепция, да и на 7.0-версии ничего толком не поменялось, после которой "ждун" скончался. Это я вам из личного опыта озвучиваю, а не по рассказам. Я прекрасно помню DOS, тогда "окна" были лишь графической оболочкой до 95-й версии. Но тогда пользователи были другого покроя и каждый второй лично редактировал config.sys и autoexec.bat, чтобы память освободить. Сейчас тренда изучения языков программирования низкого уровня я не вижу. За счёт чего должны слететь монстры высокого уровня - непонятно.
Для новичков ничего лучшего курса на Ютрубе от Наиля Алишева не встречал по теме Джавы и на русском языке.
А указанная книга действительно очень специфичная, но кому-то может и зайти.
П.С. А вообще желание изучить язык программирования не сможет испортить неудачная книга, иначе это было всего лишь фикс-идея, лучше это понять заранее, а не связав с этим всю жизнь, потратив многие года.
С каких пор производные не входят в школьную программу?
Очень странно слышать, что конструктор что-то должен, когда от конечного выхлопа он ничего не получает, стандартами не регламентированы его доп.действия, за которые он ещё и "получить от начальства на пироги" может, как за отвлечение от основной оперативной деятельности.
А что делать, если КБ работает как исключительно отдельная компания и всех нюансов технологии, где планируется производить изделие, он знать не может априори?!
Зачем вы на конструктора вешаете лишние обязанности?
Ведение проекта по продукту - это продакт-менеджер. Там даже "начальник КБ/главный конструктор" не при делах, поскольку последний отвечает лишь за свои Этапы Разработки (как минимум ГОСТ регламентирует для РФ и РБ).
Развитие и оптимизация - это развивающая деятельность. Выделение на неё ресурса правильной команды - это обязанность управленцев, а не ИТР-ов. Более того, оптимизацию изготовления необходимо прорабатывать с отделом главного технолога, а это уже регулирование между отделами и происходить должно на соответствующем уровне.
Всё, что может сделать конструктор, так это подать заявку на рациональное предложение. Но если нет никакого премирования, то это опять не ошибка конструктора, что он в нерабочее время бесплатно должен работать, наоборот, он должен свято блюсти work-life баланс ради своего хорошего самочувствия и производительности.
Ещё раз, "расшифровать и понять" - это не задача каждого из исполнителей. Да и не полная эта задача, как минимум ещё предложить решение остаётся со всеми граничными условиями.
И с последним много нюансов бывает у заказчика, очевидное для вас, может быть совсем неочевидным для него, а ещё моральные стороны вопроса при решении, сроки и т.п.
Понять очень сложно, если вы не считаете что-то проблемой или минимум её надуманность не вызывает у вас сомнений, а брать заказы нужно.
Достаточно часто встречает ситуация, когда принесенная проблема заказчиком вовсе не проблема, зато реальная проблема стоит рядом. Вот в последнем и надо переубедить заказчика, выставить перед ним цепь взаимосвязей. И как правило, при этом ты выяснишь, что заказчик может оказаться неадекватным идиотом. И будешь реализовывать его полурешение, которое с заранее известным результатом не поможет его проблеме. Но вникать в тонскости своего же бизнес-процесса он не захочет, чтобы говорить с тобой предметно. Такое встречается сплошь и рядом. Увы! Хотя конечно не с каждым первым. Но это видео как раз про этих вторых.
Вот мы и вошли в прямую рекурсию, что даже для оценки консалтинговых услуг нужны собственные компетенции.
Бизнес может и наелся "консалтингом", но он сам всегда хотел подешевле, а хорошее дешево стоить не может, в отличии от плохого, которое от цены не зависит. Сам бизнес не вырастил "культуру имени" или авторитетности, если хотите, поэтому и платить за неё не согласен.
П.С. 1-2 готовых спецов сейчас не найти, спрос намного шире. Много вы конструкторов знаете с пониманием литья под давление и штамповки?
В том и дело, что понятие "инженер" было давно и долго унижаемо, куда выгоднее идти в менеджеры или вайтишником. В результате, есть целое поколение недоинженеров, среди которого лишь редкие кадры представляют ценность, но они все заняты и к ним уже не пробиться со своими бизнес-идеями.
А у того же конструктора прессформ, как у хирурга, на становлении есть своё кладбище прессформ, которое намного дороже суммы его зарплат в этот период становления, поэтому никто в это вкладываться не хочет.
Вам никогда не приходилось писать часть приложения, когда общую решаемую проблему бизнеса вам не только не рассказали, но и категорически отказываются это делать сейчас и в будущем?
И нет, не задача всех присутствующих сторон исполнителя понять проблему. Иногда это невозможно в силу специфики задач. Рамки ответственности должны быть описаны в твоём контракте. Задача исполнителей сделать свой бизнес прибыльным даже решая несуществующие проблемы, иногда их придумывать самим и возглавлять тренды.
Понять проблему - это не задача эксперта. Эксперт предоставляет экспертную оценку, а не анализ проблем клиента. Иначе чем тогда занимает бизнес-аналитик? У вас ПМ - это продакт-менеджер или проджект-менеджер? Задачи и методы у последних тоже разные.
Вот вы и смогли разделить понятия верификации (выполнение формальных требований) и валидации (выполнение довольства продукцией). А следовательно и отличие QC (в первом варианте) от QA.
Виноват! Варкрафт имелся в виду 3-й.