Где мой летающий автомобиль?
Если вы работаете в сфере технологий, то, скорее всего, слышали о современной Великой Стагнации. В 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. Попробуйте как можно быстрее!
