Техническая разведка

в 9:32, , рубрики: анализ данных, Анализ и проектирование систем, Блог компании Timeweb Cloud, история, Научно-популярное, разведка, техническая разведка, ЦРУ, Читальный зал
Привет. Я знаю, что вы любите статьи «Чему я научился…». Обычно в них рассматривается либо личный опыт работы, либо различные книги с полезными советами. Сегодня я предлагаю вам посмотреть какой полезный опыт можно извлечь из методичек ЦРУ на примере материала Robert M. Clark «Scientific And Technical Intelligence Analysis», написанного в 1976 году. Казалось бы, ну чего там может быть полезного в повседневной жизни, да ещё сейчас, в XXI веке? Всем, кому это интересно – добро пожаловать под кат.

Техническая разведка - 1

Пара слов о технической разведке в ЦРУ

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

До 1945 года никакой систематической работы разведслужб США против СССР не велось, во время войны тем более. Закрытость первого государства рабочих и крестьян для доступа извне делала почти невозможным получение достоверной информации оттуда, кроме как от собственных дипломатов и из цензурируемой советской печати. И даже эта скупая информация была по понятным причинам не всегда достоверна. Конечно, «бывший» нацист Рейнхард Гелен, вовремя сбежавший с тонущего корабля Тысячелетнего Рейха, предложил немцам готовые разведсети бывших нацистских разведслужб по всей Восточной Европе вместе со своей персоной в качестве главы этой новоявленной карманной разведслужбы. Но принятие предложения Гелена делало ситуацию лишь ещё более болезненной – теперь, американцы плотно подсаживались на информацию от своего немецкого коллеги, при этом почти не имея своей хотя бы для проверки сведений, поставляемых Геленом. К слову, это сыграет с американцами злую шутку уже в 1960-е, когда выяснится, что в немецкой спецслужбе BND, возглавляемой Геленом, чуть ли не с самого основания работало несколько советских кротов на самом высоком уровне.

Конечно, ключевой целью перед, созданной в 1947 году для объединения усилий по внешней разведке, ЦРУ была организация собственных разведсетей в Восточной Европе. Но эта задача была и самой сложной, так как всё та же закрытость стран Восточного блока и в особенности СССР мешала любой заброске или вербовке агентов внутри, а значит затрудняла доступ к столь необходимым достоверным сведениям. Поэтому в структуре ЦРУ с самого начала были сформированы в большом числе отделы, целиком состоящие из аналитиков, чьей работой был анализ различной прямой (фотографии с самолётов и спутников-шпионов, отчёты разведки) и косвенной (периодика, книги, фильмы) информации. Данные подразделения были сгруппированы по направлениям деятельности, среди которых было крупнейшее – техническая разведка.

Техническая разведка - 2
Дайте аналитикам из Управления Науки и Технологий точку опоры и они перевернут мир

4 сценария анализа данных технической разведки

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

При этом перед специалистом технической разведки стояла задача больше похожая на попытку угадать на ощупь в тёмной комнате ухватил он хобот или хвост слона и слон ли это вообще. Единственные оружейные выставки, на которые СССР возил свои новинки, были парады и учения, а значит никакой достоверной информации о советском вооружении, пока его не применят, не было.Ни тебе рекламных буклетов, ни макетов и демонстрационных образцов – в лучшем случае мутное фото со спутника или ретушь с очередного парада в день Октябрьской революции. В худшем же – слухи разной степени полноты и достоверности.А эта ситуация совершенно неприемлема, так как столкновение с неизвестным новым оружием может стать источником больших проблем. Поэтому перед аналитиками технической разведки стояла нетривиальная задача – по минимуму достоверной информации определить, что же разрабатывает или уже разработал Советский Союз. Робер Клар, составивший материал для обучения ЦРУшников, выделил 4 сценария с которыми может столкнуться работник технической разведки в ходе своей работы.

Техническая разведка - 3
А теперь, американский tovarisch, гадай что же за вундерваффе ты увидел на фото

Первый сценарий. Мы разрабатываем оружие – они разрабатывают оружие

Самый распространённый сценарий. Американцы разрабатывают Межконтинентальные баллистические ракеты (МБР) – СССР разрабатывает МБР. Американцы ставят разделяющиеся головные части МБР — СССР ставит разделяющиеся головные части МБР. И т.д. В данном случае большим подспорьем является знание об актуальных разработках своей же страны. Сравнивая разрозненные данные по иностранным и собственным разработкам, можно с достаточной точностью восстановить неизвестные технические параметры, увидеть преимущества и недостатки, а также возможные пути улучшения и модернизации. Знание возможностей собственной промышленности в этом случае может позволить провести оценку способности промышленности противника к производству отдельного вида вооружения: понимание производственных цепочек позволяет оценивать трудо- и материалозатраты, искать подобные производственные цепочки у противника и оценивать их масштаб. К сожалению, секретность многих разработок и данных по собственным же системам может значительно мешать в такой работе.

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

Второй сценарий. Мы разрабатываем оружие – они не разрабатывают оружие

В этом случае перед сотрудником разведки стоит непосильная задача – в разведке отсутствие информации о чём-либо вовсе не значит, что этого чего-либо не существует. А потому, даже если нет информации о разработках противника, то необходимо обосновать, что у него таких разработок быть не может. Зачастую задача эта трудновыполнима. Например в сводках ВВС США начиная с 1960-х постоянно указывалось, что СССР вот-вот должен поставить на собственные перехватчики допплеровский-импульсный радар, но на 1976 год никакой информации о его разработке не было (и действительно первые такие радары для перехватчиков поступили на вооружение только в начале 80-х). Ещё более сложный случай- это ситуация с бомбардировщиком Ту-22, который в теории мог быть использован, как стратегический бомбардировщик, но без доступа к машине или её документации, опровергнуть данный тезис было невозможно. Если вам кажется, что это всё напоминало историю про мальчика, который кричал «Волки!», то так и есть – чем дольше предположения не сбывались, тем меньше им было веры.

