6. Эволюционное проектирование

Проект/design и проектирование/design

Инженер-проектировщик (в машиностроении — инженер-конструктор) в большинстве случаев раньше отождествлялся с просто «разработчиком», разделения труда особого не было. Если он становился очень опытным, то его могли называть «архитектор» (в СССР это был «главный конструктор», у которого были ещё и менеджерские роли). Результат труда проектировщика — проект/design, с детальностью, достаточной для изготовления. При этом архитектура являлась частью проекта. Но время шло, и появилось разделение труда, а также усложнение понимания того, что является проектом.

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

Проект постепенно приобрёл разные эпитеты, при этом концепция использования в первых каких-то вариантах могла и не быть частью проекта (в частности у атомщиков она называлась «обоснование инвестиций», и это ещё «до требований»), дальше были «требования», затем эскизный проект с совершенно недостаточной для изготовления детальностью, потом рабочий проект, «рабочка» — и вот там детальность была уже достаточная для изготовления. Но даже проектировщики были разными: скажем, эскизный проект делался верхнеуровневый для всей системы, а рабочий проект раздавался по заводам-изготовителям, ибо там вроде как лучше понимали, какая технология могла бы использоваться для изготовления — design for manufacturing (пришлось даже придумать такое словосочетание, «проектирования для изготовления», ибо более чем часто проектировали такое, что изготовить потом было нельзя). Но в строительстве в России всё было не так: строители получали от проектных институтов рабочий проект — и пытались его выполнить, уж как могли. В Европе же было как в машиностроении: ожидалось, что рабочий проекта выполнит строительная организация, а архитектурное бюро выдаст ей эскизный не слишком подробный проект — чтобы проще было использовать материалы и оборудование, доступные тем, кто строит. Даже однажды была коллизия при строительстве завода «Ангстрем Т»: немецкий подрядчик отдал «проект» российским строителям — и те обнаружили эскизный проект, ожидая рабочий. Был большой конфуз, проблему решали несколько лет.

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

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

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

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

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

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

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

И даже в английском языке внимательней: проект/design и проектирование/design. И в русском тоже — проект/project и проект/design. Не запутайтесь, работайте не «по терминам», а «по значениям» — определяйте типы объектов не по их названиям, а по контексту!

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

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

В ТРИЗ обсуждается, что на каждую концепцию более высокого системного уровня для её успешной реализации требуется принять ещё 10-100 решений на уровне подсистем, и так на несколько уровней вниз, чтобы можно было наладить промышленное производство. Если вы выбрали цифровой аппарат вместо плёночного, то вам сразу придётся выбирать между типом матрицы (ПЗС или КМОП, и там ещё много разновидностей), вариантами расположения четырёх пикселей по трём цветам, вариантами организации электроники считывания, и т.д.

Дальше у проектировщика два пути:

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

• Выдавать больше простых не очень сильных идей в единицу времени, в надежде, что одна из этих простых идей подойдёт — окажется сильной. Качественность генерации, то есть сила интеллекта проектировщика (впрочем, рассуждение верно не только для проектировщика) тут отступает на второй план. Работает соображение, что если разнообразных «дешёвых» идей/концепций достаточно много, то рационально выбрать среди них «наименее плохую» и доработать её до хоть как-то приемлемой оказывается проще, чем выбирать между малым числом «дорогих» идей. Скажем, можно просто использовать кофе перед совещанием (повышает количество выдаваемых идей на 30%¹), разные техники «мозгоштурма»/brainstorming, которых множество². Если не помнить, что количество идей не равно качеству, то этот путь кажется неплохим. Но если помнить, что без подобных методик трудно выйти за пределы поиска в каком-то одном месте ментального пространства не слишком качественных концепций в другое место, где концепции могут быть получше, то и без количества обойтись нельзя, и без каких-то методик типа тризовских методов развития творческого воображения («представить ситуацию как очень маленький объект, представить как очень большой объект, представить как мир, населённый маленькими человечками», и т.д.) и поэтому же мозговой штурм стараются как-то модифицировать, чтобы захватить решения из разных областей пространства решений³. Количество идей помогает существенно поднять качество, как показывают reasoning большие языковые модели, но всё-таки в основе реального прогресса лежит качество выдаваемых решений, совсем простые генераторы решений выдают очень плохие не только идеи, но и рассуждения на их основе, reasoning не срабатывает, решения не получается.

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

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

• сначала проверить, зачем вообще нужно забивать гвоздь (lean, ненужную работу просто не делаем, не тратим на неё время)

• породить альтернативы разбиения метода с сигнатурой «забить гвоздь», например, предложить разные инструменты «забивало гвоздя»: взять для забивания гвоздя а) камень, б) молоток, в) гаечный ключ, г) дядю Васю, д) микроскоп, е) … — чем больше альтернатив, тем лучше.

• Провести trade-off studies/analysis, пройти развилку в выборе из этих альтернатив-аффордансов: камень дешёвый и вот он, молоток стоит денег и за ним полдня ходить в магазин, гаечный ключ слишком лёгкий, дядя Вася имеет молоток и работает быстро, но сейчас пьян. ОК, «наименее плохой» здесь и сейчас (важно! Не «вообще», а в нашей текущей ситуации) вариант — камень как «забивало гвоздя».

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

Тут мы даже не коснулись компоновки, ограничений архитектора, ограничений технологов, ограничений визионеров (скажем, стоимостных). Но это всё тоже надо учесть.

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

Моделирование: идеи для концепции моей системы

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

Принятие решения: прохождение развилок (trade-offs)

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

Подробно trade-off studies на примерах архитектурной работы даётся в книге «Fundamentals of Software Architecture»:

Там формулируется первый закон программной архитектуры: «Everything in software architecture is a trade-off», то есть «всё в программной архитектуре — это результат прохождения развилок». И там же приводится следствие из этого закона: «если вы нашли что-то, что не похоже на развилку, то вы, скорее всего, просто не подумали об альтернативах».

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

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

• Проверьте, нужна ли вообще эта функция. Для каждой функции будет затем какая-то работа. Нужно ли на неё тратить ресурсы? Попробуйте обойтись вообще без этой функции: что изменится? Будьте элегантны, lean.

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

