У традиционных инженерных проектов есть проблема, о которой никто не говорит

Original author: Arnaud Doko
  • Translation


Где мой летающий автомобиль?


Если вы работаете в сфере технологий, то, скорее всего, слышали о современной Великой Стагнации. В 1970-х случилось нечто, после чего мир битов начал доминировать над всем технологическим прогрессом, в то время как мир атомов остался лежать в забвении. Питер Тиль, Тайлер Ковен и другие как-то произнесли знаменитую фразу:

"Мы мечтали о летающих автомобилях, а получили 140 символов."

Но правы ли они? Приведём пример: в свои ранние годы Instagram оценивался примерно в 1 миллиард долларов (на момент приобретения приложения компанией Facebook в 2012 году), имея в штате всего 6 инженеров по разработке ПО. Для контраста сравним его с более традиционной конструкторской компанией из мира атомов, например, с Rolls Royce: в 2018 году в её штате было примерно 17 тысяч инженеров из разных дисциплин (в основном не программных!), но её рыночная капитализация составляла около 27 миллиардов долларов.

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


На фондовом рынке мир битов (FAAANM) тоже доминирует над миром атомов (большинством остальных компаний).

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

Как мы попали в эту ситуацию?


И в самом деле — чем вызван огромный разрыв в производительности между проектированием ПО и непрограммным проектированием? Мы видим две основные причины:

  1. Более строгое регулирование.‍ Непрограммное проектирование значительно сильнее зарегулировано. Стандартов, регулирующих проектирование самолёта, больше, чем регулирующих разработку приложения для доставки еды. И это хорошо. Однако коллективам непрограммных инженеров приходится усваивать эту дополнительную нагрузку по соответствию требованиям. А тем временем по всему миру усиливаются тенденции по расширению регулирования.
  2. Программное обеспечение — уникальная сфера. Ключевое отличие между программной и непрограммной разработкой — стоимость производства. Когда продукт существует не в атомах, а в битах, стоимость разработки сложных систем относительно низка.

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

Похоже, эта проблема не нова, наверняка её уже кто-то решил?


И да, и нет.

Сегодня существует множество инструментов для управления данными непрограммной разработки и для снижения трудозатрат на обеспечение соответствия требованиям. Среди зарекомендовавших себя на рынке игроков такие компании, как Siemens, Autodesk и другие. По сути, это системы на основе баз данных, предназначенные для решения проблемы в форме базы данных. Такое семейство инструментов обычно называют Product Data Management (PDM), или в более общем смысле Product Lifecycle Management (PLM).

Что же не так с системами PDM/PLM?


Хороший вопрос. Снаружи на него ответить не получится. Но работая в инженерных компаниях, использующих PDM/PLM, вы заметите нечто странное. Вы увидите, что коллективы инженеров стремятся избегать пользоваться своими PDM/PLM на самых ранних стадиях проекта.

Почему? Эта ранняя стадия проекта хорошо изучена и имеет собственное название: «размытый передний край» (Fuzzy Front End, FFE). Это наиболее размытая стадия проекта, на которой требования в основном не определены, а разрабатываемые инженерами решения часто меняются. И обычно она находится на грани хаоса.

Давайте приведём несколько примеров того, чем могут заниматься инженеры на FFE:

  • Полностью избегать PDM/PLM и хранить файлы в облаке (например, в GDrive или Dropbox), вручную обеспечивая контроль версий через названия файлов.
  • Фотографировать белую доску с коллективными заметками на свой телефон, а затем отправлять её команде проекта по почте или в Slack. Затем, спустя несколько дней, путаться в том, на какой из фотографий последняя принятая версия проекта.
  • Искать во входящих список последних требований клиента в файле .pdf или .ppt. Возможно, он есть у коллеги, надо скорее позвонить ему!

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

