cgvictor

Фаза насыщения

2026-09-28T20:05:00.611Z

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

Потому что если бы он был — его не потребовалось искать. А искать полезно.

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

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

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

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

Вопрос аудитории можно грубо сформулировать «ёма, а зачем мне еще и ЭТО?»

Насыщения нет в узких сферах. Очень узких. И там голяк.

Хотите мгновенный рынок на много баксов? Напишите физический инженерный 3D-солвер нагрузок, реального времени. Аналоги стоят от $1000 до $50000 за штуку, и при этом безбожно косячат. Напишите не-кривой движок складского предсказания спроса по любой из 7 популярных моделей, и прикрутите к имеющимся inventory/warehousing — с руками оторвут. Или систему аналитики, которая из вот этих сырых данных бизнесовые знания сделает.

Но это ж думать надо, копать и заморачиваться. Там где заморачиваться почему-то не надо — вы опоздали на 20+ лет.

Эра масс-маркета прошла. Вход туда стоит недешево, и ходить в эту дверь скорее всего невыгодно и неосмысленно. Там уже всё есть. Если вам кажется, что чего-то нет — я практически уверен, что плохо смотрели.

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

Узкая ниша и узкая специализация — это всегда real-world constraints. Собрать прототип идеи в вакууме на текущий день не стоит практически ничего. Карманные деньги, ошибки округления.

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

Потому что если было всё понятно и просто, справились бы без вас.

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

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

Любой экономист замечательно предсказывает вчерашний график, знаете ли, а при попытке сыграть против «правой стенки» все гипотезы и предсказания остаются — guess what? — гипотезами и предсказаниями.

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

Можно оценить, насколько устарел вот этот (2006) ролик Карла Фиша https://www.youtube.com/watch?v=pMcfrLYDm2U с учетом +20 лет сверху. Окей, какую-то часть он подметил правильно, какую-то не очень, но вот вопрос: как вот этот прогноз помог (бы) в 2006 году что-то сделать в этой связи, к 2026? Да никак.

Если вольно цитируя деда Гибсона, сформулировать последующее за 2006+ будущее как: горячих 5 войн, 2 экономических кризиса, около 5 почти-глобальных катастроф, 3 экономических войны, одну пандемию, политический звиздец, энергетическую нестабильность, полную перекройку моделей управления, смерть дешевых денег, кризис занятости и вишенкой на торте ИИ-пузырь — то за такие прогнозы их автора выгнали бы взашей с порога офиса того редактора, кому он попытается всё это продать. В качестве прогноза, или фантастики, без разницы.

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

Даже тот факт, что ролик чудом сохранился на Ютубе — скорее полезная случайность и причуды статистики больших чисел. Это скорее исключение из правил; интернет как был бардаком так и остался, еще и успешно умеет забывать. Wow, surpri-i-se.

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

ИИ в этом месте поможет, но game changer-ом не станет скорее всего; ввиду своей универсальности и беспредметности. Нельзя за 5 дней агентского кодинга формализовать 25 лет отраслевого опыта. Особенно, если его никто не описал. То, что в руки дали очередной айтишный молоток, совсем не делает все проблемы удобными гвоздями.

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

А, вот этого как раз не завезли? Ну, штош.

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

Право послать на?ер

2026-09-13T19:10:01.238Z

У любого человека есть право послать вас нахер. Ультимативное. Чаще всего, реализуется до банальности просто.

Прекращение коммуникации. Крестик в заголовке окна. Отключение банковской подписки. Блокировка входящих. Не-продление контракта.

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

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

Кого-то куда-то «догонять» предполагает дополнительную квоту внимания и времени; зачем ее ещё тратить, если разговор уже окончен? Dead end.

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

Фундаментальных момента, здесь в контексте изложения, мне следует выделить два:

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

Просто было, а теперь всё. Может закончилось, а может и не начиналось толком. Попытки что-то выяснить могут увенчаться каким-то успехом, а могут и нет. Всё, тишина в канале, ноль на метриках, линия на медмониторе, tv on dead channel.

Знаешь, как умирают лампочки? Из них просто уходит ток.

Никто не придет объяснять лично вам, что вы вот тут мудак. Или что «надо было по-другому». Можно, а зачем?

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

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

Правилу про «нахер» — разумеется, тоже.

Когда у вас маркетинг пытается позадалбывать пользователя очередными 100500-полезными по их мнению напоминалками — вас пошлют нафиг. Вы об этом узнаете последним. В костах и бухгалтерских итогах.

Попытка навязать общение, подергать за нервы, поставить лид-воллы (оставь телефон)? Да просто нахрен идите, никто вам ничего не должен.

Если у вас первая линия непроходимо тупая, операторы с интеллектом гуппи и бухгалтерия с синдромом вахтера — опять же, идите нахрен. А если вдобавок вы, как сервис и бизнес, этого не понимаете — так не просто идите, а прям бегом.

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

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

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

Даже деньги особо не спасают. В смысле тот факт, что у вас какие-то товарно-денежные.