• Найдите заведомо более одного варианта, каким образом конструктивно реализовать функцию (учитывая ещё и варианты размещения, и стоимость, и другие системные аспекты/перспективы основных описаний системы, но ведь есть и неосновные описания, важные для вашего проекта). Всегда помним, что идеал — это когда функция исполняется, но нет ни одной добавленной части конструкции, ибо каждая часть конструкции может выполнять множество функций. А ещё одна функция может выполняться несколькими элементами конструкции. Тут мы сразу говорим о функции/методе (иногда даже культуре!), но конструктивные части выполняют роль функциональных частей (помним, что Вася выполняет роль бегуна, а бег — поведение бегуна). Тут надо спрашивать опытных товарищей, гуглить, спрашивать AI-агентов, а иногда и делать изобретения. Генерация идей, продуктивных гипотез — тут. Если вы считаете, что есть только один вариант, то вы что-то упустили. Подумайте ещё и вспомните, погуглите, спросите AI, примените приёмы генерации идей — и сделайте изобретение.

• Затем примите рациональное решение: пройдите развилку, выберите между альтернативами, обоснуйте выбор (приведите rationale — дальше будет рассказано про инженерные обоснования). Есть теории принятия решений в условиях неопределённости, вот это как раз оно.

• Примите ваш рациональный выбор всерьёз: запланируйте работы (вместе с технологом), чтобы иметь ресурсы.

• Выполните запланированные работы, потратьте ресурсы! «Политическая воля» — тут.

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

• Убедитесь, что результатами пользуются: если не пользуются — можно было бы всё это не делать.

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

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

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

• следовать эмпирицизму, то есть выводить эти модели из данных наблюдений по каким-то алгоритмам, «не сочинять», «не высказывать догадки, всё по формулам»?

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

Ответ: эмпирицизм вреден, должны быть причинно-следственные объяснения, которые сформулированы контрфактически на основе догадок. Это и есть рационализм. Эмпирицизм был полезен в прошлых веках, когда эксперимент и данные наблюдений вообще игнорировались, речь шла только о рассуждениях — царила схоластика, отвязанная от физического мира логика, а то и не очень логические рассуждения («я художник, я так вижу»). Но сейчас это не SoTA в части организации познания и инженерии. Вместо него пришёл рационализм, опирающийся на реализм, признание важности физического мира — и ещё прагматизм, как поворот любых рассуждений только как ведущих в поддержку какого-то действия по изменению мира (включая изменению самой рассуждающей о мире системы). Рассуждения ради рассуждений отметаются, но рассуждения «по наитию» — не отметаются (это догадки!), хотя без проверки сначала (причинной/causal) логикой, а затем и экспериментом — не принимаются всерьёз, то есть не служат основаниями для каких-то действий в физическом мире.

В хорошей книге «Modern software engineering» (2022) ставится интересный вопрос о том, что программная инженерия как-то утеряла свою «инженерность», оказалась цеховым ремеслом/craft, а теперь эту инженерию надо в неё вернуть.

Сама постановка вопроса заставляет сформулировать принципы современной инженерии (задача в чём-то похожа на задачи нашего руководства). Но автор (David Farley⁴) выводит «опору на опыт/эксперимент», то есть эмпирицизм, в качестве основания инженерии. Это уже не SoTA, опора должна быть на теории/объяснениях, которые отбираются в том числе с использованием опыта/эксперимента. Подробно мы это разбирали в руководстве по рациональной работе. Книга всё-таки хорошая, но вот к тамошним рассуждениям о предмете инженерии по сравнению с «просто ремесленничеством» надо относиться с осторожностью: используются не SoTA представления о том, что же такое инженерия. Тамошний эмпирицизм — это прошлый век! Эйнштейн выдал свои догадки об искривлениях пространства-времени вместо сил притяжения между большими массами, не выводя их логически «по формулам». Наоборот, он предложил это, решая противоречия, которые были в расхождении вывода по имеющимся ньютоновским формулам и экспериментом. А затем на базе догадок Эйнштейна были разработаны модели физического мира (формулы для вычислений), которые легли в основу инженерии систем навигации GPS, GLONASS, Galileo. В основе инженерии систем навигации — догадка, которую не удалось прокритиковать ни логически, ни экспериментом.

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

• Классические строго логические. Увы, не работают в реальной жизни.

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

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

Более того, нам нужны рассуждения не просто о логических (позапрошлый век), или байесовско-вероятностной (прошлый век), или квантовоподобной вероятностной (двадцать первый век) взаимосвязи одних явлений с другими «по формулам». Нет, нам нужны именно объяснения — которые находятся на третьей ступеньке лестницы причинности (ассоциации-корреляции на первой ступеньке, исчисление вмешательств, do-calculus на второй ступеньке, контрфактуальные рассуждения на третьей). При обсуждении того, как связаны решения о выборе конструктивов, которые реализуют функциональные объекты так, чтобы удовлетворить функциональным характеристикам систем самой разной природы, надо чтобы инженеры (не только проектировщики!) умели строить рассуждения с объяснениями причин и следствий — в том числе моделировать их в виде графов причинности. Как и методов моделирования (описаний самого важного!) функциональности, методов моделирования архитектурных решений, методов моделирования рационального выбора из альтернатив, которых великое множество, есть множество методов моделирования причинности. За каждым из методов стоит какое-то множество нотаций, за каждой нотацией стоит множество поддерживающих её моделеров. Вот только несколько методов моделирования причинности:

• Деревья текущей реальности Голдратта (current reality trees)⁷ — часть Теории Ограничений, разработанная Eliyahu Goldratt. Они используются чаще всего для выявления узких мест в рабочих процессах, хотя метод и носит общий характер. Ключевая терминология привязана к «нежелательным эффектам» (поэтому просто применять в производственных проектах, сразу понятно, что и как делать), сам метод качественный (без количественных оценок вероятностей), граф причинности там — дерево.

• Структурная причинная модель (SCM, structural causal model)⁸, разработанная Judea Pearl, выражаются направленными ациклическими графами (DAG, более общий вид графа, чем дерево, ибо у узла может быть больше одного родителя, а в дереве — только один). Такая модель причинности используется чаще всего в социальных науках, включая экономику и психологию, а также медицине и сельском хозяйстве. Этот метод количественный, он тоже очень общий, а ещё он крайне абстрактен и поэтому его чаще используют в исследовательских проектах, а не производственных/инженерных. Но у этого метода есть интересные плюсы: расчёты по нему могут подтвердить или опровергнуть какие-то гипотезы (например, гипотезы о направлении стрелки причинности в корреляции). Структурные причинные модели сегодня — это SoTA причинного моделирования⁹, но они довольно редко используются в инженерии, ибо их использование требует исследовательской квалификации.

• Диаграмма причинных циклов (CLD, causal loop diagram)¹⁰ используется в системной динамике¹¹ для визуализации обратных связей и взаимодействий в системе. Это не совсем прямое описание причин и следствий, скорее, описание множества взаимодействий, причём с лагами относительно друг друга — это моделирование изменений во времени. Применение в бизнесе (моделирование роста и уменьшения размера компаний), экономике, экологии, социальных науках. Несмотря на то, что системная динамика сама — количественный метод, CLD — качественный инструмент, помогающий понять, как переменные влияют друг на друга через обратные связи во времени¹².