Для всего вышеперечисленного требуется, чтобы данные, попадающие PDM/PLM, были жёсткими и медленно меняющимися после попадания в систему. Это совершенно противоположно природе работы, проводимой инженерами на этапе FFE. Инженерные коллективы по большей мере демонстрируют свои предпочтения, намеренно обходя PDM/PLM на этапе FFE. Они голосуют ногами, показывая, что эти системы не рассчитаны на такой способ применения. Сегодня ни одно из предложений на рынке не отвечает требованиям FFE.


Жизнь на размытом переднем крае: поставщикам PDM/PLM не удалось удовлетворить требованиям инженерных коллективов на самой ранней, гибкой и влияющей на результат стадии инженерных проектов.

Что же происходит вместо этого?


В условиях отсутствия подходящих технологий возникает две стратегии:

  1. Вбросить больше человеко-часов на решение задачи: многие инженерные компании справляются с хаосом FFE, нанимая команды руководителей проектов. Эти руководители вручную обеспечивают целостность данных в системах PDM/PLM и дисциплину коллектива в управлении данными. Это затратный способ решения проблемы. Для мелких компаний это роскошь, которую они не могут себе позволить.
  2. Положиться на организационные процессы: в некоторых случаях ответственные за проект сдаются и смиряются с тем, что на этапе FFE придётся обладать минимальной видимостью, контролем и отчётностью. Особенно справедливо это для крупных организаций с тысячами сотрудников. Ответственные за проект сотрудники для принятия решений ожидают наступления естественных контрольных точек в водопадном стиле процесса разработки.

Обычно такой контрольной точкой становится первый анализ проекта (Design Review). Это совещание с дедлайном, к котором все данные проекта должны быть актуальными и готовыми для анализа. На практике инженерные коллективы неделями или месяцами работают вне PDM/PLM, а затем, за неделю до Design Review, в спешке подготавливают всё для дедлайна.

Ну да, в начале всё немного хаотично, но это нормально, разве это проблема?


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

Вас бы поразил объём критически важных технических данных для непрограммных инженерных проектов, хранимых в неподходящих для этого местах. Они находятся в блокнотах, на распечатанных чертежах, в почтовых входящих в виде вложений, в сообщениях каналов Slack/Teams, оставленных месяц назад, или на фотографиях в личных телефонах инженеров. На этапе FFE обычно очень сложно понять, что происходит в реальном времени, неделя за неделей. Любой опытный руководитель проекта из крупной инженерной организации скажет вам то же самое.

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


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

Отлично, но как тогда нам подходить к реализации FFE?


Наша компания Thea заинтересована оказывать непрограммным инженерам помощь в управлении и ранними стадиями проекта, и их конечным результатом: спецификацией. Проект и спецификация растут параллельно, в структуре, напоминающей граф. В программах CAD эта структура называется feature-tree. Постепенно структура расширяется, её узлы изменяются, а рёбра меняют связи. Если инженеры будут чётче видеть эту структуру в реальном времени, то это поможет им лучше оценивать качество, стоимость и график проекта. Благодаря этому больше не придётся в последнюю минуту устранять ошибки, допущенные на ранних этапах.

Если вкратце, то мы видим миссию своей компании так:

Thea снижает неопределённость ранних этапов непрограммных инженерных проектов на устоявшихся регулируемых нормами рынках.

Замечательно, но каково ваше решение?


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

Наш основной план:

Начинать с более качественных инструментов

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

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

Каким будет развитие Thea на протяжении следующих 15 лет? Мы стремимся к тому, чтобы в будущем Thea, работая в фоновом режиме, улавливала формат и структуру любых непрограммных инженерных проектов в реальном времени. Благодаря этому инженерам больше никогда не понадобится уделять своё внимание поиску данных или их самостоятельному вводу. Thea будет своего рода автоматизированным инженерным стенографом.

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



На правах рекламы


Эпичные серверы — это надёжные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрой файловой системой, используем исключительно NVMe диски от Intel. Попробуйте как можно быстрее!

VDSina.ru
Серверы в Москве и Амстердаме