Во-первых, внимание и время все равно ценнее любых денег (и чем ценнее, тем более несоизмеримый между ними разрыв, если считать в деньгах).
Во-вторых, денег вам можно тоже запросто не дать: есть масса примеров, когда за косяки стоимостью вопроса $10 вас нахрен пошлют клиенты с $10000 LTV.

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

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

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

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

Красивыми отчетами BoD «как у нас всё (было) лучезарно» на этом этапе тоже можно подтереться, за свой счет и задорого. Было, сплыло. Аудитория почему-то горевать тоже не собирается, а ваши проблемы = только ваши проблемы.

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

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

потому что, во-первых, на одного такого кто пришел жаловаться, есть остальные 9/10, которые не пришли. А просто ушли от вас в неизвестном направлении, побрезговав. Если надо объяснять, то не надо объяснять.
во-вторых, потому что человек пришел жаловаться к вам, а мог бы в публичное поле на миллионную аудиторию. Которая молча прочитает, молча сделает выводы и молча пошлет вас нахрен. Вы это даже померить не сможете в моменте.

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

Most partnerships don’t end up in court.
Most friendships don’t end in a fight.
Most customers don’t leave in a huff.

Instead, when one party feels underappreciated, or perhaps taken advantage of, she stops showing up as often. Stops investing. Begins to move on. No, I’m not going to sue you. Yes, I’ll probably put my best efforts somewhere else.

Just because there are no firestorms on the porch doesn’t mean you’re doing okay. More likely, there are relationships out there that need more investment, quiet customers who are unhappy but not making a big deal out of it. They’re worth a lot more than the angry ones.

— Сет Годин, Not fade away (09.2011)

Дальше, в общем-то, рецепта успеха нет. Если нахрен, значит нахрен, насильно мил не будешь. Эта партия проиграна.

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

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

* в моей личной копилке есть история, как я продал долги Росгосстраха бандитам. Естественно потерял в деньгах, но божечки мои, как же оно того стоило =^.^=

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

Дальше вы платите за это ту цену, которую платите. В пустой комнате ~~с войлочными стенами~~ можете кому угодно доказывать далее, что вы самые лучшие, и всем нужны. Доказывать-то некому уже.

Hope that helps.

Сценарии или свойства?

2026-08-29T21:36:56.886Z

Кейсы и сценарии не единственный подход проектирования. И точно не панацея. Можно иначе. Есть инструменты, для которых кейсы не важны, а важно другое.

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

Не безнадежно, потенциал есть. Чего таить, я сам 15+ лет топил за сценарии, «пишите кейсы, твари ленивые» и всё такое прочее. Потому что если рукожопие и кризис, кейсы это то, с чего вы начнёте. Возможно, ими же и закончите.

Методика проблему решает, решение даёт — чего еще тебе надо, собака.

Но штука не единственная. Есть другие, и вот конкретно другая. Поехали пример.

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

А вот другой подход: вместо кейсов вы даете инструмент. Ручку шариковую. Можно ею написать документ? Очевидно да, бери пиши. Будет работать? Куда оно денется, веками так происходило. Чтобы совсем не скатываться в идиотизм примера, выдумаем к этому формочки, правила, цепочки — и мы получили решение задачи, тоже. Минусы у него есть. Но… что с плюсами?

Нас во втором случае не настолько волновали кейсы.

Инструмент — шариковая ручка. У нее есть свойства, они жестко заданы ее устройством.

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

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

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

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

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

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

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

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

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

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

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

Страницы блокнота пусты; ты волен писать там шедевр, но волен также писать там чепуху или ложь, или даже вырвать их.

Что в универсальном инструментарии потенциально хорошо: знание о нем, и навыки работы — также универсальны. Этим можно пользоваться; на этом, например, выехал Apple с тотальной жесточайшей стандартизацией UX на мобиле. Пока не наплодили бардака с 2015. Мне не нужно знать, что там накодили в конкретном случае очередные укуренные индусы; я точно знаю, как у них внутри экосистемы будет выполнена работа с текстом, контекст задач (приложуха), тапы-скроллы и прочая мишура.

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

Да, одно решение придется вписывать в ограничения, и оно может пострадать. Вся масса инструментов (и их пользователей) заведомо выигрывает.

Capitalize on the experience.

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

Сюда же попадают разнообразные песочницы — два. Есть правила и ограничения среды, «физика» взаимодействия и правила игры. Пока правила соблюдаются, реализуй там потенциально любые фантазии. Очевидно, любая бизнес-область, в смысле business domain, точно также песочница со своим DSL и правилами — аналогию дальше сами.

Где-то между примерами лежит еще набор подходов и методов типа behaviour design, aspect-driven, DDD (который про другое ащет) и аналогичные скрещивания идей.

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

Сюда попадают, также, многие классы задач где звучат слова «инфраструктура» или «экосистема».

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

Идеальность не получится, но за полезность можно побороться.

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

Это не отменяет факта, что не все задачи заранее понятны и конечны; вот там надо покурить вопрос.

Hope that helps.

Валидация продуктовых гипотез при помощи A/B-тестов

2026-08-16T19:02:18.074Z