• Анализ дерева отказов (FTA, fault tree analysis)¹³ используется в инженерии для анализа причин системных сбоев в аэрокосмической промышленности, ядерной энергетике, химической промышленности и прочих отраслях, где нужно оценивать надёжность системы. Помогает выявить потенциальные точки отказа и их последствия, улучшая надежность и безопасность систем¹⁴.

• … множество других методов моделирования причинности, как общих (Rubin causal model¹⁵, Bayesian networks¹⁶), так и более частных, поддержанных самыми разными общими и частными нотациями выражения причинности¹⁷ вроде часто встречающихся в инженерии диаграмм Ishikawa¹⁸ и диаграмм «почему-потому» (why-because)¹⁹для выяснения причин аварий/инцидентов.

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

Важно, что речь идёт о достижении каких-то характеристик главным образом времени эксплуатации (хотя и времени создания тоже — вы должны проектировать для изготовления, design for manufacturing), при этом физическое моделирование доступно отнюдь не всегда. Cкажем, вы проектируете функциональную организацию предприятия, его рабочие процессы — вы, конечно, можете задействовать моделер системной динамики для этого, но это не так просто. Приходится задействовать самые разные способы указания на то, что «вот такие причины в функциональной организации системы при условии того, что аффордансы подобраны правильно, ведут к вот таким следствиям».

Надо ещё и делать так, чтобы результаты работы системы (и результаты работы производственной платформы при изготовлении, design for manufacturing) можно было измерить, чтобы потом проверить — правда ли, что система (и её производственная платформа) имеет характеристики, которые были запланированны для неё функциональными проектировщиками и одобрены визионерами. Тут вспоминаем книгу Douglas W. Hubbard «How to Measure Anything»»²⁰, которая рассказывает, как измерить даже то, что трудно замерить физическими измерительными приборами (intangibles в бизнесе, причём понимаемые много шире бухгалтерских «нематериальных активов» вроде патентов и трейдмарок, как всё, что позволяет лучше принимать решения): удовлетворение пользователей, организационная гибкость, снятая неопределённость технологического риска, атмосфера в коллективе (employee morale).

И последнее важное замечание: в инженерии принято говорить о компромиссах (trade-offs), «решениях, которые никого не устраивают». Да, это базовый вариант инженерного рассуждения. Но иногда бывает, что вы предлагаете способ решения противоречия, способ решения конфликта — часто для этого надо предложить новую концептуализацию, в которой этого конфликта нет. Это открытия/discoveries, изобретения/inventions. Это много, много лучше компромисса²¹. Не упускайте такую возможность, но и не расстраивайтесь, если вам это не удалось сделать.

Системное проектирование

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

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

Проектирование до уровня детальности, достаточного для изготовления, иногда называют системное проектирования (system design). Этот метод работы инженера отличается в машиностроении использованием САПР для подготовки 3D-модели изделия, в программной инженерии — использованием IDE для написания кода программы. Концептуальное проектирование работает с верхнеуровневыми объектами самых разных системных разбиений (функционального, конструктивного, размещений, стоимостного, и так далее), системное проектирование идёт «до дна».

Ещё раз напомним приводимую в руководстве по системному мышлению картинку из стандарта IEC 81346-1:2022. Она приводилась там для демонстрации сути архитектурной работы, но современное понимание её такое, что она показывают работу проектирования:

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

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

В системной инженерии по факту сегодня различают тесно переплетённые:

• Функциональное проектирование — определение функциональной организации системы для выполнения какой-то функции. Функций у системы обычно много. Функциональное проектирование выполняет обычно много команд, ведущая роль — прикладной методолог, процессный инженер, функциональный проектировщик/designer.

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

• Концептуальное, а затем и рабочее проектирование конструкции (подбор аффордансов, известных из культуры, или даже изобретение: что вообще из предметов окружающего мира в их взаимодействии сможет выполнить желаемую функцию в надежде на успешность). Этим занимается каждая команда, пытающаяся реализовать нужную функциональность. Ведущая роль — проектировщик/designer.

• Отслеживание интересов бизнеса (business case, чтобы разработка системы и новых фич могла окупить инвестиции в них). Это тоже обычно на уровне всего проекта, ведущая роль — визионер («продакт» из «продакт-менеджер», иногда product owner).

• Отслеживание технологии — в каждой команде должен быть design for manufacturing, то есть должна отслеживаться возможность изготовления системы на внутренней платформе разработки (производственной платформе, «заводе», «конвейере»). Ведущая роль — технолог.

• Эксплуатация, согласно слогану «you build it, you run it!». Ведущая роль — оператор системы (а не пользователь — пользователь пользуется. Вспомните о роли системного администратора вашей компьютерной системы, вспомните о механике, обслуживающем самолёты в аэропорту, о системном операторе энергосистемы страны).

• Инженерия внутренней платформы разработки, занимается технологиями/методами разработки и изготовления, включая инструментарий их поддержки (САПР в конструкторском бюро, станки на заводе). «Инженер внутренней платформы разработки» — это роль, но иногда это три человека в службе DevOps, а иногда это огромная организация, строящая и поддерживающая огромный завод (например, конструкторское бюро и завод, выпускающий ракеты).

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

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

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

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

Вот как это деление на разработчиков и архитекторов изображает немного доработанная картинка из книги «Fundamentals of Software Architecture»:

Это, конечно, картинка для программной инженерии (книга-то об архитектуре программных систем), причём для самой распространённой парадигмы программирования: объектно-ориентированной (показан Class design, но не во всех проектах программной инженерии проектирование/design делается для классов), а ещё среди артефактов указан исходный код — это уже рабочее проектирование, а не концептуальное. Подставьте в эту картинку других прикладных инженеров, например, конструкторов. Тогда вы увидите детали сложной формы, соблюдение каких-то стандартов в размерах (для упрощения изготовления и сборки), информационные модели 3D в CAD — в инженерии это обычно проектирование/design, и новизна в том, что архитектурная работа раньше была внутри проектирования, а теперь она вынесена наружу, за пределы каждой проектной команды.

