3. Инженерные процессы (методы разработки)

V-диаграмма

Самым упрощённым, популярным и распространённым визуальным представлением «однократного» процесса инженерии (создания-без-развития) с показом основных практик в их развёртке по «логическому времени» является V-диаграмма (V-diagram, Vee diagram), популяризованная в 1991 году Kevin Forsberg¹:

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

Название этой диаграммы происходит от формы латинской буквы V, а форма выражает «логическую»/функциональную линию времени, перегнутую пополам в точке, где укрупнённая стадия описания будущей системы (работа с битами, system definition) переходит в укрупнённую стадию воплощения системы (работа с атомами, system realization). Это такой упрощённый водопад ещё первого понимания жизненного цикла как работ, поделённых на стадии. На этом первые V-диаграммы обычно и заканчивались, но потом иногда начали изображать и стадию эксплуатации/использования (работы/функционирования системы, system operation) как длинный горизонтальный отрезок. На нашем рисунке это «иногда» показано квадратными скобочками вокруг [работы системы]. Внешний вид диаграммы больше стал напоминать квадратный корень, но название «V-диаграмма» осталось. Традиционную для системной инженерии с её «от рождения до смерти» стадию вывода из эксплуатации («смерти») на V-диаграммах изображать так и не начали.

Эти дополнения начальной V отражали постепенное принятие инженерами идей системного мышления:

• сначала идея жизненного цикла проекта/project разработки системы (то, чем занимаются системные инженеры в своём проекте),

• потом охват мышлением стадии эксплуатации (ещё шаг к удержанию внимания на полном жизненном цикле, добавили стадию),

• и только в самое последнее время (уже в 21 веке, начиная со стандарта ISO 15288, первая версия которого вышла в 2002 году) умолчанием является обязательное рассмотрение полного жизненного цикла — в том числе и (инвестиционный, коммерческий) замысел, начиная с проверки соответствия идеи проекта стратегии предприятия, берущегося за проект, и заканчивая выводом из эксплуатации/уничтожением после использования.

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

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

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

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

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

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

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

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

• Описание как описывание::работа, обобщённая/укрупнённая стадия жизненного цикла, то есть работы по описыванию системы/созданию описания системы в первом смысле этого слова (информация о системе, а не стадия). И тут даже английская не -ing форма (definition) не помогает: регулярно стадии работы называют не по их процессам, а по их результирующим предметам метода. «Забитый гвоздь» вполне может быть «работой по какому-то из методов забивания гвоздя, дающей на выходе состояние гвоздя «забитый»». Будьте внимательны к типам!

После того, как система спроектирована, линия «логического»/функционального/методологического времени делает перегиб, и начинается следующая стадия воплощения системы (system realization, реализация тут как «вынос в реальность», получение физического воплощения — изготовление, сборка, наладка). Словосочетание «воплощение системы» тем самым тоже используется в двух словарных значениях:

• Название системы как вещи (система как физическое тело в пространстве-времени, воплощение-существительное в отглагольном существительном: результат работ по воплощению)

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

Сам излом V нужен для того, чтобы удобно показать инженерные обоснования/assurance. Эти обоснования делили на два рода:

• проверки/верификации/verification — обоснование того, что сделали то, что запроектировали: «мы этого хотели, вот оно». Это было особо актуально в момент, когда вместо сценариев использования говорили о требованиях. Требования описывали систему в её границах, и вот это соответствие требованиям обосновывали.

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

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

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

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

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

• разбирательство с «методологией разработки»/«инженерным процессом» (тогда это было «управление жизненным циклом», а также системноинженерный менеджмент как получение в инженерной организации оргвозможности вести инженерный процесс в соответствии с выбранным его видом),

• инженерию требований, ибо требования вроде как собирались для системы в целом (что оказалось плохой практикой!),

• системную архитектуру в её старом понимании (создание верхнеуровневой концепции системы), причём это считалось ведущей практикой системной инженерии,

• ввод в эксплуатацию готовой системы (наладку),

• инженерные обоснования (ведение испытаний, проверки и приёмки) успешности системы в целом.

Все остальные методы работы (включая, например, проектирование/design::метод с получением в результате проекта/design, проведение инженерных расчётов по каким-то инженерным отдельным методам работы — теплотехнике, аэродинамике) считались прикладными методами инженерии.

Из V-диаграммы видно, что так «по-старинке» понимаемые методы (их чаще называли «процессы», например в устаревшем уже идеологически стандарте «железной» системной инженерии ISO 15288² это system life cycle processes) системной инженерии встречаются главным образом на начальных и конечных стадиях проекта/project (сейчас при однократном проходе по «жизненному циклу» это была бы концепция использования и концепция системы, включающая современное понимание архитектуры в начале проекта, и испытания на соответствие им в конце проекта), а в середине проекта превалирует работа самых разных других инженерных специальностей, направляемая немногими архитектурными решениями. Современное понимание системной инженерии уже иное: это не какие-то отдельные «системноинженерные» методы работы, а наиболее общее описание сигнатур самых разных методов инженерной работы в их разбиении по культурно-обусловленным ролям, подробней об этих методах («как надо вести инженерную работу») и выполняющих их проектных ролях будет в руководстве по системной инженерии.

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

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

Элегантность/lean за счёт повышения точности моделирования и изготовления

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

Для V-диаграммы был сформулирован классический слоган системной инженерии: все возможные работы по методам правой части диаграммы нужно переносить в левую часть. Это означало, что всё, что можно сделать на стадии описания/моделирования будущей системы, нужно делать именно на этой стадии: битами много дешевле оперировать, нежели атомами, особенно если речь идёт о сложных дорогих системах типа самолёта или энергоблока атомной электростанции. Вот данные INCOSE по стоимости исправления ошибок в зависимости от стадии типового жизненного цикла водопадного проекта (2013)⁴:

Это иллюстрация хорошо известного вам уже тезиса уменьшения стоимости переделок/re-work: работать надо так, чтобы уменьшать число переделок, ошибки на одних стадиях не пускать на другие стадии. В Tesla на каждой заводской операции есть и входной контроль (чтобы в обработку не попал ошибочный предмет метода, и мы не потратили бы ресурсы на его переделку), и выходной контроль (чтобы брак не попал в работу — и кто-то дальше по конвейеру не потратил ресурсы на ненужную работу, ибо потом всё одно пришлось бы переделывать). Ошибки надо обнаруживать и устранять рано, проверять ошибки надо постоянно, они ведут к чудовищным тратам ресурсов, если обнаружены позже: переделка для поздно обнаруженной ошибки будет стоить очень дорого!

В современных условиях не-водопада этот тезис можно переформулировать так, что:

• Вся возможная подготовка производства (включая тестирование) должна быть выполнена в информационных моделях, а не на готовой системе. Лучше лишняя модель, чем лишний прототип. С этим регулярно спорят, но по мере нарастания точности моделирования эти споры стихают. Раньше первый экземпляр нового самолёта не взлетал. Теперь первый экземпляр самолёта гарантированно взлетает. Прототипирование становится моделированием. Это не исключает того, что мы получим богатый отклик от пользователей, когда к ним попадут первые же экземпляры системы, но эти экземпляры системы будут работать!

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

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

Современность, конечно, к этому добавила:

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

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

Моделирования в современной разработке по сравнению с древним «водопадом» тем самым стало не меньше, а больше — просто «много моделируй, а один раз сделай» стало само выполняться много раз в ходе развития системы.

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

Мы не тратим силы на обсуждение и обработку ненужных деталей моделируемого объекта. Модели — это «правильные упрощения». Обсуждаем только то, что отмоделировано, то, что важно, что нужно.

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

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

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

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

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

• С изготовления на моделирование: методом проб и ошибок на «проектирование проб — и они оказываются безошибочными». Для уменьшения числа ошибок воплощения моделей в физическом мире поднимается точность моделирования.

• С моделирования «головой» на компьютерное моделирование, при этом размер и безошибочность моделей растут. С изготовления руками на изготовление инструментами, причём компьютерно-управляемыми инструментами, это тоже поднимает безошибочность.

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

С использованием компьютерного моделирования резко поднялась точность и безошибочность основанного на проверяемых моделях проектирования и одновременно резко поднялась точность изготовления деталей. Компьютерное управление конфигурацией и изменениями позволили в разы снизить количество конфигурационных коллизий, уменьшить тем самым число переделок. Этот переход к элегантной разработке (lean, «ничего лишнего», никаких rework, никаких застреваний на work in progress) резко ускорило разработки, в разы. Если вам говорят, что самолёт или автомобиль, а также компьютерный чип сегодня разрабатывать дольше, чем раньше — не верьте: сложность и характеристики этих самолётов, автомобилей и компьютерных чипов просто несопоставимы с теми, что были раньше. Раньше их было бы разработать не просто дольше — их разработать было бы запредельно долго, попросту невозможно. Не было таких методов работы, не было инструментов, и стоимость разработки должна была бы включить и стоимость разработки методов работы со всеми их теориями и инструментарием. И не берите тут примером государственные проекты, там высокое искусство траты дармовых денег налогоплательщиков с их максимизацией по величине и длительности в оплату за ненужные работы и ненужные функции, поэтому разработки ведутся дольше, дороже, а результаты хуже, чем в частном секторе. Космические программы тут не пример успеха, а пример провала — пока речь не зашла о коммерческом космосе в исполнении SpaceX. В этот момент многим государствам пришлось переформатировать свои инженерные космические программы — и они стали ближе к описываемым тут принципам инженерии.

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

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

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

Моделирование по мере развития методов инженерии стало частью разложения методов описания системы (раньше — левая часть V-диаграммы), но модели начали использоваться и при изготовлении системы (раньше — это правая часть V), а в последнее время и при эксплуатации (третья часть дополненной V, перекладина в V‾‾). Для готовой эксплуатирующейся системы эта часть методов инженерии получила название использование «цифрового двойника»/«digital twin», а сама система (воплощение системы) тем самым стала «физическим двойником»/«physical twin». Все разные вычислители/computers с моделями, датчики и актуаторы/эффекторы самой готовой системы при этом связаны «цифровой нитью»/digital thread.

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

Методы «мышления моделированием»¹⁰ в инженерии поддерживаются инструментарием моделеров/modelers, а создание внутренней производственной платформы (internal development platform) не только для изготовления («завод»), но и для моделирования в ходе инженерии (различные компьютерные моделеры с функциями автоматизации проектирования, моделирования) — цифровой инженерией. Про это будет подробно в учебнике «Системная инженерия», а тут покажем относительно новый, но всё-таки идеологически старый вариант V-диаграммы, который появился в 2018 в связи с вниманием к моделированию в инженерии¹¹:

Этот новый вариант V-диаграммы от Boeing упоминает ещё один синоним для цифровой инженерии: моделеориентированная инженерия/model-based engineering/MBE. Кроме того, это не V, а MBE-ромб/diamond из двух сложенных своими перегибами V‾‾, где нижняя часть — это классическая V, а верхняя указывает на цифровую инженерию как создание моделеров и исполняемых моделей, которые и порождают модели-описания (например, порождают/generate аэродинамически выгодную форму системы, порождают/generate программу для станка с ЧПУ или программу для 3D-принтера для изготовления какой-то детали из материала). Этот вариант V-диаграммы стал ещё более «метафоричным», ещё более оторванным от реально проходящего в жизни процесса инженерии — ибо в жизни тесно сплетены процессы инженерии систем в графе создателей (скажем, изготовление и разворачивание, настройка моделеров, разворачивание команд инженеров-модельеров), а также тут очень плохо обсуждается независимость разработки разных конструктивов/модулей (а это важно в крупных проектах), плохо обсуждается «непрерывное всё» (когда эксплуатация уже идёт текущей версии, изготавливаются части следующей версии для модернизации текущей версии и проектируются части версии, следующей за изготавливаемой — с жёстким управлением конфигурацией, чтобы чего-то не перепутать).

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

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

Стадии жизненного цикла в водопадном виде жизненного цикла заканчивались предварительно запланированными гейтами/gates/воротами, в которых независимыми экспертами оценивались собранные в единое целое результаты предыдущей стадии/фазы/этапа работ и принималось решение о продолжении проекта на следующей стадии (go/no-go).

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

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

В авиации гейтов сначала стало порядка семи, а к 2010 году их стало всего три, при этом даже не все из них связаны с инженерией: например, решение о сворачивании проекта принимается, когда проектирование зашло уже довольно далеко, но не собран достаточный для уверенности в финансовом успехе проекта пакет предзаказов на новую модель самолёта¹².

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

Выбор инженерного процесса и организация разработки

Наши руководства каждый вопрос рассматривают два-три раза с некоторым интервалом и в немного разных контекстах, чтобы натренировать нейронную сетку человека с учётом кривых забывания (приём spaced repetition¹³). Увы, человек не компьютер, чтобы сходу загружать в мозг сжатое и компактное описание какого-то мастерства. Людям (да и AI-агентам тоже) нужно каждое новое понятие и описание его связи с другими понятиями предъявить несколько раз, чтобы произошло запоминание и появились ассоциативные связи с уже имеющимся знанием.

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

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

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

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

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

• Выбрать вид инженерного процесса (концепцию процесса разработки, модель жизненного цикла — выберите себе синоним), и затем

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

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

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

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

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

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

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

• По современному понятию принятия архитектурных решений, оформленных чаще всего как ADR (architecture decision records). На выходе — несколько десятков ADR, которые ограничивают свободу проектировщиков в выборе конструктивов/модулей, а часто ещё и предписывают использование какой-то платформы для обеспечения связи между модулями. Его задача — добиться оптимальной связности между модулями, чтобы были достигнуты требуемые значения важнейших архитектурных характеристик (которые раньше были «требованиями качества»). Минимизация связности помогает независимой разработке модулей разными командами, максимизация связности — повышению каких-то функциональных характеристик. Архитектор ищет тут баланс.