Специально унылый заголовок, потому что дальше я буду ворчать. Сильно.
Метриками и А/Б тестами можно завести разработку в кромешную жопу, зато все при деле.

A/B-тест — это когда вы делаете 2 варианта чего угодно, запускаете их параллельно. Потом пытаетесь что-то оценить относительно того, как они себя показали.

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

Сама идея неплохая — а вот то, во что она потом превращается…

Фундаментальный затык из проблематики, почему такой A/B-инструмент вообще появляется — это «мы не знаем». Запомните эту мысль, она пригодится.

Не знаем мы, или можем не знать, вообще-то многого:

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

И в общем-то инструмент позволяет не угадывать, а попробовать. То есть сделать и замерить. Беда только в том, что если в руках микроскоп (вот этот), все проблемы = гвозди.

А/Б тестированием легко подменить реальные, продуманные, взвешенные и просчитанные (заранее!) прогрессивные убедительные шаги вперёд на бесконечную возню с метриками.

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

Затраты? А это не наши затраты.

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

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

Но это уже было, повторяться лень.

Второй проблемный момент от того, что в ваших процессах управления изменениями вырастает обязательный слой псевдо-аналитического буллшита. Ребята из команды_А теперь почему-то не могут просто взять, и сделать нормально (как их просили); им потребуется:

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

Это дорого. Это развесисто. Мотивации всё это делать, каждый раз, ради трехгрошовых изменений — исчезающе мало.

И да, это признак анти-паттерна и того, что происходит какая-то хуйня.

Если у вас любой, каждый чих вместо двух дней на реализацию (день + день проверка) обрастает херотой длиною в месяц на 20+ рыл = удачи вам в этом непростом мире.

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

В общем, если мозг не включать — сдуру можно и хер сломать, даром что гидравлика.

Пойдем дальше. А что вы, собственно, меряте? И как вы это делаете?

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

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

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

Но это же удобно, голова не включалась, берут своё лень, косность и безразличие. Иногда даже прямо с саботажем идет процесс: как вы можете утверждать обратное, если не проводили эксперимента? Мы здесь аналитики. ~~Этот суд не может судить королеву~~.

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

Паровоз едет только вперед. Выкатывая сомнительные «улучшения», эксперименты ради экспериментов, и метрики ради метрик.

Наверное, если быть большим оптимистом, ваш продукт от этого не станет фундаментально в моменте хуже (что, впрочем, тоже не факт). Со временем — естественно, станет.

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

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

Зато столько народу при деле, все чем-то заняты, все зарплату получают. Зачем отказываться.

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

Задаю вопрос: а почему вы, собственно, не знаете ожидаемого результата? Причем настолько, чтобы месяц жечь ресурсы — чтобы что? Чтобы расписаться в собственной профнепригодности?

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

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

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

На последнем следует остановиться подробнее.

Самых простых (но не самых правильных) способа сходу два. Попробовать самому — раз, и спросить тех кто вам деньги платит (пользователей) — два.

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

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

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

Хорошие и качественные подходы (другие!) предполагают проблематику, карту целей, анализ альтернатив + плюс две базовые метрики.

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

Но тут думать надо. Порекомендую все-таки начать.

Вы не можете дома взять и вынести мусор, надо обязательно разложить и вынести сначала половину, чтобы оценить перспективы и потенциальную пользу?

Вы в магазине покупаете только половину списка покупок, потому что надо «оценить что станет лучше»?

Механик вам в автомобиле тоже гайки наполовину закручивает? Или только с выбранной стороны на колёсах?

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

Еще можете заплатить только половину налогов, вдруг метрики просядут.
А чорт, таких людей я даже знаю.

Вывод у меня в общем-то простой: использовать A/B инструмент под задачу, и только там, где он действительно нужен + оправдан с точки зрения сожженного времени и тонны затраченных сопутствующих ресурсов.

Но мне по опыту кажется, что если ситуация уже запущенная, «само по себе» так точно не произойдет. Надо на управленческом уровне посчитать косты (включая неявные, типа сожженного ФОТ на дармоедов и проваленного годами time to market), затем записать всю эту дрочку в запрещенный анти-паттерн, и жестко бить по рукам — за подмену результата «взяли и сделали» псевдо-аналитическими бездарными туда-сюда фрикциями.

Будет не то чтоб просто.
Но hope that helps.

Вот тут еще правильный вопрос прозвучал, и его тоже надо рассмотреть.
Попозже, пока просто подумайте.

— а почему А/Б, в смысле два варианта? Почему не три, не пять, не их комбинации.

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

Да, больше двух считать сложнее. Но операционно это выгоднее, или может оказаться выгоднее, особенно если у вас scope какой-то однотипный, и пилить его вы собираетесь еще долго. Год = всего 12 экспериментов по 1 месяцу, следовательно 11 гипотез. Не жирно ли распыляться на год ФОТа ради 11 правок?

Как считать — посмотрите например у Московица (там где RDS и сложные комбинации); как подобрать комбинации тестов, топологически по Шеннону; из прикладного применения — вместе с инструментарием — гуглить «атомарное тестирование». Методическая база есть.

