Инженерия и наука: инженерия не научна.
К спорам о научности или ненаучности инженерии -- фрагмент из моего учебника (версия апреля 2015 года, полный учебник лежит тут: http://techinvestlab.ru/systems_engineering_thinking). Сейчас я бы кое-что в этом материале переписал (скажем, добавил бы явно кусочки из Латура и прочих из STS, подробней разобрал пример инженерии машинного обучения из доклада http://ailev.livejournal.com/1245043.html, точнее прописал бы про учёных как owner/operators экспериментальных установок и инженеров как разработчиков и строителей этих установок), но пусть уж будет версия из учебника без обновлений и изменений. Продолжение рассказа (а именно, раскрытие тезиса "инженерия научна") идёт следующим постом, http://ailev.livejournal.com/1247553.html.
3. Инженерия и наука
Системноинженерное мышление и деятельность - как нам их описать?! Их ведь нельзя пощупать, нельзя наглядно продемонстрировать. Если попробовать пронаблюдать, что делает инженер - он спокойно сидит на стуле и кликает время от времени кнопками мышки. Или спокойно стоит и смотрит на приборы сложной установки, иногда крутит какие-то ручки и нажимает какие-то кнопки. И в то же время понятно, что его мышление и деятельность отличаются от мышления и деятельности пианиста, который тоже спокойно сидит на стуле и кликает время от времени кнопками рояля.
Наша книга о способах мышления и способах действия. Для начала нам нужно найти способы, которыми мы будем описывать мышление и действие.
Инженерия занимается изменением реальности - двигает горы, создаёт спички и зажигалки, строит марсоходы и медицинские роботы Да Винчи. Пространство-время физического мира были устроены одним способом, пришли инженеры, пространство-время стало устроено по-другому.
Производством компактных описаний реальности занимается наука - придумывает диаграммы Фейнмана, теории мышления, понятия системы и деятельности. Пространство-время думали, что устроено одним способом, пришли учёные, пространство-время теперь думают, что устроено другим способом.
Обучить науке - это обучить тому, как строить компактные и понятные людям описания того, как устроен мир. Например, 4 уравнения Максвелла описывают все электромагнитные явления мира, а уравнение Шрёдингера описывает волновые функции элементарных частиц. Можно ли “выучить на учёного” - это отдельный вопрос, мы его тут не будем рассматривать.
Но для начала нам придётся заняться инженерной наукой: попытками компактно описать то, что делают лучшие инженеры мира.
Тут нужно учитывать, что само понимание того, что такое наука, исследования, инженерия непрерывно меняется, чуть ли не каждый десяток лет. Интересующиеся могут ориентироваться на следующую последовательность ключевых работ по истории и философии науки (подборка Антона Николаенко, https://www.facebook.com/nikolaenko.anton.9/posts/761402053939232): в 1934 Поппер выпускает свою "Логику научного исследования",
в 1935 Флек публикует "Возникновение и развитие научного факта",
в 1937 Мертон - работу "Наука и социальный порядок",
в 1946 Полани - книгу "Наука, вера и общество",
в 1962 Кун - свою "Структуру научных революций",
в 1971 Бен-Дэвид - свою "Роль ученого в обществе",
в 1972 Тулмин - работу "Человеческое понимание",
в 1975 Фейерабенд - свою книгу "Против метода",
в 1976 Блур - свою "сильную" программу - книгу "Знание и социальное представление",
в 1978 Лакатос - свою "Методологию научно-исследовательских программ",
в 1978 Хюбнер - свою "Критику научного разума",
в 1979 Латур - свою "Лабораторную жизнь",
в 1979 Малкей - свою работу "Наука и социология знания",
в 1998 Шейпин - свою "Научную революцию",
в 1998 Коллинз - свою "Социологию философий",
в 2008 Деар - свою книгу «Событие революции в науке".
Всё из перечисленного переведено целиком на русский язык.
Инженерия не научна
Разница между инженерами и учёными
Нельзя путать инженеров и учёных. Учёные ровно обратны инженерам: если инженеры делают реальные материальные вещи, опираясь на мысль, то учёные делают мысли из реальности - получают компактные, понятные и формальные описания действительности. Конечно, инженерия и исследования тесно связаны:
● когда инженер получает инженерный объект, поведение которого не отвечает его замыслу, он исследует проблему: пытается найти наиболее компактное описание работы этой инженерной системы, из которого было бы понятно, в чём он ошибся при замысле и его воплощении. Затем исправляет ошибку: меняет систему.
● когда учёный придумывает новый способ описания, более компактный и лучше объясняющий мир, чем предыдущие способы, то он проводит эксперименты. Отнюдь не все эксперименты “мысленные”. Некоторые из них требуют создания весьма и весьма сложных инженерных объектов (например, ускорители - это одни из самых сложных на Земле инженерных объектов). Когда эксперимент проведён, учёные корректируют свои теории в зависимости от результатов эксперимента.
Тем самым инженерная и исследовательская деятельности оказываются связаны в цикл, и в каждом исследовательском или инженерном проекте обычно приходится много раз повторять цикл:
Главное тут - цель объемлющей деятельности, а не собственно сама работа “исследований” или “разработки” (“науки” или “инженерии”): целью является либо появление какой-то материальной системы, приносящей пользу пользователям, либо появление какого-то компактного описания/объяснения того, как устроен мир. В любом случае, либо инженерия оказывается спрятана в исследованиях, либо исследования спрятаны в инженерии.
Эта путаница, отражающая связь инженерии и науки, весьма распространена:
● В большинстве мультфильмов “учёный” в белом халате меньше всего учёный, это “инженер-изобретатель”. Эти якобы “учёные” не ставят эксперименты: они придумывают какие-то необходимые для их целей системы, и воплощают эти системы в реальности. Это “лаборатории Эдисона”.
● “Прикладная наука” (applied research, прикладные исследования) тоже меньше всего наука, несмотря на слово “исследования”. Никаких “теорий” от этой науки ожидать не приходится, а результаты НИОКР (научных и опытно-конструкторских разработок) как правило - вполне себе инженерные объекты, а не способы описаний. Единственная их разница с результатами классической инженерной разработки, так это то, что результатом является прототип или опытный образец, а не идущий потребителю продукт (между “работающим прототипом” и “выпускаемым продуктом” могут быть годы и годы разработки, development - и результатом являются не “изобретения”, а “инновации”, определяемые как успешно выведенные на рынок изобретения).
● Очень часто прикладные исследования (research) и классическую разработку вообще не разделяют, отсюда устойчивое сокращение R&D (research and development). Есть ли разница? Есть: “лаборатория Эдисона” (лаборатория Bell Labs, лаборатория IBM и т.д.) всё-таки отличаются существенно по организации труда и проходящим в них работам от классической инженерной разработки. Но они не отличаются принципиально! Менеджментом R&D как раз и занимается technology and innovation management.
Настоящая наука - это “basic research”, которые ведутся в “лабораториях Эйнштейна”. На выходе не “опытные образцы” (inventions, “изобретения”, прототипы систем и идеи для этих прототипов), а теории - компактные и формальные описания природы. В отличие от R&D менеджмент и финансирование науки происходят совершенно другим образом, часто они происходят вообще вне рамок предприятий.
Системная инженерия - это тоже инженерия, не наука. Системная инженерия вполне может включать R&D, изобретения, создание прототипов.
Ещё одна связь науки и инженерии - это конструирование экспериментальных установок, в какой-то мере создание инженерных прототипов может быть отнесено к научным исследованиям (хотя речь может идти не о подтверждении научной теории, а подтверждении какой-то догадки или замеченной эвристики).
Если мы хотим создать формальное компактное описание самой системной инженерии - то это наука, “инженерная наука” (engineering science).
Предмет инженерии и научные предметы для инженерных объектов
Нужно различать предмет самой инженерии (engineering) и предметы, изучающие объекты инженерии - механику, электрику, компьютерную науку и т.д. Инженерия (в том числе системная инженерия) описывает то, как работают инженеры. Инженерная наука (engineering science) даёт описание того, что делают люди в инженерном проекте. Другие предметы и другие науки описывают поведение инженерных объектов, то, как работают они: механические устройства, электрические схемы, компьютерные программы.
Наиболее просто понять разницу между такой “наукой про инженерный объект” и самой инженерией можно на примере computer science (компьютерной науки) и software engineering (программной инженерии). В блоге http://gaperton.livejournal.com/ была замечательная история, как его автор, отличник по computer science, пошёл после ВУЗа покорять иностранную софтверную компанию. Но там ему буквально за два дня объяснили, что он (может быть) умеет программировать, но совершенно точно не умеет работать: нужно было разбираться с тем, как составляются требования, писать нужно было не столько какой-то хитрый алгоритм, сколько заплатку к уже написанному коду на миллион строк, и нужное место для заплатки в этом коде нужно было как-то найти, кроме этого нужно было разобраться в управлении конфигурацией (версионированием), системой управления изменениями, наладить отношения с менеджерами и тестировщиками, понять суть принятой в проекте методологии разработки и т.д. - при этом ничему этому в ВУЗе не учили. Работа оказалась совсем не тем, чему учили: огромное количество времени уходит на общение с коллегами, а не на “думание”, время решения задачи не “сколько нужно”, а “сколько отведено графиком”. Учили computer science (ключевые слова: алгоритм, оценка скорости выполнения алгоритма, нотация, грамматика, реляционная модель данных) и не учили software engineering (ключевые слова: требования, архитектура, тестирование, изменения, сопровождение). Точно так же инженера-механика могут научить работать с прочностью, формой, скоростями, трением с использованием всяческих теорий, но могут не научить работать с требованиями, архитектурой, испытаниями и инженерными обоснованиями. Именно поэтому хороший физик может быть хорошим специалистом по сопротивлению материалов, но не быть хорошим инженером - у него знания про инженерные объекты, но не про саму инженерию.
Обучить инженерному делу как таковому - это обучить тому, как устроен ход инженерной разработки, какие основные понятия предметной области самой инженерии (а не предметной области, описывающей физику и алгоритмику создаваемого инженерного объекта): как устроен инженерный проект в целом и как разворачивается во времени проектирование/конструирование/программирование, изготовление и разворачивание целевой системы, а не только как устроена создаваемая система.
Ненаучность инженерии. Эвристики
Знания самой инженерии (как что-то сделать) и знания об инженерных объектах (установках, сооружениях, транспортных средствах, компьютерах и т.д.) могут быть как научными, так и ненаучными. Инженерия рождается и живёт методом проб и ошибок, её знания, передающиеся из проекта в проект про неё саму (как что-то сделать) и про её инженерные объекты вовсе необязательно “научны”. Так что определения инженерии как “принесение научных знаний в практику” просто неверно, хотя наука и используется там, где она есть.
В книге Discussion of the Method [http://bookzz.org/book/1244348/d69dbc] исследователь инженерии Billy Koen приводил пример: если бы в средние века к инженеру пришли с просьбой построить мост, а он бы отказался на основании того, что сопромат изобретут только через 200 лет - что можно сказать о таком инженере? Или если бы современный инженер при просьбе построить ракету, летящую на Луну или Марс, отказался бы от проекта на основании того, что достаточно подробной “теории Луны” или “теории Марса” ещё не создано? Или при необходимости создать робота инженер вдруг говорит, что “теории о том, что делать, чтобы создавать робота пока нет - поэтому я не знаю, что в каком порядке делать, поэтому подождём до тех пор, пока у учёных не появится соответствующего раздела инженерной теории”. Отказы на таких основаниях не свойственны инженерам, их не останавливает отсутствие научного знания в том, чем они занимаются.
Billy Koen (http://www.me.utexas.edu/directory/faculty/koen/billy/41/)
Инженерия кроме научных теорий активно использует эвристики (heuristics) - это догадки о закономерностях, которые вовсе необязательно “научны” в традиционном смысле этого слова, т.е. это не “фальсифицируемая теория” по Попперу: инженер с самого начала знает, что эвристики вполне могут быть в его случае ошибочны и неприменимы. Плюс обратите внимание, что инженерные эвристики определяются отличным образом от философской “эвристики”, найдите соответствующую литературу сами). Вот примеры инженерных эвристик:
Из Turton, Richard, et al. (2003) Analysis, Synthesis, and Design of Chemical Processes, Upper Saddle River, NJ: Prentice Hall.:
● Используй вертикальный резервуар на опорах, когда его объем меньше 3.8м3
● Используй горизонтальный резервуар на бетонных опорах, когда его объем между 3.8 и 38м3
● Используй вертикальный резервуар на бетонных опорах, когда его объем больше 38м3
Большая подборка подобных эвристик для инженерии химических производств дана тут: http://people.clarkson.edu/~wwilcox/Design/heurist.pdf
На эту тему есть хороший анекдот: Физику, математику и инженеру дали задание найти объём красного резинового мячика. Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости. Математик измерил диаметр мяча и рассчитал тройной интеграл. Инженер достал из стола свою “Таблицу объёмов красных резиновых мячей” и нашёл нужное значение.
Есть и другие типы инженерных эвристик, совсем не связанных с инженерными расчётами и приёмами конструирования-проектирования:
● Стейкхолдеров всегда на один больше, чем вы знаете; известные вам стейкхолдеры всегда имеют потребность (need) на одну больше, чем вам известно (это шестая из основных инженерных эвристик Tom Glib, http://www.gilb.com/dl97).
● Порядок бьёт класс (в больших проектах упорядоченная работа команды заурядных специалистов бьёт беспорядочную работу высококлассных звёзд).
Тем не менее наука и инженерия тесно связаны: эвристики в более простых системах заменяются научными теориями, в том числе в виде компьютерных моделей (разница: правильно применённая теория даёт надёжный ответ, а эвристика, возможно, врёт), а место для метода проб и ошибок смещается в сторону более сложных систем, которые плохо описываются наличными научными теориями.
Формальные (теоретические, следующие законам логики, а не чисто эвристические - хотя и те и другие могут быть подтверждены экспериментами) описания инженерных систем позволяют проводить формальный анализ: находить ошибки без создания системы, а часто и вычислять необходимые или оптимальные характеристики системы. Очень дорогой метод проб и ошибок с его бесконечным циклом догадок и экспериментов при помощи формальных описаний превращается в совсем другой метод работы, число проб становится в разы и разы меньше. Источником же полезных формализмов (методов описаний самых разных феноменов) является как раз наука. Число формализов растёт, число найденных эвристик тоже растёт, поэтому со временем растёт и уровень инженерии.
В связи с этим любые достижения в инженерии по предложению Billy Koen нужно оценивать не по абсолютной шкале, а на конкретный момент времени, в соответствии с накопленным на этот момент объёмом научного и эвристического инженерного знания - и это “текущее состояние инженерии” Billy Koen предложил называть SoTA (state-of-the-art). Инженерный проект плох, ежели он не использует всей полноты научного и эвристического знания, накопленного на конкретный момент времени. Со временем объем знаний растёт, и инженерные проекты становятся более и более сложными, достигая невозможных для предыдущего времени характеристик.
Наука как “научение птиц полёту”
Существует мнение, что наука для практической деятельности бесполезна. Практики добиваются успеха не на основе научных знаний, а на основе “возни” (tinkering, ср. “He is tinkering with a car” - “он возится с автомобилем”).
Эта точка зрения была развёрнута в книге Насима Талеба “Антихрупкость”. Он сравнивает учёных с теми, кто приходит к птицам и пытается научить их летать, давая знания по аэродинамике. Типичное высказывание в его книге на эту тему: “Никто не опасается, что ребенок, понятия не имеющий о разных теоремах из области аэродинамики и не способный решить уравнение движения, не сможет ездить на велосипеде”. Он защищает метод проб и ошибок, защищает эвристики. Он абсолютно прав. И он прав, когда пишет о создании реактивных двигателей: сначала было много проб и ошибок, потом только появилась теория, а не наоборот.
Тем не менее, исследования дают нам способ думать по-новому: осознанней, быстрее и надёжнее. Но не так, чтобы исследования вообще позволяли нам думать. Думаем мы и без них, но спонтанно, медленно и не слишком надёжно. Метод проб и ошибок всем хорош, кроме того что чрезвычайно дорог и долог. Если есть способ что-то физическое коротко описать, а потом работать с этим описанием-моделью, а не с самим физическим объектом, то так и нужно делать. Если вы учите ребёнка ездить на велосипеде, то вам особой науки не нужно. А если вы учите компьютер быть автопилотом на реактивном самолёте, то незамутнённым наукой методом проб и ошибок вы загубите слишком много реактивных самолётов.
Ещё один аргумент в пользу науки и компактных описаний появляется, когда вы замечаете, что в книжках Талеба ничего не говорится о коллективной работе. Когда речь идёт не о рынке, где “дальнее взаимодействие” (никто друг друга не знает, сделки между незнакомыми людьми) и где хорошо работают рассуждения Талеба, а когда мы хотим хорошее мышление передать кому-то другому, но не понимаем, из чего это мышление состоит, что передавать. Охота и собирательство талантливых людей хороши, но переход к осёдлому земледелию даёт скачок в производительности труда - выращивать талантов дешевле, чем их выискивать.
Так что сначала нам нужна какая-то наука, чтобы инженерные знания компактно описать - и уже после этого мы их можем передать.
Ещё один аспект инженерной работы - она не делается одиночками. Нужна координация усилий сотен, тысяч и даже десятков тысяч людей. Все эти люди должны как-то договариваться между собой. Как они могут договориться, если каждый про свою часть дела может рассказать примерно столько же, сколько едущий на велосипеде мальчик про свою езду “я чувствую, что я держу равновесие и я чувствую, что на большой скорости надо бы пригнуться”? Компактные описания нам нужны, чтобы люди могли иметь одинаковое описание того, что они делают, чтобы не возникло проблемы строительства Вавилонской башни.
Излагаемый в нашей книге подход к системноинженерному мышлению и действию совершенно необязателен для инженеров-одиночек, среди одиночек всегда найдётся Кулибин или Левша. Но вот если речь пойдёт о какой-то более-менее масштабной коллективной инженерной деятельности, то синхронизация способов обсуждения проекта может сэкономить много-много времени - все ведь помнят проблему, возникшую при строительстве Вавилонской башни? Мы должны научиться описывать другим людям, что мы делаем и почему, чтобы другие люди могли к нам присоединиться.
Конечно, уметь что-то описывать и в инженерии, и в менеджменте (и даже в литературе) вовсе не означает то, что вы опишете что-то ценное и важное. Графоманам никогда не получить Букеровскую премию, хотя они умеют писать. Научиться думать об архитектуре или проектном предложении, научиться компактно “по науке” записывать свои мысли вовсе не означает, что вы что-то придумаете интересное. “Думать и придумать” в этом плане похожи на “учить и выучить”, “делать и сделать” - процесс ничто, результат всё. Но если не думать, то и не придумаешь. Если не учить, то и не выучишь. Если не делать, то и не сделаешь. Процесс важен, без него не будет результата.
Так что для начала нам нужна инженерная наука (engineering science), хотя мы точно знаем, что инженерия (”инжиниринг”, как сейчас всё чаще говорят) - это не наука. Но нам нужны компактные описания инженерии и менеджмента как минимум для того, чтобы договариваться об инженерии и менеджменте с другими людьми.
И нам нужна наука о мышлении, хотя мы точно знаем, что само мышление - это не наука. Но нам нужны компактные описания мышления, чтобы договариваться о них с другими людьми, чтобы реализовать коллективное мышление. Построить такую ракету, чтобы она долетела до Марса или даже крошечной по космическим меркам кометы - для этого метода проб и ошибок явно недостаточно, но системные инженеры строить такие ракеты научились.
3. Инженерия и наука
Системноинженерное мышление и деятельность - как нам их описать?! Их ведь нельзя пощупать, нельзя наглядно продемонстрировать. Если попробовать пронаблюдать, что делает инженер - он спокойно сидит на стуле и кликает время от времени кнопками мышки. Или спокойно стоит и смотрит на приборы сложной установки, иногда крутит какие-то ручки и нажимает какие-то кнопки. И в то же время понятно, что его мышление и деятельность отличаются от мышления и деятельности пианиста, который тоже спокойно сидит на стуле и кликает время от времени кнопками рояля.
Наша книга о способах мышления и способах действия. Для начала нам нужно найти способы, которыми мы будем описывать мышление и действие.
Инженерия занимается изменением реальности - двигает горы, создаёт спички и зажигалки, строит марсоходы и медицинские роботы Да Винчи. Пространство-время физического мира были устроены одним способом, пришли инженеры, пространство-время стало устроено по-другому.
Производством компактных описаний реальности занимается наука - придумывает диаграммы Фейнмана, теории мышления, понятия системы и деятельности. Пространство-время думали, что устроено одним способом, пришли учёные, пространство-время теперь думают, что устроено другим способом.
Обучить науке - это обучить тому, как строить компактные и понятные людям описания того, как устроен мир. Например, 4 уравнения Максвелла описывают все электромагнитные явления мира, а уравнение Шрёдингера описывает волновые функции элементарных частиц. Можно ли “выучить на учёного” - это отдельный вопрос, мы его тут не будем рассматривать.
Но для начала нам придётся заняться инженерной наукой: попытками компактно описать то, что делают лучшие инженеры мира.
Тут нужно учитывать, что само понимание того, что такое наука, исследования, инженерия непрерывно меняется, чуть ли не каждый десяток лет. Интересующиеся могут ориентироваться на следующую последовательность ключевых работ по истории и философии науки (подборка Антона Николаенко, https://www.facebook.com/nikolaenko.anton.9/posts/761402053939232): в 1934 Поппер выпускает свою "Логику научного исследования",
в 1935 Флек публикует "Возникновение и развитие научного факта",
в 1937 Мертон - работу "Наука и социальный порядок",
в 1946 Полани - книгу "Наука, вера и общество",
в 1962 Кун - свою "Структуру научных революций",
в 1971 Бен-Дэвид - свою "Роль ученого в обществе",
в 1972 Тулмин - работу "Человеческое понимание",
в 1975 Фейерабенд - свою книгу "Против метода",
в 1976 Блур - свою "сильную" программу - книгу "Знание и социальное представление",
в 1978 Лакатос - свою "Методологию научно-исследовательских программ",
в 1978 Хюбнер - свою "Критику научного разума",
в 1979 Латур - свою "Лабораторную жизнь",
в 1979 Малкей - свою работу "Наука и социология знания",
в 1998 Шейпин - свою "Научную революцию",
в 1998 Коллинз - свою "Социологию философий",
в 2008 Деар - свою книгу «Событие революции в науке".
Всё из перечисленного переведено целиком на русский язык.
Инженерия не научна
Разница между инженерами и учёными
Нельзя путать инженеров и учёных. Учёные ровно обратны инженерам: если инженеры делают реальные материальные вещи, опираясь на мысль, то учёные делают мысли из реальности - получают компактные, понятные и формальные описания действительности. Конечно, инженерия и исследования тесно связаны:
● когда инженер получает инженерный объект, поведение которого не отвечает его замыслу, он исследует проблему: пытается найти наиболее компактное описание работы этой инженерной системы, из которого было бы понятно, в чём он ошибся при замысле и его воплощении. Затем исправляет ошибку: меняет систему.
● когда учёный придумывает новый способ описания, более компактный и лучше объясняющий мир, чем предыдущие способы, то он проводит эксперименты. Отнюдь не все эксперименты “мысленные”. Некоторые из них требуют создания весьма и весьма сложных инженерных объектов (например, ускорители - это одни из самых сложных на Земле инженерных объектов). Когда эксперимент проведён, учёные корректируют свои теории в зависимости от результатов эксперимента.
Тем самым инженерная и исследовательская деятельности оказываются связаны в цикл, и в каждом исследовательском или инженерном проекте обычно приходится много раз повторять цикл:
Главное тут - цель объемлющей деятельности, а не собственно сама работа “исследований” или “разработки” (“науки” или “инженерии”): целью является либо появление какой-то материальной системы, приносящей пользу пользователям, либо появление какого-то компактного описания/объяснения того, как устроен мир. В любом случае, либо инженерия оказывается спрятана в исследованиях, либо исследования спрятаны в инженерии.
Эта путаница, отражающая связь инженерии и науки, весьма распространена:
● В большинстве мультфильмов “учёный” в белом халате меньше всего учёный, это “инженер-изобретатель”. Эти якобы “учёные” не ставят эксперименты: они придумывают какие-то необходимые для их целей системы, и воплощают эти системы в реальности. Это “лаборатории Эдисона”.
● “Прикладная наука” (applied research, прикладные исследования) тоже меньше всего наука, несмотря на слово “исследования”. Никаких “теорий” от этой науки ожидать не приходится, а результаты НИОКР (научных и опытно-конструкторских разработок) как правило - вполне себе инженерные объекты, а не способы описаний. Единственная их разница с результатами классической инженерной разработки, так это то, что результатом является прототип или опытный образец, а не идущий потребителю продукт (между “работающим прототипом” и “выпускаемым продуктом” могут быть годы и годы разработки, development - и результатом являются не “изобретения”, а “инновации”, определяемые как успешно выведенные на рынок изобретения).
● Очень часто прикладные исследования (research) и классическую разработку вообще не разделяют, отсюда устойчивое сокращение R&D (research and development). Есть ли разница? Есть: “лаборатория Эдисона” (лаборатория Bell Labs, лаборатория IBM и т.д.) всё-таки отличаются существенно по организации труда и проходящим в них работам от классической инженерной разработки. Но они не отличаются принципиально! Менеджментом R&D как раз и занимается technology and innovation management.
Настоящая наука - это “basic research”, которые ведутся в “лабораториях Эйнштейна”. На выходе не “опытные образцы” (inventions, “изобретения”, прототипы систем и идеи для этих прототипов), а теории - компактные и формальные описания природы. В отличие от R&D менеджмент и финансирование науки происходят совершенно другим образом, часто они происходят вообще вне рамок предприятий.
Системная инженерия - это тоже инженерия, не наука. Системная инженерия вполне может включать R&D, изобретения, создание прототипов.
Ещё одна связь науки и инженерии - это конструирование экспериментальных установок, в какой-то мере создание инженерных прототипов может быть отнесено к научным исследованиям (хотя речь может идти не о подтверждении научной теории, а подтверждении какой-то догадки или замеченной эвристики).
Если мы хотим создать формальное компактное описание самой системной инженерии - то это наука, “инженерная наука” (engineering science).
Предмет инженерии и научные предметы для инженерных объектов
Нужно различать предмет самой инженерии (engineering) и предметы, изучающие объекты инженерии - механику, электрику, компьютерную науку и т.д. Инженерия (в том числе системная инженерия) описывает то, как работают инженеры. Инженерная наука (engineering science) даёт описание того, что делают люди в инженерном проекте. Другие предметы и другие науки описывают поведение инженерных объектов, то, как работают они: механические устройства, электрические схемы, компьютерные программы.
Наиболее просто понять разницу между такой “наукой про инженерный объект” и самой инженерией можно на примере computer science (компьютерной науки) и software engineering (программной инженерии). В блоге http://gaperton.livejournal.com/ была замечательная история, как его автор, отличник по computer science, пошёл после ВУЗа покорять иностранную софтверную компанию. Но там ему буквально за два дня объяснили, что он (может быть) умеет программировать, но совершенно точно не умеет работать: нужно было разбираться с тем, как составляются требования, писать нужно было не столько какой-то хитрый алгоритм, сколько заплатку к уже написанному коду на миллион строк, и нужное место для заплатки в этом коде нужно было как-то найти, кроме этого нужно было разобраться в управлении конфигурацией (версионированием), системой управления изменениями, наладить отношения с менеджерами и тестировщиками, понять суть принятой в проекте методологии разработки и т.д. - при этом ничему этому в ВУЗе не учили. Работа оказалась совсем не тем, чему учили: огромное количество времени уходит на общение с коллегами, а не на “думание”, время решения задачи не “сколько нужно”, а “сколько отведено графиком”. Учили computer science (ключевые слова: алгоритм, оценка скорости выполнения алгоритма, нотация, грамматика, реляционная модель данных) и не учили software engineering (ключевые слова: требования, архитектура, тестирование, изменения, сопровождение). Точно так же инженера-механика могут научить работать с прочностью, формой, скоростями, трением с использованием всяческих теорий, но могут не научить работать с требованиями, архитектурой, испытаниями и инженерными обоснованиями. Именно поэтому хороший физик может быть хорошим специалистом по сопротивлению материалов, но не быть хорошим инженером - у него знания про инженерные объекты, но не про саму инженерию.
Обучить инженерному делу как таковому - это обучить тому, как устроен ход инженерной разработки, какие основные понятия предметной области самой инженерии (а не предметной области, описывающей физику и алгоритмику создаваемого инженерного объекта): как устроен инженерный проект в целом и как разворачивается во времени проектирование/конструирование/программирование, изготовление и разворачивание целевой системы, а не только как устроена создаваемая система.
Ненаучность инженерии. Эвристики
Знания самой инженерии (как что-то сделать) и знания об инженерных объектах (установках, сооружениях, транспортных средствах, компьютерах и т.д.) могут быть как научными, так и ненаучными. Инженерия рождается и живёт методом проб и ошибок, её знания, передающиеся из проекта в проект про неё саму (как что-то сделать) и про её инженерные объекты вовсе необязательно “научны”. Так что определения инженерии как “принесение научных знаний в практику” просто неверно, хотя наука и используется там, где она есть.
В книге Discussion of the Method [http://bookzz.org/book/1244348/d69dbc] исследователь инженерии Billy Koen приводил пример: если бы в средние века к инженеру пришли с просьбой построить мост, а он бы отказался на основании того, что сопромат изобретут только через 200 лет - что можно сказать о таком инженере? Или если бы современный инженер при просьбе построить ракету, летящую на Луну или Марс, отказался бы от проекта на основании того, что достаточно подробной “теории Луны” или “теории Марса” ещё не создано? Или при необходимости создать робота инженер вдруг говорит, что “теории о том, что делать, чтобы создавать робота пока нет - поэтому я не знаю, что в каком порядке делать, поэтому подождём до тех пор, пока у учёных не появится соответствующего раздела инженерной теории”. Отказы на таких основаниях не свойственны инженерам, их не останавливает отсутствие научного знания в том, чем они занимаются.
Billy Koen (http://www.me.utexas.edu/directory/faculty/koen/billy/41/)
Инженерия кроме научных теорий активно использует эвристики (heuristics) - это догадки о закономерностях, которые вовсе необязательно “научны” в традиционном смысле этого слова, т.е. это не “фальсифицируемая теория” по Попперу: инженер с самого начала знает, что эвристики вполне могут быть в его случае ошибочны и неприменимы. Плюс обратите внимание, что инженерные эвристики определяются отличным образом от философской “эвристики”, найдите соответствующую литературу сами). Вот примеры инженерных эвристик:
Из Turton, Richard, et al. (2003) Analysis, Synthesis, and Design of Chemical Processes, Upper Saddle River, NJ: Prentice Hall.:
● Используй вертикальный резервуар на опорах, когда его объем меньше 3.8м3
● Используй горизонтальный резервуар на бетонных опорах, когда его объем между 3.8 и 38м3
● Используй вертикальный резервуар на бетонных опорах, когда его объем больше 38м3
Большая подборка подобных эвристик для инженерии химических производств дана тут: http://people.clarkson.edu/~wwilcox/Design/heurist.pdf
На эту тему есть хороший анекдот: Физику, математику и инженеру дали задание найти объём красного резинового мячика. Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости. Математик измерил диаметр мяча и рассчитал тройной интеграл. Инженер достал из стола свою “Таблицу объёмов красных резиновых мячей” и нашёл нужное значение.
Есть и другие типы инженерных эвристик, совсем не связанных с инженерными расчётами и приёмами конструирования-проектирования:
● Стейкхолдеров всегда на один больше, чем вы знаете; известные вам стейкхолдеры всегда имеют потребность (need) на одну больше, чем вам известно (это шестая из основных инженерных эвристик Tom Glib, http://www.gilb.com/dl97).
● Порядок бьёт класс (в больших проектах упорядоченная работа команды заурядных специалистов бьёт беспорядочную работу высококлассных звёзд).
Тем не менее наука и инженерия тесно связаны: эвристики в более простых системах заменяются научными теориями, в том числе в виде компьютерных моделей (разница: правильно применённая теория даёт надёжный ответ, а эвристика, возможно, врёт), а место для метода проб и ошибок смещается в сторону более сложных систем, которые плохо описываются наличными научными теориями.
Формальные (теоретические, следующие законам логики, а не чисто эвристические - хотя и те и другие могут быть подтверждены экспериментами) описания инженерных систем позволяют проводить формальный анализ: находить ошибки без создания системы, а часто и вычислять необходимые или оптимальные характеристики системы. Очень дорогой метод проб и ошибок с его бесконечным циклом догадок и экспериментов при помощи формальных описаний превращается в совсем другой метод работы, число проб становится в разы и разы меньше. Источником же полезных формализмов (методов описаний самых разных феноменов) является как раз наука. Число формализов растёт, число найденных эвристик тоже растёт, поэтому со временем растёт и уровень инженерии.
В связи с этим любые достижения в инженерии по предложению Billy Koen нужно оценивать не по абсолютной шкале, а на конкретный момент времени, в соответствии с накопленным на этот момент объёмом научного и эвристического инженерного знания - и это “текущее состояние инженерии” Billy Koen предложил называть SoTA (state-of-the-art). Инженерный проект плох, ежели он не использует всей полноты научного и эвристического знания, накопленного на конкретный момент времени. Со временем объем знаний растёт, и инженерные проекты становятся более и более сложными, достигая невозможных для предыдущего времени характеристик.
Наука как “научение птиц полёту”
Существует мнение, что наука для практической деятельности бесполезна. Практики добиваются успеха не на основе научных знаний, а на основе “возни” (tinkering, ср. “He is tinkering with a car” - “он возится с автомобилем”).
Эта точка зрения была развёрнута в книге Насима Талеба “Антихрупкость”. Он сравнивает учёных с теми, кто приходит к птицам и пытается научить их летать, давая знания по аэродинамике. Типичное высказывание в его книге на эту тему: “Никто не опасается, что ребенок, понятия не имеющий о разных теоремах из области аэродинамики и не способный решить уравнение движения, не сможет ездить на велосипеде”. Он защищает метод проб и ошибок, защищает эвристики. Он абсолютно прав. И он прав, когда пишет о создании реактивных двигателей: сначала было много проб и ошибок, потом только появилась теория, а не наоборот.
Тем не менее, исследования дают нам способ думать по-новому: осознанней, быстрее и надёжнее. Но не так, чтобы исследования вообще позволяли нам думать. Думаем мы и без них, но спонтанно, медленно и не слишком надёжно. Метод проб и ошибок всем хорош, кроме того что чрезвычайно дорог и долог. Если есть способ что-то физическое коротко описать, а потом работать с этим описанием-моделью, а не с самим физическим объектом, то так и нужно делать. Если вы учите ребёнка ездить на велосипеде, то вам особой науки не нужно. А если вы учите компьютер быть автопилотом на реактивном самолёте, то незамутнённым наукой методом проб и ошибок вы загубите слишком много реактивных самолётов.
Ещё один аргумент в пользу науки и компактных описаний появляется, когда вы замечаете, что в книжках Талеба ничего не говорится о коллективной работе. Когда речь идёт не о рынке, где “дальнее взаимодействие” (никто друг друга не знает, сделки между незнакомыми людьми) и где хорошо работают рассуждения Талеба, а когда мы хотим хорошее мышление передать кому-то другому, но не понимаем, из чего это мышление состоит, что передавать. Охота и собирательство талантливых людей хороши, но переход к осёдлому земледелию даёт скачок в производительности труда - выращивать талантов дешевле, чем их выискивать.
Так что сначала нам нужна какая-то наука, чтобы инженерные знания компактно описать - и уже после этого мы их можем передать.
Ещё один аспект инженерной работы - она не делается одиночками. Нужна координация усилий сотен, тысяч и даже десятков тысяч людей. Все эти люди должны как-то договариваться между собой. Как они могут договориться, если каждый про свою часть дела может рассказать примерно столько же, сколько едущий на велосипеде мальчик про свою езду “я чувствую, что я держу равновесие и я чувствую, что на большой скорости надо бы пригнуться”? Компактные описания нам нужны, чтобы люди могли иметь одинаковое описание того, что они делают, чтобы не возникло проблемы строительства Вавилонской башни.
Излагаемый в нашей книге подход к системноинженерному мышлению и действию совершенно необязателен для инженеров-одиночек, среди одиночек всегда найдётся Кулибин или Левша. Но вот если речь пойдёт о какой-то более-менее масштабной коллективной инженерной деятельности, то синхронизация способов обсуждения проекта может сэкономить много-много времени - все ведь помнят проблему, возникшую при строительстве Вавилонской башни? Мы должны научиться описывать другим людям, что мы делаем и почему, чтобы другие люди могли к нам присоединиться.
Конечно, уметь что-то описывать и в инженерии, и в менеджменте (и даже в литературе) вовсе не означает то, что вы опишете что-то ценное и важное. Графоманам никогда не получить Букеровскую премию, хотя они умеют писать. Научиться думать об архитектуре или проектном предложении, научиться компактно “по науке” записывать свои мысли вовсе не означает, что вы что-то придумаете интересное. “Думать и придумать” в этом плане похожи на “учить и выучить”, “делать и сделать” - процесс ничто, результат всё. Но если не думать, то и не придумаешь. Если не учить, то и не выучишь. Если не делать, то и не сделаешь. Процесс важен, без него не будет результата.
Так что для начала нам нужна инженерная наука (engineering science), хотя мы точно знаем, что инженерия (”инжиниринг”, как сейчас всё чаще говорят) - это не наука. Но нам нужны компактные описания инженерии и менеджмента как минимум для того, чтобы договариваться об инженерии и менеджменте с другими людьми.
И нам нужна наука о мышлении, хотя мы точно знаем, что само мышление - это не наука. Но нам нужны компактные описания мышления, чтобы договариваться о них с другими людьми, чтобы реализовать коллективное мышление. Построить такую ракету, чтобы она долетела до Марса или даже крошечной по космическим меркам кометы - для этого метода проб и ошибок явно недостаточно, но системные инженеры строить такие ракеты научились.