"Техническая разведка - 4
Ту-22М3. Формально тактический бомбардировщик, но во-первых американцы этого не знают, а во-вторых, дозаправку в воздухе никто не отменял. Другой вопрос — а стоит ли оно таких сложностей

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

Третий сценарий. Мы не разрабатываем оружие – они разрабатывают оружие

Самый опасный сценарий, так как в этом случае часто приходится биться головой о стену скептицизма. Обычно наибольшими скептиками являются учёные или инженеры, которые потерпели неудачу со своим проектом и сумели убедить всех остальных, что сделать нечто подобное невозможно. Наиболее ярким случаем такого подхода является разработка СССР противокорабельных ракет. В начале 1960-х разведка США получила информацию о таких разработках, но флот, уже обжёгшийся на неудачных проектах, не воспринял эти предупреждения всерьёз. Всё перевернуло потопление израильского эсминца «Эйлат» советской ПКР в 1967 году. Так как об этом виде оружия никто ничего не знал, то и придумать какие-то контрмеры не было возможности. После этого случая в Пентагоне были очень недовольны консерватизмом флота, называя флотских«кучкой недоумков».

Техническая разведка - 5
ПКР П-15 «Термит». С точки зрения ВМФ США её не могло существовать, ракете об этом сообщить забыли

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

Четвёртый сценарий. Мы не разрабатываем оружие – они не разрабатывают оружие

Этот сценарий во многом похож на сценарий 2, так как тут тоже требуется доказать отсутствие возможности у врага создать некое оружие. Показателен случай, произошедший в 1975 году. К разведчикам пришёл представитель Пентагона с идеей, что СССР мог разместить в космосе спутники ПРО с ультрафиолетовыми лазерами, чтобы сбивать американские баллистические ракеты (что-то знакомое, не правда ли?). Разведчики вынуждены были отработать идею, но в тот момент, когда предварительный расчёт стоимости системы превзошёл стоимость всей лунной программы США, идею отбросили. Тем не менее с каждым таким «а что, если» разведчик должен разбираться, так как пример сценария 3 с излишним скепсисом может привести к трагедии.

Какие выводы можно сделать: во-первых, насколько бы безумной не казалась идея, отвергать её следует только после всестороннего анализа. Во-вторых (привет мистер Рейган), любую безумную идею можно продать при грамотном маркетинге – советские спецы тоже говорили военному и политическому руководству Союза про нереализуемость программы «Звёздных войн» в США, но они были не столь убедительны, как американские пиарщики.

Техническая разведка - 6
А я и сам обманываться рад

Минутка повышения эффективности

Или почему в комиксе Сова-эффективный менеджер Сова не всегда неправа

Техническая разведка - 7

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

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

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

Ключевые принципы работы аналитика разведки

«Бритва Оккама»

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

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

Не будь крестоносцем

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

Примером того, почему такой подход вреден служит история с разработкой советской межконтинентальной баллистической ракеты (МБР) Р-9А или по классификации НАТО SS-8 Sasin. После получения в 1961 году информации об испытаниях новой МБР в СССР между ВВС и ЦРУ разразилась натуральная война. Аналитики ВВС считали, что раз у СССР есть большая МБР (Р-7 или SS-6) и маленькая МБР (Р-16 или SS-7), то SS-8 должна быть ещё большей, чем SS-6. ЦРУ с такими выводами было несогласно. В итоге разведсообщество США поделилось на сторонников «большой SS-8» и «маленькой SS-8». В условиях минимума информации оба лагеря ни в какую не шли на компромисс из-за чего пришлось формировать специальный независимый комитет для проведения анализа ситуации с ракетой. В итоге правильной оказалась точка зрения ЦРУ, но война между разведчиками на 2 года парализовала всяческую конструктивную дискуссию на эту тему.

Техническая разведка - 8
«Маленькая» МБР, МБР поменьше и «большая» МБР

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

Все могут ошибаться, даже эксперты

Спецификой работы аналитиков ЦРУ было то, что нередко для решения какой-то сложной задачи знаний аналитиков не хватало. Обычно это происходило, когда проблема лежала на стыке разных дисциплин или наоборот в очень узкой области, требующей глубокого в неё погружения. ЦРУ не могло, да и не хотело, тратить деньги на содержание специалистов по любому вопросу, поэтому для решения проблем нередко привлекали специалистов со стороны. Всё же заплатить за одну конкретную задача один раз это не то же самое, что платить каждый месяц. Довольно скоро вокруг ЦРУ возник целый пул подрядчиков — экспертных сообществ («think-tank»), которые брали у ЦРУ заказы на оказание консультаций по разным вопросам. Экспертами в них могли быть учёные и инженеры с мировым именем, которые иногда оказывали ЦРУ за деньги консультации.

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

Какие выводы можно сделать: даже авторитетное мнение нуждается в проверке, так как все могут ошибаться. Особенно это важно в отношении подрядчиков, поэтому «не верь своему подрядчику»…

… и правильно ставь ТЗ

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

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

Вместо заключения

Несложно заметить, что как ситуации, которые описаны в методичке ЦРУ, так и выводы сделанные мной, на самом деле не являются каким-то открытием. Уверен, что каждый из вас хоть раз сталкивался по работе с описанными ситуациями. А потому, возможно, что данный текст будет не бесполезным.

Автор: Владимир Герасименко

Автор:
nemirnyatom

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js