Проект/design и проектирование/design
Инженер-проектировщик (в машиностроении — инженер-конструктор) в большинстве случаев раньше отождествлялся с просто «разработчиком», разделения труда особого не было. Если он становился очень опытным, то его могли называть «архитектор» (в СССР это был «главный конструктор», у которого были ещё и менеджерские роли). Результат труда проектировщика — проект/design, с детальностью, достаточной для изготовления. При этом архитектура являлась частью проекта. Но время шло, и появилось разделение труда, а также усложнение понимания того, что является проектом.
Так, архитектура всегда считалась частью проекта, требования считались частью проекта, при этом в требованиях не различали собственно требования и архитектурные решения — и значительная часть архитектурной работы выполнялась при этом на этапе выявления требований, который всё-таки отличался от этапа проектирования в «водопаде», тем не менее, требования и часть архитектуры в этих требованиях входили в проект. Впрочем, там были нюансы: проектом назывался не собственно проект/design, а проектная документация — и уж туда могли «подшить» всё что угодно.
Проект постепенно приобрёл разные эпитеты, при этом концепция использования в первых каких-то вариантах могла и не быть частью проекта (в частности у атомщиков она называлась «обоснование инвестиций», и это ещё «до требований»), дальше были «требования», затем эскизный проект с совершенно недостаточной для изготовления детальностью, потом рабочий проект, «рабочка» — и вот там детальность была уже достаточная для изготовления. Но даже проектировщики были разными: скажем, эскизный проект делался верхнеуровневый для всей системы, а рабочий проект раздавался по заводам-изготовителям, ибо там вроде как лучше понимали, какая технология могла бы использоваться для изготовления — design for manufacturing (пришлось даже придумать такое словосочетание, «проектирования для изготовления», ибо более чем часто проектировали такое, что изготовить потом было нельзя). Но в строительстве в России всё было не так: строители получали от проектных институтов рабочий проект — и пытались его выполнить, уж как могли. В Европе же было как в машиностроении: ожидалось, что рабочий проекта выполнит строительная организация, а архитектурное бюро выдаст ей эскизный не слишком подробный проект — чтобы проще было использовать материалы и оборудование, доступные тем, кто строит. Даже однажды была коллизия при строительстве завода «Ангстрем Т»: немецкий подрядчик отдал «проект» российским строителям — и те обнаружили эскизный проект, ожидая рабочий. Был большой конфуз, проблему решали несколько лет.
Всё дальше сильно изменилось и в части формы, в которой существовал проект — «проектной документации». Теперь это компьютерные модели, ещё и непрерывно обновляемые, ибо водопад уходит в прошлое даже в «железе».
У программистов всё было ещё интересней: проект там всегда только более чем эскизный (и делают они его так, что он плохо отличим от функциональной верхнеуровневой архитектуры, dataflow), а рабочий проект — это программный код, он как раз прописывается с точностью, «достаточной для изготовления».
И дальше ещё было разделение труда: архитекторы перестали быть «опытными проектировщиками», у них появился свой предмет: архитектурные характеристики, архитектурные стили, архитектурные решения. В последнее время начали выделяться и функциональные проектировщики, они же методологи прикладной предметной области, функциональные архитекторы, процессные инженеры.
В менеджменте разработчики вообще никак не назывались, решения по оргпроектированию принимались «в рабочем порядке». Потом выделились «опытные разработчики», их назвали «архитекторы предприятия» — но тут было что-то не так, ибо все путали архитекторов предприятия с архитекторами айтишной инфраструктуры предприятия. И заодно появились службы качества, где были «аналитики», которые вроде как «выявляли» рабочие процессы, хотя иногда всё-таки проектировали их, но чаще — просто «рисовали», интервьюируя менеджеров. Тем не менее, всё чаще и чаще слышались призывы заниматься оргпроектированием (орг-дизайном), ибо кто-то же должен проектировать структуру подразделений!
Так что разделение труда приводило к тому, что общая деятельность по разработке проекта как-то распределялась по различным инженерным специализациям, но всё-таки проектировщики (и заодно конструкторы в машиностроении, кодировщики в информационных технологиях) никуда не делись: у проектировщиков****осталось п****ринятие решений по тому, какими конструктивными объектами**-аффордансами** (комплектующими**, модулями, компонентами****)** будут выполняться роли из функциональных описаний**, а также как они будут пространственно скомпонованы****—** и это может быть как с экскизной степенью детальности, явно недостаточной для изготовления, так и рабочей степенью детальности, достаточной для изготовления**.** Конечно, это в рамках ценовых и архитектурных ограничений**.**
И ещё всё это «разделение труда» иногда было в кавычках: речь ведь идёт об интуитивно понимаемых ролях, а в жизни работы всех этих ролей выполняли какие-нибудь «опытные инженеры» на должностях начальников секторов, начальников отделов, или просто «ведущие инженеры», от которых ожидалась универсальность, а не ролевая специализация.
Так что первое, что надо запомнить, разбираясь с ролью проектировщика: в разных ситуациях эта роль будет называться очень по-разному (тот же «конструктор»), часто вообще никак не называться, это будет просто «инженер»— сверхобобщение. К основному методу работы этой роли (принятие решений по тому, какие конструктивные объекты в какой компоновке будут играть роли**—** при ограничениях архитектурных, ценовых, безопасности, технологических) у какого-то агента легко будут подмешаны работы других ролей так, что выделить именно работу проектировщика в явном виде может быть затруднительно.
И даже в английском языке внимательней: проект/designи проектирование/design. И в русском тоже**—** проект/projectи проект/design. Не запутайтесь, работайте не «по терминам», а «по значениям»****— определяйте типы объектов не по их названиям, а по контексту!
Это не мешает нам дать довольно абстрактное описание метода работы проектировщика: главное, что он должен сделать — это сгенерировать идеи/изобретения (впрочем, изобретением это назовут только тогда, когда какой-нибудь набор конструктивных объектов был первый раз применён для выполнения какой-то функции), какие объекты-аффордансы (комплектующие, конструктивы) будут играть роль функциональных объектов. А дальше он должен детализировать это конструктивное описание, предоставить формы и компоновку в пространстве, проверить выполнение всех ограничений (архитектурных решений, стоимостных ограничений от визионера, технологических от инженеров внутренней платформы разработки, «завода»).
Методы генерации идей имеют долгую историю, но большинство из них имеет сравнимую эффективность, явных преимуществ нет ни у каких методов, но есть явно неудачные методы. Скажем, «метод Диснея», в котором предлагалось сначала генерировать варианты без критики, а только потом критиковать их, в экспериментах не показал никаких преимуществ перед другими методами.
В ТРИЗ обсуждается, что на каждую концепцию более высокого системного уровня для её успешной реализации требуется принять ещё 10-100 решений на уровне подсистем, и так на несколько уровней вниз, чтобы можно было наладить промышленное производство. Если вы выбрали цифровой аппарат вместо плёночного, то вам сразу придётся выбирать между типом матрицы (ПЗС или КМОП, и там ещё много разновидностей), вариантами расположения четырёх пикселей по трём цветам, вариантами организации электроники считывания, и т.д.
Дальше у проектировщика два пути:
- Поднимать качество выдаваемых идей. Этот пример мы приводили, сравнивая IQ фон Неймана и Эйнштейна: первый был редкостным эрудитом и обладал редкой умственной производительностью по выдаче идей, отметился во многих областях науки. Второй выдал поменьше идей, но эти идеи оказались более глубоко продуманными, они существенно поменяли представления человечества о физике. Так что высокий IQ в генерации концепций необязательно помогает. И тут есть ресурсное ограничение: вы можете потратить много времени на продумывание одного потенциально хорошего решения и его доводку до приемлемого варианта, а можете это же время потратить на десяток самых разных решений — в надежде, что среди них окажется «то самое, наш выигрыш!». Как увеличить качество выдаваемых идей — это пока непонятно. Звучат общие слова об искусственном интеллекте, талантливых людях, удачливости и прочем таком, но на метод указать нельзя. В принципе, для систем искусственного интеллекта более качественная модель выдаёт сразу хорошую идею, не тратится много сил на «много раз попробовать». Кошечка не выдаст хорошей инженерной идеи, а человек выдаст — интеллект всё-таки имеет значение, сила выдвигаемой идеи имеет значение.
- Выдавать больше простых не очень сильных идей в единицу времени, в надежде, что одна из этих простых идей подойдёт — окажется сильной. Качественность генерации, то есть сила интеллекта проектировщика (впрочем, рассуждение верно не только для проектировщика) тут отступает на второй план. Работает соображение, что если разнообразных «дешёвых» идей/концепций достаточно много, то рационально выбрать среди них «наименее плохую» и доработать её до хоть как-то приемлемой оказывается проще, чем выбирать между малым числом «дорогих» идей. Скажем, можно просто использовать кофе перед совещанием (повышает количество выдаваемых идей на 30%[1]), разные техники «мозгоштурма»/brainstorming, которых множество[2]. Если не помнить, что количество идей не равно качеству, то этот путь кажется неплохим. Но если помнить, что без подобных методик трудно выйти за пределы поиска в каком-то одном месте ментального пространства не слишком качественных концепций в другое место, где концепции могут быть получше, то и без количества обойтись нельзя, и без каких-то методик типа тризовских методов развития творческого воображения («представить ситуацию как очень маленький объект, представить как очень большой объект, представить как мир, населённый маленькими человечками», и т.д.) и поэтому же мозговой штурм стараются как-то модифицировать, чтобы захватить решения из разных областей пространства решений[3]. Количество идей помогает существенно поднять качество, как показывают reasoning большие языковые модели, но всё-таки в основе реального прогресса лежит качество выдаваемых решений, совсем простые генераторы решений выдают очень плохие не только идеи, но и рассуждения на их основе, reasoning не срабатывает, решения не получается.
Меметические алгоритмы зависят от того, насколько вы можете закинуть основную идею в область значимого максимума в динамическом ландшафте приспособленности. Если вы породите много-много идей, которые окажутся на склоне одного из маленьких холмиков в этом ландшафте, вы проиграете. Если силы интеллекта хватит на то, чтобы раскидать идеи достаточно далеко в этом динамическом ландшафте, чтобы увеличить вероятность их попадания на разные склоны разных максимумов — это поможет получить в итоге качественное конструкторское решение. «Конструкторское решение» тут не случайный синоним проектного решения: помним, что конструктор — это по факту синоним проектировщика, в машиностроении есть большая путаница в значениях этих слов, мы это уже говорили. Но проектное решение может быть и в части функциональной организации, а конструкторское — уж точно про структуру конструкции/модулей в увязке с играемыми ими функциями.
Тут важно понимать, что в инженерии под концепцией/«идеей решения» понимается предложение каких-то взаимосвязанных конструктивных частей-аффордансов, которые выдадут в случае задействования их в надсистеме нужную функцию, если их собрать в правильной пространственной компоновке. Так, если нужно забить гвоздь, то нужно
- сначала проверить, зачем вообще нужно забивать гвоздь (lean, ненужную работу просто не делаем, не тратим на неё время)
- породить альтернативы разбиения метода с сигнатурой «забить гвоздь», например, предложить разные инструменты «забивало гвоздя»: взять для забивания гвоздя а) камень, б) молоток, в) гаечный ключ, г) дядю Васю, д) микроскоп, е) … — чем больше альтернатив, тем лучше.
- Провести trade-off studies/analysis, пройти развилку в выборе из этих альтернатив-аффордансов: камень дешёвый и вот он, молоток стоит денег и за ним полдня ходить в магазин, гаечный ключ слишком лёгкий, дядя Вася имеет молоток и работает быстро, но сейчас пьян. ОК, «наименее плохой» здесь и сейчас (важно! Не «вообще», а в нашей текущей ситуации) вариант — камень как «забивало гвоздя».
- Дальше работаем по улучшению камня: выбираем подходящей формы, веса, прочности, пытаемся привязать ручку или нет, добавляем какую-то держалку для гвоздя, чтобы не попасть по пальцу и т.д.
Тут мы даже не коснулись компоновки, ограничений архитектора, ограничений технологов, ограничений визионеров (скажем, стоимостных). Но это всё тоже надо учесть.
Проектировочных решений в проектах огромное количество, они все тесно связаны друг с другом. Прохождение каждой развилки влечёт появление многих новых развилок, а иногда приходится под давлением фактов (мы в офисе! Камня не нашли!) возвращаться назад, и брать другой вариант: ищем что-то похожее на камень, или дожидаемся, пока дядя Вася с его молотком протрезвеет до такой степени, чтобы хотя бы сказать, где этот молоток, или даже возвращаемся к постановке проблемы — кто сказал, что функцию крепления будет выполнять гвоздь? А если использовать клей? Или болт с гайкой?