cgvictor

Переносимый локальный 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 коллег, с ними советуется, и они принимают то решение, которое им покажется наиболее адекватным. Логику и решение фиксируют, делают.

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

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

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

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

Hope that helps.

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

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

Проектные команды и Skunk Works

2026-05-13T11:21:47.005Z

— Давайте умные люди соберутся, и быстро сделают чего-то прорывное, лучше всех, быстро и без уйни?
— Можно. Но не у вас.

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

На высоком уровне (типа, государственном) такую концепцию оценили и приняли после творчества Кларенса Джонсона, которое вывело противостояние сверхдержав ~~холодной~~ войны на принципиально новый уровень — то есть, Skunk Works.

Который очень любят вспоминать в качестве примера «смотрите, как бати-инженеры зажигали!»

Так то очень рекомендую сначала почитать книжку. Если выкинуть оттуда 30% самолюбования и бравурной политоты, то в остальном — действительно, зажигали. Не было практически ни единого исторического шанса, что подобные результаты обычным способом достигнет и Локхид-корп, и любой из остальных 4х основных контракторов зарубежного минобороны.

Кратко в чем суть, если книжку вы не читали.

Локхид в 1943 году столкнулся с вызовом, что надо собирать перспективные планеры, чтобы не отстать технологически — особенно на фоне того, что британцы и конкретно Роллс-Ройс собирались выкатывать реактивные истребители — причем делать, и собирать что-то сукоблять_быстро. Иначе контракты просто уйдут на сторону, а это деньги.

И выделил отдельное подразделение*** под предводительством Келли (к 1958), как самого отбитого — который отжал себе, условно, гараж, в котором с командой из 15 инженеров пошел креативить.

Накреативил так, что команда Skunk разрослась до 7000 людей в холке, дала миру печально известный уникальный разведчик U-2, адаптировала идею радиолокационной малозаметности до F-117 «стелс-файтер», подпрыгнула в прыжке до SR-71 Blackbird и так далее. Но самое интересное в этой истории, что «сарай» Келли выдавал летающие прототипы от идеи до железа за 150-250 дней, то есть меньше года. Даже с учетом всей секретности, отсутствия людей, трудностей в снабжении, попутно решая инженерные задачи, которые ранее считались нерешаемыми вовсе.

Тут вот некоторые цифровые фичи за год дотащить в релиз не могут. А вот там люди из говна и палок за год уникальные самолеты успешно собирали.

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

В книжке есть много мнений от первоисточников — собственно, Келли и Бена — которые наглядно рассказывают, что конкретно дало им такие возможности. В первую голову, конечно, отсутствие бюрократии: когда даже в соседнем Локхиде на похожих проектах до +300 васянов занимаются исключительно перекладыванием бумажек, выброси их как явление, и получишь избавление от инженерного балласта.

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

В-третьих, но не в последнюю очередь, гибкость в снабжении. Ряд их проектов бюджетировал не Локхид, а напрямую ЦРУ. И куча прокладок. Это позволило им обыграться на мелкотиражных и узко-специальных заказах опять же без тонны волокиты, секретки и условностей, и заказывать всякие штучные вещи напрямую у контракторов. Или нагло тырить на смежных производствах. Значит, опять же, сократить цикл проб и ошибок, что влияет на time to market весьма положительным образом.

«Правила Келли» в оригинале приведены тут, 14 пунктов.

И в-четвертых, уже от меня — риски. Которые никто корректно не обрабатывал и даже не учитывал, а вывозилось всё и вся исключительно посредством седых волос авторитета Келли, борзостью (и знакомствами) Бена и уникальностью задач от ЦРУ. Тебе не надо быть предсказуемее конкурентов, если конкурентов на этом поле у тебя нет. Впрочем, на этом факте далее остановимся подробнее.

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

Внутри команд и микрокоманд самоорганизация. Как удобно, так и работайте, только результат дайте. Бюрократия постфактум, в объёме минимально требуемом коммитментами. Об этом сетовал Бен, когда выяснилось, что документацию никто особо не вёл, release first, а даже если она почему-то есть — её способны прочитать и понять 3.5 персонажа которые непосредственно её делали.

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

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

Несложно заметить, что всё вышеописанное очень напоминает

а) аджайл, то есть ворох гибких методологий, и