Идея картинки в том, что архитектор должен убедить/«уболтать» разработчика следовать его решениям (leadership, «уболтать» актёра-разработчика чётко выполнять роль разработчика, сотрудничая в команде и в коллективе изо всех команд), а для этого должен разъяснить разработчику, в чём суть этих решений (mentoring). Кроме этого, архитектор выполняет функцию надзора/governance над разработчиками: если уговорить разработчиков следовать архитектуре не удаётся, то «принимаются меры». Например, строптивые агенты, выполняющие роль разработчиков, просто увольняются, и это правильно: провал проекта из-за плохой архитектуры никому не нужен, а архитекторы в жизни встречаются реже, чем разработчики, разработчика проще заменить. При этом разработчик обычно цепляется за характеристики функциональности в области интересов подсистемы его команды, а архитектор — следит за архитектурными характеристиками всей системы, отслеживая результаты работы всех команд.

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

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

Например, если непонятна концепция типа «электронная вакуумная лампа триод может выполнить роль логического вентиля для универсального вычислителя, делаем электронную вычислительную машину, а не пневматическую или механическую. А память будем делать на ферритовых колечках²²» (в какой-то момент это было изобретением! Это сейчас всё всем понятно!), то архитектору не удастся поделить систему на модули. Скажем, блок питания, блок памяти, блок арифметически-логического устройства, или таки независимые блоки питания для ячеек обработки данных с памятью, которые собираются в многопроцессорный компьютер? Или надо сделать блок питания в каждом из блоков отдельный, а ещё отдельные блок АЛУ, блок процессорных регистров на вакуумных лампах и блок оперативной памяти на колечках? Это всё решения архитектора. Но архитектор не будет проектировать блок оперативной памяти на колечках, вряд ли он разбирается хорошо в материалах колечек, а ещё в устройстве АЛУ (арифметико-логического устройства) и даже устройстве блоков питания. Это будут делать разработчики, скорее всего в отдельных командах.

Надо отличать работу разработчиков (разбирающихся в компьютерных компонентах и принципах их работы) и архитекторов (разбирающихся в том, как сгруппировать модули между собой так, чтобы достичь оптимума архитектурных интересов). Помним, например, о законе Амдала²³, что увеличение числа вычислителей для повышения скорости работы компьютера быстро съедается увеличением времени связи между отдельными вычислителями для их координации. Архитектор работает вот с этими «неожиданными» для неархитекторов эффектами от зацепления/coupling модулей при небрежном их синтезе/сборке. Разработчики же, которые думают больше об отдельных блоках/модулях/конструктах и их особенностях, могут такие неожиданности пропустить. Скажем, разработчики в 90х годах все хотели делать части системы, которые легко повторно использовать (design for reuse) — но потом выяснилось, что сам этот подход вреден архитектурно: если какая-то часть системы использована в нескольких модулях системы, то этим неявно введена зависимость этих нескольких модулей друг от друга, и нельзя быстро поменять эту часть в одном модуле, чтобы не зацепить работу нескольких других. Архитекторы нужны, чтобы такое замечать и запрещать (ну, или разрешать — но зная, какие там могут быть неприятные последствия).

Проектирование как следование архитектуре

Предполагается, что архитектор бьёт систему на части, которые как-то соответствуют предметным областям/domain, а они обычно соответствуют методам работы с объектами какой-то предметной области. В DDD — это поделить систему в соответствии с bounded contexts, предметными областями. В классической «железной» инженерии такой вопрос в явном виде обсуждается редко, но там примерно то же самое: двигателистам отдают проектирование и изготовление двигателя, а разработчикам крыльев — крылья (ибо там много особенностей в использовании композитных материалов, которые прочные, но хрупкие). На крылья и двигатель самолёт нарезает архитектор.

В DDD программисты нарезают программные системы по bounded context в предметной области поддерживаемой организации (business переводим как «организация», ибо не все организации, поддерживаемые софтом — бизнес-организации, есть и госведомства, и некоммерческие организации). Софт в DDD — модель предметной области, которую этот софт поддерживает. Принцип моделирования: каждому важному объекту предметной области соответствует объект программы. Скажем, если в организации есть «счёт» и «клиент», то и в софте поддержки этой организации должен быть и объект «счёт», и объект «клиент» (таблицы в базе данных, процедуры в языке программирования — это неважно, у вас есть средства выбрать что-то подходящее).

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

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

Ещё одна книга, которая рассказывает о концепции системы как об архитектуре, и поэтому двигает рассмотрение архитектуры от чисто функциональной архитектуры к конструктивному/модульному рассмотрению как ограничений в работе проектировщика — это второе издание «The Enterprise Ontology», 2020.

В этой книге отмечается, что в предприятии можно выявить функциональные элементы и конструктивные, причём и те, и другие определяются поведенчески: первые через функции, вторые через трансакции, проходящие между оргзвеньями фирмы, а также оргзвеньями фирмы и внешними предприятиями. Вот пример функциональной декомпозиции предприятия Malum из главы 7 этой книги, «The TAO Theory: Understanding Function and Construction».

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

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

В этом подходе, конечно, есть и поведения (методы/функции и работы), и функциональные и конструктивные объекты (Вася и его забег утром за хлебом, бегун и бег). Но вот терминология «авторская», и надо быть внимательным к терминологии дважды:

• Функциональное и конструктивное вполне путаются

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

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

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

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

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

Вот ещё одна диаграмма из обсуждаемой книги «The Enterprise Ontology», иллюстрирующая концептуальное проектирование в его связи между функциональной архитектурой и структурой модулей:

Описывается метод/process проектирования/design системы. Надсистема называется using system (использующая в своём составе целевую), целевая система — object system (один из переводов object — как раз «цель»). По‑старинке говорится о «функциональных требованиях» (требования к назначению целевой системы, её поведение в составе использующей её надсистемы), а вот «конструктивные требования» — это как раз ограничения на модульный синтез: с одной стороны, какие модули можно или нужно задействовать, с другой стороны — архитектурные ограничения, архитектурные решения, влияющие на группировку функциональности по модулям, влияющую на архитектурные характеристики.

Как ответить на вопрос: важнее/главнее концепция системы, или архитектура? Концепция системы — это верхнеуровневое системное описание, верхнеуровневый проект/design системы. Архитектура (архитектурные решения по верхнеуровневому делению на модули) тут только часть проектных решений (проект всей системы тоже можно представить как «набор решений»!). Функциональная архитектура — это просто функциональное описание системы (часто верхнеуровневое, слово «архитектура» может подчёркивать эту верхнеуровневость). А что с остальной частью проекта? Ей заняты функциональные проектировщики (процессные инженеры, прикладные методологи) и проектировщики-конструкторы.

