Comments 570
Как сказано ниже «это проблема приемки»
Не знаю, правда ли, но, говорят, французские танки имеют сходную надежность, и до поломки накатывают километров 60-100 — так, что их даже на учения возят только трейлерами, от греха.
Думаю выгода там и в преодолении пересеченной месности: лес, склоны, брод, поле, трасса
Невыгодно. Гусеничный движитель — вовсе не образец эффективности. У вполне гражданского, и довольно легкого ГТС-М (двигатель от ГАЗ-66) пробег до капремонта составляет, емнип, 5000 км. Танк и тяжелее, и дороже, и требования к двигателю у него повыше.
Но основное назначение танка, как бы странно это не звучало, вовсе не те пятнадцать минут гипотетического боя. Основное назначение танка — боевая учеба, именно ей на танке занимаются долгие годы. А это занятие, как ни крути, связано с расходом моторесурса: чтобы учиться, надо ездить и ездить.
Поэтому на полигон своим ходом — тоже оправдано.
Да и половину Конкорда французы делали :)
Танки, конечно, разбивают дорогу быстрее, чем колесная техника, а тяжелая колесная техника делает это быстрее, чем легковушки, но если асфальт положен правильно, то периодические проезды современного танка сильно ему не повредят.
Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
Единственная причина, по которой танки катают на трейлерах (кстати, если и быстрее собственного хода танка, то ненамного) — высокая стоимость покатушек танка своим ходом, что проистекает из трех составляющих: малый ресурс ходовой части (как у любой тяжелой гусеничной техники), большой расход горючки (как не в себя) и (в мирное время) необходимость дополнительных мероприятий по обеспечению безлпасности движения (танки "забыли" оснастить хорошим обзором для мехвода и сигналами поворота и остановки).
Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.а если разрешённая скорость — 120?
В остальном — так и есть.
Маловероятно. Самые шустрые танки из распространенных по достаточно твердой и ровной поверхности делают до 80.
Так что либо скорость преувеличили, либо спидометр врал (кстати говорят, что спидометры завышают показания скорости, чтобы не превышали).
Или случилось чудо и они встретили Т-15, который может больше 80, но это маловероятно.
Ничего против французской техники не имею. Но заявленная вами надежность ИМХО не очень реальна. Откуда такие данные? Катастрофа из-за отказа двигателя и отказ двигателя — разные вещи. Открытую статистику отказов военного самолета сложно представить.
A3-79 — отказ двигателя в полете, самолет потерян, пилот погиб
A3-4, A3-18, A3-28, A3-46, A3-52, A3-67, A3-70, A3-82, A3-94, A3-95 — отказ двигателя в полете, самолет потерян, пилот успешно катапультировался
A3-97 — отказ двигателя в полете, самолет поврежден, пилот не постардал
A3-2, A3-41 — отказ двигателя в полете, пилот успешно посадил самолет
A3-63 — разрушение двигателя при опрбовании на земле, пилот не пострадал
A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался
Итого 15 серьезных происшествий по вине двигателя. И это только один тип и одна страна c 116 закупленными самолетами. А были еще Mirage IV, 5, F-1, 2000 — всего порядка 3500 выпущенных.
A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался
Ну тут как бы немного не вина двигателя. Не удивлюсь, если и среди остальных проишествий имеются спорные моменты, связанные с возможной неправильной эксплуатацией.
Я всеже думаю что имеется в виду Rafale с M88 у которых ЕМНИП небыло серьезных происшествий по вине двигателей. Но Rafale двухдвигательный и суммарный налет парка не очень большой.
Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд.
Как житель Донецка, могу сказать однозначно: это миф. Танки и САУ, конечно, оставляют царапины на асфальте, но никакого сколь-нибудь заметного вреда ему не наносят. Наверное, если взять полуразвалившуюся дорогу без основы, её и размолотят. Но по обычной нормальной городской дороге хоть сто танков проедет, ничего особого ей не делается, кроме вот таких царапин:
pbs.twimg.com/media/BsqqrOsCEAAoc3-.jpg
Плиты прочнее асфальта, и не подвержены разрушению от воды.
Затем, что до поля боя еще нужно доехать и это будет совсем не катание до полигона.
Как думаете, какое среднее время танка с отказавшим двигателем в бою?
Это вроде вообще статистика по боям во время второй мировой войны. С того момента живучесть танков значительно повысилась. Да и пехоты тоже.
Зачем ему ради 15 минут супернадежный двигатель?
Потому что не каждый бой это Курская дуга, до первого серьезного боя может быть несколько недель маневров, ну и среднее время жизни это как и среднее время пехотинца в бою (которое тоже что-то минут 10), кто-то погибает в первой минуте первого боя, кто-то проходит всю войну от начала до конца.
Это нужно спросить у французов, в суперджете их двигатели
Доля НПО «Сатурн» в совместном предприятии составляет 49,84%.
Доля НПО «Сатурн» в общем объёме работ над двигателем SaM146 составляет около 38%.
Пока что списывают на то, что французы не умеют делать камеру сгорания, но, по странному стечению обстоятельств, это — именно та версия, которая устраивает всех. По ещё более странному стечению обстоятельств, о проблемах с двигателем известно только из Ведомостей и их источников: никто из незаинтересованных лиц проверить слив не смог.
Так или иначе,
Мы испытываем мощнейшие сложности, связанные с нашим партнерством с французскими партнерами по двигателю SaM146. У коллег жесткая бизнес-модель и идти на симметричные снижения стоимости владения двигателем они не готовы. Разбирая все проблемы эксплуатации двигателя с региональными компаниями, мы видим, что и они пользуются сложившейся ситуацией, стремятся занять более выгодное для себя положение, в наших спорах с французами. (Фотография очень грустного кота) Мы понимаем, что нам надо создать банк подменных двигателей. Такая программа у ОДК есть. Документацию на полную разборку/сборку двигателей на территории рыбинского завода мы получили. Первый двигатель там уже полностью отремонтирован, то есть, разобран-собран. Вопрос коммерческий – идет торговля, за сколько мы с французами сговоримся. Мы понимаем, что условия, которые они выставляют по покупке/аренде подменных двигателей у компании PowerJet, неприемлемы для российских региональных авиакомпаний. Просто не приемлемы и все. А качество самого двигателя вне гарантийного срока и внутри гарантийного срока, вызывает вопросы по горячей части (горячая часть — французская производственная зона ответственности). С этим двигателем нам все равно жить и дальше. Это решение предшествующих периодов и никто не мог знать, что оно так пойдет. Безусловно, будем мучиться с этим двигателем, пока не произведем свой.
TL;DR: Каким бы плохим двигатель ни был — будете мучаться. О чём вы собираетесь спрашивать французов я не совсем понимаю.
Эти же французы (Safran) поставляют движки для A320 и 737MAX и даже второй знаменит не отказом движка. Так что наверное проблема где-то ещё.
Ещё есть на просторах интернета интересное заявление главы Роснефти о "немного нечестной конкуренции" когда европейские производители занижают ресурс своим двигателям в случае использования для заправки топлива произведённого российскими компаниями.
Ссылка на статью про сокращение ресурса производителями https://www.kommersant.ru/doc/3869044
Тогда я понимаю занижение ресурса двигателей, да.
Общее в истории с Боингом — рост диаметров современных двигателей. Больший диаметр движков требует иных компоновочных решений, на которые авиапроизводители идти не хотят, прибегая к паллиативам (костылям).
Индусы может и написали код точно в рамках ТЗ, но как это отменяет тестирование?
По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало, но если софт кривой и написан спецами с зарплатой в 1 миллион долларов в секунду, то как это отменяет кривость софта?
Имхо, это проблема приемки, а не зарплат.
По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работалоКривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
как это отменяет тестирование? Имхо, это проблема приемки, а не зарплат.Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.
Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
так 9 баксов в час — это не копейка. Если вы не умеете в преувеличение — используйте исходные данные.
Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.
вы, видимо, плохо представляете себе правильное тестирование. Это не только юнит-тесты. Это целая методика. Наши тестеры для каждой (намного более простой и менее ответственной, чем самолет) фичи пишут сценарии тестирования, определяют корнер кейсы и т.д. И у нас оно еще (осознанно) далеко от идеала. Потому, что от нашего софта жизни не зависят.
Задача юнит-тестов — зафиксировать поведение кода, чтобы он не ломался при рефакторинге. А вот проверить правильность работы сложного кода с помощью юнит-тестов попросту нельзя. Но многие до сих пор считают, что 100% покрытие тестами гарантирует правильность работы кода.
А вот более сложное высокоуровневое тестирование с написанием сценариев, обнаружением крайних случаев — всё это уже требует высокой квалификации тестировщика и его компетенции в смежных областях. Программист, который пилит маленький модуль в большой системе, о которой ничего не знает, не сможет написать интеграционные тесты.
Инженеры — отдельная тема. Как правило, редко человек бывает одновременно и хорошим инженером, и хорошим кодером. Человек достигает высокой квалификации, если занимается чем-то одним.
В итоге проблема заключается не в переводе спецификации в код, а в переводе спецификации на язык, понятный кодеру, потому что если кодер не понимает (да и не должен понимать) спецификацию, то это будет только зря потраченное время.
а в переводе спецификации на язык, понятный кодеру
В боинге с этим все было ок, по крайней мере, в те полгода, когда я участвовал в написании юнит-тестов для 787. Спецификации были очень подробными и понятными, и не требовали знаний по разработке авиации.
P.S. У нас в иехархии были люди, которые тщательно проверяли, что юнит-тесты написаны правильно :)
более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях
В идеале компетенция в низкоуровневых вещах тоже должна быть.
Кто видит картину шире
Так я это и написал.
Непонятно где производственный выигрыш такой модели — экономите на разработчиках, увеличиваете расходы на тестирование, да еще и сроки проекта увеличиваете, т.к. проходите больше итераций.
А вот такой зерг раш прекрасно масштабируется и работает.
Видел я такой "Зерг раш". За пару дней до конца спринта завершается тестирование с результатами, что ни один юз-кейс полностью пройти нельзя. При этом команда раздута до десятков человек, суб-команды перекидывают ответственность друг на друга, из-за размеров команды частенько кто-то нужный сваливает в запланированный отпуск, центральный менеджемент мечет молнии но ничего не понимает, т.к. не в состоянии погрузиться глубоко. Неизбежно начинается игра с Заказчиком в "Это было в требованиях, а этого не было".
И все равно это проще, чем найти чудо-разработчика.
Бортовые системы самолёта по тем же принципам работают?
Мне кажется, вы как-то не правильно вопрос задали.
Вопрос: нужны ли все эти микросервисы-фронтэнд-бэкэнд в бортовой системе самолёта?
Вот поэтому мне и хочется понять, насколько популярные сейчас методы и инструменты разработки подходят под rocket science.
Не отказоустойчивым, а выполняемым в реальном времени. То есть программа должна гарантированно выполниться за xx миллисекунд при любых входных условиях. Большее время выполнения равнозначно отказу ПО.
Да, про чудо-разработчика абсолютно согласен. И сложно найти и массу рисков несёт. Нужны крепкие миддлы, выстроенные процессы, железная дисциплина (чему кстати способствуют кажущиеся бессмысленными приседания в Скраме). Но вам понадобится чудо-менеджер, которых наверное еще меньше чем чудо-разработчиков.
Вот только одна проблема: крепкие мидлы остаются мидлами очень ограниченный срок.
Это прозвучит не очень красиво, но я в какой-то момент понял что основная часть команды не должна состоять из амбициозных людей. Они действительно стремительно вырастают и улетают из гнезда.
Другое дело, работодатели любят дуть в уши про то, сколько они в тебя вложили, поэтому ты должен работать за сильно меньшую зп, чем мог бы получать.
А вот такой зерг раш прекрасно масштабируется и работает.
Данная статья показывает, что для высокотехнологичных задач зерг раш не работает, а может стоить даже дороже.
Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.
Абсолютно верно, проблема по существу, в ускорении конкуренции
Если код проходит автотесты, это лишь означает, что при определённых входных данных он выдаёт соответствующие выходные значения. А вот о правильности код речи идти не может.
Работал как-то над софтиной, написанной индусами. Прилично удивил кусок кода вида (примерно, на псевдокоде):
function CalculateSomething(int id, ...params...) {
...
distance = GetOdometer(id)
...
if (id = 123456) {
return
}
...
PerformSomeComputations(distance, ...params...)
...
}
В отличие от прочих «программистов» компании, я стал в этом коде ковыряться и докапываться до истины — благо базы были доступны. Оказалось, что у одного из клиентов какой-то *удак в графу «показания одометра» у автомобиля с id=123456 забил число вроде 3786731 (если кто не знает — редкий автомобиль может проехать 200'000 миль, не развалившись на запчасти, а тут имелось в виду 37867,31 — но забивальщик отвлёкся и пропустил запятую), соответственно при обработке конкретно этой записи у конкретно этой компании PerformSomeComputations() падала из-за переполнения и рушила всю систему. В нашу компанию пришёл баг вида «у клиента X при обработке автомобиля id=123456» падает система". «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.
Автотесты код, естественно, проходил…
«А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.А ревью кода у них отсутствовал как класс? СММ какого уровня у конторы?
Автотесты код, естественно, проходил…
Так данные-то корректные (формально). Просто они оказались неожиданными конкретно для функции PerformSomeComputations().
Мы вот как-то в базе прода "нашли" 78-осный грузовик, и он так же "не пролез" через одну из функций. Означает ли это, что грузовик некорректный?
>>Означает ли это, что грузовик некорректный
Зачем Вы подменяете понятия? Вопрос не в грузовике, а отсутствии контроля входных данных при импорте/входной форме, это же грёбаные азы.
Тут мы упираемся в парадокс кучи: где та граница, ниже которой значения еще реальные, но свыше которой ни одна машина ни одного километра проехать не может?
Почему вы даже не рассматриваете вариант, при котором функция PerformSomeComputations должна работать с любыми числами?
Или тот вариант, при котором она должна на них падать, но не рушить при этом всю систему?
Кто вообще писал ТЗ и проектировал этот бардак?
Компания называлась ADP — гигантский когломерат, производящий автоматизацию всего и вся. Я в то время работал в подразделении, которое автоматизировало (вернее, привносило зачатки big data в) работу автосалонов. Подразделение почти целиком состояло из индусов. :) Дело было лет 12 назад, тогда код-ревью и проч. ещё не были buzzwords.
Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть.
Одной из характеристик выставленных на продажу б/у автомобилей как раз и является пробег — он фиксируется, когда продавец привозит машину на продажу, и, естественно, не меняется, когда машина стоит на продажной площадке. Поэтому предыдущих значений нету.
Пример работы эффективных менеджеров в действии.
а что, код белого человека проверять не надо? Он ошибок не совершает? А это, повторюсь, самолет.
И пишет он неделю, а проверяют час
В том-то и дело, что не час. Это же самолёт.
По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.
Юнит-тесты не проверяют правильность кода. А более высокоуровневые тесты индусы писать не смогут.
Чем больше и разнообразнее опыт инженера и чем лучше он знает для чего он пишет софт и как это работает не только программно, тем меньше вероятность получить комплексную проблему на выходе (а к пуговицам то претензий нет), но такой инженер стоит, обычно, немного дороже, работает, часто, медленней, в общем пока гром не грянет — сплошные убытки :)
p.s. наблюдаю такую картину постоянно, кусочки работают по регламенту и по т.з. а в сумме то тут то там что-то идёт не так...
Чем больше и разнообразнее опыт инженера
В данном случае дело даже не в опыте. Специфическая для индийских хм… «инженеров» (а равно и программистов в инженерных доменах) проблема закладывается еще во время учебы, и отлично описана Фейнманом в его известной книге. Конечно, там место действия — Бразилия, НО. Удивительным образом все совпадает до деталей. Поэтому не буду плодить сущности и просто процитирую (извиняюсь за размер)
Но потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе. Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?» Все молчат. Тогда я сказал: – Вы когда-нибудь слышали об угле Брюстера? – Да, сэр. Угол Брюстера – это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется. – В каком направлении свет поляризуется при отражении? – Свет поляризуется перпендикулярно плоскости падения, сэр. Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Ну?» По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид». – О-о-о, он поляризован! – воскликнули они. После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» – это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», – ничего не срабатывало. У них ничего не было закодировано под этими словами.
Вот это нынешняя система технического (= не гуманитарного) образования в Индии как она есть.
bool value;
if(value.ToString.Length() == 4)
return true;
else if(value.ToString.Length() == 5)
return false;
else
return !true && !false;
Приемка тестирует функцию — она работает? работает.
И что в ней может привести к падению самолёта?
Кроме ошибок аллокации памяти в ToString, которыми, имхо, можно пренебречь при данных вводных.
А почему там NPE может быть?
Потому что, согласно спецификации, работа toString гарантируется только на корректных входных данных, а здесь на вход пришли неинициализированные. На корректных тестах всё работало. Undefined behavior, однако.
Это, конечно, была ирония. Протестировать тестами полностью всё невозможно — два int' а во входных данных уже дадут де-факто бесконечное время для перебора.
Если бы там данные были неинициализированные, то эта функция и для обычного сравнения упала бы, разве нет?
Но я C#, считайте, не знаю, мне правда интересно.
Тут разве что оом может упасть при попытке строчку выделить, но это такое.
Неинициализированный bool нормально сравнится, оба if будут ложными либо сравнение на true будет заменено компилятором на "не ноль". Дальше если оптимизатор вырезал "недостижимый" код, то все плохо, иначе сработает последний return и всё хорошо.
toString для bool можно сделать как return constantStrings[boolValue], которая полагается на то, что bool превращается в 0 или 1. Неинициализированный, соответственно, даст выход за границы массива и там можно схватить вообще что угодно, NPE в том числе. Но тут надо будет старательно завернуть всё в unsafe и выкрутить оптимизатор.
Но я C#, считайте, не знаю, мне правда интересно.Хвала Аллаху, что подобные системы ещё не докатились до шарпа.
Такой код, скорее всего не пройдет по стандартам.
ИСТИНА/ЛОЖЬ — и мы поворачиваем не в ту сторону.
Почти, но мимо. В C# не предусмотрена локализация для типа bool.
Только "True", "False".
Почти, но мимо. В C# ToString() — функция, а не свойство.
PS. А Length — наоборот, свойство.
Вы вообще о чём?
bool.ToString() возвращает всегда либо "True", либо "False".
ToString != ToString().
На случай, если не видели исходного комментария:
bool value;
if(value.ToString.Length() == 4)
return true;
else if(value.ToString.Length() == 5)
return false;
else
return !true && !false;Более того, если это переписать на С++, компилятор все равно оптимизирует что индусятину, что прекрасный код. !true && !false точно уйдет.
Источник. Сколько получает автор кода – там не указано.
Самолеты не летают. Предзаказы отменены. Новых контрактов на авиасалоне не заключено.
Т.е. то что вы говорите — верно, но только если пишут не индусы.
поправлю вас — «сделанные дешевыми индусами».
Может, следует поправить сразу до "сделанных дешевыми программистами"? И даже не "дешевыми", а просто "плохими"?
У нас тут тоже завелись индусы, и их всё больше. Жду когда нас призовут переходить с С++ на Яву
Как проверить, что функция, перемножающая два числа и делящая результат на третье, работает всегда корректно? Кроме "открыть, почитать, подумать", я другого способа не вижу. Можно скормить ей произвольные данные, но это будет вероятностный тест. Вдруг внутри этой функции какое-то значение промежуточного результата используется как код ошибки? Это отсылка к функции MulDiv из winbase.h.
Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.
Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.
Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.
К чему это я…
А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.
Вот так оно и есть. Вся эта возня с делегированием задач оправдывает себя, если работник обладает собственными разумом. Индусу сказали копать — он и копает, не загружая мозг посторонними задачами.
Вы составили ТЗ, индус что-то написал в точном соответствии с ТЗ. Но тут внезапно оказывается, что то, что для вас очевидно, для индуса не является таковым. В итоге ТЗ выполнено, но на выходе совсем не то, что вы ожидали. Поэтому приходится уточнять ТЗ и отправлять на доработку и т.д. Но у вас нет времени на переделку, поэтому в какой-то момент просто принимаете работу в том виде, в котором она есть.
Чтобы индус написал нужный код, придётся скрупулёзно составлять ТЗ, расписывая всё до самых мелочей. И в какой-то момент окажется, что накладные расходы на делегирование задачи окажутся выше, чем решение задачи собственными силами. И если в случае штатных сотрудников такое оправдано (сотрудник наберётся опыта и станет более автономным), то в случае аутсорса каждый раз нужно начинать всё с нуля.
Что касается исходной статьи, ты прав, в целом она — «плач Ярославны» про то, что хороших американских инженеров заменяют в пропорции 1 к 5 на неопытных инженеров из Индии (собственно, большая часть статьи — слова бывших/уволенных инженеров), что со временем должно привести к плачевным результатам (тут я согласен, и, некоторым образом, жду отложенного эффекта). Даже такая пропорция не позволяет компенсировать опыт, необходимый в авиационной индустрии для разработки новых устройств, хоть и позволяет значительно сэкономить.
При этом, если почитать другие статьи по теме MCAS на том же Блумберге, можно увидеть, что основная проблема как раз не в софте — он мог вполне отработать согласно разработанным системным/функциональным требованиям.
Ошибки, скорее, оказались заложены еще на уровне разработки системы (стандарт ARP-4754A), и, что еще точнее, на уровне проведения анализов отказобезопасности (ARP-4761).
В тех самых других статьях писали, что изначально система MCAS должна была компенсировать кабрирование самолета (задирание носа) на малых скоростях из-за изменения расположения новых двигателей под крылом и изменение направления их вектора тяги, при этом за раз она могла уменьшить это самое задирание носа на 0.5 градуса.
Функционал устройства был согласован с экспертами отказобезопасности FAA и ему был назначен уровень критичности B по стандарту DO-178C (собственно, устройство не приводящее к катастрофе в случае отказа, но при этом уже возникают вопросы — как даже для уровня б разрешили снимать данные с одного датчика угла атаки...).
Ну и далее пошли совсем странные вещи (ручаться не буду, рядом совсем не стоял, но пишут): эксперты FAA были изрядно завалены работой, поэтому анализ отказобезопасности они делегировали инженерам Боинга, «тут-то им фишка и поперла» — устройство неожиданно стало «исправлять» задирание носа не на 0.5 градуса, а на 2.5, при этом делать это не один раз, а много раз, последовательно, что сделало возможным катастрофические последствия, которые и реализовались (если не ошибаюсь, в первом случае отказал датчик угла атаки, во втором — там что-то провода отсоединились от датчика из-за тряски на взлете).
Т.е. по факту — разработчикам спустили какие-то требования, может быть ни их реализовали правильно, проверить их тоже могли вполне полностью и хорошо, но кто из разработчиков кода или тестов задумывается, почему один из выходов изменил диапазон рабочий с 0.5 до 2.5? Нет таких в принципе, эти должны заниматься писатели системных требований и safety engineer, который и делает анализ отказобезопасности.
В целом же, по ситуации можно сказать следующе — боинг давит всех своих поставщиков последние несколько лет очень активно на предмет снижения стоимости поставки устройств и сервисов, те вынуждены снижать издержки за счет дешевого аутсорсинга (это все-таки из разрешенных методов), вынуждены объединяться для противостояния давлению боинга (RCI + UTC + (возможно) Raytheon) и т.п.
Боинг, в свою очередь, возвращает разработку некоторых устройств, в частности Flight Control, FBW и т.п. внутрь себя, тоже сокращает собственные издержки за счет увольнения опытных и найма пачек неопытных и так далее. В целом, в индустрии идут довольно сильные изменения, которые снаружи могут быть не так заметны.
Там жесть жестяная. Фактически, 737 «сертифицировался» не FAA, а самой корпорацией Boeing.
FAA «делегировала полномочия по сертификации» разработанного тем, кто это разрабатывал.
www.nytimes.com/2019/03/26/us/politics/boeing-faa.html
medium.com/@alexlee611/faa-delegates-aircraft-certification-to-boeing-and-yet-they-recorded-the-best-safety-record-ever-e72fc38af274
Код реально писали индусы (у нас был доступ к VCS с историей коммитов), и да, код был плохим. При том, что на каждый маленький модуль было четкое описание, что он должен получать и отдавать, они умудрялись написать код, не соответствующий этим требованиям.
Мы не разрабатывали код, мы только писали юнит-тесты на готовый код, сами же их прогоняли и в случае каких-то несоответствий с документацией писали репорты по установленным образцам. Все это перепроверялось старшими, а потом отсылалось на уровень выше. Что там дальше с этими репортами происходило, я не знаю, но обычно потом ошибки фиксились в новых ревизиях. Я был всего лишь джуном на аутсорсе, и у меня естественно не было полной картины происходящего.
“Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.
один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые.
Мне вот довелось — врагу не пожелаю. Описывать элементарную задачу пришлось несколько раз и в конечном варианте я написал спеку… которою можно было копипастить в код… что они и сделали наделав еще и ошибок.
Нет, я допускаю что мне не повезло с конкретными индусами, но только они работали на подряде у автомобильного гиганта с мировым именем.
Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 98 280 рублей в месяц
И уже не так резко звучит для российских программистов, особенно вне мск-региона, верно?
Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 45 360 рублей в месяцМного российских программистов в 2010м получали 45 000?
Размер нет, а сложная схема передачи ответственности вполне может спасти головы в руководстве, но всё зависит от уровня возникших проблем. Моё личное ИМХО если бы вторым самолётом оказался самолёт American airlines, уже бы не один человек считал годы до окончания срока...
Если сравнивать с однокурсниками, это было чуть ниже среднего. Но зато было интересно )).
Ну и опять же, мы не знаем, сколько из этих $9 в час забирал аутсорсер. Программисты же компании-заказчику обходились в $9 в час. Если аутсорсер ещё минимум 30% забирал, то всё вообще плохо. Хотя в оригинале статьи и написано, что это был именно доход разработчиков, но кто знает.
Если взять разработку в самой Boeing, где есть инженер, заложивший дублирование, тест-писатель, описавший известные ему и компании случаи отказов в тестах, и менеджер, который не примет код до того, как он пройдёт тесты — то да, можно заменить разработчика на дешёвого. Будет ли дешевле час работы сотрудника за $50 или неделя возни и возвратов индусу с $9 — другой вопрос.
А если вся задача делегирована людям, которые, условно, раньше делали софт уровня 1С — то ТЗ будет выглядеть как «типа надо компенсировать недостаток манёвренности», тесты буду выглядеть как «взлетаем, не хватает управления, триммирование включается, всё хорошо начальникама» — разработчик ПО (который, в отличие от менеджера и инженера, не обязан хоть что-то знать про самолёты) мог написать с первого раза идеальный код, который на 100% делает ровно то, что описано в ТЗ.
Но ТЗ неадекватно требованиям к подсистемам в авиации. В этом и проблема, насколько я понял — в делегировании проектирования целых подсистем в компании-подрядчики
Т.е. грубо говоря у нас заголовок преобразуется в:
«Аутсорс программисты с позорно низкой зп выше чем у вас написали говнокод для Boing»
Мне знакома изнутри ситуация, когда компания сначала зарабатывает себе имя и репутацию, растёт, и в какой-то момент оказывается, что заказов набрали больше, чем возможно выполнить. И менеджмент принимает решение воспользоваться контракторами, стажерами, вообще всеми подряд, лишь бы побольше и подешевле.
Что, в свою очередь, приводит к снижению качества, потере репутации, ухудшению продаж, увольнениям и в конце концов к коллапсу.
Да, у Boeing запас прочности большой, но вот этот «эффективный менеджмент» и погоня за краткосрочными прибылями точно до добра не доведёт.
Чтобы не путать с IA-64, которую Intel выкатила двумя годами ранее.
Вспоминается как минимум K6-III vs Pentium 3
K6-III нет, т.к. это был рывок только по сравнению с К6-2, и лебединая песня всей тогда уже бесповоротно устаревшей архитектуры. Athlon XP конкурировал на равных, хоть и не был лидером, зато его младший брат Duron рвал в нижнем сегменте Celeronы как Тузик грелку. Звездный час у них наступил с появлением Athlon 64. Вот тогда они уложили Pentium 4 на обе лопатки. Сначала с появлением 64-битного ядра, потом они же первыми вывели на рынок многоядерные процессоры.
Вообще, как по мне, сейчас АМД находится в стратегически более выигрышной позиции, и по сути, это плоды уже находящегося в далёком прошлом решения — продать свои фабрики. Риски и огромную стоимость освоения новых техпроцессов они делегировали контрактным производителям, и те с ними вполне справляются. А Intel пытается их тянуть на себе, и пока неуспешно. А когда освоят свои 10nm, TSMC уже даст для АМД 5 nm и так далее.
Делать что-то с нуля они скорее всего не вытянут, а из современного успешного выбора и нет.
Хорошо сказано. Беда в том, что у монополиста обычно запас капитала большой. Плюс инертность покупателей и долгосрочные поставки. В итоге, когда жареный петух клюет, компания нехотя начинает вновь следить за качеством.
Из недавнего: Intel. Боинг тоже не помрёт.
А если в ценах и долларах 2010, это вообще 30 получалось, в то время вполне себе средняя зарплата даже для инженеров, не говоря уж о программистах
Город-миллионник. Средняя выше 98 000 тут ну никак не получается.
А вот тут другие данные
Инженеры в Индии зарабатывали около $5 в час, сейчас это $9 или $10, в сравнении с $35-40 для тех, кто находится в США по визе H1B, добавляет Хильдерман. Но он объясняет своим клиентам, что в реальности, дешевая цена за час равняется примерно $80, из-за необходимости контроля,
Вот самая важная часть статьи. Это критика «эффективных менеджеров», которые сокращая расходы втрое увеличили их вдвое. И очередное напоминание что чудес не бывает
Существует ФОТ для департамента, в котором обитают программисты. Финансисты, в процессах разработки ПО не понимающие ничего, и потому ставящие расходы на разработку ПО в один ряд с расходами на закупки, спустили сверху указание «Снизить ФОТ на 20%». Возможно, даже реальной необходимости в этом и не было, а просто новый начальник решил выслужиться перед высшим руководством с самого начала. Или KPI ему самому такой прописали. Но указание сверху получено, пришлось взять под козырек Менеджеры нижнего звена поменяли часть дорогих офисных программистов на дешевых оутсорсеров и обновили свои резюме, чтобы свалить, когда придет время платить по счетам. И, в общем, не так уж они и виноваты — правила игры задаются сверху, и объяснять тут что-то бесполезно.
Это совершенно нормальная практика сейчас для не-программистких крупных предприятий, скорее, странно, когда бывает наоборот. Краткосрочные цели годовой прибыли имеют преимущество перед долгосрочными целями развития компании. Есть курс и прибыльность акций — это главное. Поэтому любой ценой надо добиться прибыльности в этом году, а в следующем — зальем деньгами от повышения курса этот проблемный участок. Но иногда, редко, получается и вот так, как с Боингом.
Те же индусы едут в США, пытаясь зарабатывать среднюю ЗП по рынку, причем они идут на всякие хитрости, чтобы скрыть свой низкий уровень образования/обучения. Иногда едут в США как body shopper ы, зарабатывая 1/2 средней ЗП, потом меняя работу на нормальную. Они везде, в общем. Лезут во все щели, ибо для них такая сытая жизнь великое благо, а благодаря уже осевшим индусам в корпорациях их и берут чаще, более лояльны к визовому спонсорству. Кто ее видел Кремниевую долину тот, в частности, не ощутил лёгкую панику от вездесущих индусских программистов.)
Знаю компанию, которая работала с Боингом, продавала час за $40, а сотрудникам платила фикс 20-30 тыщ(по ценам середины 2000х, не знаю, как сейчас, но вряд ли в корне изменилось).
И кстати, ходит там легенда, что один проект отдали индусам со словами «у них дешевле, передайте проект с доками» и год вернулись со словами «сколько будет стоить вернуть проект в читаемое и рабочее состояние?» — то, что наворотили индусы, ещё 5 месяцев разгребали и приводили во вменяемое состояние.
К счастью у нас для тестов была так круто разработана методика тестирования, что испортить её даже индусы не могли (хотя пытались, честно)))
Её мы применяли для всех новых и переделанных индусовских тестов.
Кстати в какой-то момент заказчик отдал кучу работы китайцам. Сначала было нормально, пока, видимо, самые умные китайцы стажировались в США. А вот когда они вернулись домой и стали учить своих коллег. Результат стал очень сильно похож на индусовский код. Сложно сказать — какой лучше, а какой хуже… он просто чуть другой :)
It was my first serious job, I got such a great experience, I went through so many trainings and learned english at work. / Это была моя первая серьёзная работа, я получил отличный опыт, ходил на всякие тренинги и учил английский прямо на работе
Nice place to start your aviation career and extend the engineering knowledge in aviation / Отличное место, чтобы начать свою карьеру в авиастроении и улучшить инженерные знания по авиации
Один мой знакомый туда рвался, потом сходил на собес или два, поговорил с кем-то из сотрудников, посмотрел на офис и свернул удочки с формулировкой типа: «Да это ж конвейерная соковыжималка для студентов: берут за копейки совершенно зелёных ребят, заставляют работать в режиме аврала 12 часов в сутки плюс обучение прямо по ходу, как только ребята начинают немного разбираться в теме и сбегают из рабства, набираем новых». При этом он не как прогер туда ходил, а как инженер-конструктор, так что там, похоже, подход один ко всем этапам разработки и своё мнение насчёт того, кому из российских специалистов стоит доверять разработку современного самолёта.
FYI у нас в регионе (на восточном побережье) минималка $9, это уровень уборщиц.
На западном побережье, где боинг, уже и уборщицы не получают $9 в час.
у меня была работа джуном — я получал 25 тысяч рублей в месяц
с клиента брали 1200 рублей за 1 час моей работы
но это рекорд был, обычно брали 600-800, что все равно интересно,
т.к. мне за 1 час давали 125 рублей примерно
Тут надо понимать, что я не возражал, мне нравилось учиться, кроме того калькуляция стоимости часа фирмы учитывает массу побочных расходов, те же компы, тот же отдел бухгалтерии, та же уборщица, тот же сисадмин — все они должны были что-то кушать, ну и масса других нош, которые несет фирма по сравнению с фрилансером
Я к тому, что надо уточнить — расценка за 1 час для клиента или действительна зарплата. Если смотреть по расценкам для клиента, то расценки я бы сказал нормальные даже в РФ. Может быть, даже низкие местами. Там где я работал, фирма бы и разговаривать не стала за такой прайс )
А я так понял что $9 получает компания-аутсорсер. А зная что маржа таких компаний обычно не менее 50%, то индус получает $4.5 до налогов.
и миллионов строк кода,
Вот этот момент интересен. Это считали вместе с кодом операционок, видеоплейеров и прочего в довесок? Код программы автоматики управления вряд ли может иметь миллионы строк. Или там действительно нужны эти самые миллионы строк?
Однако то, что заливается в контроллер, разворачивает связанные библиотеки (как минимум, cmsis для взаимодействия с железом и math) и занимает уже десятки тысяч строк кода (С) или сотни (инструкции процессора).
Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки — вот вам и миллионы строк кода (инструкций).
У настоящих микроконтроллеров (AVR, PIC, STM и далее) и обвязки к ним довольно мало место в ПЗУ, поэтому никакие миллионы строк там физически не уместятся. А каждые 2 КБ сверху стоят около ста евро в прайсе Siemens.
Заодно поржал от наличия в скобочках STM наравне с PIC и AVR.
— С уважением,
Генрих Мюллер, группенфюрер
Ну и да, я в своих личностных характеристиках несколько скромнее, и думаю, что если где-то и сморозил глупость, то вполне приемлемую — я с МК не работаю, пересекался раз или два по работе и когда делал маленького робота.
— С уважением,
Генрих Мюллер, группенфюрер
Естественно, речь не о ядрах ARM Cortex A*, а о линейках M и R.
ARM занимает 37% общего рынка МК и более 50% рынка IoT. Квадрокоптеры все на АРМах, автомобили на них переходят. Сейчас не проблема найти МК с ПЗУ 512кб или даже 1024кб.
Расскажите, а как оно разворачиваетв памяти все эти библиотеки, если их код не используется полностью? Оптимизацию вообще умышленно отключили? И да, я знаю, о чем говорю, писал для контроллеров на всех уровнях и продолжаю писать уже 15 лет.
Кстати, и не думаю, что контрактерам платят за "миллионы" строк кода math
Во-вторых, думаю, в 737 Max стоят сотни устройств с МК внутри (я не учитываю развлекательные панели в креслах, только авионику и автоматику), и если в каждом хотя бы по тысяче строк кода на асме — это уже миллионы строк. Здесь нет речи о ревизиях, разных моделях и комплектациях.
Платят, думаю, почасовую ставку, и в этом может быть одна из проблем — на мой взгляд, инженеру лучше платить за выполнение хорошо поставленной задачи, покрытой тестами и имеющей чёткие критерии выполнения и работоспособности, но увы.
Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки
Практически не будет. Мы всё это делали почти без всяких библиотек на Миландровском контроллере и на таком чуде, как аналог TMS3020C3 (да, для ВПК). Кстати, если кто случайно знает для TMS320C3 компилятор хотя бы с Си99, буду очень благодарен за информацию, где его можно взять (а то Си89 на нём уже достал). :)
Эксперты вынуждены уходить в другие отрасли с направлений, где они были сильны, потому что их работа обесценена «молодыми» специалистами, умеющими считать лишь на калькуляторах (условное название всех «помогайзеров»). Доходит до того, что электротехники не знают закон Ома.
В итоге проблемой для заказчика (желающего нормальной работы) стало НАЙТИ тех, кто МОЖЕТ нормально спроектировать в куче-мале псевдоспециалистов.
Если в промышленных гигантах, ответственных за человеческие жизни, такая неразбериха с процессами, то о чем говорить в более мелких конторах
Как раз наоборот: вероятнее, что именно в маленькой конторе подойдут к процессу проектирования с большим вниманием и ответственностью. А в «промышленных гигантах» обязательно найдутся тучи «эффективных менеджеров», озабоченных лишь снижением издержек и повышением прибыли.
Наша главная цель — всегда быть уверенными в том, что наши продукты безопасны, высочайшего качества и выполнены по всем правилам
Наглая, паршивая ложь. Ненавижу менеджеров за это.
Уже ж выяснилось что Боинг намеренно не сказал пилотам про эту систему mcas. Они руководствовались лишь одним — не просрать сроки и не допустить доминирование airbus
Кому лень гуглить/вникать — краткое содержание:
На предыдущий моделях 737 у летчиков и mcas (а также остальных систем управления стабилизатором было 2 отдельных электромотора, runaway stabilizer отключал электромотор автоматики, в то время как пилоты по прежнему могли пользоваться своим электромотором для управления стабилизатором). На Max решили сэкономить и завели все на один общий электромотор. Соотвественно, единственным способом управлять стабилизатором после runaway stabilizer (который на Max обесточивает этот единственный мотор) можно только вручную через тросики, что экипаж эфиопской компании и пытался делать. Только, как выяснилось, что на скорости >300 км/ч это уже выше пределов человеческих возможностей, в чем пилоты довольно быстро и убедились (на взлете у них скорость была сильно выше). После чего пилоты решили включить мотор обратно, видимо чтобы управлять стабилизатором со штурвала, но тут им просто не повезло т.к MCAS на включении моментально загнала их в штопор.
Резюме — офигительно боинг помог со своей инструкцией после первой катастрофы (где они как раз акцентировали внимание на runaway stabilizer)
Даьи вообще эти фразы НАША цель безопасность… блабла, наша цель сделать мир лучше, наша цель сплотить общество… это все такая лапша противно даже. Ниразу таких целей не слышал на собраниях инвесторов или топ руководителей
Нет разу не слышал на собраниях, чтобы глава фирмы открыто озвучил свои цели. Обычно давят на совесть: нам верят клиенты, мы должны сделать все, что можем. При этом всем ясно, что в заявленный срок никогда не получится сделать качественно. Идёт подгонка под требования приемки, а не под опыт реальной работы у заказчика.
Работа пиарщика врать. Вам и мне противно. Ему часто тоже.
один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе
То есть боинговские сеньоры смогли предоставить техдокументацию надлежащего качества только с 18 попытки. Может тогда и правильно их аутсорсерами заменили?
Интересно-интересно.
Как эксперт, расскажите, что изменилось за 18 попыток: эти ужасные русские выучили-таки английский или страдающие от аутсорса боинговские инженеры техдокументацию на русский перевели?
Однажды знакомые ребята меня попросили узнать, сколько будет стоить на российском заводе выточить одну деталь из цельного куска алюминиевой плиты. Кое-как на пальцах объяснили, что они хотят, я кое-как сделал 3D модельку, сделал несколько скриншотов разных сечений, указал размеры в мм и отправил на известные мне заводы мехобработки. Дело было осенью 2015 года, когда с экономикой было ну совсем все плохо. Из всех заводов мне ответил только один, что, дескать, пока документация не по ЕСКД они ничего считать не будут. На мой уточняющий вопрос, могут ли они привести имеющиеся данные к ЕСКД за деньги, мне с завода уже никто не ответил.
С тех пор, знакомые ребята сотрудничают с китайцами — они, конечно, не очень, зато сообразительности им не занимать, когда дело деньгами хотя бы пахнет.
НО все меняется, когда вы начинаете работать с людьми, простыми, но хотящими что-то сделать. Такие есть, они даже что-то знают и умеют делать, но их уровень не позволяет им готовить все необходимое в соответствии с представленными требованиями. В таком случае, по-человечески, можно сделать какой-то сервис, который будет говорить с клиентом, принимать модель и проставлять опущенные детали, опираясь на область применения детали. Если это обычная хоббийная штучка, то там 0.1мм будет вполне себе нормальным допуском.
Теже китайцы просто не парятся на эту тему, есть какой-то обычный допуск для станка, например 0.05 мм и они с ним делают детали не задавая лишних вопросов.
В России на сайтах всяких компаний черт ногу сломит, прежде чем найти хоть какую-то информацию о том, как сделать заказ и т.д.
Допуски всё же не просто так, возможно ваша модель была оценена технологом "на глазок" в сумму, подразумевающую что вы не захотите её платить если даже чертежи толком сделать не можете, штучное производство всё же иметь особенности.
И про допуска, допуск не просто в n-xxxxxметров, он ещё в плюс и в минус и это не просто так...
В результате плиту продали, материал закупали уже китайцы и делали же китайцы.
Конечно, ценообразование в России и в Китае отличается, но в России мы даже до цен не дошли.
Завод можно понять, на кой ему единичная возня с некрупным заказом?
Но только вы никогда не узнаете, какой у вас случай до того момента, пока вы не доведете первый заказ до ума.
Вот например я делаю маленькие устройства для себя. Если у меня получится устройство, которым заинтересуются другие, я могу заказать больше и начать их продавать в малом объеме. Начальный доход от продаж позволит мне создать стартовый капитал. Я смогу оценить рынок, изучить аудиторию, исправить ошибки и довести устройство до качественно нового уровня. Сделать вторую версию гораздо лучше первой и продать еще больше устройств.
Но только если никто не согласится делать мне то самое первое устройство в буквально единичном экземпляре, я никогда не смогу выйти на рынок.
Как итог мы имеет плохие устройства на рынке, потому что люди, способные сделать лучше, не могут их реализовать по причине отсутствия средств, а компании не заинтересованы в новинках, пока нет конкуренции.
Получается замкнутый круг, разорвать который могут только заводы, у которых есть реальная возможность что-то производить. Но им лень, ибо проще отшивать людей формальностями и жить за счет госзаказов или 2-3 больших клиентов.
ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать. А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.
ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать.Об этом я и писал. Завод вообще задуман как оптовый производитель. Потому там обычно не связываются со штучными заказами.
А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.А это уже не завод а скажем мастерские.
Вот как раз он за деньги клиента готов хоть фоторамку из чугуния выфрезеровать.
И довольно интересно о процессе пишет.
Вы может с Алибабой спутали?
На публичную почту завода наверняка ежедневно приходит тонна спама с коммерческими предложениями от кулибиных разного калибра. Если отвечать каждому, то потребуется отдельного человека на это заводить. Будет ли конверсия кулибиных покрывать затраты на поддержание штучного производства?
По человечески тоже все просто. Почту читает человек, который допуски считать не умеет. Напрямую обратиться к человеку, умеющему считать, он не может/не хочет. Нужно задействовать насяльнике, а он в отпуске..
«Выточить с помощью стажера и какой-то матери напильником, точность — на глаз: ХХХ руб.
На обрабатывающем центре по программе подготовленной инженером по согласованному с заказчиком ТЗЖ 2*ХХХ руб.
То же но с командировкой инжинера для уточнения ТЗ к заказчику: 5*ХХХ руб.
То же но с перевозкой обрабатывающего центра к заказчику и выполнения работ на месте: ХХХ^5 руб.»
Получит ли он премию, если начнет переписку с выяснением, что именно нужно делать и сколько это будет стоить? (Нет)
Получит ли он выговор за то, что отрывает от работы кучу народа? (Возможно)
По человечески оно где-то так…
есть какой-то обычный допуск для станка, например 0.05 мм
Я знаю одного "бухгалтера", который в «домашних условиях» выдаёт точность 0.01 мм.
Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими $9 в час