image

В разгар кризиса вокруг Boeing-737 Max, до сих пор остается загадкой: каким образом компания, прославленная своим тщательным подходом к проектированию, допустила, судя по всему, детские ошибки при разработке софта, приведшие к двум катастрофам с человеческими жертвами. Инженеры, работающие в компании много лет, говорят, что разработка была осложнена из-за делегирования части работы низкооплачиваемым контракторам.

Недостатки софта, возможно, оставят самолеты прикованными к земле еще на один месяц — на этой неделе американские регуляторы обнаружили дополнительные проблемы. Программное обеспечение для серии 737-Max было написано во времена, когда компания Боинг увольняла опытных инженеров и оказывала давление на поставщиков.

Более того, икона американского самолетостроения и ее субподрядчики, доверяли временным работникам, зарабатывающим всего лишь $9 в час, разрабатывать и тестировать свое программное обеспечение. Зачастую, это были работники из стран с неразвитым самолетостроением, а именно из Индии.

“Вчерашние выпускники, нанятые на работу индийской софтверной компанией HCL Technologies Ltd, занимают несколько рядов столов в офисах Boeing Field в Сиэтле (официально King County International Airport, в этом аэропорту компания Боинг имеет свой ангар и проводит испытания самолётов — прим. перев.)”, говорит Марк Рабин (Mark Rabin), бывший инженер Боинга, работавший в группе тестирования самолетов серии 737-Max.

Кодеры из HCL обычно разрабатывают, согласно спецификациям, присланным из Боинг. Но, по словам Рабина “это спорное решение, так как оно гораздо менее эффективно, чем просто дать писать код инженерам Боинга”. Он вспоминает, что “зачастую требовалось переделывать всё по несколько раз, поскольку код был написан неверно”.

Поддержка индийских компаний возможно принесла и другие плоды. В течение последних нескольких лет Боинг выиграл несколько тендеров на поставку военных и коммерческих самолётов в Индию, например контракт стоимостью 22 млрд. долларов для компании SpiceJet Ltd. Этот контракт включает 100 самолетов 737-Max 8 и является крупнейшим заказом за всю историю индийских авиалиний, традиционно сотрудничавших с Airbus.

Согласно выводам, опубликованным в соцсетях, инженеры из HCL участвовали в разработке и тестировании ПО для PFD (Primary flight display, основной пилотажный дисплей — прим. перев.), а сотрудники другой индийской компании, Cyient Ltd., занимались ПО для контрольно-измерительных приборов, предназначенных для лётных испытаний.

Дорогостоящая задержка


В одном из постов, сотрудник HCL охарактеризовал свои рабочие обязанности таким образом: “По-быстрому сделал костыль, чтобы решить проблему на продакшене и не задерживать лётные испытания 737-Max (задержка каждого полёта обходится компании Боинг в огромную сумму)”.

Компания Боинг заявляет, что не доверяла инженерам из HCL and Cyient разработку системы MCAS (Maneuvering Characteristics Augmentation System), с который связывают катастрофы рейса JT-610 Lion Air возле Джакарты в октябре 2018 и рейса ET302 Ethiopian Airlines под Аддис-Абебой в марте 2019. Также, по словам Боинга, ни одна из этих компаний не связана с проблемой, обнаруженной после катастроф — неработающей у большинства покупателей сигнальной лампой в кабине.

“Боинг имеет многолетний опыт работы с поставщиками и партнёрами по всему миру”, говорит официальный представитель компании. “Наша главная цель — всегда быть уверенными в том, что наши продукты безопасны, высочайшего качества и выполнены по всем правилам”.

В свою очередь, компания HCL в официальном заявлении утверждает, что “имеет крепкие и давние деловые отношения с Боинг и гордится работой, которую компания проделала для своих клиентов. Тем не менее, HCL никак не комментирует, какая именно это была работа. HCL никоим образом не связана с текущими проблемами с 737 Max”.

Недавние тесты на эмуляторе, проведенные Федеральным управлением гражданской авиации США, выявили, что проблемы с софтом лежат на более глубоком уровне. Акции компании на этой неделе упали в цене, после того как регуляторы обнаружили проблему с микросхемой, начинающей отдавать критически важные ответы с задержкой, в случае, если она перегружена запросами.

Разработка 737 Max началась 8 лет назад, и работавшие над ним инженеры жаловались на давление со стороны менеджеров. Выдвигались требования ограничить изменения, потенциально создающие дополнительные издержки.

“Боинг делал всё возможное, всё, что вы только можете себе представить, чтобы сократить издержки, включая перенос разработки из Puget Sound (регион в штате Вашингтон, в котором находятся производственные мощности компании Боинг — прим. перев.), потому, что это обходится слишком дорого”, утверждает Рик Людтке (Rick Ludtke), бывший инженер по лётным испытаниям, уволенный в 2017 году. “Это можно понять, если взглянуть на ситуацию с точки зрения бизнеса. Постепенно, с течением времени, выяснилось, что это ослабило способности инженеров из Puget Sound к проектированию”.

Рабин (Mark Rabin), бывший программист, уволенный в 2015 году, вспоминает, как один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые. “Я был шокирован, что в зале, заполненном парой сотен преимущественно сеньор-инженеров, нам на полном серьезе говорят, что мы не нужны...”

Типичный реактивный лайнер состоит из миллионов частей, и миллионов строк кода, и Боинг давно уже передал большую часть работы поставщикам, которые просто следуют детальным чертежам.

Начиная с запущенного в 2004 году 787 Dreamliner, компания Боинг стремилась увеличить прибыль, вместо чертежей предоставляя высокоуровневые спецификации, а затем предлагая поставщикам самостоятельно прорабатывать детали. Идея заключалась в “они — эксперты, понимаете, и они позаботятся об этих вещах за нас”, говорит Фрэнк МакКормик (Frank McCormick), бывший инженер по лётным испытаниям, который позднее работал консультантом для регуляторов и производителей. “Это была просто глупость”.

Дополнительной причиной переноса работы за границу являются продажи. Взамен на 11-миллиардный контракт с Air India, подписанный в 2005 году, Боинг обязался инвестировать 1.7 млрд долларов в индийские компании. Это, конечно же, было благом для HCL, Cyient и других компаний, чьи программисты широко использовались в компьютерной индустрии, но еще не были задействованы в самолётостроении.

Rockwell Collins, производящая электронику для кабин самолётов, была одной из первых самолётостроительных компаний, передавших значительную часть своей работы в Индию, где начиная с 2000 года HCL начала тестировать их программное обеспечение. К 2010 году в HCL работало более 400 человек, занятых разработкой и тестированием ПО для Rockwell Collins, в офисах располагающихся в Ченнаи и Бангалоре.

В том же самом году, Боинг, совместно с HCL, открыл так называемый “центр передового опыта” в Ченнаи, заявив, что компании будут сотрудничать “с целью создания критически важного ПО для лётных испытаний”. В 2011 году Boeing добавил Cyient (в то время известный как Infotech) в список своих “поставщиков года” за проектирование, проведение испытаний и разработку ПО для моделей 787 и 747-8, осуществлёнными в другом центре в Хайдарабаде.

Конкуренты компании Боинг также частично полагаются на аутсорсеров. В дополнение к поддержке продаж (о чем упоминалось выше), самолётостроительные компании утверждают, что распределенные проектные группы имеют более высокую эффективность, так как работают круглосуточно. Но аутсорсинг давно стал больным местом для некоторых инженеров Боинга, которые, помимо боязни потери работы, говорят, что это привело к проблемам с взаимодействием между командами и ошибкам.

Московские ошибки


Боинг также расширил центр проектирования в Москве. В 2008 году, во время встречи с главным инженером, ответственным за Boeing-787, один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе, рассказала Синтия Коул (Cynthia Cole), бывший инженер Боинга, возглавлявшая профсоюз инженеров с 2006 по 2010 год.

“Проектирование стало превращаться в дешевый товар”, добавляет Вэнс Хильдерман (Vance Hilderman), соучредитель компании TekSci, предоставлявшей услуги инженеров-контракторов и начавшей терять заказы из-за зарубежных конкурентов в 2000-е годы.

По словам Хильдермана, инженера по безопасности с тридцатилетним опытом, в число недавних клиентов которого входят основные поставщики Боинга, американские компании, занимающиеся авионикой, за последние несколько лет перенесли более 30% разработки своего ПО за границу, в сравнении с всего лишь 10% европейских компаний.

Сильный доллар был залогом привлекательности данной модели. Инженеры в Индии зарабатывали около $5 в час, сейчас это $9 или $10, в сравнении с $35-40 для тех, кто находится в США по визе H1B, добавляет Хильдерман. Но он объясняет своим клиентам, что в реальности низкая цена за час обходится им в $80, из-за необходимости контроля, и говорит, что его фирма частично возвращает заказчиков, которым нужно исправлять баги.

HCL, ранее известная как Hindustan Computers, была основана в 1976 году миллиардером Шивом Надаром (Shiv Nadar) и имеет годовой объем продаж более 8,6 миллиардов долларов. По словам вице-президента компании Сукамала Банерджи (Sukamal Banerjee), HCL — это глобальная компания с 18000 сотрудниками в США и 15000 в Европе, она имеет огромный опыт в области вычислительной техники. И выиграла заказ от Боинга именно поэтому, а вовсе не из-за цены. Он прямо утверждает: “У нас большой опыт в R&D (Research & Development, научно-исследовательские и опытно-конструкторские работы — прим. перев.)”.

Тем не менее, при работе над 787, HCL выставил Боингу замечательную цену — бесплатно, согласно словам Сэма Сваро (Sam Swaro), помощника вице-президента, который предлагал услуги HCL на конференции в Сан-Диего, организованной журналом Avionics International в июне. Он сказал, что компания не брала авансовых платежей за 787 и начала выставлять счета только на основе продаж через несколько лет — «инновационная бизнес-модель», которую он предложил распространить на другие компании в отрасли.

Модель Boeing-787 была введена в эксплуатацию в 2011 году, с опозданием на три года, и превысила бюджет на миллиарды долларов, отчасти из-за путаницы, вызванной стратегией аутсорсинга. Под руководством Денниса Муйленбурга (Dennis Muilenburg), давнего инженера Боинг, который стал генеральным директором в 2015 году, компания заявила, что планирует вернуть в свои руки большую часть работы над новейшими самолетами.

Инженерное болото


Boeing-737 Max стал лидером продаж вскоре после того, как его анонсировали в 2011 году. Но для амбициозных инженеров это было что-то вроде “болота”, говорит Питер Лемм (Peter Lemme), спроектировавший автопилот для Boeing-767, ныне являющийся консультантом. Boeing-737 Max был обновлением конструкции 50-летней давности, и изменения должны были быть достаточно ограниченными, чтобы Боинг мог штамповать новые самолёты как горячие пирожки, с небольшими изменениями для сборочных линий или авиакомпаний. “Для инженера, это не самая лучшая работа”, добавил Лемм.

Rockwell Collins, в настоящее время являющаяся подразделением United Technologies Corp, выиграла контракт на поставку кабинных дисплеев для 737 Max и в своей работе опиралась на инженеров HCL, работающих в Индии, в штате Айова и в Сиэтле. Пресс-секретарь United Technologies отказался прокомментировать данную ситуацию.

Инженеры-контракторы из Cyient помогали с оборудованием для лётных испытаний. Чарльз Лавджой (Charles LoveJoy), бывший сотрудник Боинга, сказал, что инженеры из США вынуждены были каждое утро в 7:30 перепроверять чертежи, сделанные в Индии ночью. “У нас были проблемы с индийской командой. Они выполняли требования, но мы могли бы сделать лучше”.

Многочисленные расследования, в том числе уголовное расследование, осуществляемое Министерством юстиции США, пытаются выяснить, как и когда были приняты критические решения относительно программного обеспечения 737 Max. По словам следователей, во время крушений самолетов Lion Air и Ethiopian Airlines, в результате которых погибло 346 человек, система MCAS подтолкнула самолеты к неконтролируемому пикированию из-за плохих данных с одного датчика.

По словам Лемма, такая конструкция нарушает базовые принципы избыточности, бывшие незыблемыми для нескольких поколений инженеров Боинга. По-видимому, никто и никогда не проверял, как программное обеспечение будет реагировать в данной ситуации. “Это был оглушительный провал”, — сказал он. «Не один человек, а множество людей должны были подумать об этой проблеме».

Боинг также сообщил, что вскоре после начала поставок 737-Max в 2017 году, они обнаружили, что сигнальная лампа, которая могла бы предупредить экипаж о проблеме с датчиком, была неправильно настроена в ПО полётного дисплея. В майском заявлении компании Боинг, объясняющем, почему компания вовремя не проинформировала об этом регуляторов, говорится, что инженеры решили, что это не является проблемой безопасности.

“Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.

От переводчика: после прочтения статьи я перестал удивляться ситуации в своей отрасли (e-commerce). Если в промышленных гигантах, ответственных за человеческие жизни, такая неразбериха с процессами, то о чем говорить в более мелких конторах. Ну и добавлю, что Блумберг конечно передергивает (сложилось такое впечатление), так как их задача — хайп и просмотры, поэтому написанное нужно делить на два.

Сообщения об ошибках, опечатках и прочих проблемах приветствуются.