Сейчас вам уже должно быть понятней, что такое инженерный процесс, метод разработки (раньше — модель жизненного цикла) и вы не путаете

• системноинженерный менеджмент, технический менеджмент, организацию инженерных работ, организационное управление (да, это тоже оно — наладить инженерный процесс!), управление инженерным процессом, управление жизненным циклом (тут тоже огромное число синонимов!) и даже организация разработки продукта (product development) с

• управлением работами, управлением процессами, управлением проектами, управлением кейсами, управлением программами работ, операционным менеджментом.

На всякий случай ещё раз напомним основные отличия этих двух скрывающихся за двумя длинными синонимическими рядами разных методов работы в их самых разных вариантах разложения на составляющие и в самой разной связи между собой.

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

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

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

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

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

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

В том числе организатор разработки традиционно гарантирует целостность конфигурации инженерного процесса:

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

• входы одних рабочих процессов смогут работать с выходами других рабочих процессов (например, данные как предметы каких-то методов их обработки будут перекодированы из одних форматов в другие в случае информационных технологий).

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

Организатор разработки может быть реализованным агентами на должностях директора по развитию (в английском это может быть, например, chief transformation officer¹⁴), главным инженера предприятия (главного инженера предприятия не нужно путать с главным инженером проекта, ГИП, который принимает инженерные решения не по поводу создателя, а по поводу разрабатываемой создателями системы. По-английски это будет — CTO, chief technology officer¹⁵). Агенты (отдельные люди или даже целые подразделения под руководством агентов на этой должности) лучше всех разбираются в процессах разработки, ведущих к созданию успешной системы выбранного вида, но должность даёт ещё и полномочия для того, чтобы не просто аналитически «разбираться», но воплотить в физической реальности оргвозможность вести создание и развитие систем по выбранному инженерному процессу.

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

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

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

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

• орг-проектировочную, где делается оргпроект — указывается, какие оргроли играются какими огрзвеньями, какие они должны иметь полномочия и ресурсы,

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

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

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

Не ждите, что везде это будет называться как-то одинаково. Практика организации разработки как отдельная практика новая, понятие жизненного цикла по факту только ушло (вместе с «управлением жизненным циклом»), «метод работы» трудно понимаем, инженерный процесс каждый инженер и каждый менеджер понимают по-своему. Так что имена будут везде разные. Скажем, в методе организации разработки SAFe¹⁶ (они себя называют подходом/framework, scaling agile framework, SAFe, «масштабируемый гибкий подход») определяют переход к непрерывному потоку (continuous flow) в мастерстве (competency) Enterprise Solution Delivery¹⁷.

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

Вот картинка диаграммы из пятой версии SAFe¹⁸, январь 2020:

А вот вариант этой же диаграммы из версии SAFe 6.0, выпущенной в марте 2023¹⁹:

Видим, что «традиционные методы разработки» отступают. От сотни начальных утверждений о будущей системе и множества неотвеченных вопросов в ходе непрерывного хода разработки (flow по-русски всё-таки «ход» в случае как работ, так и разработки, хотя часто переводят и «поток») появляются уже тысячи утверждений о будущей системе, а также накапливается множество принятых решений по поставленным вопросам. Но требований как предмета метода инженерии требований уже нет (хотя какие-то отсылки к ним в других частях документации остаются, но незначительные), остаётся только Evolve the Solution Intent, постепенное формирование намерения/intent иметь конечную форму решения/конструктива системы, при этом видно, что это намерение никогда не оказывается окончательным (часть variable, то есть часть вопросов, не нулевая, а тысячи утверждений о том, какое будет решение всё-таки не формируют собой полностью намерение решения, вопросы остаются).

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

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

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

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

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

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

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

Разнообразие методов управления работами

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

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

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

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

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

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

Если непонятно, какие могут быть большие куски работы в задуманном проекте, то проект переименовывается в программу (которая сама будет состоять из проектов как отдельных «пакетов работ»), а метод управления работами тут — управлении программами (program management, управление программами проектов). По мере понимания содержания работ и требуемых ресурсов для проектов в рамках программы (это инженерная, содержательная работа!), в рамках программы запускаются отдельные составляющие её проекты. Каждый проект будет проходить предварительное/up-front планирование достижения своих контрольных точек (milestones), как в классическом проектном управлении. Но у программы не будет плана запуска отдельных проектов программы (только невнятные неформальные намётки, часто называемые roadmap), ибо деятельность программы как раз и состоит в выявлении этих проектов и планировании их, а дальше работы проектов управляются стандартными методами проектного управления. Скажем, roadmap может быть объявлен для создания и развития системы: создания как выпуска MVP, а развития системы — заранее будет намечено, как во времени будут располагаться какие-то версии системы с увеличивающимися со временем возможностями/фичами. Управление программами отличается от остальных методов управления работами тем, что более мелкие работы (проекты) управляются в них другим методом, нежели сама программа: в программах работ обычно нет «подпрограмм», зато есть «проекты» из проектного управления. В проектах же обычно можно найти подпроекты, в процессах процессного управления — подпроцессы, в кейсах управления кейсами — подкейсы и т.д. Все методы управления работами предусматривают разбиение работ, но методы на каждом уровне разбиения остаются теми же — за редкими исключениями, вроде управления программами проектов, которое предусматривает для своих проектов переход к проектному управлению.

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

Все эти перечисленные варианты методов управления работами потихоньку сдают свои позиции управлению кейсами (case management), которое приходит под самыми разными именами. Собственное имя «управление кейсами» она имеет разве что в медицине, а её варианты в других сферах называются очень по-разному (какой-нибудь «Kanban for development», поддерживаемый софтом issue tracker, или TameFlow с критикой Kanban как устаревшего метода операционного менеджмента).

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

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

Гибкие процессы разработки и управление кейсами

Если полный список работ неизвестен, поэтому контрольные точки (milestones, моменты времени получения определённых результатов в ходе проекта) неизвестны, и ресурсы для выполнения работ тоже неизвестны, а планирование ведётся как в судебных расследованиях (case, «судебное дело») от открывающихся в ходе ведения проекта новых обстоятельств (все разработки/development именно таковы: вы не знаете, очередная инженерная гипотеза/идея приведёт к успеху, или её после неудач в инженерном обосновании придётся отбросить и придумывать что-то новое), то от самой идеи проектирования как предварительного/up-front детального планирования приходится отказаться.

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

Это «послеспиральное» поколение видов/моделей/концепций жизненного цикла получило название гибких (agile, аджайл, эджайл, более правильный перевод был бы «ловкий» или «изворотливый», но в литературе закрепилось «гибкий») методов разработки (agile development process/agile product development). И вот эта терминология «методов разработки» (которые включали в себя и методы введения в эксплуатацию, и даже методы эксплуатации/использования, практики операторов системы) по факту сейчас вытеснила понятия «жизненный цикл» и «управление жизненным циклом». Упоминания «жизненного цикла» остались по факту только в «железной инженерии» больших военных и государственных проектов, где все недостатки связанных с этими понятиями инженерных методов просто замазываются большими деньгами и большими сроками разработки.

Самые разные инженерные процессы, которые относят себя к вариантам гибких/agile подразумевают «операционную гибкость», то есть отсутствие заранее назначенного астрономического момента выполнения работы, отсутствие up-front planning/предварительного планирования. Назначение работы (то есть выделение ресурсов) на какой-то метод может произойти в любой момент проекта — скажем в любой момент, а не только в самом начале проекта можно задействовать методы разработки концепции использования. При этом Ivar Jacobson ехидно замечает, что нет таких организаторов инженерии, которые бы признались, что их инженерные процессы негибкие — даже если речь идёт о «водопадах». Ведь «всегда можно передоговориться», это же везде оговаривается. Но в гибких (инженерных) процессах это уже были не отдельные исключения с возможностью передоговориться, внезапность/незапланированность в появлении каких-то работ признаётся как основное в этих «гибких» методах. Признавалось, что учесть новые обстоятельства и передоговориться — это основное в разработке.

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

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

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

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

Время выполнения работ по кейсу в его состоянии проблемы/«нерешённого вопроса» ещё неизвестно. Есть только ожидаемое состояние предмета кейса, а не контрольная точка (milestone, ожидаемый момент времени события): известно, что должно быть достигнуто, но пока неизвестно, каким методом и когда это может быть достигнуто, ведь непонятно, что же именно делать!

С проблемой кейса проводится исследование:

• Понимается причина возникновения проблемы (это может потребовать проведения дополнительных работ, они будут запланированы как подкейсы этого кейса). Скажем, трюковый самокат осматривается — находится, что разболтался подшипник (проверяются наиболее вероятные причины того, что самокат гремит²¹).

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

• Проводится планирование: оцениваются потребные ресурсы и время, потребное на получение ресурсов и выполнение работы (в том числе и когда метод работ неизвестен в целом, но хотя бы известны возможные первые шаги — планируются они). В результате планирования формулируется пункт плана: задача/задание на работу какого-то ресурса (task). Эти задачи назначаются на ресурсы, которые владеют соответствующими оргвозможностями/capabilities выполнять работы для определённых на предыдущем пункте методов работы. Скажем, для самоката планируется подтягивание оси, оценка времени — пара минут, работа назначена Григорию, у которого есть мастерство механика.

В результате управления кейсами в любой момент времени в проекте есть набор кейсов в разных их состояниях, кейсы из которого надо бы закрыть — и этот набор иногда называют backlog (чаще всего не переводится, так и пишут «бэклог», хотя иногда пишут «портфель невыполненных работ», но там кроме работ/задач ещё могут быть и проблемы/issues, которые часто путают с задачами). Дальше для того, чтобы определить оптимальное распределение ресурсов по этим работам, могут быть использованы удобные для управления кейсами методы планирования, например, канбан (Kanban for development²² для управления кейсами прежде всего, для планирования производственных процессов используется обычно Kanban for manufacturing²³) или TameFlow.

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

Инструментарий, используемый для гибких методов разработки в части управления кейсами как варианта метода управлении работами — это инструментарий трекинга проблем/«нерешённых вопросов» (issue tracking, сегодня часто их называют «системы управления задачами», ибо после issue предмет кейса становится работой/задачей, иногда это «системы отслеживания ошибок», ибо ошибка/bug — это как раз «нерешённый вопрос», «системы отслеживания поручений» — ибо каждое поручение это как раз «поручение решить проблему» или «поручение выполнить запланированную задачу»). Название отражает тот факт, что кейсы появляются не в плановом порядке сразу как «работы», они изначально представляют собой проблему/«нерешённый вопрос» (issue), требующую своего решения. Трекеры (issue trackers, софт для трекинга кейсов²⁴) учитывают эти кейсы по мере их появления. Вопросы (если они признаны важными), превращаются потом в назначаемые на выполняемые конкретными ресурсами задачи/tasks (после определения методов, которые помогут решить вопрос — и дальше планируются и проводятся работы по этим методам), а после выполнения задачи они превращаются ещё в уведомления/notices о завершении. Состояние мира изменилось после решения исходной проблемы/вопроса/issue, и нужно уведомить все заинтересованные в этом проектные роли.

Если появляется возможность что-то спланировать up-front, в управлении кейсами это обязательно делается. Но часто тут план — это просто опыт прохождения какого-то кейса в прошлом, который берётся как шаблон для будущих прохождений. Вот эти записи о прошлом опыте (взятые из папки «Дело», куда записывают всё происходящее в кейсе, case file) и будут называться шаблоном (template), если их используют для планирования повторения какой-нибудь удачной последовательности подкейсов — это и будет шаблоном/паттерном работ, то есть методом/способом работ. Если эти шаблоны (описания методов работы, а часто и оценки требуемых на работы ресурсов) готовят не специально обученные программисты таких шаблонов, а сами участники команды проекта, то такое управление кейсами называют адаптивным (adaptive), а шаблоны — шаблонами сообщества (community template).

Мы различаем:

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

• Управление работами в его самых разных вариантах (например, управление программами и проектами, процессное управление, управление кейсами — когда работы уже назначены и нужно просто их запланировать и отследить выполнение), а в рамках этих разных вариантов методы планирования работ (например, метод критического пути или критической цепи для планирования в управлении проектами, канбан для разработки или TameFlow в управлении кейсами). Управление работами (оно же — операционный менеджмент) тоже входит в инженерию организации, но это деятельность не времени создания организации, а времени использования организации. Операционный менеджер — это оператор уже готовой организации.

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

Вот схематическое изображение инженерного процесса одной из самых распространённых методологий (методология/method — ещё один синоним метода, обычно термин применяется, когда речь идёт о предписанном разложении какого-то метода получения результата «под ключ» на составляющие методы) гибкой (agile) разработки, SCRUM²⁵:

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

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

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

Гибкие методы разработки — это не методы управления работами, а методы создания и развития систем. Скажем, kanban — это один из методов управления работой, TameFlow — это ругающий kanban за его многочисленные недостатки метод управления работой. И TameFlow, и kanban — они вполне могут быть использованы в сочетании с самыми разными вариантами гибких методов разработки. Об этом подробно будет рассказано в руководстве по системному менеджменту — управление работами (оно же — операционный менеджмент) тут один из составляющих методов системного менеджмента. О самих гибких методах разработки и как устроена инженерная работа — это будет рассказано в руководстве системной инженерии. Организация разработки, управление разработкой — это промежуточная дисциплина между инженерией и менеджментом. Содержание её определяется вроде как инженерами, они там обычно методологи, знают SoTA методов инженерной работы, а вот воплощение в жизнь этого содержания, то есть оргархитектура и оргпроектирование, лидерство и администрирование — это делается менеджерами.

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

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

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