б) весь аджайловский бардак и сделай-сам, который вместе с ним возникает.

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

Сколько идей были выдвинуты на уровне концепций, потенциально перспективных, и остались «в столе». Мы об этом тоже знаем из первоисточника — на пару порядков больше, чем выдавал (бы) исследовательский блок того же Локхида в соизмеримое время. На этом факте долго потом кормился и материнский Локхид, и сам Skunk-ADP, потому что перспективные наработки с R&D копились, и рано или поздно уходили в серию. Не на этом проекте, так на соседнем или следующем.

** зато у Бена Рича есть прорывной патент нагревателя (нихромовая проволока), чтобы у пилота на морозе на высоте хер к трубке/бутылке не примерзал. Секретный патент безымянного героя, как он сам писал.

Была ли у Skunk возможность обосраться и ничего не сделать? Очевидно, была. Вообще говоря, такая постановка вопроса уже считается из ряда вон выходящей в обычных, конвенциональных проектах. Здесь сыграл тот факт, что от них изначально хотели уникального и запредельного — это раз. Альтернатив и аналогов все равно нет, не предвидится, и взяться им особо неоткуда. Если бы инженерная команда ничего не накопала, а физика штука бессердечная — Локхид бы обосрался на бюджет, а мир не увидел условный U-2. Ну и не увидел бы, щито поделать, можешь лучше — сделай лучше.

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

Копай, пока копается, а если не копается — значит, мало стараемся.

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

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

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

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

Можно, но сложно. Это какой-то образцовый R&D в вакууме, в идеальной среде in vitro и in vivo — когда люди занимаются непосредственно Research и непосредственно Development 24×7 со всеми имеющимися возможностями, и никто им в этом не мешает заданное количество времени. Звучит-то вкусно, сам хочу. Каждый второй инженер хочет, первые 40 лет детства для тех, кто в конструктор не наигрался.

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

Если мы подойдем к вопросу оценки рисков условного Skunk-подразделения с классических позиций управления и корпоративного планирования — это instant fail. Риски космические, ожидания нереалистичные. На 99% это заведомо похороненные деньги и время в проекте.

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

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

Если не готовы — надо честно себе об этом сказать.

Вот и ответ из заголовка. Возможность собрать научный отдел инженеров-практиков требует этой самой возможности: экономической, организационной, ресурсной (люди), проектной (задачи). И осознанного взвешенного решения «да, мы готовы об это рискнуть», сделать ставку на R&D, доверить вот этим людям прыгать до звезд. А мы будем смотреть и завидовать.

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

Принято считать, что неотъемлемым атрибутом такого отдела будет escaping routine organizational procedures.

В положительном исходе все охуеют и скажут «Wow!».
В негативном исходе все просто охуеют. Но точно будет весело и интересно.

А это уже немало.

Hope that helps.

Полиграф продолжение: а как, а нафига

2026-05-04T16:09:00.080Z

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

Начало тут https://cgvictor.ru/hr-polygraph

Научная база

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

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

Как и любые другие физические параметры, другим подходящим прибором.

Не существует никакого достоверного технического способа отличить «ложь от правды», любым способом. Точка.

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

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

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

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

Работает с исследованием — специалист-исследователь, полиграфолог. И только его мнение принимается в расчет.

** иногда встречается термин специалист-верификатор. То же самое.

Добровольность

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

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

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

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

с точки зрения закона, исследование это сбор персональных данных, и допускается только с явного, выраженного, добровольного согласия
касательно ФЗПД ст. 6, сбор таких данных не может являться обязательным для исполнения трудового договора (и проводиться без согласия), отдельное согласие обязательно
в ходе исследования допускается задавать только вопросы, касающиеся деловых и профессиональных качеств, а также отношений работника и работодателя. Вопросы о личной жизни, убеждениях, а также о третьих лицах — задавать нельзя (отвечать — на собственное усмотрение, можно отказаться)
если работник отказывается проходить проверку, даже если это установлено в форме обязанности во внутренних нормативных актах, нельзя применять к нему меры взыскания, наказания и увольнять. Есть в письме Минтруда 11.12.2024 N 14-6/ООГ-7120

Судебная практика схожая (гуглится):

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

Техническая взаимосвязь

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

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

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

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

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

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

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

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

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

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

Чего быть не должно

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

