cgvictor

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

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.

Проверяемость как бизнес-фича

2026-05-28T14:33:28.398Z

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

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

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

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

Людей, которые пользуются настольной ОС — миллионы. Людей, которые знают, как конкретно устроена Windows под капотом — пара сотен. Это не проблема, пока «всё работает».

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

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

Неважно, «айтишная» это система, или просто внешний Люба-бухгалтер на аутсорсе. Или не дай бог AI.

Верить, или не верить на слово — всегда вопрос сложный.

С бурным ростом информатизации в зарубежном медиа даже (1970+) возник отдельный художественный поджанр, в жанре хоррор (ужасов) — концепция Недружественной Системы.

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

HAL не откроет вам двери воздушного шлюза станции, потому что автоматика приняла решение в свою пользу. Не в вашу.

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

Непредсказуемость пугает человека. Непрозрачность пугает. Система, которая заведомо относится к категории «непознаваемое», воспринимается человеческим актором как враждебная среда. С ворохом рисков и без понятности; без понятности не будет доверия. А без доверия, как мы немного выясняли ранее, вообще мало что работает с positive outcome.

Примеров я по этой части потом еще накидаю: есть интересные (по крайней мере мне), но пока оффтоп.

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

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

И это не просто фича — это бизнес-фича. Она продается. Она стоит денег, которых готовы за нее доплатить.

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

Анализ операций — по отношению к самой системе это мета-задача, в смысле внешняя. Причем разная.

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

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

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

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

Знаю конкретный пример отраслевой, из мира 1С, когда люди взяли типовой расчет по логистике, закупкам и магистрали — корректный расчет, повсеместно распространенный — и сделали бизнес-продукт тупо на основе того, что дали к нему подробный проверяемый отчет в моменте: как проходил обсчет модели. Чем он руководствовался, какие входные параметры во что превратились, как и чем оценивались, и что в итоге получилось.

Поднялись миллионов на 5 зелени. Само решение и решалку, что важно, не трогали вовсе. Её и нельзя трогать, она типовая и обложена требованиями.

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

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

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

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

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

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

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

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

Пространство вариантов

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

К применяемой модели, допустим, вопросов нет. А к кейсу и к ситуации, в которой мы модельку применяем — вопросы есть.

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

Нам надо получить ответ следом на другой, более важный вопрос:
— «а как теперь сделать так, чтобы было иначе?»

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

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

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

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

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

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

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

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

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

Казалось бы, здесь проверяемость и наблюдаемость решает.

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

Сфера в данном случае не важна, схема весьма распространенная.

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

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

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

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

Процент ошибки менее критичен, чем отсутствие ответов вовсе.

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

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

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

Hope that helps.

Забавный пример из мира AI и LLM, который всегда по определению «черный ящик», получился в тот момент, когда большие языковые модели «научились» в техническую концепцию reasoning и chain of thought. Когда перед генерацией ответа программная моделька имитирует собственный же подход к генерации ответа, озвучивает контекст, и далее уже отвечает на вопрос, имея подготовленный контекст для самой себя.

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

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

Ну камон, они одним и тем же генератором создаются.

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

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

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

Анти-процессы (делай проще!)

2026-05-20T13:55:45.819Z

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

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

Только не делается нихуя.

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

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

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

Проверочный критерий:
— мы делаем вот это, чтобы лучше сделать работу,
или вместо того чтобы ее делать — ?

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

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

Но это не ответ на вопрос «что у нас не так». Это ответ на вопрос «где нам не нравится», то есть вопрос другой. Не нравится — понимаю. Но оно работает, задачи решает.

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

Оно работает. И будет работать еще 1-2 года запросто. Может и больше.

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

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

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

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

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

Процессам от этого лучше не становится. Нельзя качественно алгоритмизировать то, что некачественно работает.

Костыли и косяки просто обрастают бюрократией. А бюрократия это время.

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

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

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

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

— Вон сколько сразу людей при деле!

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

Для вопросов, которые в 90% случаях решались одним вопросом и ответом в чате.

Если такое случилось — надо упрощать. Качественно упрощать всегда кратно сложнее, чем усложнять. Усложнять даже дурак может, увы. Еще сложнее — упрощать вовремя, пока overhead и overbloat не выросли до проблемных величин.

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

Направления решения (но не рецепты!) примерно такие:

decide вместо approve. Вам не нужна на операционные и тактические вопросы цепочка валидации, и особенно она не нужна заранее. Вместо комиссии и ожидания согласий от кого-то там на что-то — верните право принятия решения конкретному человеку, и пропишите какому именно. Вот у него есть финальное операционное право «на да, нет, и я так хочу». Это его зона ответственности.
валидации постфактум. Если какие-то решения надо валидировать и оценивать, хотя бы для связности — вынесите проверки на потом. Сначала ответственный человек принимает решение и не тупит, потом это решение можно посмотреть, оценить, найти концы и прикинуть хрен к носу. Если таковая необходимость возникнет.
замещающие механизмы. Вместо созвона сформулируй вопрос, задай в чате, предложи варианты ответа. Если не можешь сформулировать — тебе не нужен созвон. Если нет ответа — возьми дефолтные варианты ответов, тебе не нужен созвон. Лог чата без флуда вполне заменяет обоснование в документе (скопипастил лог и молодец).
emergency mode. Если на задаче написано «срочно-алерт», ситуация нештатная, есть обоснование, то исполнитель может принимать операционные решения сам; и даже административные, в некоторых случаях, например посоветовавшись с коллегой. Организационные routines в этом случае становятся опциональными, коммуникации прямыми, время важнее обсуждений. Ниже приведу пример.
право на молчание. Если по вопросу за N времени нет продвижения «по процессу», принимается заранее описанное решение, то есть всем пофиг, и значит все согласны. «По вот такому вопросу завтра в полдень мы сделаем вот это, кому что-то не нравится, могут успеть нас отговорить».
предсказание ветвлений. Если 80% шансов, что вопрос разруливается именно так — берите и делайте, не ждите согласований, сэкономите время. К согласованию уже будет рамочно готово решение; а если нет или не угадали, ну 20% что делать придётся иначе там, где вы все равно бы делали иначе.
маркеры хуйни. Если в обосновании правки написано «нас просят клиенты», любой сотрудник компании/команды имеет право и даже обязанность поинтересоваться: что это за клиенты, где конкретно просят, сколько их, чего конкретно просят, в какой связи и так далее. А автор строчки обязан по первому требованию на такие вопросы ответить. Если ответ неубедительный — значит, хуйня, вычеркиваем.
типовые случаи. Разделяем когда вопрос надо эскалировать «для галочки», 90% что всё очевидно, и мы чисто формально соблюдаем процедуру (с каким-то процедурным статистическим смыслом), это можно сделать быстро; либо вот тут есть неочевидности и подводные камни, вот мы их заранее сформулировали, и нам надо получить внятные ответы вот на это, и на вот это. Перекликается с разделением типовое/нетиповое, да, мысль оттуда.

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