При указании варианта метода разработки или метода управления работами команде не нужно говорить SCRUM, или DSDM²⁶, или Open Kanban²⁷, или приводить ещё какие-то названия больших методологий со многими составляющими их методами/практиками. Вряд ли сегодня какая-то команда использует эти методологии во всей их полноте. Но нужно явно и осознанно сказать, какой вид инженерного процесса использует команда и какой вид операционного менеджмента. А ещё надо убедиться, что есть оргвозможность вести работы: все члены команды имеют мастерство выполнения этих методов в целом, мастерство в выполнении их составляющих методов, имеют надлежащие ресурсы и полномочия, а также проверять, что команда идёт именно по этим методам — это и есть «организовать работу». По большому счёту, директор по развитию, главный инженер — они должны создать и развивать именно такую оргвозможность для предприятия.

Какой выбрать вариант процесса разработки? Мы крайне рекомендуем воздерживаться от даже упоминаний традиционного «водопада», всех этих «стадий» и неизбежных «требований», если у вас проект не похож на простую сборку уже спроектированной системы из стандартных деталей, например, стройка типовых многоквартирных домов. Если это стройка типового здания — вперёд, до стадии «отделка» всё будет работать, на стадии «отделка» придётся призадуматься, одни бригады будут красить, другие по свежепокрашенному делать мелкий ремонт — и никакого «водопада» и up-front плана не будет.

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

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

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

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

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

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

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

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

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

В последней версии стандарта ISO 15288:2023 даже есть «6.4.1. Business or mission analysis process». Суть этого рабочего процесса — понять, какую целевую систему берётся делать команда, и определить, стоит ли её вообще делать, соответствует ли это стратегии компании, чья команда будет выполнять проект. Хотя ISO 15288 и содержит в себе отражение «водопада» в части стадий и V-диаграммы в части вида инженерного процесса, но даже однократное прохождение жизненного цикла (без развития системы) как-то надо начинать! На старте проекта готовится концепция использования (OpCon или ConOps, concept of operations, мы их не различаем, но в разных школах инженерии иногда вводят отличия), но чтобы разобраться, не утопично ли создание системы, проводится и разработка первых версий концепции системы (ибо можно написать отличную концепцию использования скатерти-самобранки, но потом обнаружить, что её не из чего сделать, система утопична).

Окончание жизненного цикла системы на сегодня обычно не планируется, хотя вполне могут обсуждаться ожидания по выпуску первой версии продукта (обычно это MVP — minimal viable product²⁸, минимальный жизнеспособный продукт, который и будет потом развиваться).

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

Microsoft объявила, что Windows 10 будет её последней операционной системой, при этом непрерывно производит в ней изменения (выпуск Windows 11 широко обсуждался как имеющий чисто маркетинговое значение, смена названия не привела к тому, что сам продукт существенно изменился, более того, изменения в Windows 11 проходят примерно так же, как в Windows 10 — программы и функциональность потихоньку меняется, но не меняется имя продукта. Просто одни программы в составе Windows потихоньку меняются на другие, это происходит уже много лет). Срок службы атомных электростанций сначала делали 60 лет, но сейчас продляют его до 80 лет, проводя частичные модернизации — при этом часть стран хотят избавиться от атомных станций, а часть стран как раз хочет развивать атомную энергетику. Тесла придумала софтверные изменения для автомобиля, поддерживающие его ценность путём модернизации по ходу эксплуатации, электромобили Tesla не нужно вовремя продавать, они перестают морально устаревать: это изменение бизнес-модели автомобильной промышленности²⁹.

Жизненный цикл системы оказывается не содержащим чёткое заранее определённое число проектов перед выводом из эксплуатации/уничтожением после использования, и может не иметь чёткого срока окончания. И тем самым понятие «жизненного цикла» перестаёт быть важным. Можно говорить о жизненном цикле организма динозавра, но труднее говорить о «жизненном цикле» вида динозавра, который потихоньку за десяток миллионов лет, или чуточку подольше превратился в птичку. Это уже «ход эволюции» (развития системы, изменения в геноме, ведущие к изменению фенома), а не «жизненный цикл» создания одной системы (геном воплощается в свой феном, феном «прокачивается» и используется — и конец истории). Третье поколение системного мышления привело к тому, что мы говорим о создании и развитии системы, а систему понимаем уже как множество экземпляров системы, которые представляют собой разные версии системы. Это похоже на то, как мы воспринимаем биологические виды в ходе эволюции: тех же динозавров, превращающихся в птичек — и, конечно, это рассмотрение идёт на более длинных промежутках времени, чем время жизни одной версии системы. Операционные системы Android и iOS имеют уже огромное количество версий, каждая версия разрабатывается по полгода-году, но сама разработка этих операционных систем как видов систем занимает уже полтора десятка лет (первая версия Android вышла в сентябре 2008 года, первая версия iOS вышла в июне 2007 года, развитие этих систем продолжается).

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

С вот этой бесконечной/неоканчивающейся/открытой/open-ended³¹ разработкой связан ещё один вариант показа стадийности инженерного процесса — как развёртки во времени выпуска версий какой-то системы, roadmap/дорожная карта. Этот термин пришёл из проектного управления³², но всё чаще используется для показа ориентировочных сроков выпуска версий системы. Вот пример инженерного процесса, показанного как жизненный цикл спиральной модели с заданным прохождением водопада несколько раз, с упором на методы не столько инженерии или менеджмента, сколько предпринимательства³³ — и эта диаграмма приведена в совмещении с диаграммой типовой дорожной карты (roadmap, показаны три версии продукта разной степени готовности):

JTBD: клиентоориентированность? Нет, метод-ориентированность!

Мы стратегируем — и получаем по итогам стратегирования стратегию::метод создания и развития системы, планируем и проводим работы по этому методу, отслеживаем в ходе разработки в конечном итоге альфу (воплощения) целевой системы, которая должна будет удовлетворить потребности (needs) внешних проектных ролей. Некоторые из этих внешних проектных ролей обычно скрываются за словами client, customer, user, consumer. То, что в системном подходе было «от границы целевой системы смотрим сначала всегда наружу, в поведение в окружении во время эксплуатации», в бизнес-литературе выражается тем, что в название методологии разработки вставляют какой-то синоним (как обычно, тысячи их) ориентированности на клиента/заказчика/пользователя и добавляют focused, centered, driven, first, oriented или даже obsessed в название метода (в том числе бизнес-стратегии, метода разработки, предоставления сервиса, организационной культуры — слово "метод/процесс" тут тоже имеет множество синонимов):

• Customer-focused

• Consumer-focused

• User-centered

• User-centric

• Customer-driven

• Client-focused

• Market-oriented

• Customer-first

• Customer-obsessed

• Customer-led

• Human-centered

• Client-driven

• User-driven

• Customer-oriented

• Service-oriented

• Audience-focused

Напомним, что первое поколение системного подхода делало акцент на технические процессы и минимальное внимание на клиентах (1950-1980-е), ещё до водопада была модель code-and-fix, структурное программирование, затем «водопад» (предложен Winston W.Royce в 1970, хотя он сам и не использовал слово «waterfall»).

Второе поколение системного подхода заметило людей-создателей и внешние проектные роли. После чего заговорили о прототипировании (1980-е) и спиральной модели (1986), в программировании возникла идея reuse и объектно-ориентированного программирования для переиспользования (потом эта идея была похоронена архитекторами: «повторное использование» оказалось лазейкой, в которую проникали лишние зависимости между модулями). Но там уже была замечена внешняя проектная роль User — и в HCI (human-computer interaction как одной из ветвей software engineering) появился UCD (user-centered design, 1980-1990e). И уже опираясь на это, появился agile с его манифестом в 2001 году и идеями активного сотрудничества с клиентом в ходе разработки. Примерно в это же время (2000е) — идеи lean development в agile, где пытались применить принципы Toyota manufacturing system, lean construction в строительстве с тщетными попытками планировать непланируемое.

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

Третье поколение системного подхода с учётом времени эволюции и самой возможности эволюционирования систем (evolvability), инженерной идеей "непрерывного всего" в разработке (прежде всего «непрерывная сборка» и «непрерывный ввод в эксплуатацию») начинается в 10е годы 21 века, с идей lean startup и дальше с переходом от стартапов к управлению инновациями (innovation management) как выражению той же самой идеи, но уже не только для стартапов, а для всех.

Идея lean была взята у производственников (Toyota production system). Она означала, что не должно быть лишних работ. «Ничего лишнего», lean/элегантно — но не только при производстве, но даже и при задумывании продукта, в стартапе. Но как узнать, что там лишнее, а что нет?

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

В случае людей, наконец, признали, что людей нельзя заставить пройти через стадии обработки, которые дают гарантированные результаты. И надо смотреть на ситуацию не только с точки зрения желающего что-то сделать с клиентом, но и наоборот — с «точки зрения»/«позиции восприятия»/«индекса отсылки»/«referential index» клиента.

Появляется множество разных прикладных методологий клиентоориентированности, слово customer становится центральным. Во всех, конечно, voice of customer с неизбежной критикой, ибо customers при их опросах не могут высказать невысказываемое («изречённое дао — не настоящее дао»), говорят одно, а делают другое, вообще не ощущают свои «боли» и даже не догадываются, что у них болит (ибо надо было находить даже не «потребности», а «боль», чтобы уж точно было желание купить лекарство от этой боли), долгосрочное стратегирование у клиентов вообще на нуле и влиять на него оказалось нельзя — и так далее, список критики этих методологий учёта «голоса клиента» длинный. Поэтому первое же развитие в этой предметной области сдвинуло «голос клиента» (понимающийся как голос персонажа из какой-то «целевой аудитории» — аудитория задавалась образом жизни, возрастом, полом и прочими демографическими характеристиками) на метод работы, который хочет выполнять клиент в своих работах, и дальше смотреть на проблемы этого метода. При этом то, что было важно раньше (возраст, пол, семейное положение и т.д.) абстрагировалось. Внимание начало уделяться методам/функциям, поэтому для новой теории клиенториентированности в разработке термин был предложен jobs to be done, а не works to be done. Важным оказалось то, что делает клиент, метод его работы, и это уже было выделение действительно важного — не надо было гадать, что там выделять из всего «потока сознания», который выдавал клиент и который предлагалось хоть как-то учитывать в ранних методологиях клиентоориентированности.

Outcome-driven innovation³⁴ от Anthony Ulwick, "What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services", 2005. Первый документированный успех «инноваций, ориентированных на общий результат» (outcome), а не на частный результат одной операции (output) был в 1992, патенты по методологии Ulwik получал ещё с 1999 года, затем публикация в HBR в 2002 году, затем — книжка в 2005³⁵. Формально JTBD theory была создана в 1990. В 1990 Ulwik предложил, чтобы компании прекратили фокусироваться на продукте и на клиенте (при этом термин был, помним, «клиентоориентированность»!). Вместо этого компании должны были разобраться с “underlying process” (or job), который клиент пытается выполнить, когда он использует продукт или сервис компании. Грубо говоря, «думай про метод/job, который задействует конечный потребитель, используя продукт или задействуя сервис». Это явная отсылка к методу (job ведь это не «работа» в смысле work, это работа в смысле «занятость каким-то видом труда»). По факту Ulwik в 1990 году предложил искать сигнатуру метода (что с чем клиент хочет делать, и зачем), а дальше компании могли бы предлагать другое разложение метода с использованием своего инструмента. Клиент тогда «наймёт на работу» твой продукт, если метод с твоим продуктом будет получше (дешевле, быстрей, приятней). Всё то же самое, но другая терминология — и оттуда объяснение через какой-то определённый набор метафор.

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

С идеями Ulwick по outcome-driven development довольно рано ознакомился Christensen (тот самый, который предложил в 1997 году термин «disruptive innovation» и написал «Дилемму инноватора»), он и популяризовал подход с некоторыми добавками своих примеров — он и дал название Jobs-to-be-done (с альтернативным термином-синонимом «outcomes that customers are seeking»), в книге 2003 года «The Innovator Solution», когда идеи Ulwik были известны только по публикации в HBR, то есть ещё раньше, чем вышла книга самого Ulwik.

Подход outcome-driven innovation тем самым начал пониматься как происходящий на основе Jobs-to-be-done theory, которую затем тащили в разные предметные области за пределами b2c. В 2016 году Ulwik выпускает книжку уже с термином в заглавии «Jobs to be Done: From Theory to Practice», где показывает, как теорию превратить в рабочий метод. В том же 2016 году выходит аналогичная книжка Christensen с вариантом этого фреймворка, «Competing Against Luck».

Если сделать этот трюк со сдвигом внимания на метод работы клиента с использованием продукта (job to be done), то Ulwik отмечает многие изменения в онтологизации маркетинговых рассмотрений³⁶:

• The unit of analysis is no longer the customer or the product, it’s the core functional “job” [не просто job, а functional job — это чтобы вы не перепутали с work, job тут не синоним для work!] the customer is trying to get done.

• Markets aren’t defined around products, they are defined as groups of people [сообщества!] trying to get a job done [сообщества объединяются по общим методам/культурам/занятостям своих участников, «занятости» тут отсылают к job]

• Customers aren’t buyers, they are job executors [это у нас исправление ошибки «моментом использования системы будет момент её покупки» выпячивание клиента не как пользователя, а как покупателя. Это самая частая начальная ошибка студентов кафедры технологического предпринимательства, а также тех инженеров-менеджеров, которые себя считают «чистыми менеджерами» — им же надо прежде всего продать, а там хоть трава не расти! Нет, моментом использования будет момент эксплуатации/работы/функционирования системы или результата сервиса].