Вот именно это сложная и первоочередная задача специалиста.

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

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

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

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

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

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

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

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

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

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

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

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

Что видно по показателям

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

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

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

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

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

Можно ли обмануть полиграф (ц)

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

Можно ли обмануть полиграфолога?

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

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

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

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

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

Если полиграфологу что-то непонятно в реакциях человека (или прибора), он попросит объяснить происходящее. Это правильно, и так надо делать.

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

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

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

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

Коррекция ответов

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

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

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

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

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

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

А что спрашиваем?

Ну кстати да, что вообще можно и нужно спрашивать.

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

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

Что здесь важно.

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

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

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

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

Такое можно использовать только в пред/пост беседах чтобы человека откалибровать, да и то с оговорками.

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

— проблемы с веществами
— проблемы с законом
— проблемы с зависимостями
— работа на конкурентов (инсайдерство)
— проверка фактов из резюме

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

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

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

Кто лично в проблемах замешан, а кто просто рядом стоял.

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

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

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

Извините, отвлеклись :)

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

— Когда Оксана сказала «ответь мне, только честно!», Олег приготовился п*здеть как никогда (ц)

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

Структуру бесед я уже приводил.

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

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

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

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

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

Когда не работает

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

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

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

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

Преступники и психопаты отдельная тема. Это не про нас.

Телеметрия

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

Я очень сомневаюсь, что «коммерческие конторы» так делают.
Но буду верить в лучшее.

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

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

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

Падытожим. Опросить человека, и снять показания с полиграфа проводами — дело не такое сложное.

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

Hope that helps, ну и развлёк вас еще немного.

HR и полиграф (детектор лжи)

2026-05-02T14:17:19.671Z

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

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

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

Если на собеседование на уровень C-руководителя условный Сбербанк или Газпром хочет полиграф — их право, законом не запрещено.

Если лично конкретно Васю это парит, всегда можно отказаться. У нас страна свободная.

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

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

Поэтому исследует вас и вашу реакцию не полиграф. Исследует вас исключительно полиграфолог. Живой человек.

Описываю сначала самый простой и топорный протокол. Так не надо делать вживую, это жирное упрощение, но вот минимальная канва сюжета.

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

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

Это вводные вопросы «общего характера». Опишите погоду за окном. Расскажите, чего обычно готовите на завтрак. Расскажите, что думаете о компании (если мы про HR). Как вы выбираете одежду на день. Есть ли у вас домашние животные, кого больше любите, кошек или собак. Увлекаетесь ли спортом. Любите ли путешествовать, где были. И тому подобное. Нам надо успокоиться и определить состояние нормальное.

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

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

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

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

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

Повторюсь: полиграфологу пофиг на ваши ответы. Ему важна ваша реакция.

Умный развесистый протокол (который мы когда-то с Юрой К., привет, проектировали в СПбГУ, доводили до ума) содержит около 300+ вопросов и 8 шкал, включая 2 калибровочные. Это веселуха часа на два. Он хорош тем, что там две калибровочных шкалы, которые позволяют исключить намеренное враньё и девиацию от ошибок.

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

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

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

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

Вопросы по группам риска обычно включают в себя тематики:

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

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

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

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

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

Модель поведения

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

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

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

Как врач МРТ в поликлинике: назовите хоть одну причину, почему ему на вас не насрать.

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

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

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

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

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

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

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

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

Это — нормально. Закон и практика на вашей стороне.

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

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

В результате исследования будут подсвечены (в результатах в протоколе):

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

Примеры результатов можно легко загуглить.

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

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

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

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

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

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

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

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

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

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

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

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

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

Hope that helps.

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

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

Вот тут продолжение, посмотрите если зашло, и если интересно: https://cgvictor.ru/hr-polygraph-2

P. S. Я так вольно пишу в вопросах «расскажите», но на практике если время ограничено — я бы ожидал «данетку», вопросы «да или нет». Если спрашивают глупость или двусмысленность — «перестали вы пить коньяк по утрам?»(ц) — так и скажите, вопрос некорректно поставлен.

P. P. S. Логично указывают, я не упомянул, что: вне зависимости от полиграфа, хорошо бы ваши ответы на вопросы не отличались фактурой друг от друга :) в смысле чтобы вы сами себе не противоречили. А то можно спокойно и честно наговорить такого, что с вашим же написанным в резюме не будет совпадать. СБ почешет голову на две версии правды, и сделает какие-то свои выводы.