Потому что если вы собираете встречу на 2 часа на 20 рыл «как нам работать эффективнее», вы только что закопали еще +40 человеко-часов в ту хуйню, которой вроде как собираетесь избежать.

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

Явно пишу: не является рецептом.

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

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

Будут обидки, и кто-то даже наживет себе врагов.

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

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

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

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

Профессия сложная.

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

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

Человеки смотрят на факты, и правильно делают.

Если Вася честно спросил «а нахуя вот это?», и это правильный вопрос, и он есть в документах,

— а потом почему-то именно Вася остался без премии, и получил кучу придирок — значит, ваша «анти-» механика = профанация и пиздеж.

И Вася, и все остальные очень быстро усвоят этот урок.

Если механики прописаны, а по факту не работают — не надо потом удивляться, «а когда мы стали гребаным мейлру?»(ц)

Знаю компанию, в которой целый региональный отдел (на 50+ человек) отвечающий за заданное направление, сначала наплодил себе «инструментов», а потом героически их поддерживает — ни разу не покривив душой, в общем-то, действительно поддерживает. Месяц за месяцем жрет примерно ($3k×50×80р) = 12 миллионов рублей/месяц, просто чтобы сделать вид, что «мы делаем важную работу».

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

Это такой извращенный случай job security, мне кажется. В рамках целого направления.

Разумеется, если задать вопрос, а что такого конкретного вот эти люди сделали за 3 года, потратив (12×36) = 432 миллиона рублей (полмиллиарда, суко, сожженного ФОТ!), кроме обеспечения работой себя любимых, и чего принципиально не существовало три года назад — ну угадайте, кто мгновенно станет главным врагом и troublemaker на районе.

Зарплата сама себя не заработает.

Вот вам живой кейс. Компания, РФ. Внутри компании разделение по зонам ответственности (ну, типа), по организационной вертикали, технике, и даже по любимчикам у собственников.

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

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

Педалировать процесс будет та группировка, которую больше нагнет собственник. Вторая в ответ будет сопротивляться и имитировать.

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

Кому нам? Какие процессы? Как они будут на практике работать, кроме как лежать на бумаге? Не, это вопросы сложные. Надо доки писать.

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

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

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

Недостаточно доков, надо больше доков.

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

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

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

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

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

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

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

Механика была со своими нюансиками, но признана годной.

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

Процент косяков и косячного выхода — 1 юнит, то есть 10% (1 юнит/2w, 2u/1mo)
Надо сильно меньше, что-то около 1 косяка в квартал, то есть 1/60, 1.66% как целевой показатель.

Проблема только в том, что перепроверить работу по времени стоит фактически столько же, сколько её сделать. Если заставлять перепроверять каждый юнит работы, производительность падает вдвое (1u+1u).

В количественном мире такое делают путем ОТК и рандомизированной выборки. Типа, если из партии в 100 штук хвосторезов отобрали 10 случайных и нашли там брак — вся партия в 100 признается негодной и идет в отбраковку.

Но балансировка всё еще «дохера». На 100u это +10% работы сверху, и шанс в исходных 10% что остальные 90u уйдут или в брак, или в перепроверку — т.е еще 9u костов. Стоимость решения по юнитам становится 119 против 100, это +20% затрат. Затраты линейные по конвейеру, но нелинейные по графику — встрять на -20% недовыполнения плана (а в холке на 50%, полная перепроверка) может стать сильно дорого, чисто по просранным обязательствам и неустойкам.

Решали успешно, через leaky bucket / неубывающую цепочку, last streak. Вы эту штуку видели в американских фильмах, когда на доске пишут «0 дней без инцидентов». Там обычно не показывают момент, когда сумма выше границы приносит премию безопасникам, а ниже границы — штрафы.

Если отдел выдает работу 40 и более дней без косяков — за ними не проверяют.

Если отдел выдает один косяк, назначается выборочная проверка на 2 из последних 10 юнитов.

Если там обнаруживается косяк (либо) за это время в новой работе еще один косяк — проверяется далее каждая вторая.

Если и там ошибки, хотя бы +1 — отдел далее работает с полной проверкой.

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

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

У них сработало. Кейс примерно на +2 млн дохода/mo.

Hope that helps.

Куда еще полезно посмотреть:

Бюрократия или нет
Кроме «что», надо «как»: тактическое руководство
Право на «да», «нет», и «я так хочу»
Negative outcome, коллизия изменений
Рамки и баланс у процессов
Паттерны ради паттернов