• Needs aren’t vague, latent and unknowable, they are the metrics customers use to measure success when getting a job done. [эта тема выходит на actionable metrics, что требует вообще отдельного разговора — но об этом мы расскажем позже]

• Competitors aren’t companies that make products like yours, they are any solution being used to get the job done [аффордансы могут быть очень разными, а всё новое приходит сбоку — под конкретную сигнатуру может прийти аффорданс совершенно другой природы, это мы подробно разбираем в теории стратегирования в последнем разделе нашего руководства].

• Customer segments aren’t based on demographics or psychographics, they are based on how customers struggle differently to get a job done. [это мы обсуждаем как переход от «метода персон» к рассмотрению методов и внешних проектных ролей не просто «клиента», а уточняющих эту роль — скажем, «игрок» (и даже разные подклассы игроков, если речь идёт о профессиональном геймдизайне), а не просто «клиент». Интересно, что JTBD постулирует акцент на методе, роль и её именование по сути опускается — чтобы сразу перейти к «сообществу как группе с какими-то культурами работы», но рассуждения с точно названной ролью обычно проще]

В jobs-to-be-done и тем самым outcome-driven innovation стараниями главным образом Clayton Christensen³⁷ (самый активный популяризатор теории) появились самые разные варианты понимания метода работы, например:

• Методы-действия (помним, что тут jobs как методы, которыми работает клиент, а не система) как действия (activity), где прямо пишутся «функциональные шаги» (простейшее императивное разложение метода), которые клиент должен предпринять в работе, чтобы получить результат. Инкрементальные улучшения, акцент на «что клиент делает». Это основная линия рассуждений Ulwik, «рабочие процессы клиента с вашим продуктом».

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

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

Популярность тут пришла и из-за того, что огромное число крупных компаний начали использовать ровно вот эти рассуждения, чтобы выяснить эти самые customer jobs — и дальше предложить продукты с улучшенным восприятием/eXperience того, как прошло задействование метода (грубо говоря, ищется вариант впечатления «мне понравилось, как я сработал вами предложенным методом»). Поэтому появилось огромное число success stories и case studies, в вузах пошло массовое обучение теории JTBD.

JTBD отлично интегрируется со многими клиентоориентированными методологиями разработки, они же — маркетинговые методологии (в классическом понимании маркетинга: определить, чем будет выгодно торговать — и найти аргументы для объяснения клиенту его выгод). Конечно, есть огромное число публикаций по поводу этой теории и результирующего современного фреймворка. Вот, например, картинка из исследования 2020 года с альтернативной версией истории JTBD, преодоление противоречий между job с идеей process и идеей progress, но через job steps, и вы сами с использованием материала нашего руководства отойдите от императивного представления процессов в этой картинке³⁸:

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

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

Пример методологии маркетинга: customer eXperience management.

В нулевых годах сделали несколько замеров: оказалось, что впечатления по поводу товаров и сервисов самих клиентов и работников фирм, которые продают эти товары и сервисы, разительно различаются. Конечно, у всех фирм в этот момент уже победили идеи TQM (total quality management)³⁹, и идея о шикарном качестве товара была реализована. Но это качество не связывалось с впечатлениями клиентов — качество шло как отсутствие дефектов! Идеи шести сигм⁴⁰ — это 3.4 дефекта на миллион изделий, не больше, меньше сигм — больше дефектов, так что стремимся к бездефектности на уровне шести сигмам! И вдруг — у нас качественнейшая продукция, но покупают товары конкурентов, ибо плохие впечатления у клиентов оказываются не от бездефектного товара, а от эстетики упаковки, навязчивости рекламы, репутации фирмы (у которой могут быть проблемы не с товарами, а чем-то другим), что угодно. Жизненный цикл (тогда ещё мыслили этими терминами) клиента оказывался не весь проходящим по рабочим процессам, которые проектировались создателями «лояльного клиента» из «просто людей» как сырья. Ключевым там оказались впечатления/experience людей, которые они получали в ходе проводящегося над ними инженерного процесса. У неживых систем впечатлений не было, у животных впечатления мало волновали, а вот у людей, если речь идёт о торговле как добровольных обменах, впечатления оказывались главным объектом внимания в проекте! Так, в маркетинге появился термин «клиентские впечатления»/«customer experience».

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

Продвиженцы (маркетологи, рекламщики, «продажники») поняли, что:

• никому не нужны дрели или сверлильные сервисы,

• но никому не нужны и дырки в стене (outcome-based innovations, смотрим, на что надо нанять наш товар-дрель, идеи JTBD),

• нужны впечатления о том, как хорошо дрель или сверлильный сервис делает дырки в стене и какие чудесные после этого дырки, дополненные впечатлениями о том, как легко было купить дрель, какая она красивая, как приятно лежит в руке, как бесшумно делает дырку, как вежливо общается служба поддержки, если с дрелью что-то не так, как легко эту дрель продать на вторичном рынке дрелей, если она мне не будет долго нужна. Эти впечатления должны быть лучше ожидаемых среднерыночных впечатлений!

• Никакое впечатление не является последним, двигать надо в получение лояльности — и там cross-selling⁴¹, upselling⁴², организация сообществ и так далее. Всё в маркетинге не заканчивается первой покупкой клиента, но превращается в непрерывную череду покупок. Ещё оказался возможен сдвиг части работы фирмы на клиента, причём не только перевод на «самообслуживание», но и на помощь другим клиентам в использовании продуктов и сервисов, а также помощь в самом в продвижении, можно уговорить клиентов делиться впечатлениями о продукте и сервисе, советовать бренд друзьям. Для фирмы оказалось важным делать постоянный приток положительных впечатлений потенциальным клиентам до, во время и уже реальным клиентам после сделок — и сделок этих должно было стать побольше. В том числе продукты и сервисы, а также ожидаемые впечатления даже без изменения продуктов и сервисов надо постоянно менять в ходе «непрерывного всего» — и тут идея рыночных гипотез и их обязательной проверки, а также невечности «рыночного окна».

Итого: важно не просто, чтобы job to be done, но важны положительные впечатления, которые будут получены по ходу выполнения работы внешними проектными ролями.

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

Тренд перехода от торговли товарами и сервисами и только иногда (индустрия развлечений) впечатлениями к торговле исключительно впечатлениями получил название «экономика впечатлений».

Речь идёт о границе тысячелетия, надувался инвестиционный пузырь доткомов⁴³. Компании тогда временно продавались не на основе уже оценки того, сколько они могли бы заработать, а на оценке того, сколько они привлекли клиентов, вбрасывая практически все полученные от инвесторов деньги в рекламу, а не в разработку продукта. А прибыли? Была надежда, что «много клиентов — много прибыли!». Тогда и появилась странная экономическая идея, что клиентам ничего не надо, кроме вау-эффекта, впечатлений/experience, чтобы купить продукт или сервис.

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

По экономике впечатлений (experience economy⁴⁴) в 1998 году вышла статья, в которой говорилось, что после аграрной, индустриальной и даже самой последней, сервис-ориентированной экономики, появился новая экономика — впечатлений. От «хлеба и зрелищ» вроде как перешли к экономике главным образом «зрелищ», ибо товары и сервисы в жизни оказались не главными, в последнее время торговля идёт впечатлениями. В следующем году (1999) вышла уже книжка Pine II и Gilmour, «The experience economy», первое издание. Всё (помним: это был бум доткомов) указывало на то, что и вправду: кто тебя удивил, тот и выиграл, а продукт, сервис и все эти jobs-to-be-done — не так уж важны. Кто даст более сильные впечатления (даже если это впечатления от фильма ужасов — поэтому воспринимаемые положительно, даже если это впечатления радости и счастья от полуобморочного состояния после марафонского пробега или побитости после выхода на боксёрский ринг), тот и победил — поэтому жизнь пойдёт по пути виртуальной реальности и погружения клиентов во впечатления, которые должны приходить к клиентам по всем каналам. А товары и сервисы? Ну, они будут, как остались продукты питания от аграрной экономики, товары длительного спроса от промышленной экономики, какие-то сервисы от сервис-ориентированной экономики. Но всё остальное — это торговля впечатлениями, причём «по проводам» (включая марафонский бег в виртуальной реальности, боксёрский бой в виртуальной реальности, и т.д.). То, что где-то там далеко в Африке люди умирают от недостатка таких товаров как вода и еда, а также таких сервисов, как медицинское обслуживания — ну, это временная трудность, экономика развлечений должна была дойти и до Африки.

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

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

В 2011 году Pine II и Gilmore переиздали апдейт своей книжки по экономике впечатлений 1999 года⁴⁵. Редакция её анонсировала так: «В 1999 году Джозеф Пайн и Джеймс Гилмор предложили эту идею читателям как новый способ думать о связи с клиентами и обеспечении их лояльности. В результате их книга «Экономика впечатлений» теперь стала классикой, принятой читателями и компаниями по всему миру и прочитанной более чем на дюжине языков. И хотя с тех пор мир во многом изменился, путь к сердцу клиента остался прежним. На самом деле, идея постановки впечатлений, чтобы оставить памятное — и прибыльное — впечатление, сейчас актуальна как никогда. С постоянным потоком брендов, атакующих потребителей со всех сторон, как вы можете выделить свой? Добро пожаловать в новую Экономику впечатлений. В этом полностью обновленном издании книги Пайн и Гилмор ещё убедительней доказывают, что впечатления — это недостающее звено между компанией и её потенциальной аудиторией».

Как всегда, надо быть внимательным к типам. Онтология experience (или даже eXperience, для пущего впечатления) в текстах customer eXperience-- то ли сам процесс вовлечения/engagement во взаимодействие (метод вовлечения), то ли само взаимодействие (результат вовлечения, которое тоже взаимодействие для получения целевого уже взаимодействия — например, «уговорить посмотреть рекламу», там «уговорить» — вовлечение, а само взаимодействие — «просмотр рекламы»), то ли впечатление от этого взаимодействия («понравилось, как меня уговорили посмотреть рекламу, понравилось, что я её посмотрел, впечатлён рекламой, имею настрой купить!»).

Одна из проблем в том, что разные люди по-разному понимают тип experience в customer experience — ровно так, как по-разному понимали тип job в job-to-be-done. Мы это разбирали чуть раньше, но напомним:

• Job to be done как цель работы и меру прогресса («нужна дырка в стене», это outcome в outcome-driven innovations — и в том числе тут всякие эмоции и впечатления, социальные последствия и прочее, как варианты outcome, которые появились не так сразу в обсуждениях, но всё-таки появились. Как раз customer experience тут, и по этой линии в обоснование обычно идут разные «теории мотивации» из психологии, нейропсихологии, социопсихологии).

• Job to be done как собственно процесс («сверление дырки в стене дрелью»), метод, который в какой-то момент будет работой. Никакой «психологии», но методология (метод надо описать и оптимизировать), а также операционный менеджмент (ресурсы и время на выполнение работы по методу надо оптимизировать).

Всё то же самое надо повторить для experience — это то ли outcome от процесса, ведущего к прогрессу в достижении цели («позитивные впечатления»), то ли сам процесс получения этих впечатлений. Если почитать тексты про customer experience management — то там онтологический винегрет, проявляющийся в самых разных определениях customer experience::

• Totality of Customer (mental, subjective) Responses⁴⁶. Customer experience is the internal and subjective response customers have to any direct or indirect contact with a company. При этом квалификаторы в тексте, где встречается это определение — good, positive, enjoyable, и вдруг driving в смысле «опыт вождения» (там упоминается BMW) — другое словарное значение! Или «драйвовое» в смысле «бодрое, побуждающее»? А ещё internal, ineffable. «Response to contact with a company» — это по-русски «опыт» или «впечатление»? Противопоставляется тут experience ожиданиям/expectations: Customers instinctively compare each new experience, positive or otherwise, with their previous ones and judge it accordingly — опыт (даже «опыты») оцениваются тут по сравнению с ожиданиями, или "впечатления"? У вас совокупный ответ на то, как вы куда-то спутешествовали (чуть позже мы введём термин «путешествие» и даже термин «контакт», хотя он будет touch, а не как в этом определении contact): опыт этого путешествия, или впечатления от него? А поскольку это «ответы на контакт», то неожиданно там будут когнитивные, поведенческие, сенсорные, социальные ответы — какое тут понятие и поэтому выбранное для перевода слово? «Когнитивные, поведенческие, сенсорные, социальные опыты», или «когнитивный, поведенческий, сенсорный, социальный опыт» (потеряли множественность в накоплении опыта по ходу путешествия), или таки «когнитивные, поведенческие, сенсорные, социальные впечатления» от взаимодействия в «точках контакта» (touchpoints)? В любом случае, это про «ментальное субъективное состояние». Сюда же — experience как impression, тут однозначно «впечатление». Поэтому дальше по этой линии — те самые теории мотивации (грубо говоря, психологические и иногда психосоциальные теории, которые очень плохо работают — если кто-то начинает задействовать такую теорию, а начинают это сейчас делать более-менее все маркетинговые службы, то через несколько соприкосновений с паттернами из этих теорий у вас будет «маркетинговый иммунитет», и результат будет обратным, впечатления негативны, мотивации не будет⁴⁷).