Но прям сюда дописывать еще и про это я пока не готов, и так портянка текста.

«Решение принято» и «я вам говорил»

2026-08-09T19:10:04.720Z

Думать и переобуваться надо в выделенное для этого время.
Сомневаться постфактум, метаться и нудить — не полезно и так делать не надо (можно даже запретить).

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

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

Если не очевидно, начинаются метания. Вот можно сделать подороже, но побыстрее. Или побыстрее, но пожертвовать вон там. Или дёшево и быстро, но если огребёмся и чего-то не учли — сядем в лужу.

Или вроде метнулись, но стало страшно, давайте передумаем в полёте, и будем брать пропасть в два прыжка.

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

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

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

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

Налицо коллизия. Её надо разрешать.

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

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

Сейчас оно принято, у этого решения есть факт принятия и ответственность за него; остальная пересортица вам далее не нужна, и чаще всего — вредна.

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

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

Проще всего это решили в армии. Когда приказ отдан и принят к исполнению — он исполняется. Если не исполняется — это нарушение приказа.

Мы чаще всего не в армии, но суть идеи примерно та же.

После того, как решение принято, каждый участник обязуется принять и выполнять его так, как если бы оно было его собственное.

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

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

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

Мнение людей, которые точно знают, как лучше, если бы сами умели и могли.

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

Чье мнение и в каких случаях является определяющим, и в какой момент времени — лучше прописать.

Про «я же говорил»

Знаю минимум ~~одну~~ две конторы, где в документах прямо запрещена фраза «а я говорил».

Потому что если «ты говорил», то твоя задача, как специалиста и профессионала, состояла в том чтобы:

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

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

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

Отсюда проистекает момент про то, что «говорил» неплохо бы слышать и фиксировать. Например, в ADR. Хорошо, если там будет написано не только рабочее primary-решения, но и все остальные опции, и рассмотренные варианты

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

Некоторые решения принимаются единолично; есть конкретные люди, которые их принимают, и кто-то из них обычно несет за это ответственность.

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

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

Вся страна с дивана лучше знает, как должны играть 11 футболистов.

В этот момент включаются soft skills и hard docs.
На одних софт скиллах вывозить достаточно муторно.
Тексто-говорильня рискует никогда не закончиться.

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

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

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

Если действительно надо принимать решения в контрольных точках — лучше (для всех) не полениться, и прописать заранее: что проверяем, каким образом, когда и кем. Чтобы метания «а вот тогда надо было вот так…» не сбивали прицел.

Hopa that helps.

Метод «трех кнопок» (функциональный анализ)

2026-08-01T20:38:26.038Z

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

Это опять рецепт, и метод быстрой оценки требований и потребностей.

Удобно применять для набросков, и как способ «сняться с ручника», стартовать анализ и последующее. Полноценную работу, естественно, собой не заменяет.

Придумал/озвучил его кажется Горбунов в 2003. Ну или я от него просто в пересказе услышал. Может и вовсе ошибаюсь.

Но Артём = голова, и точно мог. На сайте Бюро не нашел.

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

— Дайте мне волшебную кнопку «пыщ!», и всё станет хорошо.

(вы про себя думаете: может и не станет, но давай попробуем)

Требования пока мутные, постановка вялая, решение еще искать и искать.

И вы представляете себе кнопку. Вы же можете себе представить кнопку? Если вы инженер, представьте рычаг; если вы басист или водитель, я не знаю, представьте педаль. Какую-то хрень, с которой можно повзаимодействовать уже известным, приемлемым способом.

Она нихрена не делает. И не должна. От вас просили кнопку — ну вот, пожалуйста. За ~500 лет уже худо-бедно кнопку все рожать научились.

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

Дальше вы рисуете (представляете) рядом вторую кнопку. Полностью, пока что, аналогичную первой.

Они пока идентичны, как близнецы. Но будет не так.
Но вы точно знаете, что вторая кнопка — отличается от первой.
Тем, что она что-то делает.

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

Вот прямо в столбик и записывайте.
Чем отличается полезная кнопка от бесполезной?

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

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

Посмотрите на свой список. Проверьте его, примерьте хотя бы на себя.

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

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

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

И вот теперь, вы «рисуете» рядом третью кнопку.

Третья кнопка будет отличаться от второй. Как вторая отличалась от первой.

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

Лучшая версия второй кнопки. Чтобы по сравнению с ней вторая кнопка меркла, и терялась в лучах славы.

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

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

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

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

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

Осталось понять где из того «что можно» лежит то, что нужно.

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

Вы сделали очень важную штуку: подумали, и подумали дважды. Вы молодец.

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

Можно попробовать сделать хорошо — плохо (и с компромиссами) само получится.

Это всего лишь метод, чтобы раскачать вашу мысль. Если хочется чуть боле умного, эта методика точно описана (более развесисто) например в ТРИЗе. Да много где.

Следующий уровень колдунства — сделать так, чтобы кнопки не было. Совсем.
Просто «вот такое надо» — а вот всё уже сделано, забирай. Лучшее взаимодействие = то, которое не нужно.

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