Комментарии (481)


  1. nevzorofff
    30.06.2019 14:35
    +1

    У суперджетов с двигателями, которые ходят 1-2 тысячи часов вместо 8 — история такого же плана?


    1. v12aml
      30.06.2019 14:59
      +1

      Это нужно спросить у французов, в суперджете их двигатели


      1. zerg59
        30.06.2019 15:07
        -1

        Также и Боинг может сказать: «Спросите у индусов, это же их софт»… ;-)
        Как сказано ниже «это проблема приемки»


      1. Dmitri-D
        01.07.2019 06:45

        Там не только их движки. Их инженеры еще и участвовали в проектировании.


      1. achekalin
        01.07.2019 11:07

        Честно говоря, если у них движки такие же, как авто… Я лучше на ТУ полетаю.

        Не знаю, правда ли, но, говорят, французские танки имеют сходную надежность, и до поломки накатывают километров 60-100 — так, что их даже на учения возят только трейлерами, от греха.


        1. severgun
          01.07.2019 13:15
          +5

          Ты не поверишь. Танки всех стран мира транспортируют на тралах


          1. ad1Dima
            01.07.2019 14:24
            +1

            не поверю, с НВВКУ на полигон своим ходом ездят.


            1. arheops
              01.07.2019 17:01
              +1

              Невыгодно. Двигатель танка очень сильно больше, чем нужно для передвижения по обычным дорогам, ресурс его ограничен и стоит он на порядок или два дешевле трала.


              1. maxzhurkin
                01.07.2019 22:35
                +2

                дороже


              1. ad1Dima
                02.07.2019 05:28
                +2

                Я им говорю ходят, и это факт. А они говорят не выгодно. Они параллельно трассе ходят пару раз её пересекая. километров 10 в каждую стороны.

                Думаю выгода там и в преодолении пересеченной месности: лес, склоны, брод, поле, трасса


                1. MTyrz
                  02.07.2019 11:10
                  +3

                  А тут все правы.

                  Невыгодно. Гусеничный движитель — вовсе не образец эффективности. У вполне гражданского, и довольно легкого ГТС-М (двигатель от ГАЗ-66) пробег до капремонта составляет, емнип, 5000 км. Танк и тяжелее, и дороже, и требования к двигателю у него повыше.

                  Но основное назначение танка, как бы странно это не звучало, вовсе не те пятнадцать минут гипотетического боя. Основное назначение танка — боевая учеба, именно ей на танке занимаются долгие годы. А это занятие, как ни крути, связано с расходом моторесурса: чтобы учиться, надо ездить и ездить.
                  Поэтому на полигон своим ходом — тоже оправдано.


              1. Muzzy0
                02.07.2019 12:36

                А ещё невыходно потому, что потом асфальт после танков перекладывать. Ну и скорость на асфальте у них такова, что движение просто встанет.

                Да и половину Конкорда французы делали :)


                1. geher
                  02.07.2019 12:56

                  Танки, конечно, разбивают дорогу быстрее, чем колесная техника, а тяжелая колесная техника делает это быстрее, чем легковушки, но если асфальт положен правильно, то периодические проезды современного танка сильно ему не повредят.
                  Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
                  Единственная причина, по которой танки катают на трейлерах (кстати, если и быстрее собственного хода танка, то ненамного) — высокая стоимость покатушек танка своим ходом, что проистекает из трех составляющих: малый ресурс ходовой части (как у любой тяжелой гусеничной техники), большой расход горючки (как не в себя) и (в мирное время) необходимость дополнительных мероприятий по обеспечению безлпасности движения (танки "забыли" оснастить хорошим обзором для мехвода и сигналами поворота и остановки).


                  1. Muzzy0
                    02.07.2019 13:45

                    Да и скорость движения современного танка на дороге с твердым покрытием составляет по меньшей мере 50 км/ч, а у некоторых и заметно больше. Мадленнее легковушки, но движение не станет.
                    а если разрешённая скорость — 120?
                    В остальном — так и есть.


                    1. geher
                      02.07.2019 14:22

                      Во-первых, с такой сеоростью танк и на трейлере не поедет.
                      Во-вторых, движение замедлится, но не станет.


                      1. DrPass
                        02.07.2019 14:28

                        В-третьих, разрешенная скорость 120 — это на дорогах первой категории, а там как минимум две полосы в одном направлении


                        1. Muzzy0
                          02.07.2019 14:34

                          про категории местные не знаю, но на участке 120 3 полосы минимум, местами 4-5.


                      1. Muzzy0
                        02.07.2019 14:33

                        90-100 тягач едет.


                        1. DrPass
                          02.07.2019 14:37

                          Да, но у тягача с танком все равно по правилам будет ограничение 70 км/ч.


                        1. geher
                          02.07.2019 14:40

                          А разве так можно с грузом больше 40 тонн? Правила не запрещают?


                1. boroda_el
                  02.07.2019 13:55

                  Слышал как-то рассказ, как колонну грузовиков, едущую по трассе со скоростью около 80, по полю обогнала колонна танков.


                  1. DrPass
                    02.07.2019 14:28

                    Да то байка чья-то. Не бывает танков, которые ездят по пересеченной местности с такой скоростью, да и вообще скорее всего, такой шустрой гусеничной техники не существует. На такое только колёсные машины способны, например, БТР-90.


                    1. boroda_el
                      02.07.2019 14:36

                      Да наверняка. У танков типа Т-80, Т-90 скорость хода по бездорожью заявлена 50-60кмч. Пусть даже он мог такой достигнуть на ровном поле. Если скорость колонны грузовиков убавить раза в 2 то достоверно получается.


                  1. geher
                    02.07.2019 14:35

                    Маловероятно. Самые шустрые танки из распространенных по достаточно твердой и ровной поверхности делают до 80.
                    Так что либо скорость преувеличили, либо спидометр врал (кстати говорят, что спидометры завышают показания скорости, чтобы не превышали).
                    Или случилось чудо и они встретили Т-15, который может больше 80, но это маловероятно.


        1. DrEds
          01.07.2019 13:21
          +1

          Причём тут танки? У французов Миражи есть, у которых за всю историю у всех моделей 3 или 4 случая отказа двигателей


          1. polus
            01.07.2019 13:51

            Ничего против французской техники не имею. Но заявленная вами надежность ИМХО не очень реальна. Откуда такие данные? Катастрофа из-за отказа двигателя и отказ двигателя — разные вещи. Открытую статистику отказов военного самолета сложно представить.


          1. dasFlug
            01.07.2019 18:57

            Точно Mirage? Статистика происшествий с двигателем на Mirage III по ВВС Австралии (второй по численности парк Mirage III в мире):

            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 выпущенных.


            1. Ctacfs
              01.07.2019 22:44

              A3-74, A3-75 — попадание птиц или осколков в двигатель, самолет потерян, пилот успешно катапультировался

              Ну тут как бы немного не вина двигателя. Не удивлюсь, если и среди остальных проишествий имеются спорные моменты, связанные с возможной неправильной эксплуатацией.


              1. dasFlug
                01.07.2019 23:45
                +1

                Случаи попадания посторонних предметов в двигатель в «Итого» не посчитаны, как не относящиеся к делу. В целом двигатели устанавливавшиеся на Mirage какой-то выдающейся надежностью не отличались. Особенно SNECMA Atar 09.
                Я всеже думаю что имеется в виду Rafale с M88 у которых ЕМНИП небыло серьезных происшествий по вине двигателей. Но Rafale двухдвигательный и суммарный налет парка не очень большой.


        1. playnet
          01.07.2019 16:21

          Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд. Достаточно посмотреть на следы после бульдозера, когда он по асфальту проехал. Или надо ставить резиновые накладки, что для парада можно сделать раз в год, но гонять на полигон и назад постоянно — это долго. И не факт что они вообще так умеют.


          1. ad1Dima
            01.07.2019 16:32

            У нас от НВВКУ до полигона ходят параллельно трассе через поля. Пару раз трассу пересекая. Километров 10 так проходят )


            1. Rikkitik
              01.07.2019 16:55

              У нас близко к полигонам спец. ветки ЖД были, от неё уже бетонка проложена. Из гражданских дорог раздалбыванию были подвергнуты только пара кусков по паре сот метров в военнородке (ничего сильно плохого им, если мне память не изменяет, от этого не стало, возможно, это всё та же бетонка, закатанная асфальтом сверху). В месте разгрузки — здоровенный пандус-перрон тоже бетонными плитами покрытый, на длину нескольких вагонов, чтоб техника прямо с платформ могла съезжать на дорогу. Потом в некоторых местах ЖД и платформы разобрали, и никто там больше танков не видал, лет 10 уж как. А такое пацанве счастье было! Но кое-где инфраструктура осталась, что как бы намекает.


          1. DrPass
            02.07.2019 03:24
            +4

            Если завод не напротив полигона — иначе никак, гусеницы разрушают дороги уже за 1 проезд.

            Как житель Донецка, могу сказать однозначно: это миф. Танки и САУ, конечно, оставляют царапины на асфальте, но никакого сколь-нибудь заметного вреда ему не наносят. Наверное, если взять полуразвалившуюся дорогу без основы, её и размолотят. Но по обычной нормальной городской дороге хоть сто танков проедет, ничего особого ей не делается, кроме вот таких царапин:
            pbs.twimg.com/media/BsqqrOsCEAAoc3-.jpg


            1. playnet
              02.07.2019 17:19

              Именно про это я и говорю. Тут явно не сотня проехала, а уже такие повреждения (а они довольно серьёзны — через год будут больше). Теперь представим что сотня танков утром проехала на полигон, вечером назад. И так месяц. И от каждого такие «царапины», выбивающие всё больше из полотна.
              Плиты прочнее асфальта, и не подвержены разрушению от воды.


              1. DrPass
                02.07.2019 17:31
                +1

                Это проспект Ильича в Донецке. По нему за пять лет их сотни, если не тысячи туда-сюда проехали, без какого-либо ремонта дороги. И это никакие не повреждения, просто поверхностные царапины. Они за день-два просто исчезают, т.к. затираются обычными легковыми машинами.


                1. tvr
                  02.07.2019 18:18
                  +2

                  пять лет ......, без какого-либо ремонта дороги.

                  Off.
                  Судя по картинке, у вас и разметка вместе со снегом весной не сходит.
                  /посмотрел в окно, на переложенные к ЧМ 2018 дороги с колеями, проваливающимся асфальтом и следовыми остатками разметки/.


        1. k1b0rg
          01.07.2019 18:21

          1. akryukov
            01.07.2019 18:58
            +1

            Затем, что до поля боя еще нужно доехать и это будет совсем не катание до полигона.


          1. Ctacfs
            01.07.2019 22:57
            +4

            Эта статистика художественная, чтобы люди прониклись сочувствием к танкистам. Никаких выводов из нее делать нельзя (и никто в общем-то не делает), особенно о требованиях к двигателю, это средняя температура по больнице.
            Как думаете, какое среднее время танка с отказавшим двигателем в бою?


          1. lingvo
            02.07.2019 10:52

            Это вроде вообще статистика по боям во время второй мировой войны. С того момента живучесть танков значительно повысилась. Да и пехоты тоже.


            1. boroda_el
              02.07.2019 14:00
              +1

              Ну и как бы противотанковые средства на месте не стояли. От пушек колотушек с целым взводом обслуги до индивидуального РПГ.


          1. vedenin1980
            02.07.2019 16:51
            +1

            Зачем ему ради 15 минут супернадежный двигатель?

            Потому что не каждый бой это Курская дуга, до первого серьезного боя может быть несколько недель маневров, ну и среднее время жизни это как и среднее время пехотинца в бою (которое тоже что-то минут 10), кто-то погибает в первой минуте первого боя, кто-то проходит всю войну от начала до конца.


        1. Muzzy0
          02.07.2019 12:37

          В наших Палестинах танки тоже на трейлерах возят, время от времени вижу их на дорогах.


      1. geisha
        01.07.2019 14:02
        +1

        Это нужно спросить у французов, в суперджете их двигатели

        Двигатели SaM146%


        Доля НПО «Сатурн» в совместном предприятии составляет 49,84%.
        Доля НПО «Сатурн» в общем объёме работ над двигателем SaM146 составляет около 38%.

        Пока что списывают на то, что французы не умеют делать камеру сгорания, но, по странному стечению обстоятельств, это — именно та версия, которая устраивает всех. По ещё более странному стечению обстоятельств, о проблемах с двигателем известно только из Ведомостей и их источников: никто из незаинтересованных лиц проверить слив не смог.


        Так или иначе,


        Нытьё Бочарова Олега Евгеньевича из минпромторга на этот счёт

        Мы испытываем мощнейшие сложности, связанные с нашим партнерством с французскими партнерами по двигателю SaM146. У коллег жесткая бизнес-модель и идти на симметричные снижения стоимости владения двигателем они не готовы. Разбирая все проблемы эксплуатации двигателя с региональными компаниями, мы видим, что и они пользуются сложившейся ситуацией, стремятся занять более выгодное для себя положение, в наших спорах с французами. (Фотография очень грустного кота) Мы понимаем, что нам надо создать банк подменных двигателей. Такая программа у ОДК есть. Документацию на полную разборку/сборку двигателей на территории рыбинского завода мы получили. Первый двигатель там уже полностью отремонтирован, то есть, разобран-собран. Вопрос коммерческий – идет торговля, за сколько мы с французами сговоримся. Мы понимаем, что условия, которые они выставляют по покупке/аренде подменных двигателей у компании PowerJet, неприемлемы для российских региональных авиакомпаний. Просто не приемлемы и все. А качество самого двигателя вне гарантийного срока и внутри гарантийного срока, вызывает вопросы по горячей части (горячая часть — французская производственная зона ответственности). С этим двигателем нам все равно жить и дальше. Это решение предшествующих периодов и никто не мог знать, что оно так пойдет. Безусловно, будем мучиться с этим двигателем, пока не произведем свой.


      1. CAJAX
        01.07.2019 14:17
        +2

        Эти же французы (Safran) поставляют движки для A320 и 737MAX и даже второй знаменит не отказом движка. Так что наверное проблема где-то ещё.


    1. Graf54r
      30.06.2019 15:04

      1. nevzorofff
        30.06.2019 15:51

        «Однако, здравствуйте», прямо. Спасибо за статью.


        1. nikolayv81
          30.06.2019 21:25
          -7

          Ещё есть на просторах интернета интересное заявление главы Роснефти о "немного нечестной конкуренции" когда европейские производители занижают ресурс своим двигателям в случае использования для заправки топлива произведённого российскими компаниями.


          1. nikolayv81
            30.06.2019 22:34
            -4

            Ссылка на статью про сокращение ресурса производителями https://www.kommersant.ru/doc/3869044


          1. MTyrz
            01.07.2019 01:26
            +18

            Это те компании, которые нефть с хлорорганикой гнали?
            Тогда я понимаю занижение ресурса двигателей, да.


    1. poznawatel
      01.07.2019 05:31
      +2

      У меня есть подозрение, что малый ресурс движков на Суперджете связан с эффектом пылесоса — движки слишком близко к ВПП.
      Общее в истории с Боингом — рост диаметров современных двигателей. Больший диаметр движков требует иных компоновочных решений, на которые авиапроизводители идти не хотят, прибегая к паллиативам (костылям).


      1. Vlad_2016
        01.07.2019 14:31

        Ваши подозрения в корне неверны.


  1. halted
    30.06.2019 14:59
    +2

    Как-то некорректно сравнивать оплачиваемость специалистов и недотестированность софта.
    Индусы может и написали код точно в рамках ТЗ, но как это отменяет тестирование?
    По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало, но если софт кривой и написан спецами с зарплатой в 1 миллион долларов в секунду, то как это отменяет кривость софта?
    Имхо, это проблема приемки, а не зарплат.


    1. Antervis
      30.06.2019 17:10
      +6

      но ведь тесты тоже какие-то спецы пишут


    1. edogs
      30.06.2019 18:08
      +22

      По сути софт могут писать и спецы с оплатой 1 копейка в сутки, лишь бы корретно работало
      Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.
      как это отменяет тестирование? Имхо, это проблема приемки, а не зарплат.
      Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.
      Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.


      1. dimkrayan
        30.06.2019 23:02
        -1

        Кривой софт могут написать и за 1 копейку и за миллион, а вот прямой за копейку не напишут.

        так 9 баксов в час — это не копейка. Если вы не умеете в преувеличение — используйте исходные данные.
        Тестирование может пройти и кривой код, в сложной системе абсолютно все варианты развития событий протестировать невозможно.

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


        1. DistortNeo
          01.07.2019 10:09
          +6

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

          Задача юнит-тестов — зафиксировать поведение кода, чтобы он не ломался при рефакторинге. А вот проверить правильность работы сложного кода с помощью юнит-тестов попросту нельзя. Но многие до сих пор считают, что 100% покрытие тестами гарантирует правильность работы кода.


          А вот более сложное высокоуровневое тестирование с написанием сценариев, обнаружением крайних случаев — всё это уже требует высокой квалификации тестировщика и его компетенции в смежных областях. Программист, который пилит маленький модуль в большой системе, о которой ничего не знает, не сможет написать интеграционные тесты.


          1. dimkrayan
            01.07.2019 10:43

            более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях. Кто видит картину шире. Кто принимает код.


            1. megathrone
              01.07.2019 11:04

              У них так и есть. Инженеры пишут спецификации, а кодеры просто тупо переводят их на язык Си. Юнит-тестировщики проверяют, что поведение кода соответствует спецификациям. Никто не требует от кодеров понимать, как работает автопилот или датчик высоты.


              1. DistortNeo
                01.07.2019 11:15
                +3

                Инженеры — отдельная тема. Как правило, редко человек бывает одновременно и хорошим инженером, и хорошим кодером. Человек достигает высокой квалификации, если занимается чем-то одним.


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


                1. megathrone
                  01.07.2019 12:01

                  а в переводе спецификации на язык, понятный кодеру

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


                  1. Peter03
                    01.07.2019 18:52

                    Если не секрет — сколько вам платили в час?


                    1. megathrone
                      01.07.2019 19:14

                      Это было в 2007 году. Я точно не помню почасовую ставку. Я учился в универе и работал неполный день (как и большинство коллег). Наверное долларов 3-5 в час. Там же была куча посредников, желающих поиметь свой гешефт. Для меня это были очень хорошие деньги, особенно если учесть что альтернативой была работа эникейщиком в больнице за 3500р в месяц. Потом начался кризис и весь наш филиал сократили.


              1. dimkrayan
                01.07.2019 11:26
                +2

                вы напрасно зацикливаетесь именно на юнит тестах. Этого сильно не достаточно. Нужны более разнообразные тесты на всех уровнях, и этим должны заниматься специально обученные люди


                1. megathrone
                  01.07.2019 12:03

                  Я ни на чем не зацикливаюсь и сам считаю что юнит-тестов недостаточно. Я всего лишь рассказываю о той области, в которой довелось работать. Как там все проверяется уровнем выше, я не имею представления, но уверен, что как-то проверяется.
                  P.S. У нас в иехархии были люди, которые тщательно проверяли, что юнит-тесты написаны правильно :)


                  1. severgun
                    01.07.2019 13:22

                    346 трупов ставят под сомнение ваше утверждение.


                    1. megathrone
                      01.07.2019 13:52

                      ваше утверждение

                      Какое из моих утверждений?
                      Если в реализации ПО оказались какие-то косяки, то, очевидно, на каком-то уровне проверяли недостаточно тщательно. Но это еще не говорит о том, что проверок вообще не было.


            1. DistortNeo
              01.07.2019 11:17

              более высокоуровневые тесты должны писать не те, кто имеет компетенцию в смежных областях, а те, кто имеет компетенцию в более высокоуровневых областях

              В идеале компетенция в низкоуровневых вещах тоже должна быть.


              Кто видит картину шире

              Так я это и написал.


              1. dimkrayan
                01.07.2019 11:27

                абсолютно не обязательно. А учитывая невозможность знать все, в идеале человек должен заниматься своим делом.


        1. ncix
          01.07.2019 10:26
          +4

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


          1. dimkrayan
            01.07.2019 10:47

            большая управляемость. Найти одного чудо-разработчика, который не лагает очень-очень сложно. Если его переманят — бизнес встанет.
            А вот такой зерг раш прекрасно масштабируется и работает.


            1. ncix
              01.07.2019 11:04
              +8

              Видел я такой "Зерг раш". За пару дней до конца спринта завершается тестирование с результатами, что ни один юз-кейс полностью пройти нельзя. При этом команда раздута до десятков человек, суб-команды перекидывают ответственность друг на друга, из-за размеров команды частенько кто-то нужный сваливает в запланированный отпуск, центральный менеджемент мечет молнии но ничего не понимает, т.к. не в состоянии погрузиться глубоко. Неизбежно начинается игра с Заказчиком в "Это было в требованиях, а этого не было".


              1. dimkrayan
                01.07.2019 11:34

                да, есть такая проблема, но за счет новых архитектурных моделей — разбиения на микросервисы, фронтенд-бекенд и прочее, ну и всяких там аджайлов, получается все больше людей включить в этот хоровод.
                И все равно это проще, чем найти чудо-разработчика.


                1. DistortNeo
                  01.07.2019 11:40

                  Бортовые системы самолёта по тем же принципам работают?


                  1. dimkrayan
                    01.07.2019 11:42

                    по тем же принципам, что и управление персоналом?
                    Мне кажется, вы как-то не правильно вопрос задали.


                    1. DistortNeo
                      01.07.2019 11:57

                      Вопрос: нужны ли все эти микросервисы-фронтэнд-бэкэнд в бортовой системе самолёта?


                      1. megathrone
                        01.07.2019 12:09

                        Там не то что микросервисов нет, там по-моему даже ООП и динамическое выделение памяти стараются не использовать, из соображений что код должен быть максимально отказоустойчивым, чтобы летательный аппарат не упал.


                        1. DistortNeo
                          01.07.2019 12:21

                          Вот поэтому мне и хочется понять, насколько популярные сейчас методы и инструменты разработки подходят под rocket science.


                        1. lingvo
                          01.07.2019 13:09

                          Не отказоустойчивым, а выполняемым в реальном времени. То есть программа должна гарантированно выполниться за xx миллисекунд при любых входных условиях. Большее время выполнения равнозначно отказу ПО.


                1. ncix
                  01.07.2019 11:43

                  Да, про чудо-разработчика абсолютно согласен. И сложно найти и массу рисков несёт. Нужны крепкие миддлы, выстроенные процессы, железная дисциплина (чему кстати способствуют кажущиеся бессмысленными приседания в Скраме). Но вам понадобится чудо-менеджер, которых наверное еще меньше чем чудо-разработчиков.


                  1. dimkrayan
                    01.07.2019 11:49
                    +1

                    про менеджеров ничего не знаю.
                    Вот только одна проблема: крепкие мидлы остаются мидлами очень ограниченный срок.


                    1. ncix
                      01.07.2019 14:29

                      Это прозвучит не очень красиво, но я в какой-то момент понял что основная часть команды не должна состоять из амбициозных людей. Они действительно стремительно вырастают и улетают из гнезда.


                      1. dimkrayan
                        01.07.2019 14:36
                        +1

                        если вы создаете условия для дальнейшего роста и платите в соответствии с квалификацией — с чего бы им улетать?
                        Другое дело, работодатели любят дуть в уши про то, сколько они в тебя вложили, поэтому ты должен работать за сильно меньшую зп, чем мог бы получать.


                        1. ncix
                          01.07.2019 14:55
                          +1

                          если вы создаете условия для дальнейшего роста

                          в одной команде сложно ужиться нескольким сеньорам. Они хотят либо тимлидить либо принимать общие архитектурные решения, а не исполнять в коде чьи-то идеи.


                          1. andreylartsev
                            02.07.2019 11:10

                            Правильный подход к управлению командой легко решает такие проблемы


                            1. ncix
                              02.07.2019 13:48

                              Такого "правильного" управленца найти еще сложнее чем крутого разаботчика, писал выше.


            1. DistortNeo
              01.07.2019 11:18
              +1

              А вот такой зерг раш прекрасно масштабируется и работает.

              Данная статья показывает, что для высокотехнологичных задач зерг раш не работает, а может стоить даже дороже.


              1. dimkrayan
                01.07.2019 11:31
                +2

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


      1. donbob
        01.07.2019 10:58

        Это комплексная проблема, корни которой все же лежат в первую очередь в экономии.

        Абсолютно верно, проблема по существу, в ускорении конкуренции


      1. kickstarter
        03.07.2019 13:47

        Не удивлюсь, что тестирование выполняли те же индусы


    1. raamid
      30.06.2019 18:31
      +9

      Как было сказано в статье, «белые» инженеры задолбались исправлять ошибки «черных». Здесь белые и черные — это условные названия высокооплачивемых спецов и низкооплачивамых аутсорсеров. Если ошибки встречаются 100 раз в день, то гораздо легче пропустить ошибку, чем в случае, когда ошибки встречаются 1 раз в неделю. Так что тут общая отвественность. Хотя конечно, высшему руководству стоило подумать, прежде чем аутсорсить такую важную часть работы.


      1. Gutt
        30.06.2019 21:30

        Хм. Если код пишет аутсорсер, то на выходе должен быть товар, проходящий автотесты, то есть как минимум обеспечивающий затребованный функционал. Кроме того, при хорошей архитектуре не так уж и важно, что там внутри модуля, если на допустимый диапазон входных данных от выдаёт ожидаемые значения. Хоть таблица соответствия на гигабайт. Так что дело не аутсорсерах, «белых» и «чёрных» девелоперах, а в организации процесса.


        1. DistortNeo
          01.07.2019 09:51
          +6

          Если код проходит автотесты, это лишь означает, что при определённых входных данных он выдаёт соответствующие выходные значения. А вот о правильности код речи идти не может.


          1. TIMOHIUS
            01.07.2019 12:35

            Да и само тестирование не исключает наличие ошибки, а лишь снижает вероятность наличия…


          1. dimm_ddr
            01.07.2019 14:04

            При этом соответствующие значения совершенно необязательно вообще верны.


          1. Wesha
            01.07.2019 22:00
            +14

            Приведу пример из моей практики.

            Работал как-то над софтиной, написанной индусами. Прилично удивил кусок кода вида (примерно, на псевдокоде):

            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» падает система". «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.

            Автотесты код, естественно, проходил…


            1. 9660
              02.07.2019 06:59

              «А, понятно!» — сказал индийский программист и исправил (как мог). Результат Вы видите.
              Автотесты код, естественно, проходил…
              А ревью кода у них отсутствовал как класс? СММ какого уровня у конторы?


            1. AlexSpirit
              02.07.2019 07:04

              У меня вопрос, а какого чёрта входные данные не проверяются на стадии ввода?


              1. mayorovp
                02.07.2019 09:24

                Так данные-то корректные (формально). Просто они оказались неожиданными конкретно для функции PerformSomeComputations().


                Мы вот как-то в базе прода "нашли" 78-осный грузовик, и он так же "не пролез" через одну из функций. Означает ли это, что грузовик некорректный?


                1. AlexSpirit
                  02.07.2019 13:40

                  Почти 4 миллиона миль это корректные данные? При том, что для этого автопарка и 200 000 это уже много. Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть. Там считается, что проехать пару миллионов миль, между событиями учёта, это корректные данные? Кто вообще писал ТЗ и проектировал этот бардак?

                  >>Означает ли это, что грузовик некорректный

                  Зачем Вы подменяете понятия? Вопрос не в грузовике, а отсутствии контроля входных данных при импорте/входной форме, это же грёбаные азы.


                  1. mayorovp
                    02.07.2019 14:42

                    Тут мы упираемся в парадокс кучи: где та граница, ниже которой значения еще реальные, но свыше которой ни одна машина ни одного километра проехать не может?


                    Почему вы даже не рассматриваете вариант, при котором функция PerformSomeComputations должна работать с любыми числами?


                    Или тот вариант, при котором она должна на них падать, но не рушить при этом всю систему?


                  1. Wesha
                    02.07.2019 19:01

                    Кто вообще писал ТЗ и проектировал этот бардак?

                    Компания называлась ADP — гигантский когломерат, производящий автоматизацию всего и вся. Я в то время работал в подразделении, которое автоматизировало (вернее, привносило зачатки big data в) работу автосалонов. Подразделение почти целиком состояло из индусов. :) Дело было лет 12 назад, тогда код-ревью и проч. ещё не были buzzwords.


                    Кроме того уверен, что в той базе данных предыдущие показания одометра по данному ТС есть.

                    Одной из характеристик выставленных на продажу б/у автомобилей как раз и является пробег — он фиксируется, когда продавец привозит машину на продажу, и, естественно, не меняется, когда машина стоит на продажной площадке. Поэтому предыдущих значений нету.


            1. playnet
              02.07.2019 17:46

              У меня был пассат с пробегом около 300к км по одометру, на момент моей покупки он уже был сломан и больше не считал, а я ещё хз сколько накатал. То есть моя машина не может быть внесена в вашу базу без скручивания?


              1. Whuthering
                02.07.2019 20:14

                у вас 300 тысяч, а в комментарии выше речь идет про 3 миллиона.


      1. dimkrayan
        30.06.2019 23:05

        если 100 ошибок в день — значит тестить надо еще тщательнее. Значит, двое должны ревьювить. Или трое. Все-таки самолет делают.


        1. CrashLogger
          01.07.2019 10:09
          +11

          А в чем тогда смысл аутсорсинга, если код одного индуса будут проверять два высококвалифицированных инженера? Может тогда пусть они и пишут?


          1. DistortNeo
            01.07.2019 10:25
            +6

            Пример работы эффективных менеджеров в действии.


          1. dimkrayan
            01.07.2019 10:49

            не одного, а сотни. И пишет он неделю, а проверяют час. По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.

            а что, код белого человека проверять не надо? Он ошибок не совершает? А это, повторюсь, самолет.


            1. DistortNeo
              01.07.2019 11:21
              +2

              И пишет он неделю, а проверяют час

              В том-то и дело, что не час. Это же самолёт.


              По хорошему, значительную часть работы в виде покрытия тестами аутсорсы сделают сами.

              Юнит-тесты не проверяют правильность кода. А более высокоуровневые тесты индусы писать не смогут.


              1. dimkrayan
                01.07.2019 11:35

                так все равно эти тесты нужны. Даже если самых-присамых лучшие кодеры будут это писать.


                1. DistortNeo
                  01.07.2019 11:40
                  +1

                  Они нужны, но решают другую задачу.


            1. iago
              01.07.2019 11:48
              +1

              Где-то я читал, что в коде SQLite 95%, что ли, занимают тесты и только 5% — код самой базы. Так что в самолетостроении очень может быть, что сам код занимает значительно меньше, чем тесты, а затраты на тестирование больше затрат на разработку — отчего бы и нет


            1. dimm_ddr
              01.07.2019 14:07
              +1

              В случае системы с большим количеством возможных состояний и большими рисками при ошибке тестирование легко может занимать гораздо больше времени чем разработка. Причем временами — на порядок больше. И это даже не касаясь юнит тестов.



    1. nikolayv81
      30.06.2019 21:29
      +7

      Чем больше и разнообразнее опыт инженера и чем лучше он знает для чего он пишет софт и как это работает не только программно, тем меньше вероятность получить комплексную проблему на выходе (а к пуговицам то претензий нет), но такой инженер стоит, обычно, немного дороже, работает, часто, медленней, в общем пока гром не грянет — сплошные убытки :)
      p.s. наблюдаю такую картину постоянно, кусочки работают по регламенту и по т.з. а в сумме то тут то там что-то идёт не так...


      1. yurisv3
        02.07.2019 13:16
        +2

        Чем больше и разнообразнее опыт инженера

        В данном случае дело даже не в опыте. Специфическая для индийских хм… «инженеров» (а равно и программистов в инженерных доменах) проблема закладывается еще во время учебы, и отлично описана Фейнманом в его известной книге. Конечно, там место действия — Бразилия, НО. Удивительным образом все совпадает до деталей. Поэтому не буду плодить сущности и просто процитирую (извиняюсь за размер)

        Но потом я спросил, можно ли, имея всего один кусок поляроида, определить, в каком направлении он поляризует свет. Они совершенно не представляли себе. Я знал, что это требует известной доли находчивости, поэтому я подсказал: «Посмотрите на залив. Как от него отражается свет?» Все молчат. Тогда я сказал: – Вы когда-нибудь слышали об угле Брюстера? – Да, сэр. Угол Брюстера – это угол, отражаясь под которым от преломляющей среды, свет полностью поляризуется. – В каком направлении свет поляризуется при отражении? – Свет поляризуется перпендикулярно плоскости падения, сэр. Даже теперь я не могу этого понять. Они знали все наизусть. Они знали даже, что тангенс угла Брюстера равен показателю преломления! Я сказал: «Ну?» По-прежнему, ничего. Они только что сказали мне, что свет, отражаясь от преломляющей среды, как, например, воды в заливе, поляризуется. Они даже сказали, в каком направлении он поляризуется. Я сказал: «Посмотрите на залив через поляроид. Теперь поворачивайте поляроид». – О-о-о, он поляризован! – воскликнули они. После длительного расследования я, наконец, понял, что студенты все запоминали, но ничего не понимали. Когда они слышали «свет, отраженный от преломляющей среды», они не понимали, что под средой имеется в виду, например, вода. Они не понимали, что «направление распространения света» – это направление, в котором видишь что-то, когда смотришь на него, и т.д. Все только запоминалось, и ничего не переводилось в осмысленные понятия. Так что, если я спрашивал: «Что такое угол Брюстера?», я обращался к компьютеру с правильными ключевыми словами. Но если я говорил: «Посмотрите на воду», – ничего не срабатывало. У них ничего не было закодировано под этими словами.

        Вот это нынешняя система технического (= не гуманитарного) образования в Индии как она есть.


    1. BobbieZi
      30.06.2019 21:33
      +8

      Пример кода специалиста с оплатой в 1 копейка в сутки:

      bool value;
      if(value.ToString.Length() == 4)
      return true;
      else if(value.ToString.Length() == 5)
      return false;

      else
      return !true && !false;

      Приемка тестирует функцию — она работает? работает.


      1. 0xd34df00d
        01.07.2019 05:33

        И что в ней может привести к падению самолёта?


        Кроме ошибок аллокации памяти в ToString, которыми, имхо, можно пренебречь при данных вводных.


        1. balexa
          01.07.2019 07:08
          +2

          Например если toString выбросит NPE


          1. 0xd34df00d
            01.07.2019 07:15

            А почему там NPE может быть?


            1. virrus
              01.07.2019 08:51

              Потому что, согласно спецификации, работа toString гарантируется только на корректных входных данных, а здесь на вход пришли неинициализированные. На корректных тестах всё работало. Undefined behavior, однако.


              Это, конечно, была ирония. Протестировать тестами полностью всё невозможно — два int' а во входных данных уже дадут де-факто бесконечное время для перебора.


              1. 0xd34df00d
                01.07.2019 15:36

                Если бы там данные были неинициализированные, то эта функция и для обычного сравнения упала бы, разве нет?


                Но я C#, считайте, не знаю, мне правда интересно.


                1. PsyHaSTe
                  01.07.2019 17:21

                  Тут разве что оом может упасть при попытке строчку выделить, но это такое.


                1. virrus
                  02.07.2019 01:56
                  -3

                  Неинициализированный bool нормально сравнится, оба if будут ложными либо сравнение на true будет заменено компилятором на "не ноль". Дальше если оптимизатор вырезал "недостижимый" код, то все плохо, иначе сработает последний return и всё хорошо.


                  toString для bool можно сделать как return constantStrings[boolValue], которая полагается на то, что bool превращается в 0 или 1. Неинициализированный, соответственно, даст выход за границы массива и там можно схватить вообще что угодно, NPE в том числе. Но тут надо будет старательно завернуть всё в unsafe и выкрутить оптимизатор.


                  1. mayorovp
                    02.07.2019 09:33
                    +2

                    В C# не бывает "неинициализированного" bool.


                    1. virrus
                      02.07.2019 10:40

                      Даже если передать указатель на структуру с bool в очень плохой unmanaged код?


                      1. DistortNeo
                        02.07.2019 10:44

                        Да.


                      1. mayorovp
                        02.07.2019 14:48

                        Да, даже в этом случае. В результате в bool может оказаться мусор — но это все равно будет инициализированный мусор.


                1. Muzzy0
                  02.07.2019 14:52
                  -3

                  Но я C#, считайте, не знаю, мне правда интересно.
                  Хвала Аллаху, что подобные системы ещё не докатились до шарпа.


        1. r00tGER
          01.07.2019 09:21
          +2

          А, зачем вообще String и динамическое выделение памяти в ответственных местах?
          Такой код, скорее всего не пройдет по стандартам.


          1. 0xd34df00d
            01.07.2019 15:38

            Это другой вопрос, и я поэтому и сказал сразу, что проблемами возможного недостатка памяти пренебрежём — это сразу в целом, вообще, совсем другой класс процессов разработки и подходов к коду.


            Может, там, кстати, small string optimization, хехе.


            1. mayorovp
              02.07.2019 09:36

              small string optimization тут ни при чем, если это и правда C# имелся в виду — то там все строковые литералы интернированные (так же как и в Java, Javascript и Python). А результат bool.ToString() должен быть именно литералом (нет никаких причин делать иначе).


        1. roscomtheend
          01.07.2019 16:09

          ИСТИНА/ЛОЖЬ — и мы поворачиваем не в ту сторону.


          1. DistortNeo
            01.07.2019 16:25

            Почти, но мимо. В C# не предусмотрена локализация для типа bool.
            Только "True", "False".


            1. roscomtheend
              02.07.2019 08:30

              Почти, но мимо. В C# ToString() — функция, а не свойство.
              PS. А Length — наоборот, свойство.


              1. DistortNeo
                02.07.2019 10:44

                Вы вообще о чём?
                bool.ToString() возвращает всегда либо "True", либо "False".


      1. mikelavr
        01.07.2019 06:23
        +7

        Последний return — впечатляет :-D


      1. iig
        01.07.2019 08:05

        Более того, если это переписать на С++, компилятор все равно оптимизирует что индусятину, что прекрасный код. !true && !false точно уйдет.


        1. goldrobot
          02.07.2019 08:57

          >!true && !false точно уйдет

          А в шарпе что будет?


          1. iig
            02.07.2019 11:15

            Своя, шарповская магия ;) Я о том, что процессор выполняет совершенно не тот код, который написан в текстовом редакторе.


      1. justboris
        01.07.2019 09:58
        +1

        Источник. Сколько получает автор кода – там не указано.


      1. weird_one_man
        01.07.2019 11:24
        -1

        Я думаю, что в этой области применяют, всё-таки, фортран


    1. silverpopov
      30.06.2019 23:56
      +17

      Рецепт быдлокодеры+тестирование=хороший софт является в корне ошибочным.


      1. glestwid
        01.07.2019 09:15
        +1

        Осталось донести эту мысль в головы владельцев заводов, газет и пароходов. Ну или Итшных галер для начала.


        1. r00tGER
          01.07.2019 09:26

          А, в чем проблема то для них? Владельцы заводов, пароходов, «галер»..., и так получают прибыль.


          1. glestwid
            01.07.2019 10:29
            +2

            В том-то и дело что для них это не проблема, пока деньга капает, а пипл хавает. Плюс к этому эффект короткого горизонта планирования в стиле отчитаться перед годовым собранием акционеров, на крайняк перед SEC и FBI, а потом хоть потоп.


          1. severgun
            01.07.2019 13:33
            +1

            боинг больше не получает.
            Самолеты не летают. Предзаказы отменены. Новых контрактов на авиасалоне не заключено.


      1. 8street
        01.07.2019 11:13
        +3

        В России так же дороги делают. Отдают на аутсорс подрядчикам. Те в свою очередь еще одним, а те находят команду, готовую работать за еду. К сожалению, это во всех сферах так.


    1. Yuriks111
      30.06.2019 23:56
      +3

      Согласен. Главное, проблема была в единственном сенсоре который отвечал за стабилизацию, без резервирования. Качество разработчиков, ИМХО, тут не причем.


      1. 8street
        01.07.2019 11:14

        Там было резервирование сенсора. Но реализовано криво.


      1. kramer3d
        01.07.2019 11:45

        В том-то и беда, что их (датчиков угла атаки) два, и при расхождении данных с них MCAS выбирает большее значение.


    1. Dmitri-D
      01.07.2019 06:49
      +1

      halted вам нужно своими глазами посмотреть хотя бы на 1 проект, сделанные индусами. Вопросы отпадут сами собой.
      Т.е. то что вы говорите — верно, но только если пишут не индусы.


      1. iago
        01.07.2019 11:51
        +3

        поправлю вас — «сделанные дешевыми индусами». Я работаю сейчас с «дорогим» индусом, который эмигрировал из Дели в Финляндию, он пишет код намного чище и лучше большинства наших разработчиков.


        1. Druu
          01.07.2019 15:03
          +1

          поправлю вас — «сделанные дешевыми индусами».

          Может, следует поправить сразу до "сделанных дешевыми программистами"? И даже не "дешевыми", а просто "плохими"?


        1. Dmitri-D
          01.07.2019 16:17

          Всё-таки есть разница между теми, кто сидит в бангалоре и теми кто вырос из бангалора и сумел трудоустроиться в Европе или Штатах.
          У нас тут тоже завелись индусы, и их всё больше. Жду когда нас призовут переходить с С++ на Яву


    1. virrus
      01.07.2019 09:02
      +3

      Как проверить, что функция, перемножающая два числа и делящая результат на третье, работает всегда корректно? Кроме "открыть, почитать, подумать", я другого способа не вижу. Можно скормить ей произвольные данные, но это будет вероятностный тест. Вдруг внутри этой функции какое-то значение промежуточного результата используется как код ошибки? Это отсылка к функции MulDiv из winbase.h.


      1. struvv
        01.07.2019 12:07

        Для этого есть языки с автоматическим доказательством теорем. В таких, например, невозможно получить ошибки типо деление на ноль. От ошибок в бизнес логике, впрочем, это не защитит


        1. PsyHaSTe
          01.07.2019 15:25

          Осталось только узнать, умеют ли среднестатичтические индусы а ATS.


    1. woooody
      01.07.2019 10:08
      +9

      Цена за час — это просто объяснение, почему отдали в индию. Речь не об этом.
      Речь о том, что люди, которые выползли из трущоб не могут мыслить широко и глубоко, иначе они бы не жили там десятилетиями. А те, кто могут, уверяю вас, уже давно там не живут и работают далеко не за 10, а может даже и не за 40 в час.

      Качественно протестировать код тоже стоит денег и хороших инженеров. Кстати если брать метрики за строчки кода (да, такие встречаются), то протестировать строчку кода стоит примерно в 2 раза дороже (в часах), чем её написать.
      Например у меня была история с одним самолетом. Было, казалось бы, пустяковое изменение — изменение частоты процесса в 2 раза. Это не подразумевало никаких других изменений в коде и тестах, а тесты стали падать (т.к. их требовалось просто перепрогнать). Весь модуль был давно написан и протестирован (угадайте с одной попытки — кем ;)). Но даже когда он попал к нам, специалисты уровня Middle не смогли даже подступиться к причине на первом этапе.

      Чтобы не раздувать пост, скажу только что были требования, был код, написанный четко по этим требованиям, и тесты, которые, о боже, тоже написаны по требованиями. Проблема была в том, что требования были неоднозначны.
      За полтора года за не сколько итераций удалось привести требования в нормальный вид, и тесты заодно. Почему так долго? Потому что вместо того чтобы плавно и аккуратно исправлять косяки на следующей итерации они выкатывают один CR за 2 дня до дедлайна, в котором «запилены» все непонятные_им_проблемы_в_виде_костылей. Инженер, который не принимал участие в тестировании этого модуля сразу упадет в обморок. Человек с опытом будет громко кричать что это всё г****но и надо переделать, но большинство его замечаний будет проигнорировано. Там по большому счету надо было пару месяцев плотной переписки, чтобы всё привести в порядок. А когда это 2 дня раз в 5 месяцев… ну сами понимаете.
      А вот код не успели, потому что сертификация закончилась и времени и бюджета на исправление косяка в одну строчку уже не было, хотя первый раз я им ткнул на эту строчку за подлгода до дедлайна.

      К чему это я…
      А к тому, что даже очень опытный и дотошный тестировщик не имеет нормальных возможностей убедить разработчиков исправить косяк до того, как этот код начнет перевозить пассажиров. В тех реалиях, которые есть на данный момент.


      1. DistortNeo
        01.07.2019 10:22
        +3

        Вот так оно и есть. Вся эта возня с делегированием задач оправдывает себя, если работник обладает собственными разумом. Индусу сказали копать — он и копает, не загружая мозг посторонними задачами.


        Вы составили ТЗ, индус что-то написал в точном соответствии с ТЗ. Но тут внезапно оказывается, что то, что для вас очевидно, для индуса не является таковым. В итоге ТЗ выполнено, но на выходе совсем не то, что вы ожидали. Поэтому приходится уточнять ТЗ и отправлять на доработку и т.д. Но у вас нет времени на переделку, поэтому в какой-то момент просто принимаете работу в том виде, в котором она есть.


        Чтобы индус написал нужный код, придётся скрупулёзно составлять ТЗ, расписывая всё до самых мелочей. И в какой-то момент окажется, что накладные расходы на делегирование задачи окажутся выше, чем решение задачи собственными силами. И если в случае штатных сотрудников такое оправдано (сотрудник наберётся опыта и станет более автономным), то в случае аутсорса каждый раз нужно начинать всё с нуля.


        1. Peter03
          01.07.2019 19:09

          Самое интересное что существуют культурные различия, одно из наиболее известных это неумение говорить «нет». Менее известная, но интересная особенность, что для многих у них растянутая картинка (т.е. с неправильным aspect ratio), выглядит нормально и они не воспринимают это как проблему. Или например факт что для многих это норма иметь пару слуг которые делают грязную/неинтересную работу и они могут воспринимать это ниже собственного достоинства делать определённые вещи (особенно некоторые касты).

          У нас например есть специальный тренинг для индусов которые приходят в команду, написанный умным индусом. Остальным его не обязательно проходить, но очень интересно и помогает понять подобных коллег и т.п.


      1. winclil
        02.07.2019 00:50
        +3

        Дима, привет! с тех пор, как ты от нас ушел, в индустрии все изменилось еще дальше в худшую сторону :)

        Что касается исходной статьи, ты прав, в целом она — «плач Ярославны» про то, что хороших американских инженеров заменяют в пропорции 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 и т.п. внутрь себя, тоже сокращает собственные издержки за счет увольнения опытных и найма пачек неопытных и так далее. В целом, в индустрии идут довольно сильные изменения, которые снаружи могут быть не так заметны.


        1. arielf
          03.07.2019 02:33

          Как ужасно! Полное разложение нормальной инженерии!


    1. Anduin76
      01.07.2019 10:58
      -6

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


      1. Kanut
        01.07.2019 11:07
        +4

        Боинг и так находится под надзором FAA. Так что как мы видим госнадзор тоже не панацея.


        1. cadmi
          01.07.2019 14:25

          Боинг не находится под надзором FAA.

          Там жесть жестяная. Фактически, 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


          1. Kanut
            01.07.2019 14:29

            Официально Боинг находится под контролем FAA. И то что FAA делегировала контроль кому-то другому, а точнее самому Боингу, сути дела не меняет.
            Потому что точно так же любая другая госконтора может «делегировать» надзор за Боингом кому-то другому, в том числе и менеджерам самого Боинга :)


            1. eshirshov
              02.07.2019 13:24

              … джентельмен джентельмену верит наслово, и тут мне такая масть пошла!


    1. megathrone
      01.07.2019 11:03
      +2

      Я работал (правда, недолго) тестовщиком кода для Боинга 787, когда был студентом.
      Код реально писали индусы (у нас был доступ к VCS с историей коммитов), и да, код был плохим. При том, что на каждый маленький модуль было четкое описание, что он должен получать и отдавать, они умудрялись написать код, не соответствующий этим требованиям.


      1. vdonich
        03.07.2019 00:15

        А как с тестированием там было?


        1. megathrone
          03.07.2019 10:59

          Тестированием чего?
          Мы не разрабатывали код, мы только писали юнит-тесты на готовый код, сами же их прогоняли и в случае каких-то несоответствий с документацией писали репорты по установленным образцам. Все это перепроверялось старшими, а потом отсылалось на уровень выше. Что там дальше с этими репортами происходило, я не знаю, но обычно потом ошибки фиксились в новых ревизиях. Я был всего лишь джуном на аутсорсе, и у меня естественно не было полной картины происходящего.


    1. saboteur_kiev
      01.07.2019 13:12

      IMHO это проблема менеджмента компании, а точнее тех, кто делает следующие заявления:

      “Генеральное руководство компании”, — говорится в заявлении, — “не участвовало в данной проверке”.


      один из менеджеров на всеобщем собрании заявил, что компания Боинг не нуждается в сеньорах, так как их продукты уже достаточно зрелые.



    1. Sly_tom_cat
      01.07.2019 14:35

      А вы работали с индусами на аутсорсе?

      Мне вот довелось — врагу не пожелаю. Описывать элементарную задачу пришлось несколько раз и в конечном варианте я написал спеку… которою можно было копипастить в код… что они и сделали наделав еще и ошибок.

      Нет, я допускаю что мне не повезло с конкретными индусами, но только они работали на подряде у автомобильного гиганта с мировым именем.


  1. staticmain
    30.06.2019 15:01
    +5

    Правильный заголовок:

    Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 98 280 рублей в месяц


    И уже не так резко звучит для российских программистов, особенно вне мск-региона, верно?


    1. Graf54r
      30.06.2019 15:05

      вроде же софт писался когда доллар был по 30р


      1. staticmain
        30.06.2019 15:07

        Окей, для 2010го года следует читать так:

        Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими 45 360 рублей в месяц
        Много российских программистов в 2010м получали 45 000?


        1. halted
          30.06.2019 15:28

          Т.е. размер зарплаты освобождает от ответственности за жизни людей? Посыл получается именно такой.


          1. Areso
            30.06.2019 15:45

            Нет, не освобождает. А посыл звучит типа «ваша жизнь зависит от джунов, потому что на сеньорах и даже миддлах мы решили сэкономить».


          1. nikolayv81
            30.06.2019 21:32
            -2

            Размер нет, а сложная схема передачи ответственности вполне может спасти головы в руководстве, но всё зависит от уровня возникших проблем. Моё личное ИМХО если бы вторым самолётом оказался самолёт American airlines, уже бы не один человек считал годы до окончания срока...


          1. ganqqwerty
            01.07.2019 12:28
            +1

            а много гениев и даже просто скрупулезных спецов пойдут на такую зп?


        1. smitevg
          01.07.2019 00:11

          Думаю зп 45тыр в 2010 для спецов 2-3 года после вуза это минимум для города 1млн человек. сейчас около 90 наверное.


          1. staticmain
            01.07.2019 00:46
            +8

            Либо вы живете в какой-то другой реальности, либо не в России.


            1. PsyHaSTe
              01.07.2019 15:42

              в 2013 я устроился на 15 тысяч полставки (от 30), студентом-третьекурсником с 0 опыта. 45 тысяч через 2 года после вуза более чем реально. ХОтя конечно, может 2010 и 2013 сильно отличаются, не знаю.


          1. hint000
            01.07.2019 11:24
            +2

            2019 год на дворе. Город 2+ млн человек. Скоро 20 лет после вуза. Недавно прилетело предложение «инженер Линукс, от 50тыр». И это было бы хорошее предложение (если бы компания вызывала хоть малейшее доверие, что такую зарплату действительно заплатят).


        1. UnknownUser
          01.07.2019 10:23

          Насколько помню, я в 2010м в Перми примерно столько и получал.
          Если сравнивать с однокурсниками, это было чуть ниже среднего. Но зато было интересно )).


        1. vt4a2h
          01.07.2019 11:37
          +1

          Ну и минус ~40% налогов, надо полагать. Всё-таки в РФ обычно считается з/п после вычета всех налогов, так что ~27к рублей.

          Ну и опять же, мы не знаем, сколько из этих $9 в час забирал аутсорсер. Программисты же компании-заказчику обходились в $9 в час. Если аутсорсер ещё минимум 30% забирал, то всё вообще плохо. Хотя в оригинале статьи и написано, что это был именно доход разработчиков, но кто знает.


        1. VSOP_juDGe
          02.07.2019 12:13

          много


    1. NetBUG
      30.06.2019 15:16

      Проблема не в сумме зарплаты сотрудника, а в том, что не только разработка, но весь цикл проектирование-разработка-тестирование-приёмка проводился в компании, которая никогда не делала отказоустойчивые системы.
      Если взять разработку в самой Boeing, где есть инженер, заложивший дублирование, тест-писатель, описавший известные ему и компании случаи отказов в тестах, и менеджер, который не примет код до того, как он пройдёт тесты — то да, можно заменить разработчика на дешёвого. Будет ли дешевле час работы сотрудника за $50 или неделя возни и возвратов индусу с $9 — другой вопрос.
      А если вся задача делегирована людям, которые, условно, раньше делали софт уровня 1С — то ТЗ будет выглядеть как «типа надо компенсировать недостаток манёвренности», тесты буду выглядеть как «взлетаем, не хватает управления, триммирование включается, всё хорошо начальникама» — разработчик ПО (который, в отличие от менеджера и инженера, не обязан хоть что-то знать про самолёты) мог написать с первого раза идеальный код, который на 100% делает ровно то, что описано в ТЗ.
      Но ТЗ неадекватно требованиям к подсистемам в авиации. В этом и проблема, насколько я понял — в делегировании проектирования целых подсистем в компании-подрядчики


      1. staticmain
        30.06.2019 15:20
        +1

        Суть не в уровне зарплат, суть в заголовке, который за бугром еще можно назвать кричащим, но у нас этот заголовок звучит еще хуже, чем если бы статью опубликовали в Индии.

        Т.е. грубо говоря у нас заголовок преобразуется в:
        «Аутсорс программисты с позорно низкой зп выше чем у вас написали говнокод для Boing»


        1. tommyangelo27 Автор
          30.06.2019 16:08
          +9

          Я на всякий случай хочу уточнить, что статью переводил совершенно не ради заголовка, он такой же, как в оригинале.

          Мне знакома изнутри ситуация, когда компания сначала зарабатывает себе имя и репутацию, растёт, и в какой-то момент оказывается, что заказов набрали больше, чем возможно выполнить. И менеджмент принимает решение воспользоваться контракторами, стажерами, вообще всеми подряд, лишь бы побольше и подешевле.
          Что, в свою очередь, приводит к снижению качества, потере репутации, ухудшению продаж, увольнениям и в конце концов к коллапсу.

          Да, у Boeing запас прочности большой, но вот этот «эффективный менеджмент» и погоня за краткосрочными прибылями точно до добра не доведёт.


          1. puyol_dev2
            30.06.2019 17:50
            +17

            Так вот и умирают или загнивают монополии. Большие зарплаты и возможность «карьерного роста» привлекают халявщиков карьеристов. Те быстро смекают, что качество работы отходит на второй план, уступая человеческим отношениям. Специалисты, работающие на совесть, в итоге разбегаются и работать становится просто некому. Остаются вруны и дармоеды, которые рисуют красивые цифры на графиках, не имеющие ничего общего с реальностью. Реальные продажи падают, конкуренция проиграна, компания стагнирует или волочит существование на вторых ролях


            1. raamid
              30.06.2019 18:37
              +1

              Поставил бы плюс, если бы мог. Похожая ситуация сейчас у Интел. Десятилетиями компания купалась в деньгах, однако, вместо того, чтобы продолжать интенсивно крутить педалями, просто зажралась. И теперь приходится глотать пыль азиатских тигров, которые уже давно освоили 7нм техпроцесс.


              1. puyol_dev2
                30.06.2019 21:07
                +2

                Полностью соглашусь на счет Intel. У компании исторически очень сильные позиции на рынке ПК, но вот в мобильном рынке они отстают колоссально. Интел выпускает процессор с компоновкой big.LITTLE в начале 2019. Китайский MediaTek сделал это в 2013. Есть слух, что и процессорах для ПК у Intel не все так безоблачно. AMD со своим Ryzen потеснил Intel с первых строчек бенчмарков. Но это еще не самое плохое. Плохо настанет тогда, когда Apple откажется от процессоров Intel на Macbook. А слухи такие уже ходят, что яблочники разрабатывают собственный процессор, как это было в случае с PowerPC (кто еще помнит)


                1. river-fall
                  01.07.2019 11:18
                  +1

                  Ну это далеко не первый рывок AMD, когда они оказывались быстрее (и дешевле) чем Intel. Вспоминается как минимум K6-III vs Pentium 3 и особенно Athlon XP vs Pentium 4. Ну и x86-64 сделал тоже AMD.


                  1. garageman
                    02.07.2019 12:35

                    Недаром архитектура «64» в дебиане называется «amd-64».


                    1. DistortNeo
                      02.07.2019 12:50

                      Чтобы не путать с IA-64, которую Intel выкатила двумя годами ранее.


                      1. DrPass
                        02.07.2019 13:01

                        Ну AMD-то действительно разработала 64-битную архитектуру современных процессоров, и Intel перешла на неё тоже, по кросс-лицензионному соглашению. А вот IA-64, это совершенно другая архитектура, которая использовалась в серверных процессорах Itanium, и хоть была и интересной, но сейчас уже можно считать её мёртвой.


                        1. arielf
                          03.07.2019 02:34

                          А зря, хорошая она была.


                  1. DrPass
                    02.07.2019 12:57
                    +2

                    Вспоминается как минимум K6-III vs Pentium 3

                    K6-III нет, т.к. это был рывок только по сравнению с К6-2, и лебединая песня всей тогда уже бесповоротно устаревшей архитектуры. Athlon XP конкурировал на равных, хоть и не был лидером, зато его младший брат Duron рвал в нижнем сегменте Celeronы как Тузик грелку. Звездный час у них наступил с появлением Athlon 64. Вот тогда они уложили Pentium 4 на обе лопатки. Сначала с появлением 64-битного ядра, потом они же первыми вывели на рынок многоядерные процессоры.
                    Вообще, как по мне, сейчас АМД находится в стратегически более выигрышной позиции, и по сути, это плоды уже находящегося в далёком прошлом решения — продать свои фабрики. Риски и огромную стоимость освоения новых техпроцессов они делегировали контрактным производителям, и те с ними вполне справляются. А Intel пытается их тянуть на себе, и пока неуспешно. А когда освоят свои 10nm, TSMC уже даст для АМД 5 nm и так далее.


                    1. MTyrz
                      02.07.2019 14:32

                      Я напомню еще про слотовый Athlon, самый первый. Который тоже был божественно хорош для своего времени, и разделывал Willamette'ы под орех.


                1. Raspy
                  01.07.2019 21:12

                  Собственно в битве за консольное железо они полностью проиграли. Последнее поколение xBox и PS на AMD железе.


                1. svitoglad
                  02.07.2019 08:19

                  Еще и сервера масово перейдут на какой-то POWER9 или на набирающие популярность ARM и Xeon`ам не останется места на рынке.


            1. Kvento
              30.06.2019 23:23

              Хорошо сказано. Беда в том, что у монополиста обычно запас капитала большой. Плюс инертность покупателей и долгосрочные поставки. В итоге, когда жареный петух клюет, компания нехотя начинает вновь следить за качеством.
              Из недавнего: Intel. Боинг тоже не помрёт.


              1. puyol_dev2
                01.07.2019 14:02

                В середине 90х из-за «эффективного менеджмента» чуть не откинулась Apple. Так что при неудачном стечении обстоятельств могут помереть и такие гиганты


                1. Peter03
                  01.07.2019 19:19

                  В середине 90х Apple была не монополистом и даже близко к этому. Так, компания среднего размера каких очень много, просто сейчас с высоты текущего знания выглядит иначе. Хотя даже сейчас не монополист.


            1. DIHALT
              30.06.2019 23:43
              +4

              Точно также умирают государства-корпорации.


    1. radonit
      30.06.2019 16:12
      +3

      Это полная сумма с налогами (фонд оплаты труда), вычтите из неё есн 22+5.9+2.1=30% и от оставшегося ещё 13% ндфл будет: 98280*0.7=68796 и ещё умножить на 0.87 59852, согласитесь совсем другое дело, много ли программистов за 60 т.р. Работают, особенно в Москве?


      1. staticmain
        30.06.2019 16:45
        +2

        В Москве все, кто работают в госконторах. Я с самого начала уточнил про не-Москву, потому что Москва — не россия.


        1. radonit
          30.06.2019 18:32

          Тут недавно статистику зарплат it выкладывали, в том числе регионы, все зарплаты были выше.
          А если в ценах и долларах 2010, это вообще 30 получалось, в то время вполне себе средняя зарплата даже для инженеров, не говоря уж о программистах


          1. staticmain
            30.06.2019 18:35
            +2

            >в том числе регионы, все зарплаты были выше.
            image
            Город-миллионник. Средняя выше 98 000 тут ну никак не получается.


            1. radonit
              30.06.2019 19:32

              habr.com/ru/company/moikrug/blog/439152
              А вот тут другие данные


              1. akryukov
                01.07.2019 08:55

                staticmain пишет о вакансиях, в которых зп указана, а Мой Круг тогда писал про зп, которые указывали работающие специалисты.
                Может так получиться что и то и другое — правда, но на разных группах населения. Много ли специалистов из Ростова-на-дону сообщает о своей зарплате на Моем Круге?


                1. PsyHaSTe
                  01.07.2019 15:49

                  Точно так же открытые вакансии не говорят, что на них идут люди. Видел вакансии открытые по полгода и больше.


                1. AEP
                  02.07.2019 23:40
                  +3

                  Еще надо учесть трюк: пользователь Моего Круга может указать зарплату выше реальной, чтобы потом получить больше.


      1. evs38
        30.06.2019 22:10
        -1

        Многие компании, работающие на УСН фактически, не платят то, что вы называете ЕСН, т.к. его полностью покрывает дальнейшая налоговая льгота: на сумму уплаченных взносов в ПФР и ФОМС уменьшается сумма налога предприятия.


        1. mayorovp
          01.07.2019 09:42

          Причем тут компании, когда речь идет о зарплате сотрудников?


          1. evs38
            02.07.2019 13:12

            Потому, что ФОТ формируется из денег компании, разве нет? :)


    1. Antervis
      30.06.2019 17:26
      +12

      Инженеры в Индии зарабатывали около $5 в час, сейчас это $9 или $10, в сравнении с $35-40 для тех, кто находится в США по визе H1B, добавляет Хильдерман. Но он объясняет своим клиентам, что в реальности, дешевая цена за час равняется примерно $80, из-за необходимости контроля,

      Вот самая важная часть статьи. Это критика «эффективных менеджеров», которые сокращая расходы втрое увеличили их вдвое. И очередное напоминание что чудес не бывает


      1. DarkTiger
        01.07.2019 00:57
        +2

        «Вы не понимаете!» (с)
        Существует ФОТ для департамента, в котором обитают программисты. Финансисты, в процессах разработки ПО не понимающие ничего, и потому ставящие расходы на разработку ПО в один ряд с расходами на закупки, спустили сверху указание «Снизить ФОТ на 20%». Возможно, даже реальной необходимости в этом и не было, а просто новый начальник решил выслужиться перед высшим руководством с самого начала. Или KPI ему самому такой прописали. Но указание сверху получено, пришлось взять под козырек Менеджеры нижнего звена поменяли часть дорогих офисных программистов на дешевых оутсорсеров и обновили свои резюме, чтобы свалить, когда придет время платить по счетам. И, в общем, не так уж они и виноваты — правила игры задаются сверху, и объяснять тут что-то бесполезно.
        Это совершенно нормальная практика сейчас для не-программистких крупных предприятий, скорее, странно, когда бывает наоборот. Краткосрочные цели годовой прибыли имеют преимущество перед долгосрочными целями развития компании. Есть курс и прибыльность акций — это главное. Поэтому любой ценой надо добиться прибыльности в этом году, а в следующем — зальем деньгами от повышения курса этот проблемный участок. Но иногда, редко, получается и вот так, как с Боингом.


    1. OnYourLips
      30.06.2019 19:43

      И уже не так резко звучит для российских программистов, особенно вне мск-региона, верно?

      Тогда курс другой был. В Москве столько получали стажеры, в регионах — джуны. Средние разработчики в регионах и джуны в Москве получали больше.
      Так что это звучит в российских реалиях так же дико.


    1. iDeviL
      30.06.2019 20:37
      +12

      С чего вы взяли, что 9$ отдают индусу? 9$ получает компания за час работы технического специалиста сданного в аренду боингу (аутсорсинг это или аутстаффинг не важно), при этом сам индус вполне может получать и 1$ в час.


      1. Alexey_mosc
        01.07.2019 10:42

        Те же индусы едут в США, пытаясь зарабатывать среднюю ЗП по рынку, причем они идут на всякие хитрости, чтобы скрыть свой низкий уровень образования/обучения. Иногда едут в США как body shopper ы, зарабатывая 1/2 средней ЗП, потом меняя работу на нормальную. Они везде, в общем. Лезут во все щели, ибо для них такая сытая жизнь великое благо, а благодаря уже осевшим индусам в корпорациях их и берут чаще, более лояльны к визовому спонсорству. Кто ее видел Кремниевую долину тот, в частности, не ощутил лёгкую панику от вездесущих индусских программистов.)


      1. DrunkBear
        01.07.2019 11:27
        +1

        Именно.
        Знаю компанию, которая работала с Боингом, продавала час за $40, а сотрудникам платила фикс 20-30 тыщ(по ценам середины 2000х, не знаю, как сейчас, но вряд ли в корне изменилось).
        И кстати, ходит там легенда, что один проект отдали индусам со словами «у них дешевле, передайте проект с доками» и год вернулись со словами «сколько будет стоить вернуть проект в читаемое и рабочее состояние?» — то, что наворотили индусы, ещё 5 месяцев разгребали и приводили во вменяемое состояние.


        1. woooody
          01.07.2019 23:08

          До боли знакомая картина :)
          К счастью у нас для тестов была так круто разработана методика тестирования, что испортить её даже индусы не могли (хотя пытались, честно)))
          Её мы применяли для всех новых и переделанных индусовских тестов.
          Кстати в какой-то момент заказчик отдал кучу работы китайцам. Сначала было нормально, пока, видимо, самые умные китайцы стажировались в США. А вот когда они вернулись домой и стали учить своих коллег. Результат стал очень сильно похож на индусовский код. Сложно сказать — какой лучше, а какой хуже… он просто чуть другой :)


    1. IvUs
      30.06.2019 21:09
      +3

      А многим ли российским программистам, особенно вне мск-региона можно доверить разработку ПО современного самолета?


      1. Rikkitik
        30.06.2019 22:45
        +6

        Вот тут есть пара отзывов работников о московском отделении Боинга. Меня вот эти фрагменты слегка шокировали:

        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 часов в сутки плюс обучение прямо по ходу, как только ребята начинают немного разбираться в теме и сбегают из рабства, набираем новых». При этом он не как прогер туда ходил, а как инженер-конструктор, так что там, похоже, подход один ко всем этапам разработки и своё мнение насчёт того, кому из российских специалистов стоит доверять разработку современного самолёта.


    1. Dmitri-D
      01.07.2019 06:51
      +1

      staticmain
      FYI у нас в регионе (на восточном побережье) минималка $9, это уровень уборщиц.
      На западном побережье, где боинг, уже и уборщицы не получают $9 в час.


    1. Zoolander
      01.07.2019 07:26
      +1

      там смотреть надо — это они зарабатывали или Боинг платил за час столько

      у меня была работа джуном — я получал 25 тысяч рублей в месяц
      с клиента брали 1200 рублей за 1 час моей работы

      но это рекорд был, обычно брали 600-800, что все равно интересно,
      т.к. мне за 1 час давали 125 рублей примерно

      Тут надо понимать, что я не возражал, мне нравилось учиться, кроме того калькуляция стоимости часа фирмы учитывает массу побочных расходов, те же компы, тот же отдел бухгалтерии, та же уборщица, тот же сисадмин — все они должны были что-то кушать, ну и масса других нош, которые несет фирма по сравнению с фрилансером

      Я к тому, что надо уточнить — расценка за 1 час для клиента или действительна зарплата. Если смотреть по расценкам для клиента, то расценки я бы сказал нормальные даже в РФ. Может быть, даже низкие местами. Там где я работал, фирма бы и разговаривать не стала за такой прайс )


    1. ncix
      01.07.2019 10:33
      +1

      А я так понял что $9 получает компания-аутсорсер. А зная что маржа таких компаний обычно не менее 50%, то индус получает $4.5 до налогов.


  1. da-nie
    30.06.2019 15:03

    и миллионов строк кода,


    Вот этот момент интересен. Это считали вместе с кодом операционок, видеоплейеров и прочего в довесок? Код программы автоматики управления вряд ли может иметь миллионы строк. Или там действительно нужны эти самые миллионы строк?


    1. NetBUG
      30.06.2019 15:20

      Возьмите несложный алгоритм (хотя бы PID-регулирование) и соберите его под любой микроконтроллер (скажем, ARM). На верхнем уровне у Вас будет несколько строк и читабельная программа. Если копнуть глубже — реализация PID занимает несколько экранов и всё ещё читабельна, а так же в идеале должна быть покрыта тестами.
      Однако то, что заливается в контроллер, разворачивает связанные библиотеки (как минимум, cmsis для взаимодействия с железом и math) и занимает уже десятки тысяч строк кода (С) или сотни (инструкции процессора).
      Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки — вот вам и миллионы строк кода (инструкций).


      1. Areso
        30.06.2019 15:50

        ARM не совсем микроконтроллер :)
        У настоящих микроконтроллеров (AVR, PIC, STM и далее) и обвязки к ним довольно мало место в ПЗУ, поэтому никакие миллионы строк там физически не уместятся. А каждые 2 КБ сверху стоят около ста евро в прайсе Siemens.


        1. papasha_mueller
          30.06.2019 17:22
          -8

          Areso не совсем хабраюзер :) У настоящих хабраюзеров (тут следует список) член 27 сантиметров и зарплата 300 килорублей/секунду.

          Заодно поржал от наличия в скобочках STM наравне с PIC и AVR.

          — С уважением,
          Генрих Мюллер, группенфюрер


          1. Areso
            30.06.2019 17:36
            +2

            У STM есть серии 8 битных микроконтроллеров.
            Ну и да, я в своих личностных характеристиках несколько скромнее, и думаю, что если где-то и сморозил глупость, то вполне приемлемую — я с МК не работаю, пересекался раз или два по работе и когда делал маленького робота.


            1. papasha_mueller
              30.06.2019 17:51
              -16

              Так зачем высказываться на темы, в которых понимаешь примерно как свинья в апельсинах?

              — С уважением,
              Генрих Мюллер, группенфюрер


            1. NetBUG
              01.07.2019 11:54

              В любом случае, ARM — нормальная архитектура для МК. Есть чипы за $0.5 с 32 Кб флэш-памяти и 8 Кб ОЗУ, работающие год от батарейки CR2032, есть чипы с несколькими ядрами, отлично справляющиеся с задачей управления парой двигателей.
              Естественно, речь не о ядрах ARM Cortex A*, а о линейках M и R.


        1. lingvo
          01.07.2019 08:52
          +4

          ARM занимает 37% общего рынка МК и более 50% рынка IoT. Квадрокоптеры все на АРМах, автомобили на них переходят. Сейчас не проблема найти МК с ПЗУ 512кб или даже 1024кб.


          1. Areso
            01.07.2019 09:31
            +2

            Да, я уже понял, что серьёзно ошибся.
            Ранее я работал с 8 битными МКшками, и на момент написания своего комментария полностью забыл о существовании ARM Cortex-M.
            Посыпаю голову пеплом.
            Мне, наверное, не стоило комментировать на тему, в которой я недостаточно разбираюсь.


            1. svitoglad
              01.07.2019 18:57

              А еще есть и PIC32 c 2Мб встроеного флеша и поддержкой внешней памяти до 16Мбайт адресации.
              У STM тоже есть что-то похожее.


      1. Polaris99
        30.06.2019 18:37
        +1

        Расскажите, а как оно разворачиваетв памяти все эти библиотеки, если их код не используется полностью? Оптимизацию вообще умышленно отключили? И да, я знаю, о чем говорю, писал для контроллеров на всех уровнях и продолжаю писать уже 15 лет.
        Кстати, и не думаю, что контрактерам платят за "миллионы" строк кода math


        1. NetBUG
          01.07.2019 11:58

          Во-первых, на мой взгляд, «миллионы строк» — это жертва изнасилования журналистами.
          Во-вторых, думаю, в 737 Max стоят сотни устройств с МК внутри (я не учитываю развлекательные панели в креслах, только авионику и автоматику), и если в каждом хотя бы по тысяче строк кода на асме — это уже миллионы строк. Здесь нет речи о ревизиях, разных моделях и комплектациях.
          Платят, думаю, почасовую ставку, и в этом может быть одна из проблем — на мой взгляд, инженеру лучше платить за выполнение хорошо поставленной задачи, покрытой тестами и имеющей чёткие критерии выполнения и работоспособности, но увы.


          1. woooody
            01.07.2019 23:20
            +1

            Код, отвечаюший за отрисовку картинок на дисплеях (PFD), для не очень большого самолета весил десятки мегабайт текстовых файлов. Но он по большей части был автоматически сгенерен из другой приблуды, где содержимое этих экранов дефайнилось (если очень приближенно) как формы в Delphi.


      1. da-nie
        30.06.2019 21:59
        +3

        Вот только к разработанной программе весь этот объём уже не относится — это код ОС и сопутствующих библиотек. Из статьи же читается, словно эти индусы нафигачили миллионы строк кода для управления самолётом.

        Если добавить сюда работу нескольких дублированных устройств, сетевой протокол, механизм голосования/выбора неисправных, и всё это так же будет содержать библиотеки


        Практически не будет. Мы всё это делали почти без всяких библиотек на Миландровском контроллере и на таком чуде, как аналог TMS3020C3 (да, для ВПК). Кстати, если кто случайно знает для TMS320C3 компилятор хотя бы с Си99, буду очень благодарен за информацию, где его можно взять (а то Си89 на нём уже достал). :)


      1. woooody
        01.07.2019 23:17
        +1

        Кстати в авиации библиотеки редко используют. Они должны быть сертифицированы и поэтому стоят денег. Часто дешевле написать свои функции и сертифицировать как часть своего кода, чем покупать библиотеку целиком.


    1. solariserj
      30.06.2019 15:32

      Может им платили за количество строк?


      1. Peacemaker
        01.07.2019 14:24

        В таком случае вполне возможны перлы в коде вида:

        var a = ...
        ...
        if(a == a)
        {
           DoSomething();
        }
        else
        {
           DontDoSomething();
        }


        1. woooody
          01.07.2019 23:23

          В кавераге дыры будут — не прокатит :)


    1. emmibox
      30.06.2019 18:21
      +1

      В современных системах управления автомобилей около 10миллионов строк кода на блок… В самолетах всяко должно быть поменьше но в пределах этого порядка. Собственно цифра скорее говорит об эффективности представления ПО в виде тех самых строк… (в нормальной индустрии никто конечно руками давным давно эти строки не писал и ни одного индуса не страдало)…


      1. NetBUG
        01.07.2019 11:59

        На блок?! Я думал, это на самолёт, если честно.

        Блок в смысле ECU с мелким реалтаймовым МК, или всё-таки речь про голову с цветным экраном?

        У меня машина начала нулевых, и там вся прошивка весит сотню килобайт для ECU и десятки кб для всяких блоков комфорта.


        1. emmibox
          02.07.2019 07:25

          Так 20 лет прошло. Сейчас в ЭБУ по 8-16мегабайт прошивки.


    1. h0use
      01.07.2019 05:57
      +3

      Код FMS может быть легко в миллион строк и выше, достаточно сложное устройство со своими внутренними БД, input/output для пилотов, контролем сотен систем и датчиков самолета. Даже в симуляторах эта система реализуется непросто.


  1. arozhankov
    30.06.2019 15:04
    -1

    «Проектирование стало превращаться в дешевый товар» — не стало превращаться, а превратили продажные представители заказчиков, совместно с гнильем в руководстве проектных организаций.

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

    В итоге проблемой для заказчика (желающего нормальной работы) стало НАЙТИ тех, кто МОЖЕТ нормально спроектировать в куче-мале псевдоспециалистов.


  1. RedCatX
    30.06.2019 15:11

    Если в промышленных гигантах, ответственных за человеческие жизни, такая неразбериха с процессами, то о чем говорить в более мелких конторах

    Как раз наоборот: вероятнее, что именно в маленькой конторе подойдут к процессу проектирования с большим вниманием и ответственностью. А в «промышленных гигантах» обязательно найдутся тучи «эффективных менеджеров», озабоченных лишь снижением издержек и повышением прибыли.


    1. tommyangelo27 Автор
      30.06.2019 15:15

      Я скорее имею в виду фирмы размером 250-500 человек, у которых вроде бы все друг друга знают, уже есть проекты серьезного уровня, но контроль над происходящим уже начинает теряться.


      1. keydon2
        30.06.2019 19:52

        Работаю в такой компании. Да, контроль если уже не потерялся, то теряется.


  1. zim32
    30.06.2019 15:38

    Наша главная цель — всегда быть уверенными в том, что наши продукты безопасны, высочайшего качества и выполнены по всем правилам


    Наглая, паршивая ложь. Ненавижу менеджеров за это.


    1. Anrock
      30.06.2019 20:38
      +2

      Почему ложь? Может они вполне себе были уверены в этом.


      1. zim32
        30.06.2019 21:12

        Уже ж выяснилось что Боинг намеренно не сказал пилотам про эту систему mcas. Они руководствовались лишь одним — не просрать сроки и не допустить доминирование airbus


        1. Whuthering
          30.06.2019 21:23
          +6

          Уже ж выяснилось что Боинг намеренно не сказал пилотам про эту систему mcas.
          Потому что случай некорректной работы этой системы полностью покрывался задолго до этого существующей инструкцией «Runaway stabilizer».


          1. LaMort
            01.07.2019 11:25
            +1

            Почитайте разбор действий пилотов во второй катастрофе, где они пытались ее выполнить.
            Кому лень гуглить/вникать — краткое содержание:

            На предыдущий моделях 737 у летчиков и mcas (а также остальных систем управления стабилизатором было 2 отдельных электромотора, runaway stabilizer отключал электромотор автоматики, в то время как пилоты по прежнему могли пользоваться своим электромотором для управления стабилизатором). На Max решили сэкономить и завели все на один общий электромотор. Соотвественно, единственным способом управлять стабилизатором после runaway stabilizer (который на Max обесточивает этот единственный мотор) можно только вручную через тросики, что экипаж эфиопской компании и пытался делать. Только, как выяснилось, что на скорости >300 км/ч это уже выше пределов человеческих возможностей, в чем пилоты довольно быстро и убедились (на взлете у них скорость была сильно выше). После чего пилоты решили включить мотор обратно, видимо чтобы управлять стабилизатором со штурвала, но тут им просто не повезло т.к MCAS на включении моментально загнала их в штопор.

            Резюме — офигительно боинг помог со своей инструкцией после первой катастрофы (где они как раз акцентировали внимание на runaway stabilizer)


            1. mayorovp
              01.07.2019 12:17
              +1

              но тут им просто не повезло т.к MCAS на включении моментально загнала их в штопор

              Ничего не мешало при включении электромотора сразу же выставить положение стабилизатора ближе к правильному, а потом выключить его обратно.


              1. PsyHaSTe
                01.07.2019 16:02

                Они сразу же в штопор и впилились.


      1. zim32
        30.06.2019 21:17
        +4

        Даьи вообще эти фразы НАША цель безопасность… блабла, наша цель сделать мир лучше, наша цель сплотить общество… это все такая лапша противно даже. Ниразу таких целей не слышал на собраниях инвесторов или топ руководителей


        1. Kvento
          30.06.2019 23:37

          Нет разу не слышал на собраниях, чтобы глава фирмы открыто озвучил свои цели. Обычно давят на совесть: нам верят клиенты, мы должны сделать все, что можем. При этом всем ясно, что в заявленный срок никогда не получится сделать качественно. Идёт подгонка под требования приемки, а не под опыт реальной работы у заказчика.


    1. Kvento
      30.06.2019 23:33

      Работа пиарщика врать. Вам и мне противно. Ему часто тоже.


  1. Maccimo
    30.06.2019 15:52

    один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе

    То есть боинговские сеньоры смогли предоставить техдокументацию надлежащего качества только с 18 попытки. Может тогда и правильно их аутсорсерами заменили?


    1. zoonman
      30.06.2019 17:03

      Скорее русские, привыкшие к ГОСТам и непонимающие английского языка и терминологии.


      1. Maccimo
        30.06.2019 17:21
        +6

        Интересно-интересно.
        Как эксперт, расскажите, что изменилось за 18 попыток: эти ужасные русские выучили-таки английский или страдающие от аутсорса боинговские инженеры техдокументацию на русский перевели?


        1. Areso
          30.06.2019 17:30
          +22

          Расскажу случай из личного опыта.
          Однажды знакомые ребята меня попросили узнать, сколько будет стоить на российском заводе выточить одну деталь из цельного куска алюминиевой плиты. Кое-как на пальцах объяснили, что они хотят, я кое-как сделал 3D модельку, сделал несколько скриншотов разных сечений, указал размеры в мм и отправил на известные мне заводы мехобработки. Дело было осенью 2015 года, когда с экономикой было ну совсем все плохо. Из всех заводов мне ответил только один, что, дескать, пока документация не по ЕСКД они ничего считать не будут. На мой уточняющий вопрос, могут ли они привести имеющиеся данные к ЕСКД за деньги, мне с завода уже никто не ответил.
          С тех пор, знакомые ребята сотрудничают с китайцами — они, конечно, не очень, зато сообразительности им не занимать, когда дело деньгами хотя бы пахнет.


          1. u_235
            30.06.2019 18:16
            +5

            ЕСКД подразумевает не только набор сечений с размерами, но и допуски на размеры. А допуски должен знать именно заказчик.


            1. zoonman
              30.06.2019 19:11
              +12

              Здесь все верно и это работает, когда вы взаимодействуете с профессиональным инженером. Он и допуски напишет, и материал, и тех карту и т.д.
              НО все меняется, когда вы начинаете работать с людьми, простыми, но хотящими что-то сделать. Такие есть, они даже что-то знают и умеют делать, но их уровень не позволяет им готовить все необходимое в соответствии с представленными требованиями. В таком случае, по-человечески, можно сделать какой-то сервис, который будет говорить с клиентом, принимать модель и проставлять опущенные детали, опираясь на область применения детали. Если это обычная хоббийная штучка, то там 0.1мм будет вполне себе нормальным допуском.
              Теже китайцы просто не парятся на эту тему, есть какой-то обычный допуск для станка, например 0.05 мм и они с ним делают детали не задавая лишних вопросов.
              В России на сайтах всяких компаний черт ногу сломит, прежде чем найти хоть какую-то информацию о том, как сделать заказ и т.д.


              1. nikolayv81
                30.06.2019 22:40

                Допуски всё же не просто так, возможно ваша модель была оценена технологом "на глазок" в сумму, подразумевающую что вы не захотите её платить если даже чертежи толком сделать не можете, штучное производство всё же иметь особенности.
                И про допуска, допуск не просто в n-xxxxxметров, он ещё в плюс и в минус и это не просто так...


                1. Areso
                  30.06.2019 22:47
                  +1

                  Ну, люди где-то раздобыли алюминиевую плиту (думаю, вы можете себе представить, сколько такая может стоить), захотели из нее что-то сделать. Выточить корпуса а-ля мак мини для какой-то там электроники.
                  В результате плиту продали, материал закупали уже китайцы и делали же китайцы.
                  Конечно, ценообразование в России и в Китае отличается, но в России мы даже до цен не дошли.


                  1. nikolayv81
                    30.06.2019 23:00

                    Про "раздобыли плиту", как то на одном заводе работяги решили сдать на металлолом аллюминиевые чушки диаметром 200мм. Ну лежат на складе…
                    Так что происхождение таких вещей может быть весьма оригинальным...


                1. dimm_ddr
                  01.07.2019 14:42
                  +1

                  Мне кажется корректным решением данного вопроса было бы ответное письмо с примерной стоимостью и вопросом нужно ли считать более точно за деньги. Я уверен что завод не получает таких предложений тысячами в день и значит ответить всем совершенно реально. То есть завод (и конкретный менеджер, технолог) не теряет практически ничего, но может потенциально получить нового заказчика. Терять заказчика просто потому что тебе показалось что он столько не захочет платить? Я конечно не супер бизнесмен, но мне кажется так дела не делаются.


                  1. 9660
                    02.07.2019 08:02

                    Попробуйте на бао заказать штучно товар. Большинство пошлет лесом — типа торгуем от сотен и тысяч.
                    Завод можно понять, на кой ему единичная возня с некрупным заказом?


                    1. zoonman
                      02.07.2019 09:00
                      +1

                      Понимаете, со штучных заказов начинается любое производство. Просто в одном случае, оно становится успешным и тогда заказываются мелкие серии, а потом и крупные. А в другом не очень или не планируется вообще. Так что в первом к вам приходит будущий клиент, с которым можно будет работать на протяжении нескольких лет.
                      Но только вы никогда не узнаете, какой у вас случай до того момента, пока вы не доведете первый заказ до ума.
                      Вот например я делаю маленькие устройства для себя. Если у меня получится устройство, которым заинтересуются другие, я могу заказать больше и начать их продавать в малом объеме. Начальный доход от продаж позволит мне создать стартовый капитал. Я смогу оценить рынок, изучить аудиторию, исправить ошибки и довести устройство до качественно нового уровня. Сделать вторую версию гораздо лучше первой и продать еще больше устройств.
                      Но только если никто не согласится делать мне то самое первое устройство в буквально единичном экземпляре, я никогда не смогу выйти на рынок.
                      Как итог мы имеет плохие устройства на рынке, потому что люди, способные сделать лучше, не могут их реализовать по причине отсутствия средств, а компании не заинтересованы в новинках, пока нет конкуренции.
                      Получается замкнутый круг, разорвать который могут только заводы, у которых есть реальная возможность что-то производить. Но им лень, ибо проще отшивать людей формальностями и жить за счет госзаказов или 2-3 больших клиентов.
                      ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать. А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.


                      1. 9660
                        02.07.2019 09:06
                        +1

                        ТаоБао вообще задуман как оптовая площадка. Там никто не будет вам что-то поштучно делать.
                        Об этом я и писал. Завод вообще задуман как оптовый производитель. Потому там обычно не связываются со штучными заказами.
                        А вот на AliExpress вполне можно найти конторки, которые могут делать что-то практически поштучно, просто дорого.
                        А это уже не завод а скажем мастерские.


                      1. garageman
                        02.07.2019 12:55

                        Есть на LJ юзер bougaev.livejournal.com
                        Вот как раз он за деньги клиента готов хоть фоторамку из чугуния выфрезеровать.
                        И довольно интересно о процессе пишет.


                      1. dimas
                        02.07.2019 17:28
                        -1

                        Понимаете, если завод ответил что им нужна документация по ЕСКД, то наверное они и были готовы к мелкому заказу, иначе бы так и сказали? Не выбирали же они более красивую форму посыла?


                    1. dimas
                      02.07.2019 17:27
                      +2

                      Регулярно покупаю на таобао и тмолле чай, инструменты, посуду в розничных количествах, ЧЯДНТ?

                      Вы может с Алибабой спутали?


                      1. 9660
                        03.07.2019 02:56

                        Вероятно да.


                  1. akryukov
                    02.07.2019 09:33

                    На публичную почту завода наверняка ежедневно приходит тонна спама с коммерческими предложениями от кулибиных разного калибра. Если отвечать каждому, то потребуется отдельного человека на это заводить. Будет ли конверсия кулибиных покрывать затраты на поддержание штучного производства?


                    1. Areso
                      02.07.2019 09:44

                      Коммерческие предложения — это про другое. Это когда стопицот разных людей пытаются предложить свои услуги и товары заводу.
                      А тут, какой-никакой, а заказчик. Пришло не КП, а его запрос (на бланке предприятия).


              1. iig
                01.07.2019 08:16
                +1

                По человечески тоже все просто. Почту читает человек, который допуски считать не умеет. Напрямую обратиться к человеку, умеющему считать, он не может/не хочет. Нужно задействовать насяльнике, а он в отпуске..


                1. RiseOfDeath
                  01.07.2019 10:29
                  +7

                  А потом эти же люди, «по-человечески» ноют на кухнях, на форумах и кабаках что «работы нет, денег нет, Путин виноват».


                1. garageman
                  02.07.2019 12:59

                  Ну так не обязательно ж «до копейки». Можно назвать диапазон цен.
                  «Выточить с помощью стажера и какой-то матери напильником, точность — на глаз: ХХХ руб.
                  На обрабатывающем центре по программе подготовленной инженером по согласованному с заказчиком ТЗЖ 2*ХХХ руб.
                  То же но с командировкой инжинера для уточнения ТЗ к заказчику: 5*ХХХ руб.
                  То же но с перевозкой обрабатывающего центра к заказчику и выполнения работ на месте: ХХХ^5 руб.»


                  1. iig
                    02.07.2019 14:19
                    +2

                    Накажут ли ответственного за почту, если он отправит подобное коммерческое предложение в спам? (Нет)
                    Получит ли он премию, если начнет переписку с выяснением, что именно нужно делать и сколько это будет стоить? (Нет)
                    Получит ли он выговор за то, что отрывает от работы кучу народа? (Возможно)
                    По человечески оно где-то так…


              1. LESHIY_ODESSA
                03.07.2019 14:50

                есть какой-то обычный допуск для станка, например 0.05 мм


                Я знаю одного "бухгалтера", который в «домашних условиях» выдаёт точность 0.01 мм.


          1. raamid
            30.06.2019 18:45
            +8

            Виноваты раздутые штаты. В китайском заводике с вами будет общаться владелец или его родственник, которые кровно заинтересованы в заказе, а у нас — тетенька-бухгалтер у которой в соседнем окошке Lines, а в голове попытки вспомнить убрала ли она суп в холодильник.


            1. Kvento
              30.06.2019 23:40

              Согласен.


            1. Symphel
              01.07.2019 07:01
              +2

              Неправда, китайцы очень любят раздувать штат, чем больше штат, тем более серьезная у тебя Компания. И работа с клиентами — одна из точек раздувания. Просто они больше нацелены на результат.


            1. Terras
              01.07.2019 07:23
              +1

              Тут есть один нюанс.

              1) Китайцы готовы делать горбатого. Т.е. ты скидываешь им какую-то херню, они её делают, что-то косячат, что-то додумывают и так далее. Но как итог, ты получаешь деталь.

              2) У нас обсуждение начинается с документации. Ибо инженер на заводе знает, что если он сделает что-то горбатое, сам что-то додумает, то потом к нему же придут и скажут «Нахера ты это делал. Вот претензия от заказчика, исправляй как хочешь или плати из своего кармана!». Поэтому без нормальной документации никто зад не поднимет.

              __

              Это как в IT. Кто-то работает с заказчиками, которые сами не знают, что им надо и требуется. А кто-то любые заявки без четкого ТЗ даже рассматривать не будут.

              Да, первые получают больше заказов по итогу, но если ты сам прямой, то со вторыми работать надежней.


              1. EviGL
                01.07.2019 18:25
                +1

                А если посмотреть на эту модель со стороны, то очень-очень часто самые большие деньги могут прийти от тех клиентов, у которых нет ТЗ на то, что им требуется.


                Взгляните, у кого будет самое подробное ТЗ на заказ? Только у того, кто сам знает-умеет-занимался. Скорее всего у него просто станков на текущий заказ не хватает, вот и дозаказал у посредника. Ещё он в мелочах знает вашу структуру издержек и будет торговаться так, чтобы оставить вас на грани маржинальности.


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


                1. Symphel
                  01.07.2019 19:10
                  +1

                  У кого есть деньги, тот наймет спеца, который напишет ТЗ и проконтролирует результат.


          1. JerleShannara
            30.06.2019 23:18
            +4

            Вот мне пришла модель, которая напоминает обычный кран (вентиль). Допуска и посадки никто там не указал (т.к. это эскиз и вообще). А теперь два вопроса (может даже и три, если экономиста подключать):
            1) Что там через этот «вентиль» будет идти, где этот кран будет применяться, от этого весьма некисло зависит какие допуски можно сделать, т.к. для пивного крана и для вентиля, которым там метан будет перекрываться много чего различается, да хоть давление например, плюс если дриснет пивной кран — ну будет от бармена вонять пивом и бар закроется пораньше, а если дриснет метановый вентиль, то проблемы будут куда больше.
            2) На какой станок надо зарядить эту деталь, на «Имени 20 летия Октябрьской революции» с Петровичем или на Mitushiba MegadrukerDrillerLatte. Цена работы этих станков как вы понимаете весьма некисло различается.
            Можно врубить режим «И так сойдет», но тогда мы получим на выходе очередную деталь, которая будет являться массогабаритным макетом, который иногда(и не долго) может даже будет работать.
            Ну или вам завод может выкатить «От 10000р до 1 млн. р.», что будет очень ценной и полезной информацией.


            1. DIHALT
              30.06.2019 23:53
              +12

              А можно взять и уточнить у заказчика сколько и чего он хочет. И в итоге работу будете делать и зарабатывать вы, а не китаец Ляо. Который не повернут к клиенту жопой.


              1. JerleShannara
                01.07.2019 00:51
                -2

                Я исповедую принцип «без ТЗ и результат ХЗ» и пока он меня в заработке не подводил. Если я буду идти по принципу «и так сойдет» и буду по ходу работы спрашивать «а шо тут нада», то на этом заказе просажу кучу времени и нервов.


                1. DIHALT
                  01.07.2019 01:17
                  +22

                  Просто у вас видимо конкуренция еще задницу не припекает и заказы есть.

                  В конце концов, клиент готов платить, так почему бы с него не взять деньги еще и за это? Собственно пока у нас производство работает по принципу «без ТЗ результат ХЗ» все так и будет в жопе. Т.к. у нормальных людей принципы несколько иные — «У вас есть задача? Отлично. Мы ее решим, только платите». Чем меньше клиент думает тем больше он приносит денег. Так не заставляйте его излишне думать. А то он ведь додумается до того, что вы ему нахрен не уперлись.


                  1. radonit
                    01.07.2019 09:24
                    +3

                    Проблема в том что об этом пишут люди обращаются на крупные предприятия, в основном серийные, в то время как задача под мелкую контору.
                    Т.к. предприятие серийное, все бизнеса процессы заточены под серию, включая создание и утверждение документации, что выражается в чудовищный бюрократические проволоки в единичных заказах. По сути вы приходите на автомат и говорите выложите мне деталь, ясно что пошлют.
                    Такие работы для фирм персоналом человек 10, правда зачастую тогда нет термички и гальваники. В общем не там искали.


                    1. DIHALT
                      01.07.2019 10:26
                      +3

                      С мелкими та же история. Да и со средними то же самое. Собственно один мой знакомый так в свое время и поднялся до владельца собственного завода. На том, что был посредником между заказчиком и производителем, знал кто где что умеет делать и что ему надо. А по мере раскрутки докупал собственное оборудование, чтобы делать то же самое самому, а не отдавать подрядчикам. В итоге, через 10-12 лет он владелец полноценного завода со своим КБ, сотнями людей персонала и цехами в собственности.


                      1. anko__2000
                        02.07.2019 13:45

                        И он сейчас возьмет штучный заказ?


                        1. DIHALT
                          02.07.2019 14:13

                          Да, берет. Если есть возможность. Есть технолог который все обработает, сделает чертежи и обсчитает.


                    1. garageman
                      02.07.2019 13:05

                      А в мелких фирмочках как правило есть выходы на гальванику и термичку крупных.


                  1. u_235
                    01.07.2019 18:02
                    +1

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


                    1. DIHALT
                      01.07.2019 18:53
                      +2

                      Бывает и так, а как показывает практика до цены в 95% случае даже не доходит. Т.е. они даже не пытаются. В итоге делают китайцы, у них растет число оборудования и они делают дешевле. А после начинают перебивать не только розинцу, но и опт. И если бы не геморрой с нашей таможней, то все наше частное производство с таким отношением сдохло бы тут единомоментно.


                  1. garageman
                    02.07.2019 13:04
                    +1

                    Шедеврально сказано! Деньги надо брать именно за решение проблемы. Если клиент не знает что нужно ТЗ — ну объяснить ему что у него оказывается на одну заботу больше. И мы готовы и в этом вопросе помочь.


            1. AstarothAst
              01.07.2019 09:52
              +5

              Вот видите, вы за 5 минут практически пообщались с заказчиком и доступным языком объяснили чего вам не хватает для оценки стоимости работ. Правда же не трудно?


              1. JerleShannara
                03.07.2019 18:14

                Трудно, поскольку для этого надо отрывать технолога (а может и не одного технолога), давать ему имеющуюся «документацию» и спрашивать, чего ему тут ещё нужно, чтобы начать работать. И бывает, что такие заказы превращаются в вечный испорченный телефон.


          1. Barbaresk
            01.07.2019 02:07
            +10

            Довольно забавно и иронично смотрится то, что ваш комментарий заплюсовали, а знакомых ваших пожалели. Видимо, хаить любое российское предприятие только потому, что оно российское — это тренд нынче. Давайте посмотрим на ситуацию с другой стороны.
            Ваши друзья-кулибины решили выточить одну (1) деталь из какого-то куска непонятно где раздобытого непонятного металла. Для этого они обратились на завод, который вполне может выпускать танковую дивизию в месяц, с просьбой выточить эту одну деталь. Ваши знакомые при этом не шарят в ЕСКД, которая просто жизненно необходима при любых крупных инженерных проектах. Вместо этого накалякали (извините, но вы сами так написали: «кое-как сделал 3д модель») какую-то модель в очередном «опен-либри-3д-модельере для проектирования комнатных интерьеров» недоавтокаде. И с ней написали на завод. Очевидно, что большинство заводов отправило ваше письмо в спам, а ящик занесло в ч/с. Один решил прикольнутся и ответить.
            Это как если бы в компанию про производству всяких АСУ написали бы письмо «Здравствуйте, я школьник из 11Б физ-мат лицея, мне для урока информатики нужно написать веб-страничку для составления расписания моего 11Б. Сколько это будет стоит?» Ну или попросил бы «аналог ВК» написать. Большинство бы просто не ответило, а кто-то решил бы пошутить и написал бы, что необходимо ТЗ по ГОСТу оформить (ГОСТы на ТЗ, к слову тоже есть). К слову, большинство фрилансеров тоже бы не ответило.
            Почему мир так жесток? Да потому что завод, блин, работает с крупными партиями (нередко проблема напечатать схему в 10к экземплярах, не говоря уж о штучных). Ему, во-первых, невыгодно ваша одна деталь вот от слова совсем. Во-вторых, он не хочет нести ответственность за какую-то левую деталь левого клиента. Тем более, если этот клиент даже не знает, что такое ЕСКД и зачем оно нужно. Завод не хочет нести риски, за последующее применение вашей детали. Завод не хочет нести риски за то, что ваш кусок металла может банально сломать станок.
            Если нужна одна деталь и плевать на допуски и всё остальное — то можно попросить токаря Васю из соседнего разваливающегося депо выточить нужную вам деталь на том самом «станке 20-летия Октября». И вы по факту это и сделали — просто завод дядюшки Ляо в Китае, это тот же самый Вася, только по-китайски. И он там и гендиректор, и главинженер, и токарь, и уборщица, и буфетчица в одном лице. Вышло бы даже дешевле — Вася сделал бы деталь за пятихатку или поллитры, а Ляо просит вечнозеленые.
            А подход, который продемонстрировали, это отнюдь не «повернуться к клиенту жопой», как написали ниже. Просто они не хотят размениваться на копейки. И правильно делают. Я бы отказался от аналогично IT-заказа, при соответствующем размере основных заказов, как и большинство фрилансеров.


            1. DrPass
              01.07.2019 03:32
              +11

              Давайте всё-таки называть вещи своими именами. Нет и практически никогда не бывает в бизнесе такого подхода, что «мы не хотим нести ответственность за то, что у вас что-то не получится с вашим заказом», «мы не хотим нести риски за то, что что-то там вы у себя налажаете». Это вообще не проблемы завода. Редко бывает подход «мы делаем только крупные партии», в том случае, когда это технологически обусловлено. Металлообработка на станке, как вы понимаете, к этому не относится.
              Зато в бизнесе бывает вот что: «Ой, нам какой-то хер написал, хочет штучный заказ сделать. Что ему ответить? — Да ну его нафиг, ещё с ним возиться».
              И вот это самое — особенность, как ни странно, российского бизнеса.


              1. Barbaresk
                01.07.2019 10:19
                +3

                Да, заводу, который выпускает сериями 100к+ и имеет обороты 1ккк+ месяц вот совсем не сдался заказ на 10к рублей (судя по всему именно столько примерно стоит заказ). В заводе все бизнес-процессы настроены на массовое производство. Отсюда и необходимость документации по ЕСКД — при массовом производстве цена документации почти незаметна в цене разрабатываемого устройства. Если же людям не в силу её сделать, значит это клиенты не нашего уровня. Поэтому да, любой бизнес в любой стране пошлёт вас нафик, если вы на 5 порядков по платёжеспособности меньше основныъ клиентов. Не понимаю, что мешало в данной ситуации сделать всё у частников / небольших фирм.


                1. DIHALT
                  01.07.2019 10:30
                  +5

                  А вы пробовали обращаться с к этим частникам и «небольшим фирмам»? Там те же самые хотелки. Абсолютно. Не говоря уже про то, что у львиной доли частников из оборудования в лучшем случае токарник и древний советский фрезер.


                  1. Barbaresk
                    01.07.2019 10:39
                    +1

                    Ну в исходном посте говорилось про заводы. Проблемы отсутствия малого бизнеса в каких-то сегментах — это проблема иного рода, а не в «отношении к клиенту». Также надо понимать, что дорогое оборудование требует большого объёма заказов, чтобы оно окупилось. Поэтому у маленьких исполнителей, многого не будет, а большим не интересны малые заказы. И сделать разовый заказ на дорогом оборудовании всегда стоит больших денег и оправдано только в каких-то дорогих научных проектах. В иных случаяъ нужно уже самому вертеться — как-то уменьшать свои хотелки и делать деталь попроще, искать небольших исполнителей, у которых есть нужное оборудование.


                    1. DIHALT
                      01.07.2019 18:57
                      +1

                      А в России понятие завод весьма размыто. Я вот знаю завод в котором от силы 30 человек работает. Делают вполне себе годное оборудование.


              1. u_235
                03.07.2019 20:57

                Редко бывает подход «мы делаем только крупные партии», в том случае, когда это технологически обусловлено. Металлообработка на станке, как вы понимаете, к этому не относится.
                С чего такая уверенность? Немногие детали можно сделать с использованием только стандартной оснастки. Измерительный инструмент тоже штангенциркулем не ограничивается. Вот и получается «Ой, нам какой-то хер написал, хочет штучный заказ сделать. Но из документации эскиз на салфетке, плюс придется купить фасонную фрезу и твердосплавное сверло. Что ему ответить? — Да ну его нафиг, ещё с ним возиться»


            1. Areso
              01.07.2019 09:48

              Смешно, но я буквально недавно получал такой заказ:

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

              Обычно я за такие заказы берусь, если денег дают.

              Аналог ВК habr.com/en/post/458188
              спорим, такое могут сделать на фрилансе за деньги?


              1. Barbaresk
                01.07.2019 10:12

                Вот эта тема больше описывает проблему «сделать как в вк»
                habr.com/en/post/454336
                Если есть нормальное ТЗ — почему бы и не сделать. Тем более, если заказчик соответствует по размерам уровню исполнителя.


          1. sepulkary
            02.07.2019 08:35

            Мне кажется, в таких случаях правильнее было бы отправлять на согласование именно файл 3D-модели, а не скриншоты.
            Решал похожую проблему в 2010. Довольно быстро нашёл предприятие (кажется, в Златоусте), которое вырезало из 80 мм алюминиевой плиты нужный корпус, и по цене в три раза меньшей, чем наш предыдущий смежник из Калуги.


            1. Areso
              02.07.2019 09:46

              3D модель я тоже прикладывал, но у меня были обоснованные сомнения, что на заводе будет стоять

              «опен-либри-3д-модельере для проектирования комнатных интерьеров» недоавтокад


        1. zoonman
          30.06.2019 18:46
          +10

          Как человек, который работает в американской компании и знает процесс изнутри, я не удивлюсь, что они нашли и наняли профессионального переводчика со специализацией в области авиастроения.
          Американцы могли даже разобраться с ГОСТами и перечертить все, я бы этому тоже не удивился.
          Если вы оцениваете американских инженеров по байкам Задорнова, то обсуждать тут нечего.


          1. radonit
            30.06.2019 20:39

            Эм, вы работали во всех американских компаниях и можете отвечать за все компании? Или вы работали конкретно в Боинг? Если ни то ни другое то какое отношение имеет ваш опыт в конкретной американской компании к другой американской кампании?
            Инженеры в Америке, как и в России сильно разные, соотношение раздолбаев и идиотов к нормальным там такое же как в России.
            У меня множество знакомых именно из боинга (Россия), в том числе которые частенько в Америку в командировку ездили, по их отзывам там в целом так же как в России, маразма там не меньше, а кое где и больше. Так что идеализировать я б не стал.
            Если конкретно про боинг, то чихать он хотел на ескд и ГОСТ, у них даже система единиц другая и работают в Москве по их инструкциям и нормам полностью. Плюс что боинг что аирбас любят прогибать под себя субподрядчиков (как по используемому по так и по стандартам)


            1. zoonman
              01.07.2019 17:51
              +1

              К сожалению или к счастью, я в Боинг не работал. Но имею некоторое представление о работе в крупной компании. Работа обычно выстроена очень четко и такие проблемы всегда решаются. Если нужно взаимодействовать с людьми говорящими на других языках и они совсем плохо говорят по-английски, то выгоднее нанять переводчика, чем терять время на бесполезные туда-сюда.

              А ещё я очень хорошо знаю русское «да пошло оно», «мне влом» и «нахрен он мне сдался». Так уж получилось, что я встречал это повсюду, от спившихся колхозников до руководителей компаний. Я знаю, что у инженеров это распространено реже, все таки есть какая-то профессиональная культура, но тоже проскакивает.


              1. radonit
                01.07.2019 18:16

                Работа обычно выстроена очень четко и такие проблемы всегда решаются.

                Это делается за счёт бюрократии, рано или поздно она становится крайне неповоротливой и действует с большим лагом
                Если нужно взаимодействовать с людьми говорящими на других языках и они совсем плохо говорят по-английски, то выгоднее нанять переводчика, чем терять время на бесполезные туда-сюда.

                В данном то случае вся документация и инструкции на английском, в том числе все руководства, никакого отношения ни к ЕСКД ни к Российской нормативной документации отношения не имеющие.
                А ещё я очень хорошо знаю русское «да пошло оно», «мне влом» и «нахрен он мне сдался».

                Это, это есть, но пожалуй не только в россии, это скорее противление новому, хорошо видно на примере смены интерфейса программ.


            1. androude
              01.07.2019 18:26
              +1

              соотношение раздолбаев и идиотов к нормальным там такое же как в России
              Эм, вы работали во всех американских российских компаниях и можете отвечать за все компании?


          1. mgremlin
            30.06.2019 20:41

            Знаете — всяко бывает.
            Бывает так, не спорю, но случается и вариант, в котором у сложной детали есть всего два размера — внешние габариты. И объяснить, что даже внешних габаритов надо минимум три — очень непросто. И ничего другого добиться не получается. Потому, что производится эта деталь на полуавтоматической линии, которую спроектировал один подрядчик, а произвел другой. А те, кто собственно делает и продает могут в лучшем случае рулеткой померить…

            И это — из моего личного опыта — встречается намного чаще, чем описанное вами. Наши люди частенько работать не хотят — это да, но средний уровень инженерной грамотности кмк значительно выше.

            Ну или по-другому сформулирую: у нас на заводах, особенно старорежимных, явно избыточное количество инженеров. В той же Германии много раз был на небольших заводах — так там запросто инженер будет один, остальные — так, мастера в лучшем случае. И этот инженер званием своим зело гордится, на визитках пишет, официальное обращение. У нас на схожем по выпуску заводе будет целый техотдел штаны протирать, и в цехах половина с вышкой…


            1. JamboJet
              01.07.2019 16:40

              Тут скорее вопрос разных названий:
              отечественный ГИП/ГАП — это как раз и будет engineer по западному.
              Наш инженер — это их техник (technician).
              Наш техник — ха ха, раньше в ссср были, но сейчас все инженеры. На таких местах обычно вообще студенты на практике или просто «взяли толковую девочку и подучили кнопку нажимать».


              1. mgremlin
                01.07.2019 18:36
                +1

                Мои лично много лет знакомые немецкие инженеры — это совсем не гипы. Я бы сказал — самые обычные инженеры, на семейных заводах работают, после обычных политехов. Только и примечательного, что типа династиями лет по 100, если не все 200 с гаком. Я со своим в какой-то мере (хотя бы по названию 8-) инженерным образованием смотрю на них сверху вниз без малейших сомнений.

                Их техник высшего образования тамошнего не имеет, равно как и наш. Другой вопрос — насколько обоснованно будет проводить параллели между нашим и их средним инженером/техником. Но что лучшие наши инженеры лучших немецких нисколько не хуже — не сомневаюсь.


              1. Whuthering
                01.07.2019 19:24
                +1

                ГИП — это скорее lead engineer или chief engineer


              1. geher
                01.07.2019 20:46

                Наш техник — ха ха, раньше в ссср были, но сейчас все инженеры.

                За все страны бывшего СССР не скажу, но, внезапно, техники в России и сейчас есть.


              1. Groramar
                02.07.2019 12:33

                Наш инженер — это их техник (technician).

                Это не так. technician — это наше среднее-специальное максимум, насколько я знаю.


                1. akryukov
                  02.07.2019 12:49

                  Наше средне-специальное дает квалификацию "техник" или "старший техник".


        1. SpeedWalker
          30.06.2019 23:53
          +2

          Не могу сказать ничего про авиастроение. Имею отношение к области строительства. Во всех современных зданиях есть датчики дыма. Могут быть как с автономным источником питания, так и «подключены к электрической системе». С трудом представляю, чтобы профильный инженер после института не смог бы разобраться в схеме подключения. В российском офисе Боинг точно есть в штате хоть один человек с профильным высшим образованием.
          Много работаю с немцами, англичанами, небольшой опыт работы с испанцами. У нас все делается намного быстрее и с меньшей бюрократией. Хуже всего работать с англичанами. Долго, дорого, низкое качество. Все эти штампы про умных трудолюбивых европейцев и ленивых русских порядочно надоели.


          1. corvair
            01.07.2019 03:13

            Хуже всего работать с англичанами. Долго, дорого, низкое качество.

            Так это же легендарная британская бюрократия. Друг, отучившийся там, был в шоке от некоторых решений.


    1. Hivemaster
      30.06.2019 18:47
      -1

      Просто подрядчик в России 9 раз переслал чертежи субподрядчику в Китае, а ещё 9 просто забил.


    1. nikolayv81
      30.06.2019 22:05
      +9

      Да там по разному может быть, после института я приходил в Boeing в Москве к "прочнистам" они тогда напротив кремля сидели, условия такие:


      1. Полписываешь бумагу о том что согласен на платное обучение ПО и должен компенсировать его либо работой в течении 2-3 лет (не помню) либо выплатить пропорционально остатку срока при увольнении, сумма более 10000$
      2. Зарплата на это время в районе 15т.р.(2006-2007 год), до окончания рабства шансы на повышение около нуля (со слов нанимающего, намекающего что заокеанские манагеры не дураки)
      3. Режим работы офиса сменный либо с 6 утра либо с обеда либо к ночи (или 2 варианта) офис то дорогой аренду платить надо + лицензии на ПО. Смену вроде как можешь выбрать но всё не так просто.
      4. К концу рабства, если повезёт, могут быть командировки в США, могут не быть но права нужны…
        В общем сами подумайте на кого там могли нарваться, ведь конкретный работник мог и Итальянскую забастовку устроить…
        p.s. никого не хотел обидеть но был в шоке ;)
        Как итог образование на свалке (очень нужное нашей стране да я помню...), и привет сектор финансов и программирование...


  1. edacval
    30.06.2019 15:55

    И вот теперь мне стало страшно летать…


  1. autuna
    30.06.2019 16:18
    +15

    Вот про это:
    "В 2008 году, во время встречи с главным инженером, ответственным за Boeing-787, один из сотрудников пожаловался, что 18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе".


    Мне стало просто до безобразия интересно.
    Если у кого-нибудь есть контакты знающие подробности — дайте знать, плиз.


    Как по мне — так это выглядит либо придуманным от начала до конца (навроде истории с закладками в чипах Supermucro), либо здесь не хватает какой-то ключевой детали в повествовании. Ибо 18 раз — это перебор, ИМХО.


    1. jrthwk
      30.06.2019 21:19
      -1

      <субьективно, по некоторому опыту работы с западными заказчиками

      ...18 раз он отправлял чертежи ХЗ куда, а после чего как с российской стороны наконец спросили «ну и когда нам пришлют чертежи?» сильно обиделся на невежливость вопроса и пошел жаловаться менеджеру.


    1. SECL
      30.06.2019 22:00

      Есть только один аутсорсер, который с ними работал и кричал про это на каждом углу) Догадаться не сложно ;)


    1. nikolayv81
      30.06.2019 22:08

      Чуть выше оставил комментарий https://m.habr.com/ru/post/458224/comments/#comment_20342732


  1. lamerok
    30.06.2019 17:57

    Если честно очень странно, даже с нами индусы не работают менее чем за 20 долларов в час… А тут боинг, здоровая компания, за 9 долларов в час, это только действительно, если студенты, но тогда им надо давать работу, которя вообще не связана с разработкой продукта, ну типа внутренний сайт для поддержки IT запросов, в параллель с запросами по почте…


    1. zoonman
      30.06.2019 18:57
      +2

      Так это было 10 лет назад.


    1. Alcpp
      01.07.2019 00:48

      Над 787 индусы вообще «бесплатно» раболтали, за процент от продаж.


      1. sergeygsd
        01.07.2019 16:12

        После памятного аварийного приземления в джунглях, появился карго-культ. Многие его последователи определили подростков в авиакомпании США.


  1. REPISOT
    30.06.2019 20:01
    +2

    А как же сертификация софта по DO-178?

    18 раз отправил чертежи команде в Россию, прежде чем они поняли, что детекторы дыма должны быть подключены к электрической системе
    Значит, чертежи такие


  1. Trixon
    30.06.2019 20:41
    -4

    Нанимать индусов писать КОД — самое последнее дело. Хотя, не удивительно для Boeing, который решил сотрудничать с индусским Microsoft. Code of conduct им в помощь, как говорится)


  1. mksma
    30.06.2019 21:18
    +4

    У меня все больше возникает ощущение, что из программистов в этой истории делают козлов отпущения. Как я понимаю основная проблема данного боинга — это корявое расположение двигателей. Именно для решения этой проблемы программисты писали костыль в виде MCAS. А складывается впечатление, что все теперь хотят свалить на кривой софт…


    1. nikolayv81
      30.06.2019 22:10

      Нет проблемы в двигателях, он ведь летает, есть проблема в нежелании пересертифицировать, менять программы обучения и т.д. а вот решение этих проблем было "некорректно закостылено"


      1. mksma
        30.06.2019 22:38
        +1

        Проблема не в том, что они не летают, а в их расположении. Если коротко, то из-за расположения двигателей, при определенных условиях, самолет слишком высоко задирает нос, что может привести к остановке самолета. MCAS — это костыль, который должен был решить проблему с задиранием носа. Подробнее тут.


        1. nikolayv81
          30.06.2019 22:50
          +1

          Спасибо я знаком с этой особенностью, у современных самолётов много особенностей, но сами по себе они не являются проблемами.
          Как у ан-148 включение подогрева трубок ППД не более чем за 20 минут, или как то что стабилизатор на Боинге 737 очень долго вручную крутить, можно их много найти, но если все варианты работы этих систем должным образом доносятся до пилотов и есть работающие способы преодолеть возникшие трудности штатно, то самолёты с этим летают, а вот Боинге приземлили из-за того что по их же инструкции с особенностями работы системы не справиться...


        1. BD9
          01.07.2019 03:39
          +2

          что может привести к остановке самолета

          «Делать остановку» самолёты умеют только на земле.


          1. DrPass
            01.07.2019 03:49
            +7

            Это и произошло


  1. QtRoS
    30.06.2019 22:51
    +1

    Меня во всей этой истории беспокоит то, что код между моделями наверняка переиспользуется, вот и летай потом на Боингах. Ну или даже если не код, то подход к разработке точно...


    1. corvair
      01.07.2019 03:16
      +3

      Therac-6, Therac-20, Therac-25…
      Налетал же этот код сколько то там сотен тысяч часов без проблем на предыдущей модели с тем же планером…


  1. schokoro
    01.07.2019 00:51
    -1

    Кажется, что-то подобное уже было
    https://ko.com.ua/kachestvo_vstraivaemogo_po_ili_pogrom_vsyo-taki_sluchilsya_98518


  1. yatagarasu
    01.07.2019 01:12

    Boeing-737 Max был обновлением конструкции 50-летней давности, и изменения должны были быть достаточно ограниченными, чтобы Боинг мог штамповать новые самолёты как горячие пирожки, с небольшими изменениями для сборочных линий или авиакомпаний. “Для инженера, это не самая лучшая работа”, добавил Лемм.


    Странно, всегда думал, что жто наивсышый челендж для инженера. Что-то сродни «подковать блоху». На ферарри конечно после этого не уедешь, но ограниченные условия всегда заставляют блеснуть мыслью и необычным подходом.


    1. Dmitri-D
      01.07.2019 06:44

      да, но не в условии ограниченных изменений и под прессингом.
      К тому же новые движки, которые имеют другую массу, габариты, управление, и главное существнно бОльшую тягу. Именно эти факторы приводили к выводу на запредельные углы и сваливанию. «Пофиксили» введя MCAS. С единственным датчиком. С сигнальной лампочкой, которая ни разу не проверялась и по факту не работала.


  1. IsyanovDV
    01.07.2019 01:39

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


    1. corvus
      01.07.2019 02:39

      Если система ставит среднесрочную прибыль выше всего, чего тут удивляться?


  1. arielf
    01.07.2019 02:07
    +4

    Во почему такие программы нужно писать на Ada! Программисты на Ada не станут унижаться за 10 баксов за час. Боже мой! Меньше чем самые копеечные шлюхи!


    1. 0xd34df00d
      01.07.2019 05:50
      +1

      Вы там букву g пропустили.


      1. 0xd34df00d
        01.07.2019 07:56
        +3

        Видимо, кто-то считает, что такой софт лучше писать на языках типа Ada, а не Agda. Ну ладно.


    1. woooody
      01.07.2019 23:49

      Если пойдет мода, то и Аду выучат.
      И… как Ада поможет брать показания с разных датчиков? ;)


      1. arielf
        01.07.2019 23:53

        Ну, и хорошо! По крайней мере Ada намного строже, чем C++. И она изначальна писалась в целях применения в аэрокосмической промышленности.


        1. 9660
          02.07.2019 08:29

          В целях применения в ВПК.


  1. NIKOSV
    01.07.2019 02:16
    +3

    Заголовок желтее желтого. Это как сказать что винду пилят индусы за $9 в час. По факту, индусы пилят, условно говоря, калькулятор, тогда как инженеры пилящие ядро сидят в Редмонде и зарабатывают 200-300к.

    Да и зарплата ничего не говорит о скилах. Один и тот же индус в Индии будет зарабатывать $9 в час, а в США — $50 и больше.


    1. ggreminder
      01.07.2019 20:25

      Не рассматривайте заголовок по отдельности, да и текст тоже не воспринимайте буквально, там несколько слоёв. Ваш пример насчёт винды тоже работает. Низкоквалифицированные программисты напишут (а низкоквалифицированные тестировщики проверят) приложение, которое будет валить вашу Windows в BSOD.
      Смысл в том, что проектировать систему, код писать и его тестировать должна элита — нельзя в таких системах допускать никаких «детских» ошибок, просто по определению. То, что у HCL или у кого там 18к человек в бодишопе американском — это как раз показатель, что всё плохо, а не хорошо. Уберите вообще аргумент про з/п и ответьте — хотели бы вы, чтобы ваши знакомые программисты (естественно, не имевшие опыта в авиации), писали бы код для самолета, на котором вы полетите? При этом будет и стоимость проекта и дедлайн, то есть они не могут код писать и тестировать 30 лет, никто не даст.


  1. corvus
    01.07.2019 02:39
    +2

    Кроилово приводит к попадалову(с)


  1. Dmitri-D
    01.07.2019 06:40

    Что-то плохо стыкуется — дешевый и потенциально проблемный софт, созданный для летных испытаний и главного дисплея, и неправильно подключенная лампочка индикации с неправильными данными, поступающими из датчика. Сотф — это софт. А железо — это железо.
    Хотя, конечно, сложный датчик может имеет свой софт внутри, но за него отвечает другая компания — производитель датчика. И они не индусы.
    Увольнение инженеров и особенно ведущих инженеров — это более правдоподобная причина. И, судя по статье, прослеживается попытка спихнуть с больной головы, нет не на здоровую, но на существенно менее больную.


    1. Terras
      01.07.2019 07:27
      +3

      В США есть небольшая проблема — разработчики и инженеры стали стоить очень дорого. Это все произошло из-за компаний типа Гугла, Оракла, Амазона и Майкрософта, которые по сути продают воздух.

      Поэтому компании, типа Боинга, которое производят железо — начинают сильно проседать из-за уровня зп инженеров. (Плюс опять же конкуенция в лице Аирбас из Европы, где нет таких раздутых зп).

      Поэтому, они и ищут способ снизить издержки, переводя разработку софта и узлов (тут как раз Россия) на аутсорс. Что из этого получается горбатый — ну это риски аутсорса.


      1. ua30
        01.07.2019 09:55
        +5

        Это все произошло из-за компаний типа Гугла, Оракла, Амазона и Майкрософта, которые по сути продают воздух.
        То же самое что электричество или связь воздухом назвать.


      1. Dmitri-D
        01.07.2019 16:14
        +2

        Terras Вы это мне, инженеру, работающему в США, рассказываете что является проблемой? )))
        Нет, конечно, означенные вами компании не выпускают воздух и вовсе не они привели к росту зарплат инженеров. Это рынок. Если на рынке не хватает специалистов в какой-то области, то ищут на стороне и поднимают зарплаты. Искать на стороне — есть квоты квоты на рабочие визы. Этих квот не хватает и на несколько дней. Своих специалистов — выпускают, разумеется, с задержкой на время обучения. Т.е. зарплату подняли сегодня, а приток на рынке от этого будет через несколько лет. Т.е. это работает медленно. Да и, в принципе, не такие уж и высокие эти зарплаты. В настоящее время, я говорю о восточном побережье Штатов, не-junior программист получает от 100 до 180. Основные предложения в районе от 120 до 140. Это больше, чем учитель в школе, но сильно меньше, чем профессор в универе или врач или юрист. И, потом, не нужно сравнивать с Россией. В Штатах всё дороже. И жилье и продукты и медицина и образование — это основные статьи расходов и эти расходы таковы, что остается, после оплаты обязательных платежей, едва ли больше затрат на продукты, т.е. это близко к уровеню бедности.
        Проблема с 737макс мне видится по-другому. Они решили поиграть в эффективность. Эффективные менеджеры сказали что опытные инженеры не нужны и наняли неопытных, но дешевых. С управлением ими справились, видимо, не очень хорошо.
        Вторая проблема — это тут в Штатах обсуждается широко — как же так получилось, что компания Боинг, выпуская 737MAX, получила право сама себя регулировать, т.е. самой устанавливать что и как сертифицировать в целом ряде вопросов?
        Третья проблема, отчасти связанная со второй, — это где проведена граница между выпуском новой модели, которую нужно заново сертифицировать и апгрейдом, который можно (и можно ли?) сертифицировать частично? Замена двигателей — на более мощные, имеющие очень существенные отличия, выглядит как слишком глубокое изменение для рядового апгрейда и контролирующие органы (TSA) явно промограли этот момент. Боинг, похоже, скрыл от них проблемы с управляемостью, которые они пытались пофиксить введя MCAS. Это тоже ускользнуло от TSA.
        Но, в целом, я уверен — Боинг справится. Уроки будут извлечены и правильный баланс будет найден. Это далеко не первая проблема у Боинг и все предыдущие они решили.


      1. arielf
        02.07.2019 00:03

        Если речь идёт о человеческих жизнях. И о многих человеческих жизнях. Вопрос цены вообще не должен превалировать. Решение — нанимать лучших из лучших, сколько бы они не стоили. Например, возьмите Concorde — и почитайте, как его проектировали — к примеру, у правого и левого борта было независимое электроснабжение. И всего 2 аварии за время эксплуатации.


        1. VMichael
          02.07.2019 12:14

          Если речь идёт о человеческих жизнях. И о многих человеческих жизнях. Вопрос цены вообще не должен превалировать. Решение — нанимать лучших из лучших, сколько бы они не стоили.

          Это хорошо звучит для лозунгов, но не работает в реальной жизни.
          Вы конечно можете нанимать лучших из лучших и выпустить продукт который никто не купит из-за слишком высокой стоимости.
          Возьмите те же автомобили. Можно, наверное выпустить авто, в котором не возможно разбиться в принципе. Но вот такой авто станет не по карману 99.99 % пользователей.
          Поэтому все балансируют между ценой и качеством.
          А эта статья похожа на статью в рамках политики возврата производства в США. Типа вынесли разработку за рубеж и вот смотрите, что получилось. Хотя нет никакой гарантии, что если бы все делалось в США, то косяков бы не допустили.


    1. yvm
      01.07.2019 10:33

      Границы стираются, hardware as code…


  1. asmolenskiy
    01.07.2019 07:45

    Софт для Boeing-737 Max писался аутсорсерами, зарабатывающими $9 в час

    И конструкция самолета тоже. И не только для Max, но и для всех остальных моделей. И не только у Boeing, но и у Airbus. Они в принципе на стафф-лизинге плотно сидят.


  1. NeiroNx
    01.07.2019 07:45
    +1

    Софта становится все больше, и не известно где и когда он откажет. Думаю что одна команда разработчиков должна была делать весь проект целиком, начиная от различных датчиков, заканчивая системами верхнего уровня. Но кто-то пожалел денег на такую команду. Походу слился Боинг в пылу оптимизаций расходов.


  1. nivorbud
    01.07.2019 09:23

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


    1. boilroom
      01.07.2019 10:20

      ЕМНИП, современные гражданские авиалайнеры в принципе статически неустойчивы. И компенсируется это как раз ЭДСУ. Т.е. это обычная практика. Не думаю, что компоновочное решение так уж повлияло на проблемы с B737MAX


      1. nivorbud
        01.07.2019 12:34
        +1

        Не думаю, что компоновочное решение так уж повлияло на проблемы с B737MAX


        Извините, но КАК тогда пилотам управлять в ручном режиме, если эти особенности лайнера даже в документации не были описаны??? На ходу изучать особенности планера?

        Смотрите, что получается:
        1) Лайнер имеет косяк — он неустойчив.
        2) Эта неустойчивость отличается, от той, что была на старых лайнерах (если там была неустойчивость).
        3) В документации этот факт не отразили.
        4) Посчитали, что достаточно имеющихся правил, т.е. пилотам надо было отключить автоматику и перейти на ручное управление рулями.
        5) Но при ручном управлении они неизбежно должны столкнуться с неустойчивостью планера, к которой не готовы, т.к. это не отражено в документации. Т.е. самолет поведет себя не так, как ожидается.

        Считаете, это нормально?


        1. MarazmDed
          02.07.2019 16:35
          +3

          Извините, но КАК тогда пилотам управлять в ручном режиме, если эти особенности лайнера даже в документации не были описаны??? На ходу изучать особенности планера?

          Спокойно управлять. Более того, поведение самолета отличается от NG весьма незначительно. Все, что нужно для пилотирования, в инструкциях есть. И в первую очередь — на случаи отказов, как с косячной MCAS.
          И да, по результатам двух катастроф, Боинг признала, что их стратегическая ошибка — думать, будто в кабине пилотов сидят профессионалы. Инструкциям IAS unreliable и runaway stabilizier — уже много десятилетий. Но да, нельзя опираться на знание экипажем инструкций.

          1) Лайнер имеет косяк — он неустойчив.

          Вы хоть уточните, в чем проблема. Проблема в том, что движки имеют склонность задирать нос самолета. И в определенных режимах (при малой скорости), это может создавать угрозу сваливания. В этих режимах самолет летать не должен. Т.е. если самолет подвели к этой черте, это уже косяк пилотирования. Называется «пролюбили скорость». Для того, чтобы этот косяк конструкции нивелировать, внедрили MCAS, которая должна определять, что лайнер на грани сваливания, и автоматически опускать нос вместо зазевавшегося пилота.

          2) Эта неустойчивость отличается, от той, что была на старых лайнерах (если там была неустойчивость).

          С учетом работающей функции MCAS — нет, не отличается.

          3) В документации этот факт не отразили.

          Опробовать MCAS есть возможность на тренажерах. В документации есть упоминание системы MCAS. И есть упоминание ее назначения. Да, недостаточно подробное.

          4) Посчитали, что достаточно имеющихся правил, т.е. пилотам надо было отключить автоматику и перейти на ручное управление рулями.

          Не про рули речь. Про стабилизатор, который самопроизвольно перекладывается. И да, имеющихся инструкций было достаточно. После Индонезии, Боинг разослала последнее китайское предупреждение всем операторам. Эфиопия показала, что не помогло.

          5) Но при ручном управлении они неизбежно должны столкнуться с неустойчивостью планера, к которой не готовы, т.к. это не отражено в документации. Т.е. самолет поведет себя не так, как ожидается.

          Это не так. Все, что должны сделать пилоты — это отключить электропривод стабилизатора, после чего управлять им вручную. Более того, если бы они правильно выполнили чек-лист IAS unreliable, который предусматривает выпуск закрылков, то они просто не узнали бы, что у них в самолете есть MCAS. Потому что MCAS отключается при выпуске закрылков.

          Считаете, это нормально?

          Боинг свои косяки признал. Признал еще после Индонезии, когда они вскрылись. Боинг свои косяки поправит. Уже правит.

          А вот кто поправит пилотов? Всем понятно, что боинг — знатные поросята. Но в этой истории есть еще одни герои. И неизвестно сколько таких «специалистов» живые и ждут своей очереди угробить очередной самолет.


          1. nivorbud
            02.07.2019 17:17

            Формально можно с вами согласиться, но только формально. Однако тупое формальное выполнение всех правил без понимания сути происходящего тоже ни к чему хорошему не приведет. В данном случае, если бы летчики были бы осведомлены об особенностях работы MCAS, а также были бы оповещены о неисправности датчика, то скорей всего они смогли бы справится с ситуацией.

            А вообще странно всё там выглядит… Датчика там этих было как минимум два, т.е. какое-то резервирование всё же было, хоть и не достаточное для полностью автоматического решения проблемы. Индикация неисправности датчика также была предусмотрена, но… по умолчанию (в базовой комплектации) отключена.

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


            1. MarazmDed
              02.07.2019 17:58
              +5

              Однако тупое формальное выполнение всех правил без понимания сути происходящего тоже ни к чему хорошему не приведет.

              1) Действия по памяти специально разработаны для того, чтобы в экстренной ситуации пилоты тупо формально, не думая, их исполняли. Ровно потому, что порефлексировать времени нет.
              2) Во время обучения смысл действий из чек-листов пилотам понятен. Они прекрасно понимают, почему чек-лист именно такой, а не другой.
              3) Если пилот не понимает сути происходящего, то нечего ему делать в кабине пилота. Может пылесосом в торговом-центре поуправлять. Или за кассой посидеть.

              В данном случае, если бы летчики были бы осведомлены об особенностях работы MCAS, а также были бы оповещены о неисправности датчика, то скорей всего они смогли бы справится с ситуацией.

              Они были снабжены всей необходимой информацией:
              1) До катастрофы в Индонезии, предыдущий борт, почему-то спокойно разрулил проблемы и приземлился. А неквалифицированный экипаж, столкнулся с теми же самыми проблемами и уронил самолет.
              2) IAS disagree не возможно не заметить. Тряска штурвала с одной стороны и горит табло. Другой информации просто не нужно. В этот момент нужно выполнять чеклист airspeed unreliable. Если бы эфиопы его выполнили, как того требовала ситуация, то остались бы живы и даже не узнали про то, что у них есть MCAS.
              3) после индонезийской катастрофы боинг всем разослала письмо. Я выше уже писал про это.
              4) Грамотный квалифицированный экипаж смог бы справиться с проблемой. Зачем в самолетах сидит неквалифицированный неграмотный экипаж — мне решительно непонятно.

              Датчика там этих было как минимум два

              Датчиков там ровно два. Столько же, сколько и на подавляющем большинстве других типов самолетов. И подобные отказы — не редкость.

              хоть и не достаточное для полностью автоматического решения проблемы.

              Трех датчиков тоже недостаточно для полностью автоматического решения проблемы. Думаю, именно поэтому их ставят два. Пилот нужен для того, чтобы принимать решение.

              Индикация неисправности датчика также была предусмотрена, но… по умолчанию (в базовой комплектации) отключена.

              Это не так. IAS disagree есть в базовой комплектации. Опциональный датчик AOA disagree не дает новую полезную информацию и является прикольной свистоперделкой.

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

              Как я понимаю ситуации, есть две виноватых стороны:
              1) Боинг. Косяк в MCAS есть и он провоцирует летчиков на ошибки, а потом роняет самолет. Этот косяк является преодолимым, не является фатальным, но — это косяк. Боинг этот косяк признала и работает над его устранением.
              2) Пилоты. И вот тут самое ужасное. Никто из журналюг не говорит о том, что пилоты непосредственно виноваты в катастрофах, потому что совершили вполне конкретные ошибки. И имеем то, что боинг косяки исправляет, а авиакомпании — нет. И это реально страшно. Верю, что у нас подготовка летчиков организована лучше, чем в индонезии и эфиопии, но катастрофа суперджета намекает, что тоже не все слава богу.


              1. geher
                02.07.2019 18:58

                Они были снабжены всей необходимой информацией:

                Пилоты (более 400) подали на Боинг в суд. жалуются, что таки не были снабжены (обвинение предъявлено "в намеренном сокрытии дефектов самолета 737 Max.")


                1. dimm_ddr
                  03.07.2019 10:23
                  +1

                  Вот если бы они суд уже выиграли (что впрочем вполне вероятно на волне общественного возмущения), тогда это могло бы считаться доводом. А так — пилоты тоже люди и когда они видят что могут отхватить немного денег от большой корпорации, то стесняться не будут.


              1. nivorbud
                02.07.2019 19:29

                1) Действия по памяти специально разработаны для того, чтобы в экстренной ситуации пилоты тупо формально, не думая, их исполняли


                Я (не один десяток лет в IT) давеча устанавливал на комп один специализированный сервис (для картографии)… Разбираться было лень, в наличии имелась пошаговая инструкция, поэтому решил решить эту задачу с наскока… Не срослось… Не вышел сходу каменный цветок… Несколько движений наугад также к успеху не привели. Хотя… делал всё по инструкции, при наличии опыта, но… без понимания работы конкретного сервиса.

                Потом пошел с ребенком погулять и пока ребенок бегал, на смартфоне просмотрел документацию на сервис, понял принцип работы и… придя домой сходу сервис этот запустил.

                Это я один пример (буквально вчерашний) подробно расписал, но это не единичные случаи, уверен, любой айтишник сталкивается с этим постоянно: без понимания процессов инструкции малополезны, иногда вредны.

                И еще момент из моей практики: когда я недавно писал код, я поставил на один критичный блок кода условие (проверку) на ситуацию… которая не должна происходить..., т.е. это условие можно было бы и не ставить. Зачем поставил? Да, потому что кусок кода — критичный, и интуитивно чувствовал, что лучше явно перестраховаться.

                А в сабжевом случае разработчик создает код, принудительно направляющий самолет в пикирование… И… у него на интуитивном уровне не возникло ощущение, что что-то не так, что надо бы подстраховаться? У меня бы возникло…


                1. dimm_ddr
                  03.07.2019 10:25
                  +3

                  без понимания процессов инструкции малополезны, иногда вредны
                  Если инструкция некорректная — то, да, конечно, она бесполезна и вредна. Если бы инструкция была корректная, то у вас бы и с наскоку все бы получилось.


                  1. nivorbud
                    03.07.2019 11:55

                    Если бы инструкция была корректная, то у вас бы и с наскоку все бы получилось.


                    Да ни фига. Корректная инструкция корректна только к конкретному окружению. Если окружение хоть немного отличается, то легко может что-то пойти не так. А окружение как правило отличается.


                    1. dimm_ddr
                      03.07.2019 12:56
                      +1

                      Если окружение прописано в инструкции и у вас оно отличается, то для вас эта инструкция, вполне может быть некорректна.


                1. kv75
                  03.07.2019 10:39

                  Я совсем не уверен, что разработчик понимает, что он «создаёт код, принудительно направляющий самолет в пикирование». Разработчик в данном случае — узкий специалист. Он создаёт код, соответствующий ТЗ. И вряд ли он пытается задумываться над тем, как его код будет использоваться.


                  1. nivorbud
                    03.07.2019 12:13

                    Я под программистом подразумеваю и разработчика ТЗ в том числе.


                1. MarazmDed
                  03.07.2019 23:34

                  Я (не один десяток лет в IT) давеча устанавливал на комп один специализированный сервис (для картографии)…

                  Какая связь между отказом в летящем самолете и сервисом, инструкцию к которому вам лень было прочитать? Существенно разные ситуации. Их некорректно сравнивать. Равно как и некорректно перенимать опыт.
                  К тому же, я специально указал: пилоты понимают смысл происходящего. Их для этого обучают. Если пилот не понимает смысла, такое бывает, то ему нечего делать в самолете.

                  Вы на авто ездили? Там тоже полно универсальных 100% работающих рецептов. Например, «в любой непонятной ситуации тормози, уходи на обочину, останавливайся и включай аварийку». Работает безотказно для любой проблемы.
                  В самолете тоже самое. Не важно, по какой причине случился отказ. Не важно, какие механизмы к этому отказу привели. Это все потом выяснят техники на земле. Важно, как этот отказ парировать. И на этот случай придуманы чек-листы и действия по памяти.

                  И… у него на интуитивном уровне не возникло ощущение, что что-то не так, что надо бы подстраховаться? У меня бы возникло…

                  Не стоит считать себя умнее всех :) У Боинга тоже возникло. Не случайно Боинг признали, что их стратегическая ошибка — полагать, что за штурвалом не может оказаться идиот. Код, принудительно загоняющий самолет в пикирование, отключается тысячей и одним условием работы в этом же самом коде. Например, включенный автопилот отключает MCAS, выпущенные закрылки отключают MCAS. Триммирование со штурвала отключает MCAS на период триммирования + 5 сек. после.

                  И самое главное: MCAS и все остальные системы и глюки, жаждущие отправить самолет в пикирование, надежно отключаются всего двумя тумблерами на центральной консоли «stab trim cutout». Щелкнул тумблером и MCAS заглох.

                  Перефразирую:
                  1) Если бы пилоты выполнили чек-лист airspeed unreliable (что они должны были сделать, поскольку горело табло IAS disagree), то самолет не пытался бы клевать носом.
                  2) Если бы пилоты выполнили чек-лист runaway stabilizier (что они должны были прочувстовать, по бешенно вращающемуся колесу стаба с диким треском), то MCAS не смогла бы дальше пакостить.
                  3) Если бы они не считали ворон, а триммировали самолет со штурвала, то они бы с легкостью перебороли MCAS. И с матюками, но — живые, долетели бы до места.
                  4) Даже если бы произошло невероятное и они в нарушение всех инструкций врубили бы автопилот, то MCAS опять же надежно успокоился бы.


                  1. nivorbud
                    04.07.2019 00:55

                    У нас разговор заходит не в то русло — мы углубились в детали начали заниматься гаданием: что было бы в этом конкретном случае, если бы… На самом деле посыл простой: такие конструкторские и организационные решения резко повышают вероятность нехорошего исхода. И это очевидно любому инженеру. Да и пилоты, думаю, не на пустом месте занервничали и волну погнали.


                    1. MarazmDed
                      04.07.2019 01:17

                      На самом деле посыл простой: такие конструкторские и организационные решения резко повышают вероятность нехорошего исхода.

                      Я и говорю, что разговор идет не в то русло. Есть плохое решение от Боинга. Это очевидно и мусолится всеми, кому не лень. А вот другая вопиющая проблема — подготовка пилотов, вообще не рассматривается как класс. И это удручает.


    1. arheops
      01.07.2019 18:31
      +1

      А стелс — бомбардировщики и некоторые истребители высокоманевренные вообще в принципе человек без софта не может пилотировать, неустойчивые.


      1. nivorbud
        01.07.2019 20:13

        >>> и некоторые истребители высокоманевренные вообще в принципе человек без софта не может пилотировать, неустойчивые

        И что из этого следует? У них используется трех — пяти кратное резервирование, плюс система катапультирования, плюс к тому наверняка военные летчики хорошо знают особенности планера истребителя при отказе автоматики. А теперь сравните с пассажирским самолетом на три сотни человек, с отсутствием какого-либо резервирования датчиков, с отсутствием оповещения о неисправности датчиков, и… с полным неведением экипажа касаемо того, как поведет себя лайнер при отключении автоматики, т.е. в ручном режиме (априори неустойчиво, но как — об этом в документации умолчали)…


  1. gshamshurin
    01.07.2019 09:29

    Задача на теорию вероятностей:
    Условный низкооплачиваемый аутсорсер пишет говнокод и допускает по 100 ошибок в каждом программном модуле.
    Условный штатный программист пытается вдумчиво писать хороший код, но всё равно допускает по две ошибки в каждом программном модуле.
    Условный штатный тестировщик в ходе тестов выявляет ошибку с вероятностью 999 из 1000.
    Количество критичных для безопасности программых модулей равно 100.
    Вопрос: при условии трёх ступенчатой проверки каждого модуля штатными тестировщиками, посчитайте сколько людей погибло из-за м***цкого решения по использованию труда аутсорсеров на разработке критичных узлов конструкции и модулей ПО?

    Я думал что в Америке не нанимают в топ-менеджмент конченых идиотов с купленными дипломами. Походу ошибался.


    1. lingvo
      01.07.2019 09:51
      +1

      Условно это решается тем, что каждый модуль продублирован или протроирован и пишется разными программистами, то есть подразумевается, что они не наделают одинаковых ошибок и если один модуль сбойнет в каком-то месте, дублирующий все вытянет.


      1. gshamshurin
        01.07.2019 10:12
        +1

        Качество исходного кода в любом случае играет роль. Писать/рассчитывать/проектировать всё связанное с безопасностью должны только и строго ответственные, квалифицированные и мотивированные люди.
        Аутсорсеру такое отдавать нельзя.


        1. lingvo
          01.07.2019 11:02

          Так вроде в статье прямым текстом указано, что безопасность аутсорсерам не давали


          1. gshamshurin
            01.07.2019 11:27

            Там прямо написано, что им давали писать ПО для основной приборной панели (интересно, за что она ещё может отвечать?).
            И есть данные что

            Rockwell Collins, производящая электронику для кабин самолётов, была одной из первых самолётостроительных компаний, передавших значительную часть своей работы в Индию, где начиная с 2000 года HCL начала тестировать их программное обеспечение. К 2010 году в HCL работало более 400 человек, занятых разработкой и тестированием ПО для Rockwell Collins, в офисах располагающихся в Ченнаи и Бангалоре.

            А вот тут неоднозначно — речь идёт о том же дисплее что и выше или о более широком круге задач. Скорее всего второе.


            1. lingvo
              01.07.2019 11:47

              Там прямо написано, что им давали писать ПО для основной приборной панели (интересно, за что она ещё может отвечать?).

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


              1. gshamshurin
                01.07.2019 12:05

                Эээ… Если пилот видит недостоверную информацию о параметрах полёта, это наипрямейшее отношение к безопасности.


                1. mayorovp
                  01.07.2019 12:19

                  Но пилоты таки видели достоверную информацию о параметрах полета (за исключением идущей от неисправного датчика)


                1. lingvo
                  01.07.2019 13:16

                  Ну как сказать. Вот у вас в автомобиле, например, поломался спидометр и теперь он показывает всякую чушь. Будет ли это относиться к безопасности? Если да, то стоит ли ради этого дублировать спидометр и принимать другие дополнительные меры, чтобы вероятность этой неисправности снизилась до 1e-12 или сколько там требуется по стандартам безопасности?


                  1. gshamshurin
                    01.07.2019 13:28

                    В автомобиле фактически нет информации, критичной для безопасности т.к. всё нужное можно увидеть глазами.
                    У самолёта например положение механизации крыла, высота, скорость (она влияет на возможность управляемого полёта) — параметры, без которых полёт может и даже с большой долей вероятности закончится не по плану.


                    1. ardraeiss
                      02.07.2019 16:34

                      Сверх того, человек в самолёте глазами может и ориентацию потерять, а вестибулярник вполне может обманывать в этот момент. Скажем, в условиях плохой видимости. Тогда без приборов вообще никак.


      1. nikolayv81
        01.07.2019 23:54
        +1

        Но именно с 737MAX и MCAS условия дублирования не выполняются, и, как пишут на форумах авиации, у Боинга 3-м голосующим является человек, просто у человека не хватает времени, особенно если ему не объясняли что происходит когда "вспомогатель" основываясь на данных только одного канала решает переложить стабилизатор....


  1. ua30
    01.07.2019 09:52
    +3

    Не пойму, чего столько шумихи из-за желтой статьи? MCAS они не разрабатывали. Как по мне, больше похоже на то, что обиженные уволенные инженеры + ньюсмейкеры злоупотребляют на трагедии. Не вижу ничего плохого в делегировании не критической работы.


    1. arielf
      02.07.2019 00:12
      -1

      Аутсорсить можно в WEB и прочей макаковщине. А в авионике аутсорсить нельзя.


  1. yannmar
    01.07.2019 09:59
    +2

    зарабатывающим всего лишь $9 в час

    Что значит «всего лишь»? Это так-то $1500 в месяц (в рублях -100 тысяч) — нормальная зарплата для хорошего аутсорсера из бедной страны.


  1. lxsmkv
    01.07.2019 10:09
    +2

    У меня впечатление, что некоторе люди думают об аутсорсе как об облаке — задание дал, денег в дал, софт получил. Это совсем не так. Что единственные расходы на аутсорс это сколько денег затребовал аутсорсер.

    Делегирование всегда рождает накладные расходы на постановку задачи и контроль результата. Как и в программировании, разделяя две системы нужен интерфейс/протокол. К его проектированию нужно подходить особенно тщательно. Если не уделить этому должного внимания, то мы получим б итоге неэффективную систему. Так и тут, если экономия от аутсорса перекрывает расходы на дополнительную коммуникацию, то аутсорс выгоден, в противном случае нет.

    Аутсорсить можно, если у тебя есть четкое представление как будут устроены коммуникация, контроль и управление. Если нет — будет все очень трудно.

    У меня ощущение, что этим пренебрегают и подменяют эти необходимые стратегические решения правовыми регламентами. Кто кому что будет должен если что-то пойдет не так. Вместо того чтобы решить проблему которую мы не знаем как по-быстрому решить — решим ту которую мы знаем как решить.


    1. asmolenskiy
      01.07.2019 11:26
      +1

      На самом деле они работают немного не так и эта схема давно отлажена.
      Обычно Boeing/Airbus/Cessna… заключает договора на стафф-лизинг с целым ворохом компаний. Например в РФ это Прогресстех и Nic, также там дофига Индии и Китая.
      Затем берется техлид с группой инженеров из компании подрядчика и перевозится в США по визе на обучение — не скажу точно какой код. Они там сидят примерно полгода на сайте у заказчика и работают там за ±60$ в день, также им оплачивают проживание, автомобиль и прочее (это дешевле чем нанимать своих, которые стоят примерно в 4-5 раз дороже). Параллельно на родине на подхвате сидит еще бригада. Через полгода они ротируются.
      Ключевые специалисты обычно находятся в штате заказчика.
      Не скажу за индусов и китайцев, наши при этом параллельно еще получают свою з/п. Она небольшая, но в сумме с такими «коммандировочными» получается неплохо. В итоге довольны остаются все.
      Это не чистый аутсорс. Просто эти компании берут в аренду инженеров на проектной основе и скидывают с себя весь кадровый головняк (больничные, отпуска и прочее).
      Самые высокооплачиваемые специалисты — прочнисты. Их мало и их очень часто хантят в голубые бэджи.


      1. lingvo
        01.07.2019 11:49

        хантят в голубые бэджи

        Можно поподробнее, что это? Про аренду инженеров я в курсе — немецкие автомобилисты тоже этим довольно сильно промышляют.


        1. asmolenskiy
          01.07.2019 11:51

          Кадровые сотрудники.
          У меня есть пара знакомых прочнистов которые получили такие офферы. Им делают нормальные визы по спонсируемым квотам, дают американскую зарплату и все положенные бенефиты.
          Но то есть человек тупо эмигрирует в США и работает в Боинге/Цессне итп как обычный белый человек.


          1. lingvo
            01.07.2019 11:54

            А от чего пошло название "голубые бэджи"?


            1. asmolenskiy
              01.07.2019 11:57

              Я думаю потому что у них бэджи голубого цвета ))).
              У меня просто жена работала в этой отрасли и добрая половина знакомых по универу. Я от них нахватался.
              Жена вот реально по полгода в году там проводила трипами по 2-3 месяца. Больше нельзя, так как становишься налоговым нерезидентом. Понапроектировала много всяких элементов конструкции для всяких разных ихних самолетов.
              У нее как раз одна из задач была — тусить там на сайте и выхватывать работу. На сайте в смысле в офисе, а не веб-сайте)


      1. lxsmkv
        01.07.2019 11:58

        Это аутстаффинг, я правильно понимаю? При такой схеме работают по процессам заказчика. Тут винить по большому счету можно только заказчика.


        1. asmolenskiy
          01.07.2019 11:59

          Ну в общем — да. Люди работают так, как будто бы они были в штате, а не сидят там сами по себе где-то и раз в неделю отчеты присылают.


  1. yvm
    01.07.2019 10:27

    Видны уши эффективных менеджеров…


  1. DarkWolf13
    01.07.2019 11:01

    надо сказать что подобным грешат по всему миру. давным давно в начале 2000 даже на одном околооборонном изделии на постсоветском пространстве заказчики кинули программиста и послали его подальше, но софт был написан с деморежимом, вот тогда всем прилелело, да и программиста подергали, но все весело развернулось против основных исполнителей, которым почти сошло с рук к сожалению… и к сожалению в современных реалиях кинуть могут еще более вероятно… вот думай где она грань когда ты хочешь спокойно отработать и получить заработанное и где тебя кидают и ты можешь стать соучасником


  1. krug
    01.07.2019 11:01
    -1

    Del


  1. Hedgehog7
    01.07.2019 11:25

    Летай после этого… :/


    1. lingvo
      01.07.2019 11:50

      Ну в принципе это же можно сказать про "езди после этого" после очередных багов в коде какого-нибудь автопроизводителя. "лечись после этого" после бага в рентгеновском аппарате и т.д.
      Это кризис отраслей, где софт начинает играть доминирующую роль.


      1. Hedgehog7
        01.07.2019 14:47

        Не спорю, да, но недавно был случай — нужно было уехать в другой город и стоял выбор — самолетом добираться или на поезде… и по мне так лучше на поезде добраться, чем на самолете. Да, долго и поезда тоже могут и с рельс сходить, и еще что-то, но, по крайней мере, ты на земле… долго меня переубедить пытались, что самолеты — самый безопасный транспорт, но как-то не вышло все же. Да статистике верить сейчас вряд ли где можно — она как раз первое оружие для обмана.

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


        1. lingvo
          01.07.2019 15:22
          +1

          долго меня переубедить пытались, что самолеты — самый безопасный транспорт

          ИМХО если в сегодняшних реалиях собрать статистику по авариям по отношению к количеству взлетов/посадок, то и среди самолетов будут явные лидеры и аутсайдеры. И вполне возможно, что аутсайдеры будут менее безопасными, чем поезда.


        1. DistortNeo
          01.07.2019 15:25
          +1

          долго меня переубедить пытались, что самолеты — самый безопасный транспорт

          В России поезд — самый безопасный. У нас часто падают самолёты, а происшествия на поездах со смертельными исходами крайне редки. =


          1. BackDoorMan
            01.07.2019 16:15

            Если не ошибаюсь в статистику трагедий на ЖД транспорте попадают погибшие вне поезда, т.е. перееханные оным. А сами пассажиры гибнут крайне редко. Другое дело, что во многих случаях ЖД вам совершенно недоступен. Попробуйте доехать из NYC до LAX на поезде, пассажирского сообщения просто нет.


        1. Neuromantix
          02.07.2019 11:04

          В случае с самолетами и всем другим транспортом есть еще один эффект, о котором я нигде не читал, но его эмпирически озвучивали многие, кто боится летать — график функции «тяжесть катастрофы от объема и сложности неполадок» в случае любого транспорта, кроме самолета, относительно монотонен, в случае же с самолетом он имеет резкий излом — т.е. после какого-то уровня проблем самолет гарантированно разобьется и все погибнут. И это подсознательно или сознательно влияет на выбор. Ну и так же то, что неполадки, критические для самолета, пусть и гипотетически — типа отказа всех двигателей, для любого другого транспорта безопасны или условно безопасны.


  1. vlaubenshtein
    01.07.2019 11:49

    Я так скажу — человек, который получает мизерную зарплату, не будет урабатываться и ему не важно что зависит от его тестирования — человеческие жизни или лояльность пользователя.


    1. tommyangelo27 Автор
      01.07.2019 11:57
      +1

      А я не согласен. Есть перед глазами пример — уборщики в моём доме, нанятые управляющей компанией.

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

      Заменили на парня, который прибегает, не курит, не пьёт кофе, улыбается, вставляет наушники с музыкой и подкастами и часа за 4-5 делает дневной объем работы и сваливает домой. И в доме чисто, жильцы довольны.

      Я думаю зарплата у них обоих что-то в районе минималки. Дело в отношении — или берись за работу и делай на совесть, или (если считаешь, что тебе мало платят) не берись совсем, ищи что-то более соответствующее твоим знаниями и умениям. Вот эти вот страдания на рабочем месте — просто оправдания.


      1. A114n
        01.07.2019 14:00

        Это вы так говорите, потому что у вас есть выбор. «Браться или не браться».
        Но в ряде случаев жизнь ставит перед людьми совсем другой выбор — браться или умереть, например, от голода.


        1. tommyangelo27 Автор
          01.07.2019 14:08

          Умереть от голода в современном мире еще надо постараться (я про более-менее развитые страны, не про африканскую глубинку).

          А если речь идёт о программировании или тестировании (как в комментарии выше), то я вообще не понимаю в чём проблема. Даже в провинции вам хватит на обычную жизнь. И зарплата среднего или пусть даже низкого уровня совсем не означает, что работу надо делать левой пяткой.

          Браться или умереть — это что-то из рабовладельческого строя.


          1. Areso
            01.07.2019 21:28

            От голода, наверное, сложно, но вот в России и близлежащих странах вполне можно двинуть ноги от холода.
            Зимы холодные, а энергоносители стоят дороже еды.


      1. vlaubenshtein
        01.07.2019 15:29

        И ваша точка зрения имеет место быть.
        Но не во всех компаниях адекватно оценивают труд сотрудников.
        И есть еще такое понятие как мотивация.
        Кто-то сейчас говорит «ах, это современное слово, ну да ну да», но оно есть и применимо.
        Энтузиазм это хорошо, но на одном нем далеко не уедешь и рано или поздно он сходит на нет, если ты работаешь хорошо, а тебя не продвигают и не ценят.
        Нормальный человек уходит на другое место работы, но не всегда есть возможность уйти быстро и на условия лучше.
        Поэтому работаешь, спустя рукава. Не обязательно не качественно. Просто не делаешь больше, чем нужно.
        Я уже давно пришел к выводу, что люди работают лучше при нормальном к ним отношении со стороны руководства и достойной зп.
        Прочие плюшки — довесок.


  1. olsamurai
    01.07.2019 12:01

    Как кто-то уже написал в комментариях, плохой код можно написать и за 1 цент и за 1 миллион. А вот хороший код напишут либо за адекватное вознаграждение и людьми с персональной ответственностью или совсем бесплатно.
    Долгие дискуссии натолкнули меня на мысль, что мол типа «эффективные менеджеры» в Боинг (подставь сюда почти любую компанию), считают, что писать программы могут быдлокодеры, которые работают у суб-суб-субподрядчиков и все будет хорошо. А «эффективные менеджеры» в авиакомпаниях тоже думают похоже: самолеты умные, можно на пилотах сэкономить! Зачем нам высококлассные (высокооплачваемые) пилоты, зачем переобучение, проверки и т.д. Тоже самое с наземными службами, зачем нам хорошие техники и инженеры! Можно тут тоже сэкономить. А потом то датчтик «соплями» забрызгают, то тряпку забудут вытащить из трубок Пито. То дырку насковозь сделают… Так что не зря есть старая украинская пословица: Дешева рибка — погана юшка.


    1. lingvo
      01.07.2019 12:07

      Ну в отличии от бизнеса, в R&D все же существуют определенные и достаточно хорошо проработанные процессы разработки, благодаря которым действительно программы могут быть написаны быдлокодерами, но благодаря процессу, не будут содержать ошибок. Такие процессы обычно включают различные Gate и Peer-to-Peer Review, Чеклисты и прочие. И без заполнения тонн документов, никто не пропустит проект в следующую стадию.
      Главное, чтобы этот процесс не отменили "эффективные менеджеры"


      1. olsamurai
        01.07.2019 14:54

        Не могу с вами не согласиться, НО, живя и работая долгое время в Германии, оутсорсить стало практически невыгодно. Когда-то, на заре оутсорсинга, когда в Индии писали за 1 рупию (утрированно), а заказчик платил 1 ДМ, это было выгодно. А сейчас нет. Серьезный разраб получает от 3500 до 6500 в месяц брутто (за исключением Мюнхена и Штуттгарта). А накладные расходы на координацию, постановку подробно задачи и ТЗ, кодревью и прочее выросли. И получается что написать по месту в итоге не (сильно) дороже, зато очень быстрый отклик и поддержка.


        1. Peter03
          01.07.2019 20:39

          Ещё есть подозрение, что аутсоурсные конторы тоже оптимизируют прибыли. Типа одного кодера продают на три-четыре проекта на фулл-тайм. Иначе я реально не могу объяснить их производительность, одновременно при очень плохом качестве кода.


  1. Timyrlan
    01.07.2019 12:28
    -1

    Вот что бывает, когда за дело берутся Эффективные Менеджеры (ТМ)


  1. ganqqwerty
    01.07.2019 12:36
    +1

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


  1. MarazmDed
    01.07.2019 12:54
    +1

    судя по всему, детские ошибки при разработке софта, приведшие к двум катастрофам с человеческими жертвами.

    Двойной facepalm!!!
    Сколько еще нужно объяснять, что катастрофы с человеческими жертвами произошли по вине ПИЛОТОВ, подготовка которых не отличается от уровня оператора пылесоса в бизнес-центре.
    Сама Боинг признала: «наша стратегическая ошибка — проектируя самолет мы полагались на пилотов. Это было ошибкой».

    Да, в софте боинга был косяк. Да, его начали исправлять после катастрофы. Но стратегическая ошибка боинга в том, что внедрив MCAS, они полагались на пилотов, которые из QRH должны были помнить действия при airspeed unreliable и runaway stabilizier и должны были с легкостью решить проблему.
    На деле квалификация пилотов такова, что они тупо забили на выполнение чек-листов, в результате получили две катастрофы.

    Боинг-то косяки исправит. А кто исправит пилотов?


    1. olsamurai
      01.07.2019 16:04
      +1

      Я думаю, что многие понимают куда вы клоните. И я в их числе. Но почему Боинг может закладываться, что за штурвалом сидят (супер)профессионалы, а авиакомпании не могут положиться на Боинг и сказать, что самолэт умный, как-то разрулит…


      1. MarazmDed
        01.07.2019 22:33

        (супер)профессионалы,

        Супер — не требуется. За штурвалом должен сидеть профессионал. Достаточно, чтобы не супер. Но и не деревяшка, которая не знает своих прямых обязанностей. Никто от пилотов не требует сверхспособностей чтобы на скорости 850км/ч пролететь в узкой расщелине, как показывают в некоторых фильмах. Но, блин, мне не хочется садиться в самолет, понимая, что это игра в русскую рулетку.

        Но почему Боинг может закладываться, что за штурвалом сидят (супер)профессионалы

        Только из понимания, что единственное назначение пилота в кабине — парирование отказов.

        а авиакомпании не могут положиться на Боинг и сказать, что самолэт умный, как-то разрулит…

        А авиакомпании и полагаются на боинг. И говорят, что самолет умный и как-то разрулит. И разруливает, что самое интересное. Но — до поры до времени. Самолет буквально напичкан всевозможными системами обеспечения безопасности. Даже MCAS — одна из таких систем. Кто бы мог предположить, что в системе, единственное назначение которой — исправлять косяки пилотов, в ней самой есть косяк.


      1. DarkGenius
        03.07.2019 09:45
        -2

        В пилоты просто так не попасть. Вася с улицы не окажется за штурвалом. Так что там профессионалы по определению.


        1. tvr
          03.07.2019 10:54
          +2

          В ______ просто так не попасть. Вася с улицы не окажется за _______. Так что там профессионалы по определению.

          Это работает только в мире розовых пони, а в нашем реальном — не так давно за штурвалом небольшого пассажирского самолёта оказался человек, который вдруг решил самоубиться об гору. И как выяснилось — проблемы с психикой у него были давно. И ещё вопрос — вы разве сами не сталкивались с людьми у которых куча дипломов, регалий, пройденных курсов, немалый стаж — т.е. по идее ас из асов, профессионал, на котором пробу ставить негде, а по факту — ни в зуб ногой, хуже продвинутого джуна, из-за раздутого ЧСВ.


          1. DarkGenius
            03.07.2019 18:53

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

            Непонятно, за что заминусовали.


            1. akryukov
              03.07.2019 19:22

              Для пилотов тоже есть курсы, которые дают право летать на одноместном одномоторном самолете.
              Это примерно такой же уровень сложности, как и у программистов после курсов.


              1. DarkGenius
                03.07.2019 19:23

                И после таких курсов возьмут в гражданскую авиацию сразу?


        1. olsamurai
          03.07.2019 12:00

          Ну судя по всему они примерно такие же профессионалы, как и те программисты… Которым нужно все подробно разжевать, потом проконтролировать и еще 100 раз проверить и исправить. В чем я на 100% согласен с MarazmDed, так это в том, что большинству пилотов до профессионалов, как раком до Луны.


        1. boroda_el
          03.07.2019 18:49
          +1

          Распределение профессионалов там как и везде: отличные пилоты, средние пилоты, полные дауны. Первые обычно не попадают в сводки по происшествиям, ибо успевают понять что происходит и как это исправить. А вот про вторых и третьих можно узнать гораздо больше.

          Например, самолет пытается взлететь. Пробежал рассчитанное для взлета расстояние, но не влетает. Что-то не так? А хз, прибавь тяги. Тяга на полную, полоса уже вот-вот кончится, может подумаем почему не взлетаем? Нэт, жми! Самолет уже катится по траве, точно уже пора тягу уменьшать и попытаться остановиться. Ты что делаешь! Тягу вернул быстро!

          Три идиота угробили 40 человек.


        1. dimas
          03.07.2019 19:30

          Однако это не делает их идеальными, и там своих проблем хватает. Так, например, многие пишут про «проблемы операторов», что настолько привыкают в нормальных условиях выполнять взлет-автопилот-посадка, причем и посадку тоже порой автопилотом, что в нестандартных условиях не хватает опыта/реакции/и т.д. А времени достать мануал и чек-листы банально может не хватить.

          Почитайте того же Дениса Оканя.


          1. Rikkitik
            03.07.2019 19:46

            Автопилот вообще расслабляет:

            В опросе, проведенном профсоюзом пилотов BALPA (британская лётная ассоциация), более половины пилотов (56%) признались, что засыпали прямо в кабине, и почти треть опрошенных (29%) просыпаясь, обнаруживали, что второй пилот тоже спит.


            1. dimas
              03.07.2019 20:07

              Усыпляет, ага.

              У того же Ершова в «Исповеди ездового пса» есть как заснули все, хотя вроде как следили друг за другом…

              А Денокан, если правильно помню, описывает что в их АК, например, на эшелоне разрешен «контролируемый сон», когда в кабину приглашается кто-то из стюардов/стюардесс, и один из пилотов дремлет какое-то время. Потом второй.


    1. Alcpp
      01.07.2019 23:06

      «Ранее более 400 пилотов присоединились к коллективному иску против Boeing. Они обвиняют компанию в сокрытии конструктивных недостатков 737 MAX и требуют «миллионных компенсаций». Истцы указали, что после приостановки полетов лайнеров этой модели они пострадали от финансовых потерь и психических расстройств.»


      1. MarazmDed
        01.07.2019 23:37

        Они обвиняют компанию в сокрытии конструктивных недостатков 737 MAX

        Я это читал. Есть серьезные подозрения, что опять пилоты изнасиловали журналистов. Ну и потом, буквально на следующий день после катастрофы в индонезии, всем операторам было разослано письмо с разъяснениями от боинга.


    1. nikolayv81
      02.07.2019 00:05

      2я катастрофа, когда mcas включилась после взлёта, всё же есть мнение что не успели вручную открутить стаб (надо много и энергично) отрубив mcas по инструкции...


      1. MarazmDed
        02.07.2019 00:53
        +1

        всё же есть мнение что не успели вручную открутить стаб (надо много и энергично) отрубив mcas по инструкции...

        А есть мнение, что как только у них вылезло IAS disagree, незамедлительно следует выполнять чек-лист IAS unreliable. Если бы они его выполнили, то спокойно вернулись бы в аэропорт вылета. Т.е. ребята вообще ничего не делали в течении нескольких минут, пока у них стаб откручивался на пикирование, а когда наконец соизволили выключить электропривод, то уже ничего исправить было нельзя. Никто не знает, какого лешего они руками триммировать не пытались, как экипаж в Индонезии. Плюс у них разъяснение от боинга было. Прошляпать такое… Это просто вопиющий непрофессионализм. У них еще свежа в памяти индонезийская катастрофа должна была быть. Чегож они по полочкам ту катастрофу не разобрали?


        1. nikolayv81
          02.07.2019 10:01

          А в IAS unreliable выключается mcas?


          1. MarazmDed
            02.07.2019 10:36

            Выключается. IAS unreliable предусматривает выпуск закрылков. А выпущенные закрылки отрубают MCAS.


        1. nikolayv81
          02.07.2019 10:21

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


          1. MarazmDed
            03.07.2019 09:14
            +2

            Более того, единственное заявление которое сейчас удалось найти, это то что пилоты эфиопской авиакомпании следовали строго указаниям, но до сих пор нет (вроде как) официального отчёта,

            Пилоты вообще не следовали указаниям:
            1) Не было даже попытки выполнить airspeed unreliable. Как результат — не отключили автомат тяги. Как результат, набрали такую скорость, что руками стаб крутить бесполезно.
            2) Не пытались триммировать самолет. Несмотря на то, что со штурвала все прекрасно триммировалось. Как результат, MCAS спокойно открутил стаб на пикирование
            3) Когда MCAS закончил свою работу по максимальной перекладке стабилизатора. Пилоты догадались отключить электропривод стаба. А в письме от Боинга было указано, что перед отключением электропривода нужно оттриммировать самолет со штурвала, а то это может быть проблематичным.


        1. ggreminder
          03.07.2019 06:06
          -1

          Они пытались. 8 раз, кажется. Просто вручную трим перемещался почти незаметно, а как только они включали привод обратно чтобы «перебороть» MCAS через кнопку на штурвале, то оказывалось, что MCAS всегда успевает сделать больше и лучше.


          1. MarazmDed
            03.07.2019 06:18
            +2

            Это явно не так. Триммирование через кнопку на штурвале имеет приоритет над MCAS. Пока пилот триммирует самолет, MCAS отключается. После отпускания кнопок штурвала MCAS не работает еще 5сек. После чего включается в работу и проверяет выполнение условий. Т.е. пилот имеет возможность перевести стаб на кабрирование. А MCAS может перемещать стаб только порциями.
            MCAS делает больше и лучше всего по одной причине — пилоты забили на стаб.
            В случае с Индонезией, пилоты успешно боролись с MCAS, пока им это не надоело. Эфиопы вообще не пытались триммировать самолет. А когда очухались, выполнили инструкцию криво и загнали себя в ситуацию, из которой не смогли выбраться. Беда в том, что попадать в такую ситуацию не следовало.


  1. air_squirrel
    01.07.2019 13:13

    Вопрос как это потом сертифицировалось by FAA in acc with FAR21/25 plus Do-178B требованиями. Платить Боинг мог столько сколько хотел 9, 10, 5 баксов в час… Задача Aviation Authorities (Faa USA, EASA Eu ) через процесс разработки сертифицировать софт через жесткий контроль процесса его создания.


    1. JamboJet
      01.07.2019 16:57

      Так писалось выше: в некоторых разделах Боингу делегировали право самому себя проверять и сертифицировать.
      Естественно, под давлением менеджеров «давай давай» возникает соблазн срезать углы…


      1. air_squirrel
        01.07.2019 17:06

        Да у Боинга есть так называемая Design Organization Approval который дает право на определенные изменения давать approvals, причем дают это спец представители FAA(delegate engineers), которые независимые от менеджмента и отвечают своими sign offs головой.
        Не буду спорить что в любой ситуации виноват менеджмент :))


  1. Hakujin
    01.07.2019 13:22

    Обалдеть. А я со стажем с 2003го года, все еще считаю, что мой код слишком низок по уровню, для серьезных вещей.
    И, что самое страшное, непрофессионализм захватывает все больше и больше и все более серьезхные сферы жизнедеятельности. Куда мы катимся?


  1. NLO
    00.00.0000 00:00

    НЛО прилетело и опубликовало эту надпись здесь


  1. AlexAV1000
    01.07.2019 13:28

    Программное обеспечение для серии 737-Max было написано во времена, когда компания Боинг увольняла опытных инженеров и оказывала давление на поставщиков.

    Более того, икона американского самолетостроения и ее субподрядчики, доверяли временным работникам, зарабатывающим всего лишь $9 в час, разрабатывать и тестировать свое программное обеспечение. Зачастую, это были работники из стран с неразвитым самолетостроением, а именно из Индии.


    Ржали всей Индией.


  1. Alcpp
    01.07.2019 23:07

    Меж тем следствие запросило документы по сборке уже и 787.


  1. suicide_sky92
    02.07.2019 00:53
    -1

    Думаю было очевидно что после смерти великого инженера боинга mr.Hands, в этой конторе стали работать программисты-Индусы за еду.


    1. Samoglas
      02.07.2019 05:11
      -1

      Да, великий человек был, самоотверженный.
      А арабский жеребец — олицетворение родственников всех погибших по вине авиастроителей пассажиров Боингов.

      И нет, не ищите в Гугле файл mr.Hands.mpg, не сможете развидеть.
      И в Боингах летать будет ещё тяжелее, зная, какие во всю голову интересные личности их строят.

      Пиньян погиб за них за всех, инженеров Боинга, прошлых и, видимо, особенно будущих. Искупительная жертва.
      Вечная память.


  1. chabapok
    02.07.2019 09:41
    +1

    При нормально поставленном техпроцессе код для боинга версии N+1 получается из ~80% кода для боинга версии N, и ~20% нового кода.
    При этом, в той, части, где речь идет о функциональной безопасности, процент нового кода желательно чтобы был еще меньше. В идеале 0.

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


    1. svitoglad
      02.07.2019 11:26
      -1

      Может они решили заменить старые проверенные РС/104 на что-то другое. Это могло привести к глобальному изменению кода. Но даже при этом оно может пройти тесты и работать пока не «вылезет» в каком-то месте при эксплуатации.


  1. Urub
    02.07.2019 11:06
    +3

    > «Боинг делал всё возможное, всё, что вы только можете себе представить, чтобы сократить издержки»

    Урезать зарплату ТОП менеджерам? Нет, не могу себе представать.


  1. MSC6502
    02.07.2019 22:35
    -5

    Возникают вопросы: для чего нужны вообще самолёты в их нынешнем виде, где велик риск погибнуть от непрофессионализма пилотов, суперэффективных менеджеров, экономящих на всём и вся, конструкторских просчётов и недоработок, миллионов строк никогда и никем не проверенного кода, работающего в общем-то достаточно вероятностно и еще кучи факторов? Едем поездом или сидим дома. Мир велик, в каждом отдельном регионе вполне могут справиться своими силами.
    И всё таки, на чём написан софт этого Боинга? И зачем там «миллионы строк кода»? Шаттлы в качестве встроенных контроллеров использовали специализированные ЭВМ на ТТЛ микросхемах с производительностью 480 тыс. оп/сек. и памятью на магнитных колечках. И этого хватало для космических полётов. И там были не " миллионы строк код". Что же сейчас только и пишут, тут отказ, там отказ, заклинило, не переложилось, не повернулось и проч. Подозреваю, что нормально спроектированная система управления самолётом вполне может уложиться в вычислительные ресурсы чипов типа STM32 и с десятками-сотнями килобайт кода. Но настоящего, вылизанного до безумия и оптимизированного до последнего бита. Причём ручками, ручками, а не «оптимизирующими» компиляторами, которые «оптимизируют» всё, кроме безопасности пассажиров.


    1. Whuthering
      02.07.2019 23:22
      +3

      Возникают вопросы: для чего нужны вообще автомобили и автобусы в их нынешнем виде, где велик риск погибнуть от непрофессионализма водителей, суперэффективных менеджеров, экономящих на всём и вся, конструкторских просчётов и недоработок, тысяч строк никогда и никем не проверенного кода, работающего в общем-то достаточно вероятностно, уймы различных деталей и агрегатов, сконструированных непонятно кем и как, и еще кучи факторов? Идём пешком или сидим дома. Город велик, в каждом отдельном его квартале или районе люди вполне могут справиться своими силами, свободного времени у нас неограниченное количество, общаться будем только с соседями по этажу, отдыхать во дворе, да и вообще, где родился там и пригодился...


      1. MSC6502
        03.07.2019 23:55
        -1

        Ну вот, с ненужностью автомобилей вы согласны. А там и остальные «достижения» современной так называемой «цивилизации» можно будет пересмотреть и отправить на свалку.


  1. nk11k
    03.07.2019 10:39

    Смотрел ещё давно это видео (2016-го года), рассказывали про то, как они используют Clojure для разработки 737 Max: www.youtube.com/watch?v=iUC7noGU1mQ

    Что изменилось с тех пор? Неужели всю команду инженеров заменили на аутсорс?