Концепция системы важна: если вы не знаете, что из конструктивных объектов могло бы исполнить функцию системы (аффордансы/комплектующие/конструктивы), то системы не будет. Можете дать себе три дня на «гугление», вопросы к AI-агентам и друзьям, возможное изобретение, но лучше уходите из проекта, где непонятно, из чего можно сделать систему с предлагаемой функцией. Скажем, вы получили много денег на проект биологического бессмертия. Если непонятно, что именно конструктивно надо делать для бессмертного организма, нет хоть как-то обоснованных на приемлемом уровне риска предложений, то в такой проект идти не надо: нужное вам открытие ещё может просто не существовать, а шансы, что его сделаете именно вы, и успеете при этом сделать его за срок проекта — этот шанс мал. На планете сейчас примерно 500тыс. биологов, которые разбираются в сворачивании белков, а также несколько AI, которые в этом разбираются. Но не факт, что вы найдёте среди них таких, кто добьётся успеха в проекте бессмертия, даже если получит неограниченное финансирование.

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

На заре интернета было множество поисковых систем, но они все базировались либо на краулере (робот, собирающий по всему интернету веб-страницы в поисковую систему) и «индексе» поисковика на мощном центральном сервере (обычно компьютер Sun), либо на идее распределённого поиска (каждый вебсайт делал свой поиск, потом они объединялись). Гугль победил, ибо в его архитектуре краулер собирал веб-страницы в датацентр из множества дешёвых компьютеров (а не в мощный Sun-сервер, который не справлялся с нагрузкой, каким бы он ни был мощным). Связь между серверами вебсайтов с фрагментами децентрализованной системы была ненадёжной, плюс поиск давал дополнительную нагрузку на маломощные вебсайты — эти системы вообще оказались неработоспособны, по факту в конкуренции поисковых систем они не участвовали. Победившее архитектурное решение Гугла было внешне централизованным (одна точка входа), но внутри — распределённым (не один мощный сервер, а много маленьких слабых). И Гугль победил практически всех за счёт грамотной архитектуры (а вовсе не за счёт более качественного алгоритма поиска, как это обычно показано в литературе). Мощностей датацентра (в то время ещё не было такого понятия, это была новинка! Были только «вычислительные центры») как раз хватало, чтобы Гугль отдавал ответ на запрос практически мгновенно, как и сейчас, а лучший конкурент AltaVista — минуту и больше. Хороший алгоритм самого поиска (PageRank) пригодился много позже, когда конкуренция была уже выиграна за счёт новой архитектуры (изобретения) и надо было защищаться от повторяющих подобную архитектуру (например, от Bing).

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

Как неправильно понять первый подраздел про «требований теперь нет»

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

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

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

Поэтому акцент в системной инженерии сейчас делается не на разовое привлечение прикладного специалиста (предметника/«business domain expert»/«subject matter expert») для разработки «начальных требований», а на понимание предметной области/business domain командами разработчиков, визионером, архитектором.

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

Для команд поддержки предметных подобластей (domains, bounded contexts) тем самым важно понимание ими этих предметных областей, а не «понимание спецификации требований». Описание системы этими командами (как описание чёрного ящика, так и описание прозрачного ящика) делается другими документами, при этом сегодня это будут исполнимые в форме тестов (то есть формальные) описания, разработка будет идти test-first. Сначала отвечаем на вопрос «как мы узнаем, что система работает, и делает это хорошо?». Никаких требований, другие формы описания функциональности, интерфейсов, и жёсткое управление конфигурацией, ибо у разных команд будут быстро меняющиеся разные системные описания. Конечно, команды сотрудничают в том, чтобы система оставалась целостной.

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

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

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

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

Для прототипов космического корабля Starship фирмы SpaceX иногда разработчики меняют своё мнение так быстро, что даже не успевают испытать свежеизготовленный прототип, и его тогда разбирают на запчасти, если нельзя просто быстро модифицировать целый корабль. Каждый прототип делается отличным от предыдущего, а в конечном итоге планируется выпускать один космический корабль раз в три дня, и это гарантированно будут не абсолютно одинаковые космические корабли. Пассажирские самолёты Boeing и сейчас выпускаются каждый в своей уникальной конфигурации, но мы тут говорим даже не о том, что в разработке продуктовая линия со множеством модификаций одного продукта, а о том, что по мере выпуска продукт всё время обновляется и единицей рассмотрения для разработчиков является не только какое-то изменение (инкремент, фича) с его жизненным циклом от понимания нужности до эксплуатации в составе целой системы, но и сама жизнь системы, которая разрабатывается-эксплуатируется одновременно (что и отражалось в названии метода DevOps — от development и operations, этот метод и последовавшая за ним инженерия платформы разработки будут рассмотрены в нашем руководстве позже).

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

Если оставлять слово «требования», то начинаются споры на ровном месте: сам термин, похоже, отражает второе поколение системного мышления, а для третьего поколения нужно смотреть не только на описание системы, но и на развитие/эволюцию описания вместе с развитием/эволюцией системы. А «развитие требований» как-то «не звучит», требования наборот — ожидается, что они «стабилизируются»! Поэтому от слова уходим, споры на ровном месте (каждый понимает под «требованиями» что-то своё) не нужны, это «ложный друг переводчика». Почему бы описание системы как чёрного ящика не оставить как «требования»? С оставлением термина «требования» возникают много соблазнов:

• Ошибочно считать, что это описание в деонтической (долженствования), а не доксической (предположение, вера) модальности. Нет, это не «требования», а «гипотеза». Нельзя говорить «вы должны, ах нет, уже не должны, но нет, мы опять поменяли, что вы должны — вы должны, но уже другое». Перестали говорить «X должен быть 10», но «я сейчас верю, что X будет 10, а завтра посмотрим, давайте проверим догадку/гипотезу».

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

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

• «Спецификации требований» (а не спецификации системы!) сегодня представляют собой документы со смесью описаний функциональности, архитектурных характеристик, архитектурных решений и всего чего угодно. Нет «требований», значит нет «спецификации требований» и можно отдельно говорить обо всех этих разных видах описаний, разных видах спецификаций. В частности, можно проконтролировать, чтобы описание (спецификация, причём как гипотеза) было именно описанием желаемого поведения системы, а не просто описанием конструкции системы в статике. Для этого и «сценарии», хорошо подходящие для описания поведения. Подойдут use cases, сценарии (use case текстом), storyboards (картинки заставляют сделать grounding в физический мир) и т.д.: всё, где есть поведение. Всякие языки для BDD (ATDD и похожих методов) пишутся как business rules (в том числе Gherkin) и они тут вообще предпочтительны, хотя без картинок, зато с возможностью проверки.