Но об этом поговорим в другой раз, очередной раз.

Hope that hepls.

Еще обратите внимание на соседний рецепт, как сняться с ручника — 5W+W5

С мест подсказывают: «а еще бывают такие кнопки, которые что-то делают, но суко так, что лучше бы блин вообще не делали».

Бывают. Не смогу поспорить.

Но мы тут как бы про пользу. А если вместо пользы = риски и вред, то наверное — мне кажется — не надо такое выдумывать, пока отдельно не попросили :)

5W + W5: читкод для ленивого аналитика

2026-07-30T21:15:44.215Z

Две техники (старых как кал мамонта), которые позволяют писать проблематику и требования без лишней херни. Или хотя бы начать, для старта. Аккуратно, внутри лексика 18+.

Пишу коротко, как рецепт от тупняка, и от наливания воды в целеполагание.

Задолбало читать из раза в раз высеры вида «проблему мы толком не поняли, но целью задачи является анализ и выработка перспективного решения, отвечающего отраслевым требованиям, и его реализация в сроки вчера».

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

«Все равно их никто читать не будет», пускай потом инженерный отдел поебётся. Чтобы потом пообтекать миллионов на десять (в личном топе ВТБ который обосрался на $153 000 000).

Требуется от человека ответить на три вопроса (challenge-definition-solution):

— какую проблему мы решаем
— что мы для этого предлагаем сделать
— нахуя делать именно так

Следом выплюнуть хер изо рта, и не писать следом в документ что-то, что к вышеперечисленному не относится.

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

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

Это лажа.

Аналитика не спрашивают, как решать задачу.
Не надо учить инженеров решать задачи, спасибо, опыта явно побольше будет.

От аналитика требуется понять и кристаллизовать, а какая та задача и проблема, собственно, была.

Смотрим, как это сделать, если вы ленивая тварь.

Есть две техники, краткое имя им 5W и W5.

5W: Who, What, When, Where, Why. Читать тут. Авторство Аттик (Atticus) 175 год н.э, по трудам Аристотеля (Этика Никомаха, 2200 лет назад).
W5, или 5 раз «Why». Why-Why-Why-Why-Why, если нужна расшифровка. Читать тут. Авторство 330 г. до н.э Аристотель (2300 лет назад).

Вот нихера сейчас нового не сказал, согласитесь.

5W

Who? Кто. Какие вообще люди у нас затронуты проблемой, потребностью или решением.
What? Что. Что происходит, что идёт так, что идёт не так (или вообще не идёт). Что должно происходить. Что участвует: какие компоненты, штуки, части, куски, стороны, приблуды, черные ящики.
When? Когда. Когда возникает проблема, требование. Когда потребность актуальна. В какой момент что? становится проблемой, и у кого? Когда эта проблема должна получить решение. Когда это всё должно повлиять на окружающий мир.
Where? Где. В какой предметной области (или ее части) ковыряется потребитель нашего решения. Где он ожидает свою проблему решить. Где она собственно возникает. Где должно проявить себя решение, где оно должно найти свое прикладное отражение.
Why? Почему. Почему это всё вообще надо решать. Почему мы считаем, что именно мы эту проблему адресуем, и именно в этой предметной области. Почему это требование, решение у нас появилось и какие относительно его ожидания (и у кого). Зачем требуется результат.

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

Без ответов вы никакую аналитику не напишете: ответы с их поиском — сюрприз — и называются задачей аналитики.

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

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

Последний вопрос будем копать в глубину.

W5

Идем копать в глубину. Поиск проблематики требует докапываться до причин и потребностей. Для этого есть методика: задавать вопрос «почему?», до тех пор пока не достигнем финального — то есть первичного — ответа. ~~Или нас уебут лопатой за надоедливые вопросы.~~

Если сложно «играть в почемучку» — замените вопрос «почему» на вопрос «нахуя». Так получается сильно бодрее и резвее.

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

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

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

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

Если не копать в глубину по W5, вы рискуете нагородить ситуативных припарок, которые только усложняют людям жизнь — потому что реальную потребность и реальную проблему вы не только не решили, но даже не нашли. Следовательно — не понимаете, и описать не можете.

Scopes и рамки

Берем те же две практики, и повторяем вопросы с негативной коннотацией. То есть, «наоборот».

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

