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

Прежде важно договориться о понятии системы. Мы воспользуемся для этого категорийным понятием системно-структурного подхода [Щедровицкий, 1995]. Согласно ему системой является любой объект, с которым можно проделать последовательно следующие операции:

1. выделить этот объект из окружения, очертив рамку объекта как целого и временно оборвав его связи с этим окружением и сохранив их в форме отмеченных связей;
2. выделить в объекте совокупность частей;
3. связать части воедино и организовать полученные связи в единую структуру, превратив тем самым их в элементы системы;
4. вложить полученную структуру на прежнее место целого, очертив таким образом границы системы.

Говоря проще, системой является нечто целостное, объединяющее свои части в единую структуру связей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В результате упрощения мы попадаем в следующую петлю.

«Разматывая» сложный объект, мы как исследователи и проектировщики должны рассматривать в качестве главной задачи именно захват, а не уменьшение сложности интересующих нас систем [Нортроп, 2014]. Захват сложности подразумевает сохранение на виду у проектной группы существенной структуры системы, выявление и удержание её главных принципов работы. Причём как естественных так и создаваемых нами искусственных аспектов её поведения в охватывающих системах и средах.

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

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

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

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

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

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

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

Я буду называть знанием такие допущения или договорённости в проектной группе об объектах проектирования, которые существенным образом влияют на судьбу проектируемой целевой системы.

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

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

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


Допущения и договорённости о создаваемой системе я подразделяю на три типа.

К ним относятся описания целей и целевые критерии. Всё то, что формирует замысел шага развития. Смыслообразующие договорённости отвечают на вопрос «что мы делаем в действительности?» и «зачем?» мы что-то делаем.

Примеры смыслообразующих допущений:

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

Примеры инструментальных гипотез:

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

Примеры онтологических допущений:

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

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

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

Или схематически:

Таким образом, научное знание — это то, от чего мы по возможности отказываемся, то, что может быть опровергнуто экспериментом. Поэтому гипотеза всегда должна иметь структуру, в которой присутствует то, от чего мы можем отказаться — предположение, и то, что сохраняем — посылки и наблюдения в её основании [П. Щедровицкий].

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

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

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

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

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

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

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

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

Итак, как мы поняли, смыслообразующие, инструментальные и онтологические принципиальные допущения не всегда в отдельности являются самостоятельными гипотезами. Это смысловые кусочки, являющиеся деталями конструктора гипотез. Настоящими гипотезами они становятся при объединении друг с другом.

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

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

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

В этом бульоне переплелись все виды гипотез, но кристаллизовался смысл предстоящего действия и проявилась основательность предлагаемых мероприятий.

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

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

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

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

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

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

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

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

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

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

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

Значения смысловых типов могут отличаться от проекта к проекту, но чаще всего в области проектировании цифровых сервисов пригождаются следующие.

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

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

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

Начнём с подхода к планированию эффекта с названием карта гипотез, который увязывает в направленную схему четыре типа допущений, настраивая между ними причинно-следственную связь от первой к последней [Бындю, 2024]:

Другая форма связи знаний существует в практике ИТ-архитекторов. Речь пойдёт о шаблоне фиксации договорённостей: Architect Decision Record (ADR или просто DR, запись о договорённости). Эта практика призвана сохранить подробности любого принимаемого решения в отдельности. Для этого предлагается заполнять структуру, состоящую из следующих смысловых частей:

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

Лучшие мировые специалисты в области контролируемых онлайн-экспериментов рекомендуют следующую схему дизайна эксперимента [Kovahi, Tang, Xu]. Для фиксации содержания будущего эксперимента предлагается запонить шаблон, в котором первые элементы являются причинами и основаниям для последующих. При несложном анализе можно увидеть как составные части шаблона раскрывают логику планирования эксперимента. Принимаемая для эксперимента гипотеза, влечёт за собой выбор набора метрик, центральная метрика набора определяет требуемый уровень практической значимости, а та, в свою очередь, определяет все остальные параметры эксперимента для обеспечения нужных измерений. Вот итоговый шаблон планирования эксперимента:

И, напоследок, приведу в качестве примера свой собственный метод по проектированию развития цифрового продукта — дерево продуктовых гипотез [Шапиро, 2021]. Суть метода заключается в фиксации в единой иерархированной программе всех гипотез о проблемах и улучшениях продукта. Иерархия в этом дереве организована за счёт представления бизнеса как потока ценности. Каждая ветка дерева максимизирует один из потоков в бизнесе. Гипотезы-«листья» связываются с гипотезами-«ветками» через причинно-следственные связи. Метод даёт в первую очередь понимание собственной системы и буквально ощущение влияний каждой из гипотез на главный потоковый ствол дерева.

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

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

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

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

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

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

В моем личном опыте первые начатки практик систематизации появились в процессе работы над пользовательским интерфейсом. В 2021-м вышла статья «Журнал проектировщика», собирающая первую версию описанного подхода [Шапиро, 2021].

Надо отметить, что в практиках систематизации знаний нет никакой необходимости, если ваши задачи просты. Простейшие интерфейсы типа датчика Холла [Раскин, 2000] или проектирование веб-сайта — простые задачи, в которых всё необходимое легко удерживается в памяти. Трудности, вынудившие меня искать какие-то методы, появляются лишь при работе с более сложными задачами.

Сложности эти выглядели обычно так, что при размышлении над одним из элементом или сборкой приходилось думать одновременно над несколькими проблемными вопросами. Думать над решением одной проблемы вместе с удержанием в оперативной памяти других крайне трудно. Лучше голову освобождать. Так появились первые варианты метода в виде почеркушек на полях макета.

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

Естественно, записи на полях, разбросанные по пространству файла с макетами, никак не похожи на систему. Эти кусочки пришлось переносить в единое хранилище. Так возник журнал и практика журналирования.

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

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

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

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

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

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

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

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

❏

Photo by Alina Grubnyak on Unsplash