• Архитектурные характеристики попадали в состав требований как какие-нибудь «нефункциональные требования» или «требования качества». Сейчас они обсуждаются отдельно от функциональных характеристик, с ними работают через метрики, а значения тоже проверяются автоматизированным архитектурным тестированием с помощью особых тестов — fit functions. По их поводам выпускаются архитектурные решения, и они тоже предмет непрерывных изменений в ходе проекта, а выявляют их архитекторы, а не разработчики фич.

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

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

И ещё нужно понимать, что «просто требования» не бывают сами по себе, они ведь могут быть нереализуемы, и это нужно отслеживать. Например, требования «конверсия должна прирасти на 20% от текущего уровня» маловато будет, нужна какая-то идея, с чего бы она там будет прирастать — и это уже сразу не «требования». Не ввязываемся в проект, если не удалось быстро (скажем, за три дня) найти идею/изобретение/концепцию для «фичи» системы (вряд ли можно запланировать изобретение, скажем изобрести микроволновку или компьютер во времена Бэббиджа). Это подробней обсуждается в стратегировании как практике выбора направлений развития/evolving для систем. Стратегии всё чаще и чаще не формулируются в форме «требований к предприятию», но в виде документирования методов работы — сценариев (планы, функциональные описания) или архитектурных решений (policy, за соблюдением которых прислеживают — когда речь идёт об архитектурных характеристиках личности, организации, сообщества). Хотя тут, конечно, речь не идёт о формальной записи, соответствие которой легко протестировать.

Задания

Поставьте отметки о выполнении следующих дел:

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

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

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

Системный менеджмент и разработка

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

Когда команда обсуждает организацию/создание себя как системы, то агенты-люди в ней выступают в других ролях: ролях создателей организации, то есть инженеров предприятия, менеджеров-организаторов. Люди, создающие и развивающие своё оргзвено (отдел, рабочую группу проекта, предприятие) как инженера-создателя целевой системы, тоже выполняют методы системной инженерии, но для организации как одного из участников графа создателей целевой системы. То, что там целый граф создателей, важно: и саму команду‑оргзвено разработчиков как «создателей себя» тоже кто‑то создал, и после создания команды с её создателями будет отношение надзора (там ведь тоже monitoring, continuous development, continuous delivery таких команд), чтобы команда продолжала выполнять своё назначение, ради которого она была создана, а не ушла в автономное плавание со своими собственными целями и перестала заниматься разработкой для достижения и поддержания успешности системы!

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

Более того, эксперименты показывают²⁴, что оптимальный размер команды оказывается неожиданно маленьким: он ближе к пяти участникам команды, чем к двадцати. В софтверном проекте команды и из 5, и из 20 человек пишут 100 тысяч строк кода примерно за девять месяцев. При этом команда из 20 человек справляется всего на неделю раньше, чем команда из 5 человек, но ошибок делает в пять раз больше. Это как раз следствие сложной коммуникации, которая по закону Конвея проходит по поводу разных частей программы не в одном мозге, а через разные мозги, а по закону Амдаля она ещё и съедает производительность многих вычислителей на координацию между ними.

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

• Команда архитекторов целевой системы задаёт целевой создаваемый и развиваемый модуль для каждой команды, специализирующейся на какой-то предметной области, и именно это первично (помним, что целевая система оптимально нарезается на модули, а уж какие там будут команды — это будет второй вопрос, там будет применён обратный манёвр Конвея, да ещё и само разбиение на модули будет меняться по ходу проекта). При этом целью будет максимально точно определить bounded context в части проектных описаний/design и domain в части выделенной части мира, для которого будет разрабатываться командой их часть системы. Конечно, архитекторы целевой системы принимают ещё и множество других архитектурных решений, целью которых является достижение всеми разработчиками разных команд в целом (коллективом разработчиков) приемлемых значений архитектурных характеристик. Эти решения команды архитекторов могут меняться. Мы тут специально пишем «команда архитекторов», хотя в целом в руководстве говорим только о роли архитектора: напоминаем, что роль всегда кто-то исполняет — и это вполне может быть целая команда в большом проекте.

• Команда архитекторов предприятия делает архитектуру организации, задающую нарезку всего предприятия::оргзвено::модуль на максимально автономные (чтобы получилась архитектура со слабой связанностью/зацеплением, loosely coupled architecture) команды::оргзвено::модуль/конструктив. Делает это команда, ориентируясь на (непрерывно меняющиеся!) решения архитекторов целевой системы (не систему делят на части, удобно раскладываемые по уже существующим командам, а коллектив делят на более-менее автономные/независимые команды, занимающиеся определёнными частями целевой системы — в этом суть обратного манёвра Конвея). Внимание архитекторов предприятия направлено на конструкцию организации. Способ деления коллектива предприятия на команды как орг-модули и способ связи между командами коллектива как модулями задают важные организационные свойства (архитектурные характеристики предприятия): высокая производительность предприятия в целом, масштабируемость предприятия в целом, возможность быстрого изменения структуры предприятия в целом (evolvability).

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

Основные принципы современных концепций предприятия и архитектурных решений для предприятий и их команд, как всегда, можно подсмотреть в литературе по организации программных разработок, есть множество фреймворков для поддержки scaled agile (гибкой разработки, выходящей за рамки одной команды): SAFe (Scaled Agile Framework)²⁵, LeSS (Large-Scale Scrum)²⁶, DaD (Disciplined Agile Delivery)²⁷, Scrum@Scale²⁸, Scrum Nexus²⁹, Spotify Model³⁰, и другие. Но помним о том, что речь идёт о безмасштабных принципах, которые приложимы для систем практически любой природы. Требуется время, чтобы принципы разработки, масштабируемой с одной команды на множество команд, были адаптированы не только к программной инженерии. И часто каждый подход будет излагаться в какой-то своей терминологии, так что без понимания устройства разделения труда по инженерным ролям и причин такого разделения труда в этих фреймворках будет трудно разбираться. Но после понимания (хотя бы в объёме нашего небольшого кругозорного руководства) — это будет не слишком сложное чтиво.

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

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

Это означает, что многие вопросы нельзя вот так прямо разделить на «вот это разработка, пусть думают прикладные инженеры-технари/domain engineers и их системные инженеры-архитекторы/system architects», «вот это менеджерский вопрос организации разработок, пусть думают менеджеры/managers и их ответственные за развитие как инженеры предприятия/enterprise и архитекторы предприятия». Нет, инженеры должны разбираться в менеджменте, а менеджеры — в инженерии целевой системы, и они просто обязаны договориться (договорить всех вокруг себя).

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

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

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

Подробно самые разные аспекты работы в современной разработке софта описаны в книге Accelerate (2017)³¹, и опять предупреждаем: читать это нужно как описание методов разработки систем самой разной природы:

В книге приводится довольно много контринтуитивных принципов организации современной инженерной разработки, которые подтверждаются результатами исследований, evidence-based. Вот, например, один из графиков в этой книге:

Он показывает, что в высокопроизводительных организациях (на графике — high performers) при росте числа разработчиков число завершённых частей системы, готовых для сборки (deploys, включение в состав готовой системы) растёт линейно, или даже более чем линейно — за счёт всех этих методов принятия архитектурных решений, принятия решений операционного менеджмента по ограничению размера единицы выполняемой работы (small batch size, «малый размер обрабатываемой партии») и т.д. В организациях умеренной производительности скорость от добавления разработчиков остаётся примерно одинаковой. А вот в организациях низкопроизводительных (в книге показывается, что они не используют современный гибкий инженерный процесс, а придерживаются старинного «водопада») с добавлением людей в команду производительность быстро падает: они не могут решить проблемы работы «команды команд» («бригады бригад», коллектива проекта в целом).

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

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

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

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

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

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

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

Примерно такие же аргументы можно привести по необходимости освоения работы инженерии личности по нашему руководству, посвящённому инженерии людей и AI-агентов как обучению их новым методам работы (новым способам поведения):

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

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

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

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

Вот ещё одна книга, «Team Topologies» (2019) которая касается организации труда разработчиков, и тоже увязывает инженерию команды как части всей организации и прикладную инженерию целевой системы:

Книга кажется «всеохватной», но нет: она касается главным образом одного аспекта, а именно командной организационной структуры, которая влияет на производительность, то есть ускоряющей поток (работ, информации. «Поток»/flow — это общий термин для операционного менеджмента как «эксплуатационной инженерии» организации, отсылающий к логистической парадигме и lean management). Всё изложение в книге крутится вокруг архитектуры, закона Конвея и принципов рационального управления потоком, больше известных как lean.

Книга «Team Topologies» не закрывает всех аспектов, которые нужны для успешных инженерных проектов. Скажем, предыдущая книга («Accelerate») говорит о важности организационной культуры (предоставление автономии командам, свобода разговора о проблемах, общий подход к обучению на ошибках, а не обвинению в ошибках), а в «Team Topologies» этот вопрос практически не затрагивается, книжка очень компактная. Практически не рассматриваются и методы самой инженерии (сначала пишем тесты, а потом проект системы, или наоборот? Пытаемся найти «единственную исходную причину» для каждой проблемы, или нет?), не рассматриваются вопросы финансирования, вопросы бизнес-стратегии (зачем вообще возиться с созданием и поддержкой команд?!).

Объяснительная теория потока и методов lean второго поколения (то есть для разработки, а не для машиностроительных заводов) собрана в книжке 2011 года «The Principles of Product Development»:

Это всё вариации подхода Lean, который появился ещё в 1988 году, но для физических потоков заготовок в машиностроении. Эти принципы были осмыслены как принципы управления очередями (очереди — это плохо, это затор на пути потока продуктов к покупателям, и одновременно это затор на пути встречного потока денег от покупателей через производителя к источникам сырья, то есть другим производителям). И эти принципы управления очередями были взяты из самых разных других дисциплин.

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

TameFlow своими предметами имеет одновременно четыре потока (работ, денег, информации и психологический/well-being)³³. Авторы этого подхода уделяют довольно много внимания тому, как добиться того, чтобы разработчики не только быстро работали (и тут им помогают хорошо известные принципы теории ограничений Голдратта, мы не касаемся их в нашем руководстве, поскольку выяснилось, что все наши инженеры-менеджеры хорошо с ними знакомы), но и были счастливы в этой работе, отсюда много внимания работе с людьми, а не только с методами собственно разработки. «The Principles of Product Development» затрагивает теорию: как именно принимать решения по организации работ, основываясь на принципах экономики, как разумно задействовать оптимальные (не лишние и не недостаточные) ресурсы для выполнения работ.

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

Задание

Поставьте отметку о выполнении.

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

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

Каким образом добиться точности в проектировании/design? В программировании это будет не только design, но и написание кода как «проектирование с достаточной для изготовления точностью». В инженерии железа это будет design, а аналог «кода» в программировании — информационная модель. В русскоязычной практике могут различать «конструирование» как разработку форм деталей (частей системы, которые не собирают из более мелких деталей) и «проектирование» как разработку на основе уже известных деталей и более крупных частей (подсборок, сборок). В любом случае, залогом успеха является доведение абсолютно недетального описания какой-то сигнатуры функции системы («забивание гвоздя») до уровня детальности, требуемого для автоматического изготовления конструктива на производственной платформе, «перевода из битов в атомы». Такой детальности ещё не везде добились, не везде «токарь» стал «станком с ЧПУ» или «3D-принтером», а слесарь-сборщик «промышленным роботом-сборщиком». Ну, и AI позволяет задействовать vibe инженерию (по аналогии с vibe coding³⁴, прозванным так Andrej Karpathy), где значительную часть формализации берёт на себя AI-система.

Ключевых трендов тут два:

• Тщательные проверки модели инкремента, quality assurance, инженерные обоснования. Если есть какие-то ошибки, то их нужно обнаруживать рано. Инкремент маленький, поэтому ошибки обнаруживать относительно легко. У нас будет отдельный раздел про инженерные обоснования.

• Изготавливаемое изделие не надо трогать руками, ибо каждые человеческие руки привносят ошибки. Автор видел вязаный свитер машинной вязки, на котором была ввязана абсолютно чёткая и ровная надпись контрастными нитками: «Твоя бабушка так не свяжет». Люди добавляют неточность! Для того, чтобы что-то собралось, оно должно быть точно спроектировано и точно собрано.

Так же, как архитектура может быть представлена как набор архитектурных решений, так и проект системы (design в классической инженерии, или в программировании исходный код, в инженерии предприятия это могут быть скрипты маршрутизации работ, и т.д.) может быть представлен как набор решений разработчика. Но разработчик, даже если он знает, что ему надо принять решение самостоятельно, а не «подготовить предложение» для утверждения кем-нибудь, кроме самого разработчика, совершенно необязательно будет принимать решения без какой-то их внешней проверки! Как и необязательно, что внешняя проверка независимыми экспертами приведёт к более качественным решениям — эксперименты показали, что тесты, подготовленные самим разработчиком, примерно одинаковы по результативности с тестами, подготовленными независимыми экспертами.

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

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

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