• Sum of interactions, то есть сами взаимодействия «в жизни», из нейтральной внешней позиции восприятия (и уже им потом будет даваться внутренняя субъективная оценка успешности с позиции восприятия клиента). Experience тут — это как «опыт по физике», поведение взаимодействия, а не ментальное состояние. Ментальное состояние будет результатом, «ответом на взаимодействие», как в Totality of Customer responces. То есть experience — это те взаимодействия, которые были у клиента с чем-то, связанным с фирмой в точках контакта. Тут методологическое рассмотрение, «сумма процессов взаимодействия» или рассмотрение операционного менеджмента — «сумма работ взаимодействия». Но и тут можно легко запутаться, потому как часто встречается различение взаимодействий (самый узкий класс), вовлечений (класс пошире) и «опыта»/«впечатлений»⁴⁸. Например, «сustomer experience (CX) is all the interactions customers have with your company at all stages of the customer journey. Whether it’s a call to customer service, observing an ad, or something as simple as paying a bill, every exchange impacts how a customer perceives a business»⁴⁹.

• … есть и самые разные другие понимания: иногда это «срез состояния впечатления», то есть «значение состояния впечатления, впечатлённость» в каждый момент клиентского путешествия. Иногда это — «переменная», значения которой меняются в ходе путешествия, то есть подразумевается какой-то график смены впечатлений во времени.

И даже сокращение experience в customer experience делают двоякое — или СE, или CX (customer eXprerience), а поскольку впечатлениями хотят управлять, то методология получила название customer experience management — и там тоже или CEM, или CXM, никакого однообразия не наблюдается. В английских текстах с использованием experience онтологический винегрет, не ждите пощады, это buzzword — модно, модно уже пару десятков лет, поэтому будет задействовано в самых разных значениях, которые ему хотят приписать. Как разбираться? Как всегда в таких случаях: отслеживать типы, значения типов брать из контекста.

«Управление клиентскими впечатлениями»/«сustomer experience management» как методологию можно считать устоявшимся с 2003 года, когда появилась книжка профессора маркетинга Bernd H. Schmitt «Customer Experience Management: A Revolutionary Approach to Connecting with Your Customers»⁵⁰. Там главное слово вообще не experience, а experiential (по ссылке доступен список наиболее часто встречающихся терминов) — экспериментальный, основанный на эксперименте как опыте, а эксперимент основан на измерениях. Вопросы тут про то, чей опыт (роль) и чего именно опыт (метод). Обычно в customer experience management обсуждался опыт продвиженца (маркетолога, рекламиста, продавца), который или умел что-то продавать, или не умел. Много меньше это был опыт разработчика, который создавал новый продукт (разработчики в этой «серой зоне» между инженерией и маркетингом выбирали более узкие и простые методологии, типа JTBD, и их не интересовал «весь опыт»).

Разворот от классического продвижения 20 века в это новое продвижение 21 века был в клиентоориентированности: эти эксперименты/опыты с компанией вёл клиент, и опыт взаимодействия, вовлечения, получения впечатления был его — а не опыт продвиженца! Смена позиции восприятия: «деталь, обрабатываемая маркетингом, рекламой, продажей» оказалась не пассивной «деталью», а она что-то там тоже делает, что-то чувствует, и в конечном итоге решение принимает не «создатель клиента», а сам «создаваемый клиент»!

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

В русском языке с этим CEM/CXM тоже всё плохо, так что я дам какие-то англоязычные термины для самых разных понятий этой методологии и к ним дам комментарии по переводу на русский. Суть подробного разбора терминологии CEM/CXM в том, чтобы вы получили пример разбирательства с методом, как он встречается в жизни:

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

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

• Цели научить вас чему-то в области CEM/CXM нет, для этого вам придётся почитать литературу. Хотя сразу скажем, что тамошний подход серьёзно сейчас критикуется за то, что метрики «впечатлений» оказываются non-actionable (то есть ты получаешь метрику, по метрике видишь, что «клиент недоволен», но абсолютно не понимаешь, чем недоволен, что с этим делать, с кем на эту тему в компании разговаривать), а также замеры всех этих метрик приводят к тому, что клиент взвывает (когда ему на каждый чих от компании предлагают заполнить пятиминутный обзорчик, «что вам понравилось, что не понравилось, и почему, порекомендуете ли вы наш сервис ещё кому-то» и пресловутое «ваше мнение очень важно для нас» при полном понимании, что там идёт какой-то дикий поток этих откликов, и ваше индивидуальное участие точно потеряется).

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

Вот эти термины и комментарии к их возможному переводу на русский (повторим, что вы должны соотнести понятия этой мета-модели с понятиями мета-мета-модели из наших руководств для инженеров-менеджеров):

• customer — (поэтому это всё из customer-centric методологий), получатель товаров, сервисов и впечатлений (эти впечатления — из experience economy), которые поставляются/provided by компанией.

• customer experience традиционно или «опыт», или «впечатления»⁵¹. Мы уже обсудили, что под customer experience понимается много чего разного: то ли то, что делает клиент (происходит с клиентом), то ли то, что ощущает при этом клиент. Да, сюда включают и что-то знаниевое/познавательное/cognitive, и даже «социальное» (помним критику Фридриха фон Хайека термина «социальный» — когда сказать нечего, то добавляют слово «социальный», как будто это что-то объясняет, например тут — «социальные впечатления» или «социальные взаимодействия»: непонятно, как именно они отличаются от «не социальных»). Примерно в эти же годы, когда появлялась customer experience methodology, появилось много и других методологий с терминами experience и experiential, там и experiential retail⁵², и experiential learning⁵³ (и все из них содержат похожие слова и отсылки, поэтому в литературе нещадно перемешиваются). Даже event marketing⁵⁴ определяется как experiential marketing.

• touches — контакты, то есть взаимодействия, вовлечения, а иногда и "локальные приращения опыта" (и не пытайтесь разобраться, все авторы тут вкладывают свой смысл), которые происходят в точках контакта.

• touchpoint — точка/пункт контакта, где контакт — это те самые touches, «процессы» то ли вовлечения, то ли взаимодействия, то ли «соприкосновения» (авторы тут намеренно говорят мутно, часто добавляют что-нибудь типа «и всё что угодно»). Подразумевается, что компания тщательно создаёт эти точки контакта, это инфраструктура выдачи/получения (тут как «приёмка-сдача», это же взаимодействие) впечатлений. Конечно, в литературе вы увидите дикую путаницу — touchpoints будут типа «процесс», путаться с самими touches, которые там происходят. И да, «контакт» как синоним «точки/места контакта» и «контакт» как «происходящее в месте контакта» — они тоже регулярно путаются между собой. Можно вообще переводить это как «ловушка», ибо компания в ходе customer journey ловит клиента и пытается впечатать ему нужные впечатления, "гипнотизировать" (подробней в «Иммунный ответ мокрой нейросетки на "маркетинг»⁵⁵). Сначала «анализировали», современные версии говорят о «тщательном проектировании», но признают, что большинство взаимодействий случайно.

• channel — иногда специфицируют «канал», по которому происходит touch клиента с touchpoint, например, пришло письмо по почте, или через чат, или через почтовый ящик, или вы поглядели сообщение в «личном кабинете», или кто-то позвонил и сказал. Поэтому «просто» experience (который путают, как мы помним, с совокупностью всех touches или же «всеми взаимодействиями» и «вовлечениями») часто называют omni-channel experience, то есть явно добавляют ещё «общности». Добавить общности — это в customer experience любимый приём, хотя и приводится множество примеров, чтобы было хоть какое-то заземление. В итоге в голове остаётся приятный онтологический туман, сопровождаемый множеством примеров, по которым каждый строит своё собственное представление о понятии.

• customer journey — чаще всего «путь»::«траектория по точкам контакта», но тогда отсекается «путешествие»::процесс::поведение, в котором были получены впечатления! Если это «путь», то легко его увидеть на карте. Путь как последовательность прохождения точек контакта, часто весьма запутан и уникален для каждого отдельного клиента. Сначала это был пошаговый путь по специально спроектированным ловушкам/touchpoints с «промывкой мозгов»/touch клиента с целью дать клиенту позитивные впечатления и добиться каких-то последовательных состояний клиента на каждом маршруте (по факту этот journey мыслился как жёсткая последовательность обработок в «воронке продаж», говорили о «причудливом маршруте», но рисовали жёсткие «шаги процесса»). Затем маркетинговые методологи признали, что не могут повлиять на то, как и в какой последовательности клиент попадает в ловушки, причём часть этих ловушек не они сами ставили (скажем, клиент попадает к недовольному брендом другу и тот рассказывает пару анекдотов о плохих собственных впечатлениях), перестали рисовать жёсткие этапы «жизненного пути/цикла клиента» (перестали говорить о «воронке продаж»). Путь клиента становится не линейным, а графом общего вида, а после того, как наступает понимание, что никакая сделка не является последней, ещё и с кольцами. И это не конец истории, ибо пришлось признать, что путь клиента пролегает и через незапланированные контакты (типа того же «друга, который отговаривает от покупки» или «маркетплейс, где можно найти с отзывы других клиентов», причём клиенты уже отлично распознают фейковые отзывы, проплаченные маркетологами). И ещё всё это происходит в незапланированные моменты времени, так что графовое представление оказывается неадекватным, надо говорить об управлении кейсами. Experience design — это когда пытаются спроектировать впечатление по всем точкам контакта в клиентском путешествии, по какому бы пути оно ни пошло. В какой-то мере это похоже на проектирование игр: игрокам должно казаться, что они делают какие-то собственные выборы, но в реальности их неумолимо ведут по серии каких-то действий, в конце будет какой-то босс, затем запланированный переход на следующий уровень — и для игродела там нет никаких случайностей, а для игрока — вроде как полностью его собственные уникальные выборы. Клиент же попадает в «маркетинговую игру», где его удержать в рамках игры невозможно, он и впрямь может придумать что-то необычное, что не учли маркетологи. «Путешествие» отражает вот этот «процесс» прохождения по «пути». У реки течение как процесс и русло как путь, и ещё есть сама река с течением и руслом — вот тут то же самое с клиентом и его journey. С точки зрения служб маркетинга можно говорить о клиентском потоке в смысле типа «поток» из ISO 15926: поток — это представление системы, удерживающее единство пути.

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

• emotions, feelings — это вполне себе синонимы для одного из пониманий experience (впечатления), которые получаются по ходу путешествия по точкам контакта. Для них есть оценки (позитивность, негативность), получаемые при сравнении с ожиданиями (тот experience, который можно ожидать a priori). И ровно тот пункт, за который ругают метрики: ничего нельзя сказать про то, почему эмоции позитивны или негативны. Разве что если негативны, то «разбираться дальше», метрики non-actionable.

• satisfaction, удовлетворение как степень соответствия experience ожиданиям. Лояльность/loyalty тут же: правдоподобность того, что клиент будет и дальше путешествовать по touchpoints. И тут же множество их метрик, которые, конечно, должны потом стать actionable metrics, но пока с этим плохо, а ещё плохо с тем, что добыча данных для этих метрик приводит к «усталости» клиентов, сама по себе раздражает. Вас никогда не спрашивали по десять раз за день в самые неподходящие моменты: «ты меня любишь? Крепко-крепко? Будешь рекомендовать меня своему другу? А за что ты меня любишь? Твоё мнение крайне важно для меня!».

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

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

• Личность может сама пройти такие обработки, которые вы не предусмотрели.

• Конкуренты тоже ведут свои обработки (или даже успели эти обработки провести перед вашими попытками повлиять на личность).

• … и такого довольно много. Личность принадлежит себе — и это как-то сразу не даёт вам возможность что-то с ней делать без предварительного согласия. А, например, продвиженцам ровно это и нужно: заманить без предварительного согласия, научить покупать их продукт! Учителям нужно согласие родителей, а не детей, чтобы их учить — а вот чему учить, они даже у родителей спрашивать не будут.

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

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

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

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

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

• Цифровая трансформация тут будет — переход от CRM (customer relationship management), информация о части путешествий клиента, часть контактов) к CXP (customer eXperience platform, информация обо всех контактах, сквозная для всех служб — маркетинга, продаж, обслуживания и даже проектирования и производства). Но об этом будет подробней в руководстве по системному менеджменту.

• -- ...добавьте сюда что-нибудь сами.

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

Дальше идея eXperience пошла работать и с другими ролями: стали обсуждать и employee experience, и community member experience, и самые разные прочие experience.

Иллюстрации диаграмм для customer experience journey погуглите сами — и оцените, сколько их наследуется со времён «водопадов» и отражающих их в маркетинге «воронок продаж», а сколько отражают современные идеи учёта самопринадлежности клиента, который не всегда идёт туда, куда его пытаются направить.

Клиентоориентированность и управление впечатлениями

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

Мы можем излагать это самыми разными словами. Основная терминология нашего руководства взята из инженерного процесса в его современных версиях непрерывной/agile разработки. Но речь идёт об общих паттернах деятельности и общих паттернах описания этой деятельности. Experience management (тут намеренно опущено слово customer, ибо мы собираемся сейчас обобщить эту онтологию) говорит, что рассказ таки нужно вести с точки зрения изменения состояний создаваемой и обсуждаемой системы, причём в случае интеллектуальных агентов принимая во внимание:

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

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

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

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

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