Who / not: кого рассматриваемая (предполагаемая) проблематика не затрагивает, и затрагивать не должна? Чьи проблемы нас не ебут, и ебать не должны? Кому мы ничего в жизни не обещали, ничья персональная армия, и кто нам даже спасибо не скажет? Кто основной приобретатель выгоды, а кто им не является и не должен? Чем это всё определяется, кстати?
What / not: что мы не делаем, и делать не будем? Какая предметная область и домен нас (или других акторов) не касается? Что мы не будем трогать, потому что мы не сможем далее за это отвечать? Что мы обязаны оставить в покое?
When / not: когда по времени мы можем предложить решения, в какой момент, а где уже всё поздняк метаться и поезд ушёл? Когда и в какой момент мы еще не можем решить проблему и/ли даже её понять в предметной связи — например, требуется сбор и анализ данных? Когда во внешней цепочке взаимодействий появляемся мы / наши возможности, либо что происходит вне очерченных временнЫх рамок?
Where / not: в каких частях предметной области проблематика и рассматриваемая потребность НЕ возникает? И почему так получается? (вопросы WhyX5 никто не отменял). Где наши решения не применимы, или не будут применимы? Где результаты и вмешательства НЕ нужны, не будут актуальны, не будут востребованы, не будут тупо найдены в нужный момент? Чего можно НЕ трогать, или даже нужно НЕ трогать, и не поломать ни в коем случае?
Why / not: почему эту проблему НЕ надо решать? (может это не проблема вовсе, а натягивание совы на глобус). Почему вот эти фантазии не надо пихать именно сюда. Почему эта задача НЕ возникает в других местах, или у других людей, или в других ситуациях (видимо, они чем-то отличаются, чем?). Почему вот такой уровень решения нам подходит, а на вот такой замахиваться точно не стоит (дорого, долго, непонятно, неосмысленно, бесконечно итп).

Последний Why точно также разворачивается через W5 в глубину, и точно также применима, при желании, негативная проверка на каждом уровне.

Определяем а) рамки, б) status quo «как сейчас», в) негативные кейсы г) out of scope который нас не касается.

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

В каком порядке комбинировать, и с каким усердием прикладывать — это зависит уже от того, чего от вас (и аналитической группы) вообще ждут. Упороться и писать (3 уровня Х 5W X W5) = 75 тезисов, плюс столько же негативных, может и избыточно. Это потом еще кому-то читать придётся.

Но если от вас нужны вот эти конкретные знания и анализ, а вы не почесались хотя бы попробовать их поискать, тупыми вопросами дяди Аристотеля — ну, это халтура.

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

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

С большой вероятностью решаете не те, не там и неподходящими инструментами. Корейский рандом.

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

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

Можно и нужно (!) пойти посмотреть, как это адресуется в мире, у конкурентов, в best practices, у других людей.

Если вы почему-то этого не сделали = выдумываете велосипед.

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

Либо налицо халтура, либо ответы придется искать на ходу и выдумывать «а что там реально надо-то было». С непредсказуемым результатом.

Рецепты. Hope that helps.

Наглядность это фича

2026-07-18T12:18:57.094Z

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

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

И всё. Это достаточная серебряная пуля, чтобы принимать решения в пользу ее наличия у себя.

Иллюстрация вот сюда https://cgvictor.ru/transparency-feature

Show me the money (c)

Аналитик дуреет с этой прикормки (ц)

Классы и секторы задач, которые решают этим направлением:

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

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

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

Дописано позже. Что еще важно в этой связи: вот тот скриншотик и даже инструмент под ним (там интерактив) мне собрала китайская нейросетка. Потому что я недолюбливаю решения от observablehq, а ей норм.

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

А эта штука доступна примерно каждому. То есть, даже вам, даже если у вас нет четверти века опыта — у вас нет, а у сетки-то есть, насквозь пропиталася.

Сформулируйте гипотезы, продумайте ходы. Делов на один кальян.

Переносимый локальный secret (и «взлом» Макса)

2026-06-10T11:14:08.107Z

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

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

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

Беда здесь в том, что мы доверяем единственному фактору. Даже если в полном flow аутентификации их использовалось несколько ~~вплоть до анализа кала~~.

Когда аутентификация пройдена один раз, вот этот самый секрет становится единственным фактором, который всё определяет.

Занудно напомню терминологию:
— аутентификация — понять, кто к нам ломится
— авторизация — понять, чего ему сейчас можно делать

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

Собственно exploit в данном случае так и сработает, аналогично ключам: вытащи token из сессии браузера, руками, передай в другой браузер, и всё «заработает», тебе/злоумышленнику «дальше можно».

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

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

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

Вы правда на 100% уверены, что никто их не сломает и не впихнет туда localStorage.getItem() с последующей пересылкой куда надо — ?
И как вы собираетесь это проверять?

Какие-то части данных можно пометить как «неизвлекаемые» (см про non-extractable), но из какого-то контекста прочитать их все-таки можно. И руками можно.

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

Сразу отсекает все атаки «уровня клиента приложения», доступ ограничен.

Это не панацея ни в коем случае, всё что сохранено в cookie jar и летит по сети — точно также можно спереть, только придумать как. Варианты есть.

Самый очевидный с XSS и внедрением кода мы (вроде как) отсекли.
Менее очевидные — остаются.

Для примера и последующего разбора представим, что я копирую руками полностью профиль браузера: со всеми хранилищами, cookie jar и иными «недоступными» фишечками. Если я перенесу такой профиль на другую машину, или сопру его при помощи malware на системе — вуаля. Это полностью валидный профиль. Как один, и единственный фактор для проверки со стороны приложения.

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

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

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

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

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

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

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

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