PMBoK и PRINCE2: тяжелая артиллерия

2026-04-30T19:12:22.565Z

Если с различными Agile жить просто и понятно, то вот эти две методологии, стандарта — уже серьёзнее. Плана больше, разброда меньше, требования жестче.

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

PMBoK (Project Management Body of Knowledge)
PRINCE2 (Projects IN Controlled Environments)

Для старта, что в обоих важно, и что отличается от различных Agile:

— требования и задача фиксируются и планируются.

Заранее, на старте.

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

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

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

Корректно сказать, что в этом смысле они, оба два подхода, ближе к waterfall-модели.

PMBoK (Project Management Body of Knowledge)

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

В последних версиях PMBoK упоминается не только «каскадная модель» (waterfall), но есть дополнительно дается набор методов — итеративный, предиктивный, гибридный — то есть, можно кусками подобрать гибкие подходы внутрь операций. Чтобы не замыкаться намертво в жестких рамких процессов там, где объективно не надо.

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

Что внутри:

10 областей знаний (потому что knowledge): управление интеграцией, содержанием, сроками, стоимостью, качеством, ресурсами, коммуникациями, рисками, закупками, заинтересованные стороны
5 групп процессов: инициация, планирование, исполнение, мониторинг/контроль, закрытие. Итого около 50 процессов (5х10).
содержание работы, время и стоимость/ресурсы фиксированы, и жестко связаны. Это не «выберите любые два»; мы знаем что мы делаем, и как конкретно.
соответственно, цель — пройти каждый этап практически, и весь проект с минимальными отклонениями от плана (и от оценки).

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

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

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

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

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

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

Дальше прилагаем к этому календарное + ресурсное планирование, и понеслась.

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

PRINCE2 (Projects IN Controlled Environments)

Prince — это методология управления проектами, внутри которой (аналогично) лежит директивный контроль. А также управление исключениями.

У нас есть заданные заранее бизнес-задача, требования и допуски (от Project Board), далее менеджер действует самостоятельно, по этапам. Пока в эти допуски — по срокам, бюджетам, качеству — укладывается. Если не укладывается, вопрос эскалируется до собрания PB.

В основе и по центру лежит бизнес-обоснование, business case. Содержимое «чего делаем, чего строим, как мы это делаем» записано в Business Case и в Initiation Docs, и в любой момент может (и должно) быть оценено применительно к кейсу, и к бизнесовой целесообразности.

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

Управление в PRINCE обязательно по стадиям, с процедурой оценки каждой стадии. И по допускам, и по бизнес-цели.

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

Что внутри:

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

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

Ответ на вопрос «что» фиксируется заранее, ответ «как» можно подгонять под необходимости.

Управление в prince иерархическое: команда, менеджер проекта, руководство проекта (project board), руководство компании.

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

Организация внутри команд: как ни странно, в prince можно впихнуть agile на командном и тактическом уровне. Так бывает, так и называется, Prince Agile. Управленческая структура сохраняется, а внутри команд или даже целых стадий — работайте чем удобно, хоть скрамом, хоть досками, хоть гибридом.

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

Гибриды

Тут да, можно сказать что из этих двух, «гибридизируются» они только на тактическом уровне, и то не очень шедеврально. Потому что agile и гибкие практики фокусируются на релизе, продукте, time to market — а эти два на плане, структуре задач, и фиксируют содержание работ. Фокус разный.

Плюс к тому, «непонятные» задачи исследовательского типа, которые нормально перевариваются в agile — в PMBoK/Prince вам запросто похоронят и оценки, и допуски, и ожидания по срокам/ресурсам.

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

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

Ритуалистика вам привнесет только профанацию и кучу ненужной работы.

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

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

PMBoK: косяки и грабли

Масштаб документации (golden burden)

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

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

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

Управление рисками, которое не актуализировали

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

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

Критерии стопа проекта (stop-loss)

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

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

Надо прописывать конкретные цифры, конкретные нестыковки, конкретные убытки. И проверять. Ну да, риски — а что вы хотели.

Критерии бизнес-кейса

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