• в машиностроении в терминах «процесса разработки» или «инженерного процесса» с последующим разложением его на несколько уровней «практик»/practice. Например, мы создаём и развиваем гравицапу, для которой мы применяем процесс «scaled грави-agile с поправками для цап». Наши самые разные инженеры (архитекторы, проектировщики, технологи и т.д.) двигают альфу гравицапы как воплощение целевой системы по её состояниям от «задумано», через «спроектировано» и «изготовлено» до «используется» и даже «выведена из эксплуатации» (взяты состояния из классического типового «водопадного» рассмотрения), пытаясь как-то скоординироваться. Гравицапа находится в состояниях «как замысел», «как проект/design», «в виде сырья», «готовая» и когда-нибудь «мусор». Чтобы не запутаться, версии проекта храним в PDM (информационная система product data management, хранение данных о продукте, и только о продукте), работы и прохождение состояний — в issue tracker (а поскольку мы современны, то это вместе называем PLM, информационная система product lifecycle management, определяемая как система хранения данных о продукте и ещё чём-то, в данном случае кейсах работы с продуктами, поддержка версионирования и управления кейсами, в софте это обычно в разных системах, а в машиностроении и строительстве — в одной), версии того, что происходит с воплощениями в ходе изготовления храним в ERP (ибо это «ресурсы», речь идёт об enterprise resource planning, и не путайте с «бухгалтерской системой» — в ERP есть алгоритм планирования ресурсов, в бухгалтерских системах его нет), версии в ходе эксплуатации в EAM (информационные системы enterprise asset management, и там ведётся учёт данных о поломках и ремонтах воплощений).

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

• В терминах путешествий, контактов, точек контактов и обязательно впечатлений или опыта (experience) там, где есть автономные интеллектуальные агенты, которые могут запросто сами что-то задумать и сделать. Обычно это люди, но могут быть сегодня и какими-нибудь AI-системами, а также коллективами из них всех (при этом коллективы вроде организации, «лица» мы ещё признаём как-то с натяжкой агентами, иногда даже государства признаём такими «лицами», но вот сообщества и общества, даже клиентуры и даже инвестуры — тут с агентностью проблема⁵⁶). Если создатели с ними работают, то возникает проблема: агенты ещё и сами себе создатели, поэтому нельзя планово переводить их из одних требуемых состояний к другим –«лошадь можно подвести к воде, а заставить попить — нельзя». Ещё они могут быть сразу в двух или больше состояниях (выделяются подальфы) и появляться у провайдеров разных обработок в заранее неизвестном порядке (ибо ещё и сами ходят, а не их за ручку водят). И ещё у них есть свои впечатления от происходящего. Если эти впечатления (или в другой терминологии — полученный опыт) становятся отрицательными, то всё, можно списывать все предыдущие потраченные на них силы, результата (скажем, покупки) не будет. Впрочем, даже гравицапу можно испортить на любом шаге обработки, это не является чем-то особенным, гравицапа может прилететь на твёрдый пол где-нибудь в ходе строго предписанной последовательности обработок и погнуться, так что идея «путешествия» с незапланированными обработками в незапланированных точках контакта вполне может работать и тут. Понятно, что надо отслеживать experience (впечатления) агентов-людей в ходе контактов/touches (и тут много чего может быть разного в ходе контакта-как-процесса: вовлечение, обучение, формирование впечатлений, взаимодействие и т.д.) с нашими создателями/местами-обработки/местами-контакта/touchpoints. Но ещё можно подумать и о впечатлениях внешних проектных ролей при инженерном процессе с чем-то «не очень живым и агентным», с теми же гравицапами. У гравицапы впечатлений нет, а вот у проектных ролей (и внешних, и внутренних) в ходе проекта создания и развития гравицапы впечатления будут. Кто-нибудь их планирует?

• … есть и множество других вариантов в самых разных предметных областях. Вы должны понимать, что все эти варианты — попытки разными словами и немного разными понятиями рассказать про одно и то же, про метод/культуру/стиль/способ работы: какой-то создатель в какой-то роли берёт какой-то объект и проводит его через ряд состояний каким-то методом, причём можно разложить этот метод на составляющие, в том числе и разложить роль на подроли — примерно так, как мы обсуждали в первом разделе руководства. И для всех этих вариантов мы понимаем, что легко выразить что-то одно, но чуть труднее — что-то другое, поэтому приходится дорабатывать описания методов, если чего-то не хватает. И использовать при этом терминологию, привычную в той или иной предметной области.

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

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

В маркетинге этот подход уже более-менее мейнстримный, customer journey уже в развитых странах вытеснил sales funnel, но по факту понимается он не как «причудливое путешествие» вместо «строгой последовательности шагов», а как «смена позиции восприятия». «Водопад» в мышлении оказывается бессмертен.

На диаграммах сейчас какой-то гибрид. Посмотрите на картинки: о нелинейном customer journey в тексте говорят «как надо», а иллюстрации приводят такие, что воронка продаж и путешествие клиента оказываются неразличимыми. Это та же «колбаска» прохода разных обработок клиента для перевода клиента в разные состояния, только там вроде как чуть побольше стадий и они более красочно нарисованы (вероятно, чтобы отразить «впечатления»). Вот типичная customer journey map⁵⁷, пример на русском:

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

Маркетологи уже договорились, что вообще неплохо бы иметь «бесконечное путешествие» — и продавать, продавать, продавать по up-sales и cross-sales что-нибудь до самой смерти или компании, или клиента, а также вербовать в сотрудники (делать из клиентов собственный touchpoint — загонять в сообщество клиентов, предлагать рекомендовать продукт знакомым, вовлекать в помощь другим клиентам в пользовании продуктом, разгружая свои колл-центры, и т.д.). Это всё было «управление жизненным циклом» клиента, теперь это стало «управлением путешествиями» клиента (customer journey management), хотя картинки и остались почти прежними (на них стадии обработки остались, но результат обработки теперь ещё и включает опыт/впечатления — чтобы не забывали о смене позиции восприятия с «как задумал маркетолог» на «как отреагировал на эту задумку клиент»).

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

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

• Управление впечатлениями. Оценка реальных впечатлений по сравнению с ожиданием этих впечатлений должна оставаться положительной. Нужно моделировать по реальным замерам впечатления по ходу путешествия агента (замерять что-то, а затем косвенно определять впечатления — ибо на постоянные расспросы «потратьте пять минут на то, чтобы оценить наш продукт» люди реагируют уже крайне нервно), а не только иметь проект впечатлений, которые хотят дать сотрудники. Это называют не «клиентоориентированность», а experience management: управление впечатлениями по мере путешествия по точкам контакта. Управлять впечатлениями — это проектировать такие точки контакта, чтобы контакты в них оставляли положительные впечатления, «превосходили ожидания».

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

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

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

Собранность как удержание (в компаниях — коллективного) внимания на каком-то объекте сегодня обеспечивается не «ментальными практиками», а информационными системами: базами данных, которые помнят о состояниях самых разных объектов, получаемых в ходе их путешествия (и вы к слову «путешествие» сами должны добавить «по точкам контактов» и подумать о разветвлённом графе состояний объекта как предмета метода. Эти состояния меняются в ходе собственно контактов как обработок этих объектов как предметов метода по каким-то методам. Вот это и есть онтологическое мышление: видите одно слово для понятия какой-то онтики, восстанавливаете в этом месте полную онтику). Эти информационные системы служат для усиления возможностей головного мозга, они как бы «внешняя кора головного мозга», экзокортекс (по аналогии с неокортексом — это «новая кора» как часть головного мозга человека, которая отвечает за высшие психические функции). Термин «экзокортекс» был предложен довольно давно, напрямую связывается с нейроинтерфейсами и относится к фантастике и трансгуманистическим технологиям⁵⁸. В 21 веке стало понятно, что усиливать способности к мышлению (прежде всего за счёт возможности управлять вниманием и обеспечивать надёжную память) могут даже карандаш и бумага, а уж компьютер — тем более. А поскольку собранность (управление вниманием и памятью) нужна не только индивидуальная, но и коллективная, то термин прижился. Мы будем называть корпоративные информационные системы коллективным экзокортексом, чтобы подчеркнуть, что речь идёт прежде всего об удержании коллективной собранности: удержание в корпоративном внимании и обеспечении надёжной памяти для сведений о состояниях самых разных предметов методов, которыми занимается компания. Для обсуждения программного обеспечения, используемого как личные и корпоративные экзокортексы, есть даже чат «Экзокортекс (МИМ)»⁵⁹. При этом идея экзокортекса продолжает развиваться для других классов программного обеспечения, например, предполагается использование AI-агентов как экзокортекса⁶⁰.

Экзокортексы для «клиентоориентированности» и «управления впечатлениями» будут предлагаться самые разные, часть из них будет прямо поддерживать «водопад» (по-старинке они будут хвастаться тем, что «реализуют классическое проектное управление», как будто это хорошо), часть — кейс-менеджмент (по-современному это и будет «проект» с планированием чаще всего «на лету» и ведением case files, «папок дел»). Ещё часть будет поддерживать старинное «процессное управление», где 95% экземпляров процессов проходят по стандартному маршруту, а 5% становятся дикой головной болью ввиду нестандартности своего путешествия и неминуемых отрицательных впечатлений при нерешении проблем, они занимают 95% времени на внимание к себе. Вот примерно так выглядел вариант процессного управления нулевых годов 21 века, до появления кейс-менеджмента для agile инженерных процессов, где эти 5% кейсов — просто кейсы, штатная, а не «проблемная» ситуация.

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

Скажем, только в области маркетинга вам в 2024 будет предложено 14106 софтверных продуктов самых разных типов (MarTech — маркетинговые технологии), и по факту вы можете сказать, что все они поддерживают собранность работников служб продвижения, помогают планировать и реализовывать клиентские путешествия⁶¹:

Что из них вам надо? Что не надо? Что из них поддерживает допотопные способы мышления? Что заведомо не сработает?

Понятно, что таксоны в классификации MartechMap взяты «исторически» и ничему осмысленному не соответствуют. Легко найти множество других классификаций (ни один термин в этих классификациях не повторяется, они построены на разных принципах, отражают принципиально разные описания маркетинга! хотя повсеместно повторяются уже знакомые нам слова: marketing, experience, customer, channel, journey). Конечно, все поставщики софта называют свои продукты «платформами», уже давно не «приложениями» и не «комплексами/suite». Эти «платформы» обычно пытаются сделать необъятными в числе поддерживаемых прикладных модулей (тех же «приложений»). Если вы поняли, что путешествие потока заготовок по машиностроительному заводу (отслеживается классом софта ERP, enterprise resource planning) эквивалентно путешествию клиента по точкам контакта, то легко представить, что оно будет отслеживаться каким-то вариантом ECRP как эквивалентом ERP в машиностроении (enterprise client resource planning, планирование клиентских ресурсов предприятия, пошутим так), но тут же эта первая приходящая на ум аналогия не выдерживает критики: на склад «клиентские заготовки» и «клиентские полуфабрикаты» не положишь, «клиентское сырьё» на условиях just-in-time не закупишь.

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

Пример тут — как рассуждать о том, как какого-то «проходящего мимо агента» готовят к выполнению какой-то роли, организуя его путешествие:

• Customer journey — мы только что довольно подробно рассмотрели вопрос про клиентское впечатление. Отдельно можно говорить о пользовательском (как становятся пользователем продукта, но необязательно платящим, например, на тарифных планах free в бизнес-моделях freemium⁶²) и именно клиентском путешествии как путешествии пользователя, который таки заплатил и находится в финансовых отношениях с компанией, получает «премиальное обслуживание». В любом случае, «клиенториентированность» идёт от клиента, customer. И eXperience management с идеей journey начинался именно на примере customer. Путешествия других проектных ролей с отслеживанием их впечатлений были предложены позднее.

• Employee journey тут идёт по примерно такой же линии рассуждений, только тут не клиентоориентированность, а сотруднико-ориентированность. И тут тоже отход от «водопада» к разным траекториям/путям/маршрутам путешествия по организации, и это тоже надо отслеживать. И там тоже eXperience/впечатление/опыт, вовлечение/engagement, мотивирование, попытки проектирования маршрута и неожиданные места контакта (touchpoints) с неожиданными результатами этих контактов, в конечном итоге — превращения «проходящего мимо человека из целевой аудитории» в кандидата на занятие вакантной должности, а затем сотрудника на этой должности, с возможным ещё карьерным путешествием career journey и тоже обязательным отслеживанием впечатлений и индивидуализацией этих путешествий.

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

• Community member journey, и тут тоже полно всяких «платформ» по поддержке сообществ, и тоже «путешествие, которое мы планируем» существенно отличается от «путешествия, какое было у члена сообщества», а ещё у сообществ не всегда чётко определённое членство и главное — сообщества не имеют чётко определённой одинаковой культуры, которую можно было бы легко поддержать софтом. AI это вроде должен менять, но пока это всё только в далёких планах.

• Investor journey, ибо инвестора надо где-то найти, затем провести с ним переговоры и дальше поддерживать с ним отношения, а этих инвесторов может быть много (впрочем, даже если и один, у него тоже будет «путешествие» по отношению к компании).

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

Экзокортекс для коллективного отслеживания всех этих «путешествий» имеет самые разные названия:

• Для «путешествия» софта или классических инженерных систем будет использоваться internal engineering platform, занимаются этим platform engineers⁶³.

• Для «путешествий» клиентов будут использованы системы CRM (customer relationship management⁶⁴), заниматься этим будут в службе продаж, или CXP (customer experience platform⁶⁵), заниматься этим будут в самых разных службах (и чаще службах маркетинга, как основных, а не только службах продаж),

• Для «путешествия» сотрудников этим будут заниматься административные системы (employee experience platform⁶⁶), заниматься этим будет администрация предприятия

• … и так далее.

Не всегда stakeholder journey map (общее название для описания путешествия агента по занятию и развитию какой-то роли) соответствует реальным путешествиям, ибо всегда есть какие-то неосознанные (и поэтому не описанные и не поддержанные соответствующими платформами), но важные состояния агента в этом путешествии, а также всегда есть не осознанные (и поэтому не описанные и не поддержанные соответствующими платформами) влияния в не осознанных точках контакта, которые меняют состояния агента в его путешествии по графу состояний на пути к занятию роли и дальнейшему развитию своих навыков работы в роли. Надо быть всегда начеку, надо заниматься постоянным развитием своих платформ, развитием экзокортекса компании.