Во-вторых, набор сессий и история данных. Фингерпринтинг (сам по себе) не очень хорош тем, что он может меняться, и вообще не полностью уникален. Человек включил/отключил VPN, перескочил с мобильной сети на вайфай, поменял AS провайдера, обновил браузер — фингерпринты не совпали, и мы пользователю начнем портить жизнь проверками безопасности. Где-то будет оправдано, а где-то совсем не очень.

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

Отдельно список гео, с радиусом. Отдельно список IP и подсетей. Отдельно список автономных систем. Отдельно список браузеров и их фингеров.

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

Если сетевые параметры изменились в сессии, но все равно изменение попадает в тот список, который мы уже ранее видели — это нормально, работай дальше. Если человек переключил VPN, но он это уже делал, и мы знаем его 2 адреса/подсети — да бог бы с тобой. Два, три, десять, сотня значений — это все равно лучше, чем «весь интернет».

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

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

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

Даже если всё совпадает, время проверок важно: вдруг у тебя ноутбук спёрли прямо в том кафе, с открытым браузером.

Таким образом, мы знаем и трекаем не только сессии (по ключам и токенам), но и проставляем каждой из них степень доверия. Проверялось час назад? Отлично. Совпали все параметры проверок? Умничка.

Поменялась подсеть или фингер браузера? Понижаем доверие до среднего по больнице, смотри свои гифки с котиками, но в биллинг тебе уже нельзя.

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

Ну и далее по аналогии, что у вас там в приложении есть.

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

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

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

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

А следом иметь возможность что-то оттуда выкинуть. Если я знаю, что доступа из Зимбабве в моем контексте точно быть не должно. Как минимум кнопка «разлогинить и выкинуть всё запомненное нафиг», для проблемного случая.

И логирование. Чего было, с какими параметрами, в какой сессии, с какими подключениями. Больше логов — чище жопа.

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

Рекомендую осознать и применять.

Hope that helps.

Цепочка возрастания ответственности (про риски, и про AI)

2026-05-30T14:25:19.586Z

Про математику и мат.статистику, которую не на_бёшь. Про то, как копятся риски, если их вовремя не обрабатывать (или просто некем, если вы фанат AI-интеграций).

Знаете, есть такой бородатый анекдот родом из девяностых:

— этот компьютер возьмет на себя 50% твоей работы!
— отлично, дайте два!

К 2026 году мы, как индустрия, получили штуку в виде AI, которая неплохо справляется с какими-то прикладными задачами. Задачи обычно укладываются в описание «текст на входе, текст на выходе», что полностью логично — это именно то, чем занимаются нейросетевые генераторы текста. Аббревиатура GPT, кто забыл, означает архитектуру «генеративный предиктивный трансформер». Трансформер текста.

Два класса задач, которые убедительно получили выигрыш в этой связи

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

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

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

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

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

Приходится полагаться на статистику. Причем чужую.

Для простоты мы (даже) можем говорить про статистику «одноразового» решения — и даже там 89%, и даже 99% не равны 100%. Вопрос цены ошибки. Шанс в 1% обосраться на 1 миллион зеленью уже не выглядит сильно надежным, предсказуемым и допустимым для большого класса прикладных задач.

Есть баянистый пример про конфетки:

В одной миске 100 конфеток, неотличимых друг от друга. В другой миске также 100 конфеток, также неотличимых. Но мы точно знаем, что одна из конфеток во второй (1%) = смертельно отравлена.

Желающих стырить конфетку из второй миски будет совсем немного.

У нас есть метрика риска. Спасибо примеру, наглядная. Давайте перенесем эту концепцию на процессы и на умозрительную систему. В которой 10 акторов, 10 выполняемых задач, и каждая из них может продолбаться с шансом 1% и выставить нас на $1m.

у нас есть риск в (1% х 10 =) 10%, что любой из рисков триггернет (минус $1m)
у нас есть риск в 0,1%, что триггернут все одновременно (минус $10m)
и какое-то распределение между ними.

Будет кривая с привкусом Эйлера (на бумаге), но на практике риски бывают взаимосвязанными и взаимо-исключающими, так что здесь перекос «в нашу пользу» (например, при уже триггернувшем 1% нам нет смысла проверять и рисковать остальными 9%).

Очевидно, что в реальной жизни мы как раз хотим риски друг от друга отвязать, дифференцировать, ограничить и даже друг об друга сторнировать. Чтобы вероятность наступления композитного worst case с его бумажными 0,1% и болезненными минус $10m была не 0,1%, а как можно меньше.

Для этого мы изолируем задачи друг от друга; риск не выполнить одну проблемную задачу и не_встрять на $1m нам явно выгоднее, чем разбираться с последствиями и огребаться по сумме на $10m проблем.

Практическая проверка должна стоять «в цепочке» как можно раньше. Когда мы уже можем диагностировать и обработать риск, но также можем успеть сказать «стоп, налицо проблемы», и не протащить его дальше.

Вопрос: а в какой момент и кем мы это проверяем?
Кто и как несет за это ответственность?

Предположим, мы в том же сетапе заменили 10 исполнителей 10 задач на, соответственно, 10 групп программных агентов. Которые дали нам что-то, что похоже на решение задач. С уверенностью в суммарно 90% — или, если считать «наоборот», с риском облажаться в 10%.

