Это вы очень зря про доверие. Смотреть по сделанной работе - это если у вас есть КПИ, строчки кода и т.д., иначе руководство должно разбираться в КАЖДОЙ узконаправленной должности и понимать ценность сделанной работы, а ещё важнее в творческой составляющей. И это совсем уж оторвано от реальности. Это как по количеству нот судить о музыкальном произведении.
В любом случае команда увидит, кто ничего не делает и будет требовать результат.
Это если вы работаете командами а ля Скрам и т.п., это частный случай! А ведь разработка бывает не только в АйТи.
Если трекер делает скрин экрана, то это большой перебор. Следить чтобы работник работал - 8 часов, тоже перебор.
Перебор через что? Зависит от задачи и методов поощерения или наказания. Если вам укажут на исследования, которые подтвеждают, что отвлечения на другие задачи мешает достижению результата, то что вы в ответ аргументируете? Сам автор говорит, что офис его отвлекает, а дом этого нет. Противоречим сами себе получается.
Ну давайте представим, что вам во время операции хирург вдруг бросает всё и уходит, мотивируя, что это перебор. Есть виды работ, где это необходимо, охранник за пультом, например, а лучше представьте себе авиадиспетчера. Только 21 век во многих профессиях ещё не настал и вряд ли настанет так быстро.
И первое препятствие - это отсутствие умения объективно оценивать работу. Но так мы с вами до "Капитала" договоримся.
Процессы, которые были на заводах в 20-ом веке могут не работать сейчас и это нормально.
Интересно, а куда делись эти заводы сейчас и про какие неработающие процессы идёт речь? На заводах стали работать по удалёнке?
Сейчас есть огромное количество способов грамотно следить за эффективностью команды.
Так приведите их и обоснуйте чем они лучше.
Полагаю, что главная ценность — это вовремя доставлять функциональности приложений и сервисов.
Бизнес - это про деньги, маркетинг - это про подсаживание на постоянные траты для вашего продукта. А тут я вижу какой-то юношеский максимализм. Вы правда считаете, что всегда нужно делать приложения без багов? Тогда вы остались в нулевых. ;)
Трекинг ведут не для постоянного отслеживания, а для анализа, если вдруг такой понадобится. Удобнее, чем табличка в Экселе. Всегда лучше спросить сотрудника почему он потратил на некий проект так много времени и если уровень открытости высокий, то он может сказать, что просто не хватало сил и энергии. А если он это боится сделать, то виноват не сам трекинг, а стиль руководства. Вот с последнего и надо начинать, а не лечить симптомы.
Поучавствуйте в хоть одном турнире спидмоделинга, тогда поймёте, что АвтоКАД даже часть задач решить не может, не говоря о том, что в построении моделей он никем в здравом уме пользоваться не может, а главное, самой AutoDesk не нужно было бы выпускать свой Inventor вслед за поездом SolidWorks.
Так проблема не только в САПРах, а ещё и в куче проектов и всей документации, которая в них сделана. Кто это всё будет переносить и за чей счёт?! Кто и за чей счёт будет писать новые САПРы, когда и сейчас очень тяжело идёт стыковка реальных пользователей из конструкторов и программистов, поскольку последним тяжело даже поверхностно понять процессы проектирования?! А главное, кто будет обучать всему новому, если этого не организовать за год-другой?! А кто будет поддерживать уже существующие проекты?!
Это только, если нужен велосипед, а посложнее как мне CAD-система с CAE и DB-модулями, сдобренная связью с ERP и аналитикой BI, да под корпоративную PDM и проводкой процессов к каждому клиенту в CRM. Такой космический корабль долго собирать будешь, а уже завтра все компоненты станут новыми и долгострой никому не нужен.
/ Удачи вам с командной строкой и к примеру, с солидворксом.
Кстати, да! СолидВоркс ни на Маке, ни на Линуксе не работает. Да и вообще на Линуксе КАД-систем, как говорится, днём с огнём. Как они пласт инженеров собираются обучать, которые и мышку, и клавиатуру им проектируют. Создавать с нуля математические ядра... годы и годы, если кто-то группой из уникальных математиков мира согласится взглянуть на Линукс, но за бесплатно этого точно не будет.
С всего одним тикетом график SLA TV (72ч.) совсем неинформативный. И если у вас вначале запросы приходят в саппорт, а потом вы учитываете время простоя до взятия в работу этого тикета, то это уже не SLA, а OLA между отделами. Если это у вас разные юрисдикции к тому же, то и вовсе превращаются в UC.
Сменить тип можно и в Джаве... но конечно эта инфа не для новичков. И это очень правильный подход! О тёмной стороне Джавы можно потом узнать, когда с основами разобрались и фреймворки потрогали.
Универсальность (код при переносе одинаково срабатывает на Windows, Linux, MacOS, Android и для этого ничего не надо, кроме установленного интерпретатора языка);
Правильно ли я понял, что Джаву лишили кроссплатформенности в обзоре? По мне очень смело!
Не увидел хотя бы поверхностные хард скиллы в направлениях команды. Эстимировать задачи в отраслях, в которых ты ничего не понимаешь, явно не путь начинающих.
Так же за бортом зоны ответственности и разруливание конфликтов.
Хаос-менеджмент по тому же Фридману, - планируем нынешний день вчера вечером и никакого "утром". Утром свежий мозг погружается в решение задач, а не распыляется на все задачи.
Самое интересное, что ладно бы информацию правильную предоставляли, а для 100 грамм жиров написали соответствующее количество ккал-ий, так ведь до сотни ккал и округлили, а то и вовсе не знают более точные цифры.
а цех ковриков на заводе Фольксваген может простаивать вместе со всеми работниками, когда идёт спад продаж.
И кстати, некоторые цеха простаивают, если вы не в курсе! Однако, при проектировании у них есть система, где одни инженеры проверяют оси под изделие, другие проектируют само изделие на основе дизайна третьих и по методичкам с технологическими ограничениями четвёртых, специализируясь лишь на однообразных смежных технологиях, а зачастую отдавая концепт именно для перепроектирования изготовителям. Именно затем, что экономят на содержании инженеров, которые знают все-все технологии и их особенности, каковых очень мало, поскольку таких можно взрастить только на самом производстве, а не за студенческой скамьёй. И так работает всё автомобилестроение с серийным производством. Не надо мне рассказывать как и что делается, мной лично перепроектированных деталей вы можете найти почти во всех знаменитых западных марках автомобилей и процессы я знаю изнутри. Но что хуже, вы упорно не хотите адекватно воспринимать информацию.
Это дорого, сложно, не нужно на каждый день, не понятно как управлять. Вывод: выделение конструкторского бюро на аутсорс - отличный инструмент в том случае, если проектирование не является областью вашей экспертизы (т.е. вы сами не являетесь конструкторским бюро).
Плохой вывод... Готовы спроектировать автомобиль для VW? А задумайтесь почему?
П.С. опять съезжаете с темы поддержки предпринимателя то в космос, то в автомобилестроение. С КД по ГОСТу лучше не упоминать о пещерах тем, кто работал исключительно по 3Д-моделям до того, как в ГОСТ вообще попал термин ЭМИ.
Однако, вывод очень простой, если у вас нет выходов на производителей или сами изготовители к вам не идут, то КБ в виде аутсорса - это или узкоспециализированные конторы, или кот в мешке с соответствующей лотереей по качеству, заодно с проблемами по оформлению ТЗ, которые ложатся на плечи предпринимателя.
Продакт-менеджмент? Не, не слышали... у нас диаграммы Ганта и чёткое ТЗ.
А что есть "новый продукт"? Если мы проектируем токарный станок с ЧПУ, например, то это новое изделие или это реверс и сборная солянка из существующих станков?
А что есть "проектируем"? А давайте разбираться действительно, чтобы понять разницу между терминами, которые очевидны для упомянутого вами "интересующегося предпринимателя".
И так, если ваше изделие выходит на рынок и занимает свою нишу без аналогов, то это новый продукт. Ведь проект для него начинается с идеи, понимания необходимости продукта или спроса, а так же финансовой выгоды. ТЗ формируется в процессе разработки, зато продукт выйдет таким, какой он нужен рынку, а не по заложенному ТЗ некоторое время назад. И вот это, возьму на себя смелость, я бы назвал проектированием. А когда вам спускают ТЗ на токарный станок и указывают, что он должен обрабатывать детали до Н-диаметра и длиной Л-метров, то это конструирование. Для бизнеса в этом существенная разница. Предлагаю, чтобы понять о чём я, то стоит ознакомиться с разными подходами по работе на запросы от клиентов по RFQ, RFI, RFP.
Ну и "сборная солянка" вам же хорошо известна в виде этого термина. Собираете же их из известных составляющих. И это отнюдь неплохо, поскольку стандартизированные компоненты позволяют обеспечить вменяемую цену и ремонтопригодность. Я не с позиции, что вы делаете плохо, я скорее об очертании ваших задач. И если вам надо будет сделать токарный станок с длиной обработки +5 метров, то скорее всего вы просто модифицируете первую версию. И это будет модифицированный продукт, а не новый.
Возможно, что у вас и есть экспертиза в новых проектах, о чём будет рассказано в новой статье про маркетинг КБ. Но пока об этом ни слова. Вы делаете проекты в известном окружении.
Есть-ли там такое количество новых вводных, которые не позволяют сделать планирование по Ганту?
Но если вы ссылаетесь на красивые кабинеты для ИТ-специалистов, то попробуйте узнать как у них ведут проекты, начните с SDLC, а потом и до Scrum-а доберётесь, а уж там расписано сравнение методик с тем же "водопадом". Видите ли, у вас единичные изделия, а у серийных или массовых даже смена количества является новой вводной. Вот я и пытаюсь понять охват ваших проектов. Ничего более.
Без технического проекта ни одна производственная компания сроков, цены и возможности изготовления не назовёт. Поэтому схематика изготовления сложных продуктов всегда была такой:
И первое предложение неправда, и второе, хотя бы по тому, что ГОСТ не действует во всём мире, да и откровенно говоря зачастую списан с ДИН-ов, реже ИСО и т.д., но с жуткими бюрократическими добавлениями, которые убивают бизнес и сроки в проекте, в частности. Я смею так утверждать, поскольку работал в вашей должности и там (по ГОСТу), и там(в Европе), хотя конечно это опыт всего лишь одного человека. Однако, работа с Китаем в каждом втором случае идёт без технического проекта и они дают сроки даже на основе концепта, а потом ещё и успевают их выдержать. Магия!
которое проектирует различные механизмы для космоса. По вашему их надо ликвидировать, раз они чертят в отрыве от производства?
И сколько потом доработок по технологическим причинам приходится делать, сдвигать сроки, выпускать "качественную" продукцию. Вы на меня авторитетами не повлияете, это отсутствие конкуренции конкретно в РФ на такого рода задачи и про предпринимательство тут надо молчать кроме умений рОспила. А лучше всё же съездить на воплощение ваших проектов на том же заводе Хруничева и ужаснуться. Этак мы скоро на шаражки вернём конструкторов во благо освоения Космоса. Это конечно хорошо, когда под ваше "надо" слепят на идейных соображениях новую технологию, но я бы не назвал это отличным проектом, уж простите. Думаю, что Маск со мной согласится, а в РФ своего не появится из-за этого же.
С другой стороны 90% наших клиентов - это и есть сами производства, конструкторские отделы которых по тем или иным причинам "не тянут" объём работ, который на них спускают.
Вот теперь понятнее, что работа основана на потребностях изготовителей, а не на потребности предпринимателей с в воздухе нарисованной руками идеей. Ещё раз, это не укор. Ваша ниша существования КБ понятна, вы позволяете эффективнее использовать ресурсы собственных конструкторов производственникам, срезаете пики их загруженности. Наверняка у вас и специализация под эти производства, явно технологические ограничения вы можете быстро получить по запросу к их технологам. Меня же больше интересует развитие КБ под задачи стартапов и менеджмент подобных задач.
Впрочем, за вас я рад, что действительно не плодите бездельников на заводах с низкой загруженностью и соответственно зарплатой, а позволяете, надеюсь, заработать за активное исполнение своих задач.
Макс Дорофеев конечно прекрасен в подаче материалов, но ведение проектов в Асане по "водопаду" - это только реверс-инжиниринг без создания нового продукта с кучей новых "вводных" в течении всего проекта. Где же итеративная разработка?
1С ввели в качестве ERP-системы, очень странно, что её не было раньше, а ПДМ был. Очень похоже на существование технаря в роли первого и последующего руководителя. А это совсем не жилка предпринимателя, но передача опыта реальным предпринимателям конечно же будет очень ценной.
5% занимаются предпринимательством, а сколько процентов составляются эти самые инженеры-конструктора, явно доли процента и на два порядка меньше.
И последнее. Очень плохо, что ваши проекты создаются без привязки к технологии производства. Я бы сказал, что качество проектов от этого никогда не сможет быть отличным или оптимизированным. Как в строительстве идёт разделение на тех, кто фантазирует с КМ разделом, а потом на местах изготовления дорабатывают вторым этапом в КМД. Естественно, если у вас жёсткий реверс-инжиниринг с исключительно машиностроительными детальками, то там понятно, но новые продукты под бизнес - это смесь технологий и отраслей. Вот последнее особенно ценно смотреть вкупе. А пока я вижу специализированное КБ на однотипных задачах, во всяком случае нечто листово-сварочное на мет.каркасе с навесами, но без, например, технологии литья пластика под давлением или электронных блоков управления. И главный вопрос при наличии всех подобных вещей в ведении проектов, базе технологических ограничений и достатка ресурсов под специфические редкие задачи, а так же сохранении ноу-хау продуктов.
Тогда вообще надо смотреть в сторону видеокарт Quadro. А то это и вовсе никто не упомянул, хотя собирают компы для КАД-систем. Лучше консультироваться в этой сфере не со сборщиками, а с теми, кто реально работает в этом самом 3Д-моделировании. Да и понятие это слишком широкое и везде свои нюансы.
П.С. самое плохое, что нет чёткого тех.задания и почти полная неопределённость под какие задачи и ПО берётся компьютер. Одного понятия газопровод недостаточно.
И уж тем более с переходом на 3Д-моделирование, чтобы хватило на 5 лет, задача крайне бесперспективная, таких конфигураций личного ПК уже нет, уже сегодня не хватает мощностей.
"У себя дома" и профессия - это совсем разные понятия. Вам не только делать надо сантехнику с нуля, а работать на аварии, где всё прогнило, сделано кем-то другим и через одно место, а у вас ни времени, ни финансовых ресурсов.
Так что у сантехников работа не такая лёгкая, а инструменты они отфильтровывают годами, как и понимание, да море ноухау из г..на и палок.
Учится и уметь - это тоже разные понятия. Если на объекте предыдущим кулибиным оставлен конец с NPTF, снабжение вам привезло втулку с BSPT, а в кармане только метрический метчик, то гугл вам не поможет, как и обучение, тут опыт нужен.
А самое главное, что у большинства программистов не хватит тактильных навыков для затяжек, а то и вовсе сил, причём моральных в том числе после копания в дерьме день за днём.
Я бы сказал, что только 10% программеров, что и так тянут по ночам упавшиеся системы, особенно банковские, где простой миллионами капает за каждый час, но при этом часть смузи-айтишников впадают в обморок или ступор. Последние как неприспособленные к стрессовым ситуациям и в душе социофобы - не смогут проработать долго с остальным населением в контакте.
Ну и зарплатная часть - это жить на такую зарплату надо ещё смочь под директивным управлением с матами, что уже недоступно много программистам. Иначе упрощая, я могу утверждать, что просто бить по клавишам сможет точно 90% сантехников.
А мне материал понравился, простым языком поясняется проблема и ошибка у топ-менеджмента по внедрению ОКР. Самое интересное, что для некоторых отделов практически нереально определить KPI, там внедряют SLA, OLA, UC с приоритиризацией задач. Вот об этом опыте хотелось бы услышать побольше.
Это вы очень зря про доверие. Смотреть по сделанной работе - это если у вас есть КПИ, строчки кода и т.д., иначе руководство должно разбираться в КАЖДОЙ узконаправленной должности и понимать ценность сделанной работы, а ещё важнее в творческой составляющей. И это совсем уж оторвано от реальности. Это как по количеству нот судить о музыкальном произведении.
Это если вы работаете командами а ля Скрам и т.п., это частный случай! А ведь разработка бывает не только в АйТи.
Перебор через что? Зависит от задачи и методов поощерения или наказания. Если вам укажут на исследования, которые подтвеждают, что отвлечения на другие задачи мешает достижению результата, то что вы в ответ аргументируете? Сам автор говорит, что офис его отвлекает, а дом этого нет. Противоречим сами себе получается.
Ну давайте представим, что вам во время операции хирург вдруг бросает всё и уходит, мотивируя, что это перебор. Есть виды работ, где это необходимо, охранник за пультом, например, а лучше представьте себе авиадиспетчера. Только 21 век во многих профессиях ещё не настал и вряд ли настанет так быстро.
И первое препятствие - это отсутствие умения объективно оценивать работу. Но так мы с вами до "Капитала" договоримся.
Интересно, а куда делись эти заводы сейчас и про какие неработающие процессы идёт речь? На заводах стали работать по удалёнке?
Так приведите их и обоснуйте чем они лучше.
Бизнес - это про деньги, маркетинг - это про подсаживание на постоянные траты для вашего продукта. А тут я вижу какой-то юношеский максимализм. Вы правда считаете, что всегда нужно делать приложения без багов? Тогда вы остались в нулевых. ;)
Трекинг ведут не для постоянного отслеживания, а для анализа, если вдруг такой понадобится. Удобнее, чем табличка в Экселе. Всегда лучше спросить сотрудника почему он потратил на некий проект так много времени и если уровень открытости высокий, то он может сказать, что просто не хватало сил и энергии. А если он это боится сделать, то виноват не сам трекинг, а стиль руководства. Вот с последнего и надо начинать, а не лечить симптомы.
Поучавствуйте в хоть одном турнире спидмоделинга, тогда поймёте, что АвтоКАД даже часть задач решить не может, не говоря о том, что в построении моделей он никем в здравом уме пользоваться не может, а главное, самой AutoDesk не нужно было бы выпускать свой Inventor вслед за поездом SolidWorks.
Так проблема не только в САПРах, а ещё и в куче проектов и всей документации, которая в них сделана. Кто это всё будет переносить и за чей счёт?! Кто и за чей счёт будет писать новые САПРы, когда и сейчас очень тяжело идёт стыковка реальных пользователей из конструкторов и программистов, поскольку последним тяжело даже поверхностно понять процессы проектирования?! А главное, кто будет обучать всему новому, если этого не организовать за год-другой?! А кто будет поддерживать уже существующие проекты?!
Вопросов много, но идеологам не до реализации.
Это только, если нужен велосипед, а посложнее как мне CAD-система с CAE и DB-модулями, сдобренная связью с ERP и аналитикой BI, да под корпоративную PDM и проводкой процессов к каждому клиенту в CRM. Такой космический корабль долго собирать будешь, а уже завтра все компоненты станут новыми и долгострой никому не нужен.
/ Удачи вам с командной строкой и к примеру, с солидворксом.
Кстати, да! СолидВоркс ни на Маке, ни на Линуксе не работает. Да и вообще на Линуксе КАД-систем, как говорится, днём с огнём. Как они пласт инженеров собираются обучать, которые и мышку, и клавиатуру им проектируют. Создавать с нуля математические ядра... годы и годы, если кто-то группой из уникальных математиков мира согласится взглянуть на Линукс, но за бесплатно этого точно не будет.
С всего одним тикетом график SLA TV (72ч.) совсем неинформативный. И если у вас вначале запросы приходят в саппорт, а потом вы учитываете время простоя до взятия в работу этого тикета, то это уже не SLA, а OLA между отделами. Если это у вас разные юрисдикции к тому же, то и вовсе превращаются в UC.
Сменить тип можно и в Джаве... но конечно эта инфа не для новичков. И это очень правильный подход! О тёмной стороне Джавы можно потом узнать, когда с основами разобрались и фреймворки потрогали.
Правильно ли я понял, что Джаву лишили кроссплатформенности в обзоре? По мне очень смело!
Не увидел хотя бы поверхностные хард скиллы в направлениях команды. Эстимировать задачи в отраслях, в которых ты ничего не понимаешь, явно не путь начинающих.
Так же за бортом зоны ответственности и разруливание конфликтов.
Хаос-менеджмент по тому же Фридману, - планируем нынешний день вчера вечером и никакого "утром". Утром свежий мозг погружается в решение задач, а не распыляется на все задачи.
Самое интересное, что ладно бы информацию правильную предоставляли, а для 100 грамм жиров написали соответствующее количество ккал-ий, так ведь до сотни ккал и округлили, а то и вовсе не знают более точные цифры.
И кстати, некоторые цеха простаивают, если вы не в курсе! Однако, при проектировании у них есть система, где одни инженеры проверяют оси под изделие, другие проектируют само изделие на основе дизайна третьих и по методичкам с технологическими ограничениями четвёртых, специализируясь лишь на однообразных смежных технологиях, а зачастую отдавая концепт именно для перепроектирования изготовителям. Именно затем, что экономят на содержании инженеров, которые знают все-все технологии и их особенности, каковых очень мало, поскольку таких можно взрастить только на самом производстве, а не за студенческой скамьёй. И так работает всё автомобилестроение с серийным производством. Не надо мне рассказывать как и что делается, мной лично перепроектированных деталей вы можете найти почти во всех знаменитых западных марках автомобилей и процессы я знаю изнутри. Но что хуже, вы упорно не хотите адекватно воспринимать информацию.
Плохой вывод... Готовы спроектировать автомобиль для VW? А задумайтесь почему?
П.С. опять съезжаете с темы поддержки предпринимателя то в космос, то в автомобилестроение. С КД по ГОСТу лучше не упоминать о пещерах тем, кто работал исключительно по 3Д-моделям до того, как в ГОСТ вообще попал термин ЭМИ.
Однако, вывод очень простой, если у вас нет выходов на производителей или сами изготовители к вам не идут, то КБ в виде аутсорса - это или узкоспециализированные конторы, или кот в мешке с соответствующей лотереей по качеству, заодно с проблемами по оформлению ТЗ, которые ложатся на плечи предпринимателя.
Продакт-менеджмент? Не, не слышали... у нас диаграммы Ганта и чёткое ТЗ.
Эффект плато - это даже не болезнь, скорее часто встречающийся эффект при похудении. Организм заточен на выживание, а не на создание красивого тела.
А что есть "проектируем"? А давайте разбираться действительно, чтобы понять разницу между терминами, которые очевидны для упомянутого вами "интересующегося предпринимателя".
И так, если ваше изделие выходит на рынок и занимает свою нишу без аналогов, то это новый продукт. Ведь проект для него начинается с идеи, понимания необходимости продукта или спроса, а так же финансовой выгоды. ТЗ формируется в процессе разработки, зато продукт выйдет таким, какой он нужен рынку, а не по заложенному ТЗ некоторое время назад. И вот это, возьму на себя смелость, я бы назвал проектированием. А когда вам спускают ТЗ на токарный станок и указывают, что он должен обрабатывать детали до Н-диаметра и длиной Л-метров, то это конструирование. Для бизнеса в этом существенная разница. Предлагаю, чтобы понять о чём я, то стоит ознакомиться с разными подходами по работе на запросы от клиентов по RFQ, RFI, RFP.
Ну и "сборная солянка" вам же хорошо известна в виде этого термина. Собираете же их из известных составляющих. И это отнюдь неплохо, поскольку стандартизированные компоненты позволяют обеспечить вменяемую цену и ремонтопригодность. Я не с позиции, что вы делаете плохо, я скорее об очертании ваших задач. И если вам надо будет сделать токарный станок с длиной обработки +5 метров, то скорее всего вы просто модифицируете первую версию. И это будет модифицированный продукт, а не новый.
Возможно, что у вас и есть экспертиза в новых проектах, о чём будет рассказано в новой статье про маркетинг КБ. Но пока об этом ни слова. Вы делаете проекты в известном окружении.
Но если вы ссылаетесь на красивые кабинеты для ИТ-специалистов, то попробуйте узнать как у них ведут проекты, начните с SDLC, а потом и до Scrum-а доберётесь, а уж там расписано сравнение методик с тем же "водопадом". Видите ли, у вас единичные изделия, а у серийных или массовых даже смена количества является новой вводной. Вот я и пытаюсь понять охват ваших проектов. Ничего более.
И первое предложение неправда, и второе, хотя бы по тому, что ГОСТ не действует во всём мире, да и откровенно говоря зачастую списан с ДИН-ов, реже ИСО и т.д., но с жуткими бюрократическими добавлениями, которые убивают бизнес и сроки в проекте, в частности. Я смею так утверждать, поскольку работал в вашей должности и там (по ГОСТу), и там(в Европе), хотя конечно это опыт всего лишь одного человека. Однако, работа с Китаем в каждом втором случае идёт без технического проекта и они дают сроки даже на основе концепта, а потом ещё и успевают их выдержать. Магия!
И сколько потом доработок по технологическим причинам приходится делать, сдвигать сроки, выпускать "качественную" продукцию. Вы на меня авторитетами не повлияете, это отсутствие конкуренции конкретно в РФ на такого рода задачи и про предпринимательство тут надо молчать кроме умений рОспила. А лучше всё же съездить на воплощение ваших проектов на том же заводе Хруничева и ужаснуться. Этак мы скоро на шаражки вернём конструкторов во благо освоения Космоса. Это конечно хорошо, когда под ваше "надо" слепят на идейных соображениях новую технологию, но я бы не назвал это отличным проектом, уж простите. Думаю, что Маск со мной согласится, а в РФ своего не появится из-за этого же.
Вот теперь понятнее, что работа основана на потребностях изготовителей, а не на потребности предпринимателей с в воздухе нарисованной руками идеей. Ещё раз, это не укор. Ваша ниша существования КБ понятна, вы позволяете эффективнее использовать ресурсы собственных конструкторов производственникам, срезаете пики их загруженности. Наверняка у вас и специализация под эти производства, явно технологические ограничения вы можете быстро получить по запросу к их технологам. Меня же больше интересует развитие КБ под задачи стартапов и менеджмент подобных задач.
Впрочем, за вас я рад, что действительно не плодите бездельников на заводах с низкой загруженностью и соответственно зарплатой, а позволяете, надеюсь, заработать за активное исполнение своих задач.
Макс Дорофеев конечно прекрасен в подаче материалов, но ведение проектов в Асане по "водопаду" - это только реверс-инжиниринг без создания нового продукта с кучей новых "вводных" в течении всего проекта. Где же итеративная разработка?
1С ввели в качестве ERP-системы, очень странно, что её не было раньше, а ПДМ был. Очень похоже на существование технаря в роли первого и последующего руководителя. А это совсем не жилка предпринимателя, но передача опыта реальным предпринимателям конечно же будет очень ценной.
5% занимаются предпринимательством, а сколько процентов составляются эти самые инженеры-конструктора, явно доли процента и на два порядка меньше.
И последнее. Очень плохо, что ваши проекты создаются без привязки к технологии производства. Я бы сказал, что качество проектов от этого никогда не сможет быть отличным или оптимизированным. Как в строительстве идёт разделение на тех, кто фантазирует с КМ разделом, а потом на местах изготовления дорабатывают вторым этапом в КМД. Естественно, если у вас жёсткий реверс-инжиниринг с исключительно машиностроительными детальками, то там понятно, но новые продукты под бизнес - это смесь технологий и отраслей. Вот последнее особенно ценно смотреть вкупе. А пока я вижу специализированное КБ на однотипных задачах, во всяком случае нечто листово-сварочное на мет.каркасе с навесами, но без, например, технологии литья пластика под давлением или электронных блоков управления. И главный вопрос при наличии всех подобных вещей в ведении проектов, базе технологических ограничений и достатка ресурсов под специфические редкие задачи, а так же сохранении ноу-хау продуктов.
Тогда вообще надо смотреть в сторону видеокарт Quadro. А то это и вовсе никто не упомянул, хотя собирают компы для КАД-систем. Лучше консультироваться в этой сфере не со сборщиками, а с теми, кто реально работает в этом самом 3Д-моделировании. Да и понятие это слишком широкое и везде свои нюансы.
П.С. самое плохое, что нет чёткого тех.задания и почти полная неопределённость под какие задачи и ПО берётся компьютер. Одного понятия газопровод недостаточно.
И уж тем более с переходом на 3Д-моделирование, чтобы хватило на 5 лет, задача крайне бесперспективная, таких конфигураций личного ПК уже нет, уже сегодня не хватает мощностей.
При этом, даже если родители не согласны, то "защитникам прав детей" виднее что нужно детям, а родителей лишить прав, если не согласны.
Это точно, наличка мешает многим, лучше чипировать и под полный контроль с рождения.
"У себя дома" и профессия - это совсем разные понятия. Вам не только делать надо сантехнику с нуля, а работать на аварии, где всё прогнило, сделано кем-то другим и через одно место, а у вас ни времени, ни финансовых ресурсов.
Так что у сантехников работа не такая лёгкая, а инструменты они отфильтровывают годами, как и понимание, да море ноухау из г..на и палок.
Учится и уметь - это тоже разные понятия. Если на объекте предыдущим кулибиным оставлен конец с NPTF, снабжение вам привезло втулку с BSPT, а в кармане только метрический метчик, то гугл вам не поможет, как и обучение, тут опыт нужен.
А самое главное, что у большинства программистов не хватит тактильных навыков для затяжек, а то и вовсе сил, причём моральных в том числе после копания в дерьме день за днём.
Я бы сказал, что только 10% программеров, что и так тянут по ночам упавшиеся системы, особенно банковские, где простой миллионами капает за каждый час, но при этом часть смузи-айтишников впадают в обморок или ступор. Последние как неприспособленные к стрессовым ситуациям и в душе социофобы - не смогут проработать долго с остальным населением в контакте.
Ну и зарплатная часть - это жить на такую зарплату надо ещё смочь под директивным управлением с матами, что уже недоступно много программистам. Иначе упрощая, я могу утверждать, что просто бить по клавишам сможет точно 90% сантехников.
А мне материал понравился, простым языком поясняется проблема и ошибка у топ-менеджмента по внедрению ОКР. Самое интересное, что для некоторых отделов практически нереально определить KPI, там внедряют SLA, OLA, UC с приоритиризацией задач. Вот об этом опыте хотелось бы услышать побольше.