Надо выявлять незапланированные части путешествий предметов метода даже для не очень живых продуктов. Например, вы отдаёте на завод информационную модель, завод раздаёт её фрагменты для «изготовления по кооперации» (то есть отдаёт субподрядчикам), там «улучшают» части 3D-информационной модели изделия/продукта, полученные от КБ, причём делают (иногда из самых лучших побуждений!) круглое квадратным и наоборот. Потом все эти изменённые непонятно кем непонятно где (и не проверенные поэтому конструкторским бюро) информационные модели изделия превращаются на заводе в металлические части, которые не могут быть собраны вместе. Почему? Неучтённый в internal engineering platform внешний touchpoint (а теория говорит, что обработки предметов метода могут происходить и в незапланированных точках, это всегда надо ожидать), где информационная модель изменяется подрядчиками завода по каким-то своим соображениям. Как решать эти проблемы? Отследить маршрут информационных моделей и резко снизить затраты времени и нервов (eXperience всех участников инженерного процесса) на согласование изменений информационных моделей с КБ.

Другой пример будет в методе «пропитки» как подготовке к организационным изменениям из руководства по системному менеджменту: решения принимаются не теми, с кем вы разговаривали и кого уговаривали, а какими-то их влиятельными друзьями, с которыми советуются вроде бы «принимающие решения лица». Вы уговорите начальника что-то сделать, но в последний момент он посоветуется со своим другом, который будет против этого просто потому, что не хочет рисковать сам и начальнику будет советовать «не рисковать!». Этот друг ничего не знает про ваши аргументы, вы же не с ним разговаривали! В результате посоветовавшийся со своим другом начальник легко откажется от договорённостей с вами: своему менее разбирающемуся в ваших аргументах другу начальник верит больше, чем вам. А этих друзей будет несколько. Поэтому «убалтывать» надо этих друзей, а поскольку вы не знаете, кто они, то хорошо бы уболтать вообще всех потенциальных «советчиков лица, принимающего решения» — и тогда нужное решение не встретит скрытого сопротивления. Это всё экземпляры общего рассуждения, customer experience management и customer journey тут только примеры (скажем, вам надо убедить купить какой-то продукт не только клиента, но и друзей клиента, поэтому знать о продукте и его свойствах хорошо бы не только покупателю, но и всем вообще людям — вы не знаете, кто будет давать по поводу покупки вашего продукта последний самый важный совет потенциальному покупателю).

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

Корпоративные экзокортексы для управления впечатлениями: CRM, CXP, DXP, LXP.

Трудно поверить, но ещё до информационных систем CRM (customer relationship management), то есть ещё в далёких 80х годах гуляли слова

• Database marketing⁶⁷. Им занимались «официальные спамеры» (spamming⁶⁸), которые вели списки рассылки direct marketing⁶⁹. Для того, чтобы поднять эффективность (это было ещё в эпоху бумажной рекламы через почту), надо было рассылать рекламу не всем подряд, но делая «выборку из базы данных».

• Relationship marketing⁷⁰. Для него важней было удержать отношения, «никакая продажа не является последней». Relationships/отношения — это когда у продавца не одномоментная сделка, а длящиеся во времени отношения, и хорошо бы накапливать об этом информацию, иметь память о том, с кем компания в каких отношениях, как эти отношения развивались, какие есть планы по дальнейшему «развитию отношений» (это эвфемизм для «что мы можем туда ещё продать»). Для поддержки отношений нужна была база данных, экзокортекс — разгрузить ненадёжный мозг sales managers, дать им компьютерную систему вместо ручки и бумажки. База данных (свежий ещё термин в 80х) как раз и должна была быть такой памятью о клиенте и проходимых им состояниях в его путешествии (хотя слова «путешествие» ещё не было, но «воронка продаж» — это уже было).

Дальше для целей маркетинга и взаимодействия с клиентами развивались document management systems (DMS⁷¹), монстрообразные системы сначала просто документооборота, которые главным образом хранили документы — в том числе договорную документацию по каким-то клиентам, но могли хранить и протоколы совещаний и всё остальное, что касалось продаж и маркетинга. Потом это стало enterprise content management (ECM⁷², с 2017 года предпочтительное название — intelligent information management), ибо маркетинг часто и с картинками работал, и с видео, и даже потом вебсайты там уже были с середины 90х, и там были уже просто content management systems (CMS⁷³). Конечно, все эти понятия применялись весьма широко и чёткого отнесения конкретного софта к этим классам не было. Тем не менее, в CMS не было ориентации на клиента, скорее это была ориентация на «неопределённо широкий круг лиц». Деньги были большие, но, как любил подчёркивать Jensen Huang, самые большие деньги — в специализации. Никому не нужны «чипы для искусственного интеллекта», но вот «чипы для серверов в датацентрах», «чипы для видеоигр», «чипы для обработки медицинских изображений» — это совсем другое дело, хотя это всё один и тот же чип, только в немного другой обёртке, но эту обёртку уже много проще соотнести с источником денег. Ибо «нужно всем» чаще всего означает «не нужно никому».

Content management system была роленезависимой, она не была настроена на какое-то «путешествие», на то, чтобы быть internal development platform для удерживания состояния агентов в их путешествии на занятие какой-то внешней или внутренней роли (stakeholder), например, путешествия «людей с улицы» в «клиенты». Агента для этой роли клиента (customer) надо было поймать где-то «на улице» (то есть неизвестно, где именно, скажем, перехватить красочной рекламой взгляд при просмотре какого-то вебсайта, например, вебсайта газеты), затем обучить роли (мастерство — знать продукт, любить продукт, купить продукт), затем удержать от ухода к конкурентам, затем доить вечно. Это, конечно, очень неформальный способ разговора о маркетинге, но он тут намеренно. Обычно у продвиженцев нейтральный язык, там даже спам называют не спамом, а direct marketing. Поэтому для продвиженцев в компании тут было бы приятно и привычно прочесть «обеспечивать лояльность и повторные покупки по линиям cross-sales и upsales», но это слова продвиженцев. «С другой стороны баррикады» это «меня хотят поймать, заставить купить, затем будут удерживать и надеются доить вечно».

База данных для database marketing и relationship marketing ничем принципиально не отличалась от типичной ECM системы, но имела в схеме данных и своих отчётах главную сущность customer. Чтобы как-то выделить этот менее универсальный класс систем «управления контентом», такого сорта базам данных дали с середины 90х прошлого столетия название customer relationship management, CRM⁷⁴ — новый класс информационных систем (который, конечно, ни разу не был новым) для служб продаж. Это была не столько менеджерская или айтишная идея, сколько айтишный «голимый маркетинг» своих «универсальных баз данных» с какой-то моделью данных событий, происходящих в ходе account-based marketing и account management. Смотрите на тон предыдущего предложения: сами продвиженцы-менеджеры или айтишники никогда про свои системы так не скажут, но язык вполне может выражать оценку других ролей, смену референтного интекса, позиции восприятия: «доблестные разведчики» становятся «презренными шпионами».

Account — это как раз реестр данных о контактах с клиентом. Там и контакты клиента для связи с ним (ещё одно значение русского слова «контакт»: кроме места контакта и процесса контакта тут «адрес канала клиента» — канал тут «способ связи», то есть почта, или чат в мессенджере, или телефон, или даже бумажная почта). Этот account-based marketing⁷⁵ cам по себе отдельная методология маркетинга. И вот в 1993 году Tomas Siebel покинул Oracle Corporation, чтобы основать Siebel Systems, которая стала одним из ведущих поставщиков программного обеспечения CRM. Компания Siebel сыграла значительную роль в популяризации этого термина. Примерно в это же время другие компании-разработчики корпоративного программного обеспечения, такие как SAP и Oracle, также начали разрабатывать и продвигать решения CRM, главным образом для служб продаж (а не для использования всеми остальными службами с их touchpoints, например, службами маркетинга, службами рекламы, службами клиентской поддержки).

Тут и пришёл в нулевые годы 21 века experience management, который сказал, что клиент взаимодействует не только со службой продаж, но и с результатами работы чуть ли не всех служб компании, и речь идёт не только о ключевых клиентах, но и вообще всех клиентах, и всю информацию по самым разным местам контакта и взаимодействиям надо собрать и накопить. Компания тем самым должна иметь базу данных прежде всего по впечатлениям (eXperience), которая будет использоваться всеми (platform, а не просто какая-то там system). Родился термин customer eXperience platform (CXP). Ссылок не даём намеренно, погуглите, у всех провайдеров есть своя страничка рассказа, что это за класс программных продуктов.

Главный объект в CXP — карта путешествия (journey map), которая в существенной мере состоит из списка запланированных (и иногда паразитных) контактов/touchpoints. CXP предполагает проектирование маршрута клиента по этой map, какие-то возможности по кастомизации маршрута для управления впечатлениями. Почему не просто «система управления», а именно «платформа»? Потому что CRM и прочие системы поддержки «управления» предполагалось использовать в рамках какого-то одного подразделения, а вот платформа была изначально предназначена для использования всеми службами предприятия. Предполагался полный продвиженческий (маркетинг, реклама, продажа, постпродажное обслуживание) конвейер «от и до», это был экзокортекс для всех служб компании. Такой конвейер в инженерии — internal development plaftform, только по конвейеру тут идёт какой-то агент, обрабатываясь до состояния customer.

CXP имеет особенность: там важен сбор откликов по тому, что происходит с клиентом. Главным там оказывается не journey, не само путешествие, но тот самый experience, впечатление. Эти системы продвигались не столько как «базы данных для учёта клиентов», сколько как «базы данных для накопления сведений о впечатлениях клиента, о состояниях клиента», упор на съём показателей, «получение обратной связи». Конечно, внутри таких информационных систем есть и вполне универсальный моделер для предметной области customer journey management, но акцент всё-таки на outcome, «что на выходе путешествия в целом»: всем службам надо знать, какие там у клиентов впечатления, какова их лояльность — и где там на маршруте возникают проблемы, чтобы их устранять, не терять клиентов.

Есть и класс специализированных информационных систем для customer journey management (CJM, а не CXP). Это специализированные системы управления процессами, они пытаются не столько собирать информацию про «полученный в ходе путешествия опыт», сколько отслеживать само «путешествие», проход по точкам контакта, по сути дела это разновидности issue trackers.

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

Поскольку мы тут говорим о более-менее общем механизме рассуждения «прохождения людей по конвейеру», то довольно скоро был сделан последний шаг — CXP как customer eXperience platform переименовывается в DXP — digital eXperience platform, и там уже речь идёт не просто о впечатлениях, а о «цифровых впечатлениях», то есть предполагается, что «обработка клиента» ведётся главным образом через цифровые каналы. Задача DXP — create, manage, optimize, and deliver seamless and consistent digital customer experiences across multiple channels and touchpoints. Впрямую путешествие тут не упоминается, зато подчёркивается множественность каналов и множественность точек контакта. На сегодня на рынке представлено довольно много подобного софта⁷⁶.

У разработчиков DXP eXperience становится больше «взаимодействием» (interaction), которое хорошо протоколируется — ибо «впечатление» маркетологов не запротоколируешь. Но, понятно, это «великолепные взаимодействия/experiences», которые маркетологи трактуют как «великолепные впечатления/epxerience» — несмотря на онтологическую путаницу, разработчики софта и маркетологи отлично находят общий язык.

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

Customer или digital в CXP или DXP при этом заменяется на что угодно, остаётся *XP, которая читается или «платформа впечатлений/опыта», или (в трактовке программистов) — платформа взаимодействий. Например, Dassault Systèmes⁷⁷ выпускала:

• PDM (product data management) систему, это была ENOVIA PDM, 1998 год. Это была торговля по сути чужим продуктом фирмы ENOVIA, купленным Dassault Systèmes, никакой особой интеграции с CAD от Dassault Systèmes даже не было, никакой «платформенности» и «взаимодействий». Это было просто отражение идеи первого поколения системного мышления: собрать все данные об изделиях машиностроения (и иногда — строительства), тогда это были главным образом чертежи с выходом на сводно-заказную спецификацию (BoM, bill of materials) продукта/изделия.

• PLM систему (product lifecycle management). Это было буквально через год-другой после старта продаж PDM ENOVIA. В 1999-2000 годах, ENOVIA уже продавалась как PLM Solution. PLM формально определяется как «база данных, в которой кроме данных о продукте лежат ещё какие-то данные», и там лежали данные о создателях — кто что с этими описаниями продукта делал, там внутри был issue tracker, то есть «данные о работах создателей», это было главное отличие. До полного жизненного цикла в сборе данных в этом продукте так и не добрались, но хотя бы стадию проектирования закрыли — в машиностроении тогда ещё обслуживался «водопад», каждая стадия предполагала свой вид систем.

• DXP систему (digital experience platform) Dassault Systèmes запустила в 2012, это была 3DEXPERIENCE. Слоган там был — integrating all aspects of a business into a single platform. Но слоган для PLM системы был для большинства инженеров неотличим: данные о продукте и всём остальном, что с ним происходит, на всех стадиях. Что же было нового по сравнению с ENOVIA? То, что окончательно перешли от 2D проектирования к 3D проектированию? Нет. Вот как описывается 3DEXPERIENCE: «It provides a holistic, real-time view of business activity and ecosystem, fostering innovation and collaboration not just within engineering teams but across the entire organization, including marketing, sales, and external partners. The platform enables companies to create unique customer experiences by leveraging virtual universes to simulate and optimize products and processes before actual production» — это мы видим описание в продукте для инженеров основных идей customer experience management.