Решение и получение результата дифференцировано. А его оценка = нет.

В результате тот человек, которому потребуется принять и применить готовые 10 решений, должен будет в моменте решить достаточно неприятную задачу: оценить 10 решений разом, с риском в 10% обосраться на $1m, или с риском в 0,1% обосраться на $10m. Потому что риски накопились, никуда не делись, и никем в этой цепочке не обработаны.

Если бы риски, напротив, обрабатывались сепаратно и по отдельности (а не по сумме и по факту в конце цепочки), то цена ошибки была бы 1%, а не 10%. И «стоимость риска» не превысила бы $1m, потому что одна проблемная задача исключает накопление рисков.

Чтобы понимать фундаментальную разницу между 1% и 10%, просто напомню, что вероятность выигрыша (х36) в рулетку составляет 2,7%.

Вот у нас горе-оптимизаторы заменили 10 разработчиков на 10 AI-агентов. Остался один горе-руководитель, которому надо принять ровно одно финальное решение.

У него риски и нагрузка, по оценке ответственности, выросли с 1% на +9%, = 10%, в 10 раз. Зарплата если он наемный работник, как обычно, в 10 раз не выросла. Мозгов и внимания в 10 раз точно не прибавилось.

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

Попытка «выиграть за счет скейла» тоже в такой постановке задачи скорее мешает, чем помогает.

Предположим, вот у вас был человек, который решает задачи из джирки. Код пишет. Отдаёт на ревью умному тимлиду. Человек решает 1 задачу в единицу времени, с выходом корректного результата в 95%. 5% ошибки, которые на ревью находит умный тимлид. Это его задача и ориентир по нагрузке контроля.

Мы можем заменить человека (5% fail) на модель (10% fail). Но модель же умеет «писать код» в параллель. Давайте возьмем их 10! Вон сколько задач решат, ну.

Нагрузка на «умного тимлида» по части проверок и ревью возрастает с 5% до (10% х 10 =) 100% в условных единицах время-затрат.

В двадцать, суко, раз. По весьма сложной задаче (ревью чужого бреда).

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

Суть та же: выход есть, ответственности ноль, за риски никто не отвечает, пока отдельный человек не пойдет и не проверит.

Почему-то в 2000-2010 все быстро поняли, что так работать ~~с индусами~~ нельзя. На точке финальной принятия ответственности сразу вырастает проблемный и неприятный перекос, чреватый граблями и потерями денег.

— Но проблем май фрьенд, ай вилл ду экзактли эз ю сей, ноу ворриез.

Структурка, которая просто что-то там генерит, не включая голову — хрестоматийный пример garbage in, garbage out (GIGO). Разгребать garbage по факту = тупо дорого, и иногда вовсе невозможно. И garbage, и риски в его связи, лучше ловить в процессе, или внутри-процессов.

Даже в обозначенном примере, что нам надо сделать, чтобы получить хотя бы те же показатели по рискам, в одной ключевой суммарной/финальной точке?
Ответ = снизить риски по отдельным компонентам, с 1% до 0,1%.

Тогда математика суммы остается прежней; как минимум прежней, то есть мы заебались по качеству на х10, что вообще-то весьма дорого, просто для того, чтобы суммарно остаться на том же месте.

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

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

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

Ответственность за применение технологии, и за соответствие ей, можно проверить. У грамотной технологии для этого предусмотрен инструмент.

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

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

С точки зрения агентских инструментов нам опять всё подсирает статистика. Топовые модели показывают нам 89%. Но это оценочные данные статистические — окей, предположим мы им верим. 11% процентов зоны риска мы можем митигировать другой системой, проверочной; у которой тоже 89% качества, и даже в идеальном случае они обе точно обосрутся на (0.11*0.11)= 1,2%. Вес идеального случая положительного будет (0.89*0.89)= 79%.

Разница между 79% и 99% уходит в какую-то серую зону комбинаторики.
А 20% это достаточно дофига неопределенности.

Если мы продолжаем плодить комбинации, то вероятность гарантированно негативного кейса снижается. А вот «зона неопределенности» растёт.

10 агентских систем с топовым 89% это всего (0.89^10)= 31% (!!!) гарантии результата. Или 69% неопределенностей.

Ваш бизнес готов работать с ~70% неопределенностей по рискам?
Если да, то удачи, очень рад за вас.

Честно скажу, я такое даже видел. Когда шанс получить что-то применимое, с вероятностью в 31%, гораздо лучше «полного нуля» если нихера не делать, и цена ошибки пренебрежимо мала.

Это сфера прототипирования, стартапов, экспериментов. С вероятностью в 1/3 ты получишь на выходе что-то осмысленное и подходящее, затратив на это сколько-то фикса денег на агентов.

Плохо что ли? Хорошо.

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

Но я такие подходы не люблю.

И как инженер (раз), и потому что есть еще unknown unknowns которые никто не оценил, и не заложил в модель (два).

Что надо из описанного вынести:

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

Hope that helps.