В ходе изучения руководства по системному мышлению передо мной встала задача трактовать “Toward a theory of evolution as multilevel learning” в рамках моего рабочего проекта.
Я хорошо забуксовал тут на несколько дней – читая и перечитывая работу, думая и передумывая о своём основном проекте, общаясь с FPF и не только.
Не пару слов о моём текущем основном проекте.
Это финтех-“стартап” на Ближнем Востоке, который стремится делать… много чего – начиная от обычных финтех-автоматизаций входящих и исходящих платежей бухгалтерий разного бизнеса и заканчивая так популярной в текущей истории идеей “засунем везде искусственный интеллект”. Но в общем и целом B2B, ничего особенного.
Без преувеличения скажу, что работа “Toward a theory of evolution as multilevel learning” кажется что наконец приоткрыла мне глаза на то, что такое “целевая система”, и почему надо начинать именно с поиска целевой системы, а не пытаться искать, моделировать и чинить “генотипы” и “фенотипы”, да ещё и системы-создателя. Это все конечно полезно, на начинать надо сразу с целевой системы – куда бы не попал! И вот, наконец я попробовал в этом стартапе найти целевую систему… Я нашел ее! Но не нашел нашего стартапа в ней.
Иными словами – нашлась большая проблема с пониманием целевой системы у коллег, с пониманием того, что стартап вообще делает, что меняет в реальном мире. Каждый уровень стартапа::система-создатель преследует разные цели “выживания”, часто не согласованные как друг с другом, так и очевидно мало согласованные с “целью”, которой никто не видит.
У CEO цель “визионерская”, но не в том понятии визионерства, которое даётся в руководствах Мастерской, а в обычном “визионерстве”, которое вторит инвестиционным фондам. COO занимается не операционкой, а продажами. Вся операционка заключается в устрашении средне-компетентных разработчиков, а продажи – в продаже практически чего угодно.
Именно потому что в первую очередь на верхах отсутствует “осязаемая” целевая система, ее видение, повестка того, что мы вообще продаём и разрабатываем, COO и отряд продают “что получится”, буквально кастомные решения чуть ли не под каждого клиента. Доходы от этих проектов не покрывают операционные расходы на их разработку и приводят к чрезмерному усложнению программной системы, обеспечивающей всю эту красоту (об этом далее.)
Так что менеджмент (не особо занимаясь менеджментом, а значит от не менеджмент вовсе) стремится выжить исключительно создавая revenue любыми способами.
Стартап определённо как-то эволюционирует, но мне было сложно понять, “куда”, поэтому будет проще взять и всё-таки попробовать “притянуть за уши”, трактовать попробовать потрактовать хоть какие-то принципы (P) и феномены (E) из “Toward a theory of evolution as multilevel learning”.
У нас должна быть какая-то loss function (P1)
На уровне CEO – это “не умереть как предприятие”: нужен доступ к инвестициям/капиталу, рынкам, власти/влиянию. На уровне sales и нашего COO – “не умереть по cashflow любой ценой”; отсюда имеем продажу “чего угодно”. На уровне “инженеров” (не могу не взять в кавычки, извините) – “не потерять работу, не умереть любой ценой под грузом задач/изменений” – адаптируются как-нибудь, сплошная возня и кулибинство, я пытаюсь всеми возможными способами исправить нагромождения созданные до меня. На уровне самого продукта(ов), какими бы они ни были – “не умереть в среде использования”
И вот из-за кулибинства инженеров и одержимости cashflow у верхушки получаем цикл самоуничтожения. Кажется что это лишь вопрос времени – когда стартап коллапсирует. Определенно такими темпами он может жить долго, надо лишь избавиться окончательно от фальшивой маски “стартап” и признать “service-led body shop company type” натуру.
Ввиду малой инженерной (в нашем смысле этого слова) компетенции в команде разработчиков нет никакого “прямого распространения”: никто долгое время не говорил наверх – “Этот проект X делать так как вы хотите может быть плохой идеей, потому что A, B, C; надо либо пересмотреть, как он вписывается в рынок и наш продукт, либо как минимум спланировать более аккуратное внедрение, давайте немного притормозим”. Поэтому, хотя по природе своей “инженерные” и “sales” loss’ы должны быть конфликтующими, в рассматриваемом проекте бал полностью правится одним и здорового конфликта нет.
У нас тут должны бы быть какие-то частотные разрывы, должен быть какой-то “осязаемы” генотип, какие-то “внутренние принципы”, понимание целевой системы и того, что мы конкретно для неё производим. Должны быть какие-то циклы обратной связи, “инженеры” должны не только понимать, что “тут какую-то ерунду странную предлагают сделать”, но и говорить это без страха – проверять эти новые sales-идеи на продуктопригодность. На практике же между sales speech и “закрыли сделку, пообещав кастомное решение” почти нет никакого “зазора”, “частотного разрыва” – “ну как-нибудь сделают!”. Конечно, уровень инженерной компетенции (вообще и прикладной в разработке софта) – это ресурс, и его недостаток может ощущаться очень серьезно, но мне видится, что отсутствие “медленных принципов” в рассматриваемом стартапе намного опаснее.
Остальные P из “Toward a theory of evolution as multilevel learning” я затрудняюсь связать с чем-то в описываемом проекте напрямую.
По поводу прямого и обратного распространения и эволюции вообще в рамках проекта… вот прямая цитата из “Toward a theory of evolution as multilevel learning”:
… slow variables determine the rules of the game, and changing these rules depending on the results of some particular games would be detrimental for the organism.
Собственно, это именно то, что происходит, что я выше описываю: чётких “правил”, медленных переменных нет, целевой системы в экзокортексе – нет. Что “рассовано” по головам – неизвестно.
И вроде бы пока “всё идёт хорошо”: revenue есть, инвесторы вот-вот должны принести много-много денег, но… кошмарный ball-of-mud внутри, с невообразимым числом технического долга, в состоянии “вот только подуй хорошенько и…”
И вот те нормальные архитектурные инварианты и софт-инженерные решения, а также чёткие маркетинговые стратегии, “повесточка” на целевую систему – всё это должно было бы быть и быть генотипом (я осознаю что переплел тут несколько уровней), и генотип этот должен быть контролируемым, удерживаемым во внимании, уважаемым в конце концов при принятии стратегических решений! Но такого генотипа у нас нет, и весь фенотип – всё уродство из-за кастомных решений – выходит боком на разных уровнях: существенная часть функциональности оставляет желать лучшего или просто хрупка и часто ломается, затыкается людьми и пожарами. За несколько месяцев я подпер снизу что смог и чем смог, но это бесполезная борьба со штормом, и я это наконец понимаю! Вижу где проблема.
Я не могу сказать, что “кастомные” интеграции – это плохо и абсолютное зло – конечно нет! Если делать их с умом, аккуратно, и когда доход от их производства хотя бы окупает затраты ресурсов на разработку и поддержку, тогда это был бы потенциально полезный симбиоз – можно было бы пытаться встроить эти разрабатываемые решения в нормальный, универсальный продукт, лишь бы он лез в целевую систему и был полезен ей!
То, что происходит сейчас, похоже скорее на паразитизм: эти кастомные разработки приносят только локальный выигрыш (оказалось что последние такие приносят смехотворный доход), при этом увеличивают сложность платформы, техдолг, стоимость поддержки, возрастает риск инцидентов…
И вот тут ещё интересно! Это реплицируемый паразит, потому что случай неоднократный! Это уже устоявшийся паттерн.
В общем, стартап, конечно же, эволюционирует, но вот куда – в сторону меньшей боли по доминирующей loss-функции, и мы её уже установили – это revenue с кастомных интеграций, а не продукта для целевой системы, и кажется что это прямо-таки Goodhart!
Вместо того чтобы, как нормальный стартап, быть этим самым стартапом и делать продукт для рынка, для целевой системы, потенциально двигаясь к прибыли, кратно превышающей любой микро-доход от кастомных интеграций… мы занимаемся этими самыми интеграциями, и никакой “программируемой смерти” для них не предусмотрено.
Передо мной сейчас стоит интересная задача: попробовать всё-таки донести ситуацию до власть-локально-имущих, выполнить back propagation. Жаль только что актуальный “CTO” многократно пытался это сделать, но может у меня все таки получится? По крайней мере это будет преступлением не попытаться это сделать, это же какой материал для практики того что. изучаю в руководствах!!! 
Я буду признателен любому совету тут по “социальной инженерии” директоров. Пока план такой: составить описание и презентацию на их языке, подсвечивая боли и угрозы (на том же самом языке); предоставить на обзор; дополнительно и неоднократно объяснить (если потребуется). СЕО меня вообще игнорирует, но думаю что СОО можно будет заставить послушать.