Иначе в документе появляется пункт «улучшить XXX» или «оптимизировать YYY», выгода с которого никому не понятна, а definition of done может уехать в любую сторону от нуля до бесконечности.

«Улучшить» — это на граммулечку достаточно, или надо чтоб до горизонта?

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

Иллюзия контроля

То, что PMBoK заставил нас написать план, вот ваще не гарантирует (само по себе), что этот план будет синхронизирован с реальностью, и даже с бизнес-целью.

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

Неготовность пересмотреть содержание (и да, сломать PMBoK) любой ценой no matter what — это способ похоронить и проект, и бюджет на него. Очень дорогая и ненужная упрямость.

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

Люди

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

Вот есть рукопахарь, он делает X часов работы в день, значит за полгода сделает X*125 рабдней = иди рисуй их в гантовку.

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

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

Всего этого в рисках толком нет, в планах и гантовках тоже особо не впихнешь. Значит, надо рисовать что-то с запасом «на проебать», что мало-помалу обесценивает идею жесткого плана на долгосроке.

Управление изменениями

Любое малейшее изменение в проекте эскалировать до Control Board, и документировать — вы шизанётесь от макулатуры. Ну т.е это писать change request, собирать минимум трех людей на принятие решения, журналировать его, писать change.

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

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

Способы есть. Но точно не в PMBoK. Надо прикручивать снаружи.

PRINCE2: косяки и грабли

Набор проблем похожий, как раз там, где стандарты и методологии сами похожи. Но тем не менее.

Бюрократия и театр управления

В принсе прописан ряд ролей, которые участвуют в принятии решений и во всяких boards. Ролей много. А людей на небольших проектах мало. В результате получается, что одни и те же люди принимают решения на разных уровнях, просто потому что методология того требует: играть роли, проводить формальные собрания итд. Либо вообще, управленцев становится больше, чем реализаторов. Если такое произошло — ну не майтесь дурью, сократите управленческую вертикаль. Оставив исключительно приверженность к допускам — чтобы не получилось «сами подумали, сами планы поменяли», вот так нельзя.

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

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

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

Разрыв в эскалациях

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

Либо шевелитесь быстрее, либо сокращайте составы (так можно: board неполным составом), либо вписывайте в анализ и принятие решений прямую коммуникацию верх-низ.

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

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

Тонна документов, и не-адаптация подходов

Сдуру можно и хер сломать. Если не адаптировать prince под реальность — в основном, выкидывая воду, и сокращая раздутость документов — то получается как в PMBoK, golden burden и потеря смыслов за макулатурой. Что даже более больно, потеря времени на ритуалистику с цепочками документов туда-сюда. Тяжесть проекта и внедрения усугубляется тем, что Agile с подобной фигней справляется лучше, как минимум быстрее. Иногда упущенное время важнее структуры управления. Пока вы тут заседаете, конкуренты продукт выкатывают.

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

Критерии стопа / допусков

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

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

Обучение на опыте (и постмортемы)

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

На практике, если не ходить и не проверять — там будет написано вроде «мы не попали в планы = надо было лучше планировать».

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

Так что придется быть конкретным.

Падытожим.

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

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

Или делайте компактно и по сути, или откажитесь в пользу более легких подходов.

Бизнес-ценность с оценкой, и прозрачность с контролем (без приукрашиваний и подгонок под ответ) — это core vitals, без них будет цирк.

Hope that helps.

Не надо «учить рынок жить»

2026-04-20T13:47:57.810Z

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

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

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

Почему-то оказывается, что ведётся на новизну и прорывные пропозиции куцый 1% аудитории. А для того, чтобы из 1% стало минимум 5% — надо влить какую-то тонну бабла в собственный маркетинг, ну или подождать лет десять, пока само настоится. Ждать неохота, кушать хочется.

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

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

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

Но денег там нет. И спроса нет. И потребности нет. И клиента нет.
Есть влажные фантазии.

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

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

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

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

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

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

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

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

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

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

В то же самое время, постановка вопроса «хотите мы ваши проблемы решим за $1000/месяц» уже совсем не настолько радужная; васяны хотят денег, вдобавок еще какую-то суету навести и рисков принести с собой. Оно нам надо? Да вряд ли.

Пока нахаляву — ну сходите, рискните, дело ваше.

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

Вот только у вас их нет. А там, где они есть — стопудово и без вас тесно.

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

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