Идеи «из маркетинга» съели идеи инженеров с их сухими описаниями PLM, а также идеи эккаунт-менеджеров с их CRM, а также все остальные «частные идеи» отдельных информационных систем, предназначенных для отдельных инженерных стадий или отдельных служб компаний. Если вспомнить, чем там хвасталась Dassault Systèmes при запуске своей DXP, так это всякими интеграциями вовне фирм, которые закупали 3DEXPERIENCE: во всех рекламных роликах рассказывалось, как выложить 3D-информационную модель для какого-то каталога комплектующих, как потом показать виртуальную модель изделия клиентам машиностроительных предприятий, как подключить каких-то внешних инженеров для участия в разработке. Все это объяснялось через важность обустройства точек контакта и акцент делался на цифровые каналы, по которым шли и документировались взаимодействия в этих точках контакта, которых много, очень много, и софт поможет их организовать.

Это типовой язык для DXP, так что 3DEXPERIENCE platform позиционировалась на рынке как DXP. Инженеры PLM систем традиционно называли обмен данными с другими типами софтов «интеграциями», рассматривая только «программистскую» часть проблемы, поэтому для них рекламное предложение Dassault Systèmes по поводу 3DEXPERIENCE казалось бессмысленным «бла-бла-бла», «маркетингом». Но для менеджеров машиностроительных предприятий это был связный рассказ о том, как DXP от Dassault Systèmes поможет им в customer experience design (то есть каким образом сделает клиентоориентированным их машиностроительное производство — и в части проектирования, и в части производства, и даже в части маркетинга и продаж, а затем ещё и постпродажного обслуживания). Поэтому деньги на покупку DXP выделялись менеджерами много проще. Инженерам надо было только произвести, они не были клиентоориентированными. Менеджерам надо было не только произвести, поэтому для инженеров это всё выглядело как «ребрендинг PLM ENOVIA», а для менеджеров это был совсем другой вид продукта — не PLM, а DXP.

Когда люди из служб маркетинга Dassault Systèmes писали «These developments reflect Dassault Systèmes' commitment to evolving their software solutions to meet the changing needs of engineering and enterprise environments, from managing product data to encompassing the entire product lifecycle and delivering comprehensive digital experiences» — инженеры дочитывали до слова delivering и дальше ничего уже не понимали. Правильно не понимали, слово experience пришло по линии маркетинга и отлично прочитывалось менеджерами машиностроительных предприятий. Им предъявляли онтику «современных трендов клиенториентированности».

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

Дальше идея цифровых платформ поддержки взаимодействия (DXP) нашла поддержку для самых разных сфер.

Например, LMS (learning management system⁷⁸, аналог PLM для обучения) по большей части тоже пытались перейти к LXP (learning eXperience platform). Но в вузах и даже корпоративных университетах, где использовались LMS, идеи маркетинга и экономики впечатлений были не очень распространены, поэтому не все поставщики LMS стали менять свои продукты, название класса продукта и способ разговора о продукте (то есть использовать слово eXperience, слова про learner journey). Некоторым поставщикам LMS не надо было интегрироваться по захвату данных всего учебного заведения и не надо было напирать на то, что у каждого ученика проходит learning journey (иногда пишут learning journey для позиции восприятия учителями, иногда — learner journey, чтобы подчеркнуть «ориентацию на восприятие учеником») уникально, а не представляет собой универсальный для всех предписанный учебным планом «водопад».

Маркетинг LXP шёл поэтому не по линии CRM (привлечь ученика/learner, хотя для онлайн-провайдеров обучения это оказалось ключевым — объединение LMS и CRM), не по линии интеграции данных по всем experience в понимании айтишников, то есть experience как процесс, а не как впечатления от процесса. С LMS процесс добавления новых видов данных от разных точек контакта в хранимые данные о всех взаимодействиях шёл медленно, а затем время от времени разные поставщики таких систем и сервисов делали ребрендинг их как LXP. В любом случае, этот новый тип системы поддержки «путешествия ученика» заявляли не все поставщики LMS. Но если была заявка на поддержку «всех видов взаимодействия по всему маршруту путешествия ученика», да ещё и «искусственный интеллект» и «большие данные» для «индивидуализации опыта каждого ученика» (обратите внимание, это всё прямые отсылки к experience management), то тут чаще всего и отказывались от термина LMS и переходили к platform, то есть LXP, и этих LXP сейчас очень много⁷⁹.

Для самых разных ролей все эти «путешествия» и «впечатления/опыт» (или в варианте айтишников — взаимодействия, которые дают впечатления) устроены примерно одинаково. Скажем, сотрудники (employee, взятые как сообщество) имеют свои платформы для отслеживания их «путешествий», career journey. То же самое — члены сообществ, там тоже DXP, которые работают по проектированию и отслеживанию впечатлений членов сообщества, организации взаимодействий, вовлечению в какие-то дела предприятия. Конечно, такого сорта системы поддерживают и роль пользователя (роль user сегодня понимается и как связанная с ролью customer на стадии эксплуатации, и как community member).

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

TEST Метод разработки

Команда, отвечающая за запуск новых сервисов в розничной сети, запустила в пробную эксплуатацию новый сервис в одном из регионов присутствия. По результатам тестирования были приняты решения по изменению концепции предоставления услуги и организационной структуры подразделения, ответственного за оказание сервиса. После доработок сервис начал эксплуатироваться, команда получила премию, проект разработки закрыт. Какой тип метода разработки используется в этом проекте?

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

+++ спиральная модель ### Да, спиральная модель жизненного цикла — после опробования прототипа система, оказывающая сервис, была доработана, на этом проект был закончен и началась эксплуатация.

--- agile ### Нет, в случае гибких методов разработки проект не был бы закрыт, доработки бы продолжались.

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

--- Agile ### Нет, гибкие методы предполагают возможность пересмотра характеристик продукта на всех стадиях, диаграмму Ганта по видам работ для такого проекта построить не удастся (все работы будут параллельны/одновременны на такой диаграмме, диаграмма будет бессмысленна). И ещё тут вопрос с использованием в разработке метода инженерии требований (agile практики давно избегают подготовки требований) и архитектуры (архитектура сейчас определяется так, что трудно её представить отдельной стадией, подробней об этом будет в руководстве по системной инженерии).

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

+++ Каскадный ### Да, это описание «водопада». У проекта будут огромные сложности, ибо это утопичная модель инженерного процесса, «всё пойдёт не так», работы в жизни не будут соответствовать плану работ из диаграммы Ганта.

--- Ни один из вышеперечисленных ### Нет, правильный ответ в списке присутствует: был выбран «водопад».

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

--- Agile ### Нет, agile модель обычно предполагает возможность пересмотра характеристик продукта в течение всего времени проекта и переделки текущего продукта с постоянными его улучшениями, а вовсе не то, что разработка заведомо будет доведена до неудачного конца какое-то определённое число раз (прототипы), а потом начата заново и доведена разово до успеха. В гибких методах обычно не предусматривается разовое доведение до успеха, конец разработки. Кроме создания работающей системы предусматривается и её развитие. А тут, похоже, хотят просто сделать вполне определённый продукт с несколькими прототипами.

+++ Спиральный ### Да, это спиральная модель жизненного цикла, которая предполагает постепенное достижение требуемых характеристик продукта, в том числе и по итогам предыдущих не вполне удачных попыток (многократное прототипирование).

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

--- Ни один из вышеперечисленных ### Нет, правильный ответ в списке присутствует: спиральный вид инженерного процесса.

В сказке Пушкина «Золотая рыбка» жизненный цикл жилища старика и старухи имел вид:

--- Каскадный ### Нет, каскадная модель жизненного цикла не предполагает, что разработка будет многократно доведена до не вполне удачного конца (затребованное жилище не полностью устроит проектную роль загадчика желаний), а потом будет постепенно перерабатываться в приемлемый вариант.

--- Шухарта ### Нет, цикл Шухарта-Деминга — это не вид инженерного процесса.

--- Деминга ### Нет, цикл Шухарта-Деминга — это не вид инженерного процесса.

+++ Agile ### Да, на основе опыта эксплуатации каждого варианта жилища выдвигались новые требования к разработке, и разработчики гибко отвечали на эти новые требования.

Метод разработки ничего не скажет об оргзвеньях

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

Орг-проектировщики обычно кладут в основу концепции организации метод разработки, по которому будет работать организация. Часто это даже не полный метод разработки, а только те методы, которыми будет заниматься организация. Скажем, если это завод — то только методы изготовления системы и методы инженерных обоснований в части испытаний, но не методы замысливания и проектирования системы. Или наоборот — если это КБ, то только методы архитектурной работы, проектирования, но не изготовления (хотя инженерам надо учитывать методы изготовления! Но оргпроектировщик этим не будет озабочен).

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

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

Метод разработки — это поведение создателей, то есть изменения состояний предметов метода во времени, поэтому он представляется развёртками во времени:

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

• потом двумерная диаграмма методов и стадий,

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

• самый современный вариант представляет собой исполняемые варианты в каких-то табличных моделерах, часто связанных с issue tracker, что позволяет связать в жизни управление процессом/методом разработки с управлением работами.

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

• имеет людей и AI-агентов с нужным мастерством,

• моделеры с нужными шаблонами, или на которых можно эти шаблоны получить и подстраивать, если метод включает в себя рекомендации по адаптации шаблонов моделирования,

• имеет полномочия по трате времени и других ресурсов на выполнение этого метода создания концепции системы, да ещё и

• это время, и все другие ресурсы наличествуют.

Это два разных вопроса: 1. Как будем работать, по какому методу (функциональный) и 2. Кто будет работать (конструктивный). Сама работа получается только после ответа на оба вопроса!

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

Для продуктовых линий (product lines⁸⁰, иногда product families, когда из стандартных модулей собираются разные конфигурации системы для разных потребностей, и это происходит на нескольких системных платформенных уровнях), инженерные процессы разных таких платформ как частей системы или систем в окружении могут быть переплетены причудливым образом. Нужно всегда помнить, что системы выделяются из окружающего мира субъективно (хотя это и хорошо организованная субъективность! Все договариваются, системное мышление для этого!), в зависимости от интереса роли, выполняющей какой-то частный метод работы в рамках инженерного процесса со множеством участников в весьма сложном графе создателей.

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

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

Нужно всегда помнить, что должна быть оргвозможность управления методом разработки, управления инженерным процессом, оргвозможность оргразвития: кто-то::роль с его инструментами моделирования методов инженерии и мастерством это делать должен проектировать метод разработки и превращать его в оргвозможность (чаще всего это ответственность CTO или CIO с их службами, и там особо выделим роль методолога, оргпроектировщика, оргархитектра и лидера, чтобы договариваться со всеми причастными).

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

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

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

Конечно, это мы ещё раз очень кратко помянули системную мантру.

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

Проект: это всё, что угодно

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

Слово «проект» сегодня не ассоциируется исключительно как «проект в классической практике проектного управления (project management)», то есть с тем, как определяют понятие «проект/project» в ассоциациях проектного управления Project Management Institute (PMI)⁸¹, PRINCE2⁸² или аналогичных. Проектом тем самым будет назван и кейс/case починки протекающего унитаза в офисе, и программистский трёхмесячник по методу SCRUM⁸³, в котором вообще не строилось диаграммы Ганта (зато с выдачей через месяц после начала минимального жизнеспособного продукта/MVP, ещё через пару недель второй версии этого MVP и затем ещё через неделю крутым виражом/pivot с полной сменой целей проекта и перепиской продукта «с нуля» под новые цели), и даже какая-нибудь певица у какого-нибудь продюсера (при этом сама певица-исполнитель в «проекте» может быть легко заменена одна на другую без переименования проекта), ибо продюсер::создатель создаёт и развивает певицу::«целевая система» (а как «проект создания и развития певицы» стал «певицей::проект» — это уже особенности языка, метонимия). И даже программы из классического проектного управления (то есть множество классических проектов, которые порождаются по мере осознания в них необходимости в рамках «программы проектов»/«проектной программы») тоже сегодня часто называют «проектами». Могут сказать «программа полётов человека на Луну», имея в виду всю совокупность проектов, связанных с полётами людей на Луну, в том числе и заранее неизвестных ещё проектов, которые ещё даже не осознаны как необходимые, а могут сказать «проект полётов человека на Луну».

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

Ещё в русском языке есть разница между проект/design и проект/project, это тоже нужно учитывать. Обычно продукт — это воплощение целевой системы в её окружении, а проект/project — работы создателя этого продукта. Но есть вариант, когда продукт — это воплощение целевой системы в её окружении, а проект/design — описание/«system definition» этого продукта. Иногда эти значения можно как-то разделить, если обращать внимание на глаголы: «проект дома» в русском языке часто будет design, а «проект создания дома» — это будет project. Очень редко встречается и проект как «проектная команда» («мне сказали из проекта Васи, что Маша из нашего проекта обещала закончить проект на неделю раньше плана»). Напомним: «косил косой с косой косой косой на косе» — мозг вполне справляется с омонимией, один и тот же термин может означать абсолютно разные понятия. Будьте внимательны к типам понятий (развивайте свою «машинку типов»), и вы не запутаетесь! «Проектом» может оказаться что угодно, обращайте внимание на тип!

Моделирование: управление инженерным процессом против управления работами

Напишите рядом два кратких эссе, в которых вы описываете основные идеи принятого в вашем рабочем проекте варианта инженерного процесса и варианта управления работами.