Этот метод проверки проектных решений по ходу их создания стал известен сначала для двух живых разработчиков под названием pair programming, она пришла из подхода eXtreme programming как результат идеи «если что-то хорошо, то мы доводим это до экстремума». Там рассуждали так: если кто-то посмотрит код программы кроме программиста, то это хорошо. Доводим до экстремума: за одной клавиатурой и экраном должно сидеть двое, поэтому в любой момент времени на код будут смотреть как минимум две пары глаз! Всё не так плохо с эффективностью: один из этих двоих сегодня — AI-copilot (но даже в случае живого человека производительность не слишком падала, явно не вдвое — за счёт уменьшения количества переделок, уменьшения rework в силу вовремя замеченных проблем). Это был очень контринтуитивный факт: при парном программировании производительность труда не падала вдвое. Сегодня AI-copylot превращается постепенно из pair developer в peer developer, в полноценного разработчика (прежде всего — проектировщика, designer, в программировании — кодировщик, coder). Как оценить его работу? По тому, какой длительности человеческую работу можно ему предложить? Такие оценки есть, они интересны не для идеи copilot с pair/peer programming, где AI «сидит рядом, работает вместе», но для идеи AI-assistant, который не сидит рядом, а берёт задачу — и приходит назад с ответом. Вот это (график в логарифмическом масштабе, март 2025)³⁵:

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

Заметьте, что идея парной инженерии (в оригинале — «парного программирования», сейчас это работа с AI-copilot, в том числе vibe coding или designing) отличается от идеи совместной разработки прикладного инженера и технолога по изготовлению (design for manufacturing), когда за CAD/САПР/моделером сидят конструктор детали и заводской инженер-технолог, хорошо знающий свой станочный парк. Или инженер-программист сидит и пишет программу вместе с экспертом в предметной области, для поддержки которой делается эта программа. Нет, это именно два проектировщика: один проверяет другого, даёт советы по альтернативным решениям (например, предлагает альтернативные концепции системы или помогает пройти развилку в уже имеющихся альтернативах, напоминает о каких-то ограничениях в части интересов внешних проектных ролей и т.д.).

Тренд тут был в том, что парное программирование стали брать на себя моделеры, поддерживающие мышление разработчика³⁶, это ещё до появления AI-copilot и общения с этими «вторыми пилотами», «парными проектировщиками» на естественном языке.

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

В более сложных моделерах можно сразу иметь copilot. В программной инженерии проектирование (кодирование) ведётся в IDE (interactive development environment, аналог CAD-систем в классической «железной» инженерии), которые представляют собой некоторые «микроядра» (архитектурный стиль микроядра, где есть общее «ядро» и к нему разные «плагины», реализующие дополнительные фичи). Плагины раньше нужны были как раз для возможности делать синтаксические проверки, а сегодня — для подключения самых разных AI-copilots, AI-assistants, AI-agents.

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

Можно ли надеяться на то, что эти проверки надёжны? И да, и нет:

• Современные системы AI плохо проверяют, плохо находят ошибки³⁷. Так же, как и люди — проблема в том, что и люди, и AI-системы используют нейросети, которые не в ладах с логикой и вычислениями.

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

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

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

Но что надо понимать, так это общий характер происходящей автоматизации для систем самой разной природы, для всех инженерных специальностей, которые этими системами занимаются. Вот пример такой не слишком обычной инженерии, как инженерия диджейского сета (последовательности треков на танцевальной вечеринке, или на радиостанции)³⁹: музыкальный сервис узнаёт вкусы диджея, предлагая ему послушать самые разные треки и отметить те, которые ему подходят, а затем генерирует диджейский сет, на основании этих предпочтений. Есть ли тут развитие? Конечно! Диджеи работают с уже готовой музыкой. Но сегодня и музыка генерируется вполне сравнимо с созданной людьми⁴⁰, поэтому можно ставить уже не задачу выбора, а сразу задачу генерации музыки.

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

Одна из проблем на этом пути — это планирование каких-то последовательностей преобразований моделей, ибо нейронные сети плохо планируют (хорошо «воображают» статичный результат, но плохо планируют цепочки действий, плохо отслеживают изменения в больших конфигурациях). Поэтому трудно ожидать, что вот прямо сейчас распечатанный на 3D-принтере итог работы «не слишком живого конструктора» будет автоматически и без проблем собран. Но такое сейчас не так просто и беспроблемного происходит и с живыми конструкторами. Прогресс и тут быстрый. И если AI-агенты каждые полгода умнеют с выходом очередной версии, то с инженерами-людьми такого не происходит.

И тут нужно заметить, что само понятие «сборка» (integration, раньше была отдельная стадия — ибо мало что сходу друг с другом собиралось, надо было «дорабатывать по месту напильником» каждую деталь) в современной инженерии отходит на второй план. Современные точно изготавливаемые детали просто складываются вместе — никаких проблем, никаких «доработок». Это обеспечивается точностью проектирования и точностью изготовления. Но есть и другой ход, на 3D-печать. Вместо набора простых деталей можно использовать одну сложную деталь, и сборка тогда включает в себя меньшее число более простых операций (плюс для меньшего числа деталей более простая логистика, а каждое соединение не нужно отдельно проверять). При поломке можно напечатать новую деталь, а не ремонтировать старую. Что можно так напечатать? В ракете Terran 1 компании Relative Space печаталось 85% ракеты (по весу), а цель — 95%⁴¹. Печать ракеты (как бы странно это ни звучало) идёт 60 дней, а деталей в этой ракете в сто раз меньше, чем в обычной ракете, и по этой технологии космический корабль уже выходил на орбиту. В сто раз меньше деталей — это при надлежащей точности изготовления минимум в сто раз меньше возможных ошибок при сборке! А цена? В сто раз меньше проверок по сборке, в сто раз меньше логистики на сборке, в сто раз меньше возможных конфликтов конфигурации. Плюс можно каждую следующую ракету делать чуть лучше, чем предыдущую, просто печатая улучшенные детали для этих ракет. Непрерывная разработка, непрерывная интеграция, непрерывное введение в эксплуатацию работают и в аэрокосмосе. В этом проекте не всё безоблачно, ибо при переходе на более большую ракету для скорости пришлось временно отказаться от 3D-печати самых крупных элементов (прежде всего — стенки баков)⁴², но тренд в сторону 3D-печати очевиден.

Иногда тему автоматизации проектирования (особенно в строительстве) ещё называют «порождающим проектированием» (generative design)⁴³. Но термин, похоже, не будет жить долго: всё проектирование автоматизируется — и скоро проектирование «вручную» будет выглядеть примерно так же, как «рукоделие» (скажем, свитер ручной вязки, а не промышленной вязки), то есть больше хобби, чем серьёзное занятие инженеров.

Задание

Поставьте отметку о выполнении.

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