Иначе (альтернативно) можете сходить нахуй, с комфортом фантазий и с инновациями, но за свой счёт.

Проверочный маркер: если надо кому-то убедительно доказывать, какие вы крутые, нужные и инновационные — что-то идёт не так. Решение конкретной очевидной проблемы, и закрытие реальной потребности на вменяемых условиях, если никто никому в процессе не пиздит — это обычно shut up and take my money. Еще и в очередь выстроятся. Крутое решение — ну, продемонстрируй.

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

Говоря о рецептах: тесты, тесты, тесты.

В стартаперской среде есть даже упражнение, сначала попробовать продать собственный продукт по описанию, оценки, предзаказы, а уже только потом, на основании полученной информации, что-то с этой нишей делать. Market first. Но это же не-инновационно, сталкивает с жесткой реальностью, да и жопа болит.

Интереснее играться и вливать бюджеты в никому (по факту) не пригодившиеся фантазии. Первые 40 лет детства самые сложные.

Hope that helps.

Обновление скрам-гайда

2026-04-13T13:09:06.249Z

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

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

The Scrum framework is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.

Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.

Думаю, с этим моментом разберётесь, я уже несколько раз подробно об этом писал.

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

Цель продукта

Добавилось описание product goal. Предполагается, что итерации/спринты мы еще оцениваем по части того, насколько они приближают нас к цели. Соответственно, можно сравнить импакт, и постараться взять куски работы чутка полезнее.

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

Цели у каждого этапа

Они были, их просто нормально прописали. Теперь у продуктового беклога общая цель — это product goal, у беклога спринта — это sprint goal, у инкрементов/кусков работы это Definition of Done.

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

Планирование спринта

Кроме вопросов «что делаем?» и «как делаем?» добавился третий вопрос «нахера делаем?», в смысле Why. Не в метафизическом смысле, а чего конкретно нам это дает из Product Goal и почему хотим сейчас именно это.

Why хорошая штука, которая позволяет нормально прописывать ADR (architecture decision records): что сделано, почему, как выбирали, и почему выбрали именно это.

Овнер и менеджер тоже часть команды разработки

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

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

Это раскрывает вопрос «совмещения ролей». Хотите — совмещайте. Лишь бы делалось в полном обьеме.

Овнер и с/мастер и все остальные т.к часть scrum team, «предельный» размер увеличен ST до 10 человек. Но это вообще пофиг, это ограничение всегда было рекомендательным и само-очевидным, много людей = больше бардак.

Сокращение обязательных частей

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

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

Само-управление вместо само-организации

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

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

Убрали привязки к циклу разработки

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

Основная цель

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

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

Как соотносятся задачи в Product Backlog с основной целью — зона ответственности Product Owner.

Product теперь прописан более конкретно. Как механизм (который вы строите), который приносит заявленную ценность. You need to build an engine.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

Из всего этого логически вытекает, что цель должна быть конкретной и измеримой. Конкретность определяется ценностью и набором изменений; а конкретнее по тексту, даже целевым состоянием: «a future state of the product which can serve as a target». Набор изменений от «сейчас» до «зашибись» собираются в product backlog.

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

«захватить мир» — херовая цель, потому что вы нормально это не измерите (даже в моменте), а конкретики нет
«захватить мир к октябрю» — не сильно лучше
«получить вот тут показатель лучше конкурента» — уже что-то. Потому что измеримо, хотя и относительно
«получить вот тут рост показателя на X» — измеримость появляется, можно сравнивать одно с другим
«сделать вот такие и вот такие фичи» — конкретно, но не измеримо (потому что сделать можно по-разному)
«сделать фичи по списку и получить вот такую целевую метрику» — конкретно, измеримо, но не факт что одно будет связано с другим
«сделать AA чтобы получилось XX (достигаем вот этого), сделать BB чтобы YY (будет вот так)» — еще получше, появились связи, их проще дебажить и оценивать
«сделать в продукте вот этот список, чтобы по нему последовательно получить вот такие улучшения, чтобы общие метрики стали вот такими» — уже близко к рабочему варианту, нормас (есть гипотеза, есть план, есть показатели)

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

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

С несколькими продуктами скрам работает херово. Фокусировка микрокоманды разваливается. Этот момент был, и он не поменялся.

Hope that helps.