Comments 22

    +18

    Прекрасно, пресс-релиз перевели чтобы использовать как контент для рекламы совсем другой фирмы

    • UFO just landed and posted this here
        +5
        В инстаграме не инженеры стоили миллиард, а сервис, заполнивший нишу + обширная база пользователей. Чего не скажешь о Роллс Ройс
          0
          >> Почему «атомы» торгуются в десятки раз ниже чем «биты»?

          Когда отрасль появляется она и торгуется в десятки раз выше чем остальные. А потом она превращается в «сток» — как автомобили с ДВС, как электродвигатели до того и как ещё перед этим паровые двигатели и ткацкие станки.
          • UFO just landed and posted this here
              +3
              Извините, но реклама софтового решения для реального сектора с обзором проблемы софта и реального сектора — верх цинизма :)
                0
                Вообще-то мне понравилась идея: инженер делает фотку прототипа, рисует на ней пару стрелочек и подписывает: вот эту хрень надо подвинуть в эту сторону на 5мм, и отсылает в слак или почту. А корпоративный ИИ сам распознает указание, поднимает документацию и вносит требуемые изменения в соответствии со всеми стандартами (что человекам делать ну очень влом). Ну и отчет о внесенных изменениях — автору сообщения. Тогда проблема, описанная в статье, либо сильно уменьшится, либо вообще исчезнет.
                +2
                Вообще ничего не понял. В каждом Rolls Royce строк кода больше, чем во всём Инстаграме, плюс работа над созданием ПО для, условно, клапана ЕГР требует очевидно большей квалификации по сравнению с добавлением восьмой сотни стикеров и анимированных сердечек в личные сообщения — и потому лучше оплачивается. Каким надмозгом из этого сделан вывод о «катастрофическом выборе» более выгодной в финансовом плане карьеры? Причём тут компания Thea, убогая настолько, что строит какие-то совершенно нелепые пятнадцатилетние планы, не имея в портфеле ни одного патента? На каком основании Instagram с нулевой рыночной капитализацией сравнивается с компанией, рыночная капитализация которой двадцать семь миллиардов долларов?
                  0
                  Забыли про одну важную вещь — ответственность. Сравните ответственность разработчика игрового двигателя и самолётного двигателя.
                    0
                    Ну вообще-то в производственных фирмах эти проблемы решаются написанием Технических требований по заказу клиента, а потом Технического задания на основе Требований. Ну и контролем изменений в этих документах, инструментов для этого уж достаточно. Либо я ничего не понял, либо в статье все притянуто за уши.
                      0
                      Картинка ни о чём: такие ворота сделаны чтобы автомобили не заезжали и они не заезжают.
                        0
                        Нет это как раз велосипедные тормоза. Они тут повсюду. Бесят страшно.
                          0
                          Для автомобилей было бы достаточно одного столбика или полусферы побольше.
                          Нет, это было сделано для велосипедистов. Что, впрочем, судя по картинке, им не особо помешало.
                          0
                          Когда продукт существует не в атомах, а в битах, стоимость разработки сложных систем относительно низка.
                          хаха, нет уж, стоимость цифровой разработки не ниже. Основная разница в стоимости масштабирования — облачный сервис на миллион пользователей можно расширить вдвое хоть за день, а вот построить второй завод за день ну никак не получится.
                            0
                            Я вот тот самый инженер железячник, который десятками делает проекты разной степени сложности (от 10 до 2000-3000 уникальных деталей). И из статья ну ни болта не понятно, как же этот чудесный софт поженится с закрытыми форматами САПР? Как он залезет в файл и поймет что же именно изменили в данной редакции?
                            Чего для все эти новомодные навороты, если и Slack, и Teams очень редко применяются где-то за пределами самодеятельных групп из 5-10 инженеров? А там где инженеров хотя бы больше двух все делается в соответствии с ТЗ, которое как живой организм проходит разные стадии развития от зародыша, до зрелого монстра, описывающего все-все-все в продукте. И чего для еще одна сущность вне пространства управления инженерными данными, если в большинстве PDM и PLM есть масса инструментов для этого?
                              0
                              Нашел ссылку на упоминаемую софтину:
                              www.theaportal.com
                              Все стало понятно. Это стартап из полутора хипстеров. Революции не будет. Расходимся.
                              0
                              любая инженерная дисциплина (допустим, машиностроение, химические технологии или ядерная энергетика), за исключением компьютерной является катастрофическим выбором карьеры

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

                                В программной индустрии это сплошь и рядом — системы управления изменениями например. Не версиями, а именно изменениями. Типа на эту машинку накатить новуюверсию… а вот получи форму о 100 полях, лид тайм в неделю и 20 подписей в кулёк. Решает она одну задачу — прикрыть зад от аудита (смотрите у нас все как у больших). Точнее две — там еще человек 100 чейндж менеджмента кормится.
                                  0

                                  А можно вот по меньше ваших новшеств и новых программ и ваших классных новых интерфейсов?
                                  Если руководитель не идиот, то он грамотно ОБЪЯСНИТ и СОЗДАСТ окружение для грамотного хранения данных даже на базе файловой системы.


                                  Потом есть еще системы контроля версий.


                                  И все это для промежуточных исследований/разработок. А коммитить уже надо в PDM.


                                  Работать из PDM тоже довольно не понятно… например я хочу проверить одну вещь, мне надо создать копию мой 3д модели, часть данных взять из других мест и т.д. Ок, я могу сделать все это в PDM, но что если я такое делаю часто? Я также быстро и легко засру этот PDM как и свой комп. + меня будет раздражать, что на своем компе я не буду ждать пока там чето с сервера скачается и на него закачается.


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


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


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

                                    0
                                    Нужно задать важный вопрос: почему инженеры-разработчики ПО производят на два порядка большую выгоду, чем инженер, не создающий программы?


                                    Встает вопрос, откуда такой вывод. В упомянутом примере с Instagram и Rolls Royce речь идет о капитализации, которая отнюдь не обязательно пропорциональна прибыли. Но дело даже не в этом. Instagram не существует сам по себе. Он обязан существованием непрерывной работе огромного числа сетевых инженеров, администраторов, рабочих и монтажников непрерывно поддерживающих сеть в работоспособном состоянии; инженерам, разработавшим по на клиентских устройствах и т.д. Почему их труд не учитывается в приведенной оценке? Автомобиль может проехать, пусть и медленно, по заброшенной дороге. Instagram по выключенной сети не заработает.
                                      0
                                      Некорректное сравнение. И та, и та инфраструктура поддерживается. Сеть с оплаты операторам связи, дороги с налогов. Зачем еще и это считать? В текущих условия — инстаграм самостоятелен. Он не платит за эту инфраструктуру. Дороги и сеть одно и тоже считайте — пользование не бесплатно, за эти деньги их поддерживают. Их используют много фирм-конкурентов и много людей.
                                      Он обязан существованием непрерывной работе огромного числа сетевых инженеров, администраторов, рабочих и монтажников непрерывно поддерживающих сеть в работоспособном состоянии; инженерам, разработавшим по на клиентских устройствах и т.д.

                                      А Rolls Royce обязан работе дорожникам, ГИБДД, ДПС, инженерам, разработавшим по для камер/светофров?
                                      Конечно ответ да на оба вопроса, но как это связанно с «Почему их труд не учитывается в приведенной оценке?»?
                                      Instagram по выключенной сети не заработает.

                                      Машины без дорог тоже некто покупать не будут, разве что трактора.

                                      В упомянутом примере с Instagram и Rolls Royce речь идет о капитализации, которая отнюдь не обязательно пропорциональна прибыли.

                                      Абсолютно согласен. Капитализация это лишь ожидания инвесторов.

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

                                    Only users with full accounts can post comments. Log in, please.