{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Product × Science",
    "_rss_description": "Заметки про проектирование, исследования и данные. Делюсь опытом и рассказываю как с их помощью создавать сложные технологические продукты. Автор — аналитик, разработчик и исследователь с опытом создания сервисов с многомилионной аудиторией.",
    "_rss_language": "ru",
    "_itunes_email": "martsen.anton@yandex.ru",
    "_itunes_categories_xml": "",
    "_itunes_image": "https:\/\/pxs.md\/pictures\/userpic\/userpic-square@2x.jpg?1768130329",
    "_itunes_explicit": "no",
    "home_page_url": "https:\/\/pxs.md\/",
    "feed_url": "https:\/\/pxs.md\/json\/",
    "icon": "https:\/\/pxs.md\/pictures\/userpic\/userpic@2x.jpg?1768130329",
    "authors": [
        {
            "name": "Антон Марцен",
            "url": "https:\/\/pxs.md\/",
            "avatar": "https:\/\/pxs.md\/pictures\/userpic\/userpic@2x.jpg?1768130329"
        }
    ],
    "items": [
        {
            "id": "68",
            "url": "https:\/\/pxs.md\/all\/trisigma-webinar-analytics-for-autonomous-vehicles\/",
            "title": "Вебинар с Trisigma: Как оценивать качество AI-продуктов, которые оперируют в физическом мире",
            "content_html": "<p>Качество AI-продуктов и аналитика безопасности автономного транпорта<\/p>\n<p>«Воплощенный ИИ» — это тема нишевая, которая стремительно набирает обороты. Тренд очевиден.<br \/>\nВерю, что через пять лет «вкусные» сервисы, продукты и вакансии будут в нише роботизированных продуктов. Собственно, поэтому я и занимаюсь этим уже сейчас и призываю присмотреться других уже сейчас.<\/p>\n<p>13 марта мы лампово поговорили про эту область с Витом из Trisigma (ex-ExpF).<\/p>\n<p>Обсудили<\/p>\n<ul>\n<li>мой опыт и чем я занимался раньше: программирование, роботы, построение аналитики с нуля, стартапы и Яндекс<\/li>\n<li>роль безопасности в понятии «качество»<\/li>\n<li>популярные вопросы про роботов и автономный транспорт<\/li>\n<li>как устроена аналитика и в чем отличие от онлайн-сервисов: сбор данных, подбор метрик, симуляции и эксперименты<\/li>\n<\/ul>\n<p>Запись вебинара — <a href=\"https:\/\/vk.com\/video-152990965_456240137?list=ln-DkUDH24Me6NuBFM52K\">VK<\/a>, <a href=\"https:\/\/youtu.be\/Y_bFmWjyofU\">YT<\/a><\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/Y_bFmWjyofU?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2026-03-23T09:45:21+03:00",
            "date_modified": "2026-03-24T08:33:20+03:00",
            "tags": [
                "AV",
                "Безопасность",
                "Публичные выступления"
            ],
            "image": "https:\/\/pxs.md\/pictures\/remote\/youtube-Y_bFmWjyofU-cover.jpg",
            "_date_published_rfc2822": "Mon, 23 Mar 2026 09:45:21 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "68",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/remote\/youtube-Y_bFmWjyofU-cover.jpg"
                ]
            }
        },
        {
            "id": "67",
            "url": "https:\/\/pxs.md\/all\/levels-of-driving-automation\/",
            "title": "Уровни автоматизации вождения",
            "content_html": "<p>Согласно стандарту <a href=\"https:\/\/www.sae.org\/standards\/j3016_202104-taxonomy-definitions-terms-related-driving-automation-systems-road-motor-vehicles\/\">Society of Automotive Engineers (SAE) J3016<\/a>, существует пять уровней автоматизации (шесть, если за нулевой принять полное отсутствие). Попробую рассмотреть их с точки зрения «автопилот как продукт».<\/p>\n<p>photo_2026-03-09-12.47.00.jpeg<\/p>\n<h3>L0: Без автоматизации<\/h3>\n<ul>\n<li>Никак не вмешивается в управление автомобилем<\/li>\n<li>При этом на нулевом уровне есть фичи для «усиливания» способностей человека воспринимать ситуацию и управлять автомобилем: антиблокировочная система, гидроусилитель руля, парктроник<\/li>\n<li>Полная ответственность за ситуацию на дороге на человеке<\/li>\n<\/ul>\n<h3>L1: Ассистирование<\/h3>\n<ul>\n<li>Автоматизация одного измерения управления: продольные (газ\/тормоз) ИЛИ поперечные (руль) маневры. Другой тип маневра делается человеком.<\/li>\n<li>Фичи: подруливания, удержание в полосе по дорожной разметке, корректировка скорости по впереди идущему автомобилю.<\/li>\n<li>Водитель следит за всеми действиями и готов в любой момент перехватить управление.<\/li>\n<\/ul>\n<h3>L2: Частичная<\/h3>\n<ul>\n<li>Машина может самостоятельно решить задачу, комбинируя продольные и поперечные маневры, т. е. человек не нужен для совершения «динамической водительской задачи» (Dynamic Driving Task, DDT).<\/li>\n<li>Фичи: автоматическая парковка, смена полосы по всем правилам, активный круиз-контроль<\/li>\n<li>Водитель следит за всеми действиями и готов в любой момент перехватить управление.<\/li>\n<\/ul>\n<h3>L3: Условная<\/h3>\n<ul>\n<li>Похоже на L2, но<\/li>\n<li>предусмотрены резервные системы для сенсоров<\/li>\n<li>отслеживается состояние водителя, чтобы в случае чего передать ему управление. Если водитель заигрался или уснул, то L3 будет всячески стараться привлечь его внимание и отказываться ехать.<\/li>\n<li>Водитель может отвлечься, но остается ответственным за действия автомобиля.<\/li>\n<li>Фичи: мониторинг состояния водителя, движение в спец. зоне<br \/>\n(пробка, склад, конкретный тип шоссе).<\/li>\n<li>Широкого распространения не получили, т. к. сутево не отличаются от L2, но накладывают больше ограничений на производителя и пользователя.<\/li>\n<\/ul>\n<h3>L4: Высокая<\/h3>\n<ul>\n<li>Полностью оперирует в заявленных условиях эксплуатации (Operation Design Domain, ODD).<\/li>\n<li>Фичи (а скорее продуктовые сценарии с понятным коммерческим потенциалом): перевозка груза со склада на склад между городами по шоссе, такси внутри города без заезда во двор, автоматическая остановка в безопасном месте и вызов оператора<\/li>\n<li>Высокоавтоматизированное транспортное средство (ВАТС) самостоятельно оперирует в рамках ODD, человек нужен только в нештатных ситуациях (сгодится удаленный оператор).\n<ul>\n  <li>Именно тут сейчас разгорается битва у БигТеха и миллиардных стартапов, в которой принимает участие ваш покорный слуга.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<h3>L5: Полная<\/h3>\n<ul>\n<li>Автопилот самостоятельно действует в любых условиях, помощь человека не нужна ни в каком виде<\/li>\n<li>Интересный эффект на дизайн салона: можно рассмотреть полный отказ от руля и реорганизовать пространство<\/li>\n<li>Пока выглядит слишком утопично, т. к. непонятно, как гарантировать автономное и корректное действие в любых потенциальных ситуациях.<\/li>\n<\/ul>\n<p>——<\/p>\n<p>Реальные автомобили, конечно же, не разделены четко по этой схеме. Слишком много нюансов в понятиях «маневр» и «условия эксплуатации», чтобы все четко разложить по уровням. Автопроизводители могут дать фичей уровнем выше, но по документам идти как более простой автопилот.<\/p>\n<p>Tesla тут яркий пример — она долгое время маркетировала себя как «полноценный автопилот», но по документам проходила как L2. Зачем это сделано? Чтобы в случае инцидента четко атрибутировать ответственность на водителя. Подробнее про маркетинг, его влияние на доверие к технологии и что с этим делают напишу в следующих постах.<\/p>\n<p>Что еще важного, но о чем не сказано в стандарте. Уровень автоматизации не равен уровню безопасности, и SAE J3016 об этом явно пишет. Безопасность автопилота (как частный случай Physical AI Safety) имеет свои критерии. Про безопасность, методы оценки и повышения поговорим отдельно, т. к. этим я пристально занимаюсь.<\/p>\n",
            "date_published": "2026-03-01T17:34:00+03:00",
            "date_modified": "2026-03-09T12:47:20+03:00",
            "tags": [
                "AV"
            ],
            "_date_published_rfc2822": "Sun, 01 Mar 2026 17:34:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "67",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "24",
            "url": "https:\/\/pxs.md\/all\/willingness-to-delegate\/",
            "title": "Готовность делегировать цифровому ассистенту",
            "content_html": "<p>В <a href=\"https:\/\/pxs.md\/all\/ux-metrics-guide\/\">гиде по UX-метрикам<\/a> я писал, что показателей много, но есть ограниченный набор сущностей, которые интересны для замера с точки зрения дизайна и продукта. Похоже, с развитием ИИ-помощников на сцену выходит новая концепция — готовность человека делегировать выполнение и\/или принятие решений цифровому ассистенту.<\/p>\n<p>В работе <a href=\"https:\/\/dl.acm.org\/doi\/10.1145\/3544549.3585763\">Expectation vs Reality in Users’ Willingness to Delegate to Digital Assistants<\/a> создается модель «готовности делегировать»: определены основные «переменные» и причинно-следственные связи.<\/p>\n<p><i>Исследование опубликовано в начале 2023г, поэтому часть тезисов выглядят банальными, а рекомендации устаревшими, но все еще злободневно даже три года спустя.<\/i><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png\" width=\"2160\" height=\"1215\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Теоретическая модель на основе изученной литературы<\/div>\n<\/div>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/conceptial-model-of-willingness-to-delegate.png\" width=\"2160\" height=\"1215\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Модель на основе проведенного исследования и применения математического аппарата<\/div>\n<\/div>\n<h2>Ключевые тезисы и рекомендации<\/h2>\n<p><b>Завышенные ожидания пользователей от ассистентов<\/b><\/p>\n<ol start=\"1\">\n<li>Чем проще работа с ассистентом, тем выше желание делегировать ему задачу (или как минимум попробовать)<\/li>\n<li>При этом, чем больше человек пробовал работать с агентами, тем меньше желание делегировать (видимо, столкнулся с негативным опытом и понял ограничения)<\/li>\n<\/ol>\n<p>Выводы отсюда очевидные: работать над качеством, менеджить ожидания, более сдержанно давать обещания<\/p>\n<p><b>Процесс работы ассистентов не прозрачен, а контроля практически нет<\/b><\/p>\n<p>Чем важнее задача, тем меньше желание делегировать. Так как нет доверия к системе, то и делегировать «субъективно рисковые» задачи не хочется. Даже если пользователь думает, что агент мог бы быть полезен.<\/p>\n<p>Чтобы повысить шанс допуска агентов к более сложным задачам со стороны юзера, нужно:<\/p>\n<ol start=\"1\">\n<li>Определить сценарии, где людям нужен больший контроль.<\/li>\n<li>Бить критичные задачи на подзадачи, объяснять что будет сделано, дать контроль порядком шагов и их наполнением<\/li>\n<\/ol>\n<p><b>Полезность ассистентов возрастает, когда человеку сложно выполнить задачу, но при этом увеличивается и субъективная сложность работы<\/b><\/p>\n<ol start=\"1\">\n<li>Используйте ситуации, в которых пользователям сложно выполнить задачу без посторонней помощи, например, когда у них заняты руки или они не видят экран, чтобы продемонстрировать преимущества помощника.<\/li>\n<li>Сделайте взаимодействие в таких ситуациях ещё проще<\/li>\n<\/ol>\n<p><b>Частотность сценариев работы ассистента не связана с субъективной полезностью, но повышает доверие к системе<\/b><\/p>\n<p>Например, пользователи не доверяют ИИ в вопросах, связанных со страховыми случаями, хотя в этом случае ассистенты кажутся полезными. Пользователи доверяют роботам в вопросах информации о погоде, но это не самый полезный сценарий.<br \/>\nСортировать беклог только по частотности сценария выглядит не самым разумным подходом.<\/p>\n<h2>Ссылки<\/h2>\n<ol start=\"1\">\n<li><a href=\"https:\/\/youtu.be\/Lgk2bBXRnsQ?si=vEA8_ciN9BwEChSu\">Краткая видео-презентация<\/a> и <a href=\"https:\/\/drive.google.com\/file\/d\/1DO2d0PtnxUbZougAK8U8JSkgMwlcqnia\/view?usp=drive_link\">слайды<\/a><\/li>\n<li><a href=\"https:\/\/dl.acm.org\/doi\/10.1145\/3544549.3585763\">Научная работа<\/a><\/li>\n<li><a href=\"https:\/\/sea94.github.io\/\">Сайт автора работы<\/a><\/li>\n<\/ol>\n",
            "date_published": "2026-01-19T10:31:58+03:00",
            "date_modified": "2026-01-19T12:31:06+03:00",
            "tags": [
                "HCI",
                "ИИ",
                "Исследования"
            ],
            "image": "https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png",
            "_date_published_rfc2822": "Mon, 19 Jan 2026 10:31:58 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "24",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/willingness-to-delegate-concept.png",
                    "https:\/\/pxs.md\/pictures\/conceptial-model-of-willingness-to-delegate.png"
                ]
            }
        },
        {
            "id": "42",
            "url": "https:\/\/pxs.md\/all\/staff-archetypes\/",
            "title": "Архетипы экспертов",
            "content_html": "<p>Когда я обсуждаю с сотрудниками потенциальные пути развития, то часто вспоминаю статью <a href=\"https:\/\/staffeng.com\/guides\/staff-archetypes\/\">Staff archetypes<\/a> от Уилла Ларсона. Автор — опытный IT-шник, который побывал как в управленческих должностях, так и в роли исполнителя.<\/p>\n<p>Он один из немногих, кто пишет про так называемых <b>Staff<\/b> и <b>Principal<\/b> инженеров — очень высокогрейдовых специалистов, у которых нет прямых подчиненных. Термины пришли к нам из западных компаний. Наиболее близким аналогом для Staff могут выступать роли ведущего или главного инженера, а для Principal — должность эксперта. На мой взгляд, описанные им <b>принципы подходят для любых тех.ролей<\/b>, в т.ч. для аналитиков.<\/p>\n<p>В тексте вводится понятие <b>архетипов<\/b>, которые построены на основе десятков интервью с релевантными людьми на этих ролях. Он составил четыре портрета экспертов, которые встречаются в бизнесе:<\/p>\n<ol start=\"1\">\n<li><b>Техлид<\/b> формирует техвидение, стандарты, практики, растит лидеров, выстраивает устойчивую систему принятия решений. «Свой парень на деревне», т. к. глубоко погружен в предметную область, заработал авторитета у руководителя и коллег.<\/li>\n<li><b>Архитектор<\/b> задает общий вектор движения технологического стека организации или нескольких связующих центральных технологий, чтобы это было экономически целесообразно на долгой дистанции. Может писать код, а может и не писать.<\/li>\n<li><b>Решала<\/b> — это спецназовец, которого можно кинуть в любую «горящую точку» в бизнесе и с высокой вероятностью он поднимет с колен вверенное направление. Зачастую, долго не будет задерживаться на спасенном проекте и его перекинут тушить пожар в другом месте.<\/li>\n<li><b>Десница короля<\/b> — «правая рука», персональный консультант лиц принимающих решения. В целом, из них можно сделать менеджеров в любой момент, т. к. у них много операционного влияния и стратегического контекста, который помогает строить роудмап.<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/staff-archetypes-map-3.jpg\" width=\"2080\" height=\"1922\" alt=\"\" \/>\n<\/div>\n<p>Классификацию Уилла можно представить иначе и разложить архетипы по двум осям:<\/p>\n<ol start=\"1\">\n<li><b>Фокус: Операционка ↔ Долгосрочное видение<\/b><br \/>\nНасколько человек сфокусирован на...\n<ul>\n  <li>непосредственном выполнении\/доставке результата: разруливать конкретные проекты, доводить до прода, устранять блокеры здесь-и-сейчас<\/li>\n  <li>формировании направления: стратегии, задавать технический вектор, принципы, долгосрочные ставки, выбор “куда идти”.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<ol start=\"2\">\n<li><b>Способ донесения ценности: Сам ↔ Через людей<\/b><br \/>\nНасколько влияние достигается через...\n<ul>\n  <li>личный вклад: глубоко копать, проектировать, писать код, быть “экспертом, который делает”<\/li>\n  <li>других людей и систему: выстраивать процессы, согласовывать между командами, строить коалиции, создавать условия, чтобы другие команды успешно работали.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p class=\"loud\">В разные периоды жизненного цикла продукта\/бизнеса нужны разные люди.<\/p>\n<p>От себя лишь замечу, что сложнее всего приходится Архитекторам — у них много высокоуровневых идей, но из-за высокой технической и организационной сложности <b>внедрять их они самостоятельно не могут<\/b>. Им нужен сильный протекторат от топ-менеджеров и умение продавать\/продавливать свои решения в большое количество команд. А команды (и их руководители), будучи не дураками, сами знают как им лучше и не горят желанием реализовывать чьи-то другие представления о прекрасном, особенно от людей, которые не погружены в детали на должном уровне. Уилл тоже от этого предостерегает и в <a href=\"https:\/\/staffeng.com\/book\/\">книге<\/a> приводит истории успешных людей в этой роли.<\/p>\n<p>Почитать подробнее можно в <a href=\"https:\/\/staffeng.com\/guides\/staff-archetypes\/\">оригинальной статье<\/a>.<\/p>\n",
            "date_published": "2026-01-15T10:16:31+03:00",
            "date_modified": "2026-01-15T11:03:47+03:00",
            "tags": [
                "Карьера"
            ],
            "image": "https:\/\/pxs.md\/pictures\/staff-archetypes-map-3.jpg",
            "_date_published_rfc2822": "Thu, 15 Jan 2026 10:16:31 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "42",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/staff-archetypes-map-3.jpg"
                ]
            }
        },
        {
            "id": "1",
            "url": "https:\/\/pxs.md\/all\/embodied-ai-eai-safety\/",
            "title": "Конспект лекции про Embodied AI (eAI) Safety",
            "content_html": "<p class=\"lead\">Конспект лекции от Фила Купмана<\/p>\n<p>Чтобы охватить надежность «воплощенных» ИИ-систем с разных сторон, нужно разобраться в четырех областях:<\/p>\n<ol start=\"1\">\n<li>Системная безопасность \/ теория надежности<\/li>\n<li>Кибербезопасность<\/li>\n<li>Машинное обучение \/ искуственный интеллект<\/li>\n<li>Человеко-машинное взаимодействие (Human-Computer Interaction, HCI)<\/li>\n<\/ol>\n<h2>Ключевые вопросы<\/h2>\n<ol start=\"1\">\n<li>Что такое допустимый\/приемлемый риск?<\/li>\n<li>Какие актуальные вопросы стоят в индустрии?<\/li>\n<li>Переопределение и развитие системной безопасности в контексте интеллекутальных систем<\/li>\n<\/ol>\n<blockquote>\n<p>Люди совершают ошибки, но и компьютеры тоже<\/p>\n<\/blockquote>\n<h2>Концепты системной безопасности<\/h2>\n<ol start=\"1\">\n<li>Задача — снижение рисков. Нужны методы...\n<ul>\n  <li>Определения угроз и рисков<\/li>\n  <li>Снижение рисков и валидации принятых мер<\/li>\n<\/ul>\n<\/li>\n<li>Технологисекие аспекты\n<ul>\n  <li>Резервирование систем для повышения отказоустойчивости<\/li>\n  <li>Соответствие стандартам<\/li>\n  <li>Проектирование систем безопасными, а не только тестирование на безопасное поведение<\/li>\n<\/ul>\n<\/li>\n<li>Создание рабочей среды \/ культуры, где инструменты обеспечения безопасности реально используются, а не просто существуют для галочки<\/li>\n<\/ol>\n<h2>Анализ рисков<\/h2>\n<p class=\"loud\">Риск = Частота * ТяжестьПоследствий<\/p>\n<p>Простaя таблица рисков 2х2, которую используют для подобного анализа:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td style=\"text-align: center\"><\/td>\n<td style=\"text-align: left\">Тяжесть последствий<\/td>\n<td style=\"text-align: center\"><\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Частотность<\/td>\n<td style=\"text-align: center\">Низкая<\/td>\n<td style=\"text-align: center\">Высокая<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Низкая<\/td>\n<td style=\"text-align: center\">Низкий риск<\/td>\n<td style=\"text-align: center\">???<\/td>\n<\/tr>\n<tr>\n<td style=\"text-align: center\">Высокая<\/td>\n<td style=\"text-align: center\">Средний риск<\/td>\n<td style=\"text-align: center\">Высокий риск<\/td>\n<\/tr>\n<\/table>\n<p>Для кейса с маленькой частотностью, но тяжкими последствиями сложно математически рассчитать уровень риска, т. к. тут дело не в сухих цифрах, а в социальной приемлемости.<\/p>\n<p>Safety Integrity Level (SIL) — это уровень полноты безопасности, стандартизированный показатель, который количественно оценивает надёжность систем, предотвращающих аварийные ситуации.<\/p>\n<p>SIL задаёт, насколько вероятно, что система безопасности выполнит требуемую функцию в заданный момент времени — и тем самым предотвратит опасный отказ. Чем выше уровень SIL, тем строже требования к надёжности (в т.ч. технические) и тем ниже допустимая вероятность сбоя.<\/p>\n<p>SIL и требуемые меры проработаны во многих промышленных стандартах, но они только формируются для робототехнических \/ «вопрощенных» систем.<\/p>\n<h2>Вызов №1 — только негативные случаи имеют значение<\/h2>\n<p>Метрики надежности могут выглдяеть как:<\/p>\n<ul>\n<li>«99.999.999 vs. 99.999.998 км без инцидентов»<\/li>\n<li>«1 vs. 2 инцедента на 100.000.000 км»<\/li>\n<\/ul>\n<p>Первый и второй подход к показателям имеют разный акцент. В первом варианте системы практически идентичны, во втором — разница в два раза. <b>Метрики надежности формируются исходя из второго подхода.<\/b><\/p>\n<p class=\"loud\">Как следствие — единичная короткая поездка ничего не говорит о надежности системы.<\/p>\n<h2>Вызов №2 — редкие и тяжкие события<\/h2>\n<p>Какой уровень риска у событий с околонулевой вероятностью, но тяжелейшими последствиями?<\/p>\n<p class=\"loud\">zero probabilty * infinity cost = ???<\/p>\n<p>Аргументы с т.з. экономики, будут подталкивать оценить риск как низкий. Социальные и медийные аргументы будут подталкивать оценить риск как высокий.<\/p>\n<p>Философия оценки редких и тяжких событий зависит от прикладной области. По наблюдениям Фила Купмана, в автомобильной индустрии риск принимается скорее как низкий, а в авиации — как высокий.<\/p>\n<p>Один из ярких инцедентов в 2023г привел к закрытию бизнес-направления (см. дело Cruise <a href=\"https:\/\/en.wikipedia.org\/wiki\/Cruise_(autonomous_vehicle)\">https:\/\/en.wikipedia.org\/wiki\/Cruise_(autonomous_vehicle)<\/a> )<\/p>\n<p>Тем не менее, в 2025-м году General Motors возобонил проект и нанимает команду<br \/>\n<a href=\"https:\/\/www.bloomberg.com\/news\/articles\/2025-08-11\/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle\">https:\/\/www.bloomberg.com\/news\/articles\/2025-08-11\/gm-plans-renewed-push-on-driverless-cars-after-cruise-debacle<\/a><br \/>\n<a href=\"https:\/\/www.businessinsider.com\/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12\">https:\/\/www.businessinsider.com\/gm-hires-former-tesla-exec-ronalee-mann-self-driving-cruise-2025-12<\/a><\/p>\n<h2>Кибербезопасность<\/h2>\n<p><b>1. Целостность и доступность<\/b><\/p>\n<ul>\n<li>В eAI системах упор на целостности и доступности системы. То есть, юзер должен быть уверен, что автономный автомобиль не заражен зловредной программной, которая может повлияеть на его поведение. Вопрос конфеденциальности не стоит так остро как в онлайн-сервисах, т. к. машины и так на виду на дорогах и можно визуально отследить кто куда едет.<\/li>\n<\/ul>\n<p><b>2. Вредоносные ошибки<\/b><br \/>\nКибератаки могут перестроить уровни угроз, т. к. какой-то вид инцидентом может стать более частотным.<\/p>\n<p><b> 3. Физический доступ к устройству<\/b><br \/>\nЗлоумышленник может подключиться к eAI систете и провести более сложные манипулации, нежели с удаленным сервером.<\/p>\n<h2>ML<\/h2>\n<ol start=\"1\">\n<li>Обучается по примерам и отталкивается от статистики, вероятностей, частотности\n<ul>\n  <li>Модели не закладывают фундаментальные законы работы мира<\/li>\n  <li><i>[прим. АМ] для роботехники разрабатываются специальные модели, которые имеют представление о законах физики и причинно-следственных связей, но на уровне научных исследований<\/i><\/li>\n  <li>Машинное обучение несовместимо с Vee-моделью создания надежных технических систем.<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<p class=\"loud\">Тестирование — это не про доказательство корректности работы системы, а про проверку реализованных шагов при проектировании системы и адекватность процесса разработки.<\/p>\n<p>Машинное обучение учится на основе данных удовлетворять продуктовым требованиям. Как убедиться, что данные соотвествуют требованиям? Что в них точо есть, нужные примеры? Или наоброт — в них нет лишнего, что может повляить на обучение под требования? Система может обучаться непредсказуемо, что приводит к брутфорс-тестированию всего возможного и невозможного. На практике это невозможно, что еще раз подчеркивает, что тестирование не может обеспечить гарантию корректности работы системы.<\/p>\n<p><i>Тут видимо идейно про то, что нельзя сделать ТЗ для конкретных микро-фичей и ожидать корректность работы всей системы. Нельзя решить задачу надежности для ML в общем виде<\/i><\/p>\n<p>Что с этим делать? Уходить от абстрактной задачи обеспечения надежности к более конкретным. Проектировать дизайн эксперемента (датасеты и критерии успеха) так, чтобы можно было аргументированно рассказать почему разработчик системы считает, что это повышает надежность.<\/p>\n<h2>Human & eAI Safety<\/h2>\n<p>Человек плохо подходит для рутинной задачи контроля почти идеального автопилота<\/p>\n<ol start=\"1\">\n<li>Perception-Response Time (PRT)<\/li>\n<\/ol>\n<p>Людям нужно время, чтобы разобраться в ситуации и понять что делать дальше. У экспертов может вырабатываться мышечная память как поступать в тех или иных ситуациях, что ускоряет ответную реакцию.<\/p>\n<ol start=\"2\">\n<li>Ирония автоматизации удленяет PRT\n<ul>\n  <li>больше автоматизации ведет к меньшей практике людьми => во время отказа системы, у оператора может не хватить квалификации для своевременного принятия верного решения<\/li>\n  <li>предвзятость в пользу автоматизации (automation bias) — люди склонны доверять решению специализированной системы, а не себе. особенно, если система долгое время работает корректно<\/li>\n  <li>чем дольше система работает корректно, тем больше человек ей доверяет и тем сложнее быстро вмешаться, когда что-то идет не так<\/li>\n  <li>Ирония: чем эффективнее автоматика тем менее эффективен процесс контроля за ней со стороны людей<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<h2>Этическая и юридическая проблема<\/h2>\n<ol start=\"1\">\n<li>Кто отвественен за некорректное поведение eAI системы?<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Перекладывание отвественности на человека, не делает систему надежнее и безопаснее.<\/li>\n<\/ol>\n<blockquote>\n<p>Moral crumple zone («моральная зона смятия») — концепция, описывающая ситуацию, когда человек становится «буфером ответственности» в сбоях сложных автоматизированных или автономных систем.<br \/>\nТермин построен на аналогии с зоной смятия в автомобиле (энергопоглощающей частью кузова, которая деформируется при ударе, защищая пассажиров). В социотехнических системах «моральная зона смятия»: «поглощает» вину за сбой системы;<br \/>\nперекладывает моральную и юридическую ответственность на человека‑оператора;<br \/>\nзащищает репутацию и целостность технологии\/организации, жертвуя репутацией или правовым положением человека.<br \/>\nПонятие предложил исследователь Мэдлин Клэр Элиш (Madeleine Clare Elish) в работе «Moral Crumple Zones: Cautionary Tales in Human‑Robot Interaction» (2019). Она показала, как медиа и юридические системы часто упрощают причинно‑следственные связи, делая человека «удобным» виновником.<\/p>\n<\/blockquote>\n<h2>Известные проблемы...<\/h2>\n<p>...которые видны за последние годы пилотных запуском<\/p>\n<p><b>1. Ложные срабатывания систем безопасности автомобиля<\/b><\/p>\n<ul>\n<li>ненужные торможения и передача управления водителю<\/li>\n<li>автономный траспорт начинает вести себя непредсказуемо с т.з. других участников движения, что повышает риск аварии<\/li>\n<\/ul>\n<p><b>2. Непредсказуемость работы системы<\/b><\/p>\n<ul>\n<li>Какие гарантии, что система поведет себя точно так же в такой ситуации? Зачастую поведение недетрменировано, а ситуации хоть чуть-чутьт да различаются.<\/li>\n<li>Сколько раз система должна пройти тестовый сценарий, чтобы убедиться в корректности работы? Хватит ли одного раза? Десяти? Тысячи? Миллиона?<\/li>\n<\/ul>\n<p><b>3. Статистический подход при работе с надежностью<\/b><\/p>\n<ul>\n<li>Технические метрики для ML-систем в районе 90%-99% это супер-круто<\/li>\n<li>Но в задачах надежности нужны 99.9999999...% . Какие подходы могут добиться этих значений при обучении моделей?<\/li>\n<\/ul>\n<p><b>4. «Длинный (бескончный) хвост» редких и необычных случаев<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/image.png\" width=\"400\" height=\"400\" alt=\"\" \/>\n<\/div>\n<ul>\n<li>Как построить надежную eAI-систему, которая не может физически быть обучена на всех видах ситуаций?<\/li>\n<li>Нужен человеческий бекап + система должна понимать когда она не может работать<\/li>\n<\/ul>\n<p class=\"loud\">Безопасность — это не только про травмы и смерти, но и про неадекватное (рисковое) поведение.<\/p>\n<p>Например, Cruise заезжай на стройплощадки и не был готов к ситуациям, когда территория огорена подручными средствами.<\/p>\n<h2>Социальные риски из будущего<\/h2>\n<ol start=\"1\">\n<li>АТ может быть в среднем безопаснее, но иметь явный паттерн рискового поведения. Это ОК или НеОК?<\/li>\n<li>АТ приоритезириует безопасность людей в салоне относительно людей на улице.<\/li>\n<li>АТ может быть законопослушным, но что если другой участник движения нарушил ПДД и это сподвигает АТ нарушить ПДД, чтобы избежать рисковой ситуации? (механизм компенсации)<\/li>\n<li>Роботакси теоретичеки может не закончить поездку до конца и высадить пассажира в «плохом районе в плохое время».<\/li>\n<\/ol>\n<p>Безопасность включает в себя разные критерии успеха, которые важны разным стейкхолдреам. Не получится сделать одну метрику, которая докажет что система безопасна. Будет много ограничений, которые надо учитывать.<\/p>\n<h2>Юридические аспекты<\/h2>\n<p><b>Duty of Care for Human (осторожное поведение \/ забота)<\/b><\/p>\n<ol start=\"1\">\n<li>В Праве есть понятие «здравомыслящего человека», который соблюдает юридические и социальные нормы, что помогает предотвратить приченение вреда другим людям.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Пренебрежение этих норм можно описать как халатное поведение<\/li>\n<\/ol>\n<p><b>Duty of Care for Computers<\/b><\/p>\n<ol start=\"1\">\n<li>Текущий подход: ошибка на дороге = ошибка в проектировании системы = надо проводить тех.экспертизу, доказывать ее наличие именно в системе, а не окружающей среде, т. е. потенциальо не будет отвественного<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Предлагаемый подход: ошибка компьютера интерпретировать как ошибку человека, со всеми вытекающими последствиями которые будут наложена на производителя автономного транспорта<\/li>\n<\/ol>\n<p>Представим, что человек накатал миллион км и никого не сбил, хотя по статистике к этому моменту должно было быть 10 аварий. И на миллионном километре он сбил пешехода. Он не сможет защитить себя в суде аргументами в стиле «я катаюсь лучше среднего и у меня в запасе еще 9 ДТП». Судья отклонит этот аргумент.<\/p>\n<p>Производители автопилотов хотят оперировать статистикой для защиты своих интересов, а не фактом наличия нарушений.<\/p>\n<h2>Запутывающий слоган<\/h2>\n<p>Обратная сторона тезиса «автопилоты спасают жизни». Нужны другие слоганы<\/p>\n<ol start=\"1\">\n<li>Чтобы это доказать надо миллиарды киллометров<\/li>\n<li>Медийка не даст времени, чтобы это доказать.\n<ul>\n  <li>Любой прецидент будет использован, чтобы поставить под сомнение основной тезиc<\/li>\n  <li>Люди воспринимают истории, а не статистику<\/li>\n  <li>Фотка с ДТП имеет большой эффект наглядности, который будет бить любую статистику<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/ka-jvqwJtvA?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2026-01-10T01:53:16+03:00",
            "date_modified": "2026-01-10T15:11:00+03:00",
            "tags": [
                "Безопасность",
                "ИИ"
            ],
            "image": "https:\/\/pxs.md\/pictures\/image.png",
            "_date_published_rfc2822": "Sat, 10 Jan 2026 01:53:16 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/image.png",
                    "https:\/\/pxs.md\/pictures\/remote\/youtube-ka-jvqwJtvA-cover.jpg"
                ]
            }
        },
        {
            "id": "4",
            "url": "https:\/\/pxs.md\/all\/techphilosophy\/",
            "title": "Две тех.философии",
            "content_html": "<p><a href=\"https:\/\/stratechery.com\/2025\/tech-philosophy-and-ai-opportunity\/\">Бен Томпсон пытается систематизировать подходы разных компаний в области ИИ<\/a>.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg\" width=\"1280\" height=\"893\" alt=\"\" \/>\n<\/div>\n<p>Он предлагает 2х2 матрицу с разбивкой по «философии в отношении ИИ» и «влияние на существующую бизнес-модель».<\/p>\n<p>Если супер-кратко, то есть два лагеря:<\/p>\n<ol start=\"1\">\n<li>Софт (или ИИ в контексте 2025г от Рождества Христова) — это <a href=\"https:\/\/pxs.md\/all\/bicycle-of-the-mind\/\" class=\"nu\">«<u>the bicycle of the mind<\/u>»<\/a> как однажды выразился Стив Джобс еще до того, как стал носить черные водолазки. То есть, это человеческий усилитель.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Софт\/ИИ — это личный слуга, который делает вещи за человека.<\/li>\n<\/ol>\n<p>И битву этих двух якодзун мы и наблюдаем в медийном и финансовом пространстве.<\/p>\n<p><a href=\"https:\/\/stratechery.com\/2018\/techs-two-philosophies\/\">Бен подметил эти два лагеря еще в 2018<\/a> (а может и ранее) и периодически ссылается на это в текстах и развивает мысль.<\/p>\n<p>Борьба за трактовки и интерпретации как может и должен выглядеть прислужливый ИИ разгорячилась где-то в 2022-м вместе с бумом LLM и технологии трансформеров.<\/p>\n<p>Источник бума технооптимисты, учёные и инженеры во главе с Эндрю Ыном (Andrew Ng). В 2024-м он предложил свои <a href=\"https:\/\/www.deeplearning.ai\/the-batch\/how-agents-can-improve-llm-performance\/\">дизайн-паттерны для агентов<\/a>. Технари взяли их на вооружение и понесли в треды на твиттере и в презентации к инвесторам. <a href=\"https:\/\/askell.io\/\">Anthropic нанимает штатного философа, чтобы стройно излагать кто они и зачем<\/a>.<\/p>\n<p>Но пятью годами раньше, кмк, тон дискуссии задавали в дизайнерском сообществе. На ум мне приходят отличные книги, конференции и статьи, где практики рассказывают как строить полезные человекоцентричные интеллектуальные продукты.<\/p>\n<ul>\n<li>книга <a href=\"https:\/\/rosenfeldmedia.com\/books\/designing-agentive-technology\/\">Designing Agentive Technology: AI That Works for People<\/a> (<a href=\"https:\/\/uxmag.com\/articles\/designing-agentive-technology-ai-that-works-for-peopleобзорная\">статья от автора<\/a>)<\/li>\n<li>исследования и гайдбуки от <a href=\"https:\/\/pair.withgoogle.com\/\">People AI Research Group из Google<\/a><\/li>\n<li>еще в 2019м на <a href=\"https:\/\/sigchi.org\/\">ACM SIGCHI<\/a> учёные и практики рассказывали как систематизируют опыт и делают полезные умные продукты.<\/li>\n<\/ul>\n<p>Сейчас наблюдаю в нишевом проф.сообществе битву определений, виженов и стратегий.<br \/>\nДизайнеры делают ответный выпад. Готовятся новые книги, прототипируются новые продукты, формируются стили и паттерны:<\/p>\n<ul>\n<li><a href=\"https:\/\/rosenfeldmedia.com\/books\/sentient-design\/\">sentient design<\/a> (<a href=\"https:\/\/bigmedium.com\/speaking\/sentient-design-josh-clark-talk.htmlобзор\">автора<\/a>)<\/li>\n<li>в январе ждем <a href=\"https:\/\/rosenfeldmedia.com\/books\/designing-assistant-technology\/\">Designing Assistant Technology: AI That Makes Us Smarter<\/a><\/li>\n<\/ul>\n<p>Если максимально упростить, то:<\/p>\n<ul>\n<li>условная «башня дизайнеров» развивает концепции «велосипедов для ума» и систем которым «мы делегируем рутину, но все равно контролируем исполнение»<\/li>\n<li>условная «башня программистов» топит за полную автоматизацию (алгоритмизацию, стандартизацию, упрощение?) большой части нашей жизни, где потенциально внимание человека вообще не будет нужно.<\/li>\n<\/ul>\n<p>Кто победит? Как говорится, it depends.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/tg-poll-2025-12-27.png\" width=\"694\" height=\"332\" alt=\"\" \/>\n<\/div>\n",
            "date_published": "2025-12-27T14:00:00+03:00",
            "date_modified": "2026-01-12T19:30:36+03:00",
            "tags": [
                "ИИ",
                "Мировоззрение"
            ],
            "image": "https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg",
            "_date_published_rfc2822": "Sat, 27 Dec 2025 14:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "4",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-11-15.58.37.jpeg",
                    "https:\/\/pxs.md\/pictures\/tg-poll-2025-12-27.png"
                ]
            }
        },
        {
            "id": "56",
            "url": "https:\/\/pxs.md\/all\/fundamental-skills-for-engineering-manager\/",
            "title": "Фундаментальные скиллы инжиниринг-менеджера и их актуальность в разные «эпохи» IT-индустрии",
            "content_html": "<p class=\"lead\">Лидеры прошлого десятилетия с высокой вероятностью не будут хорошими лидерами в новом<\/p>\n<p><i>(не все готовы менять подходы и\/или не успевают учиться)<\/i><\/p>\n<p><b>Избранные слайды<\/b><\/p>\n<div class=\"e2-text-picture\">\n<div class=\"fotorama\" data-width=\"960\" data-ratio=\"1.7777777777778\">\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.13.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.15.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.16.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.17.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.18.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.20.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.21.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.22.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.23.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.24.jpeg\" width=\"960\" height=\"540\" alt=\"\" \/>\n<\/div>\n<\/div>\n<p><b>Делать то что?<\/b><\/p>\n<ol start=\"1\">\n<li>Находить время и силы на адаптацию к трендам.<\/li>\n<\/ol>\n<ol start=\"2\">\n<li>Развивайте «вкус».<\/li>\n<\/ol>\n<ul>\n<li>Например, я для этого погружаюсь в сложные научные труды, посвященные вопросам будущего, а также изучаю классику, находя сюжеты, которые перекликаются с настоящим.<\/li>\n<li>Очень сильно делаю акцент на системном анализе, умении проектировать и создавать концепты.<\/li>\n<\/ul>\n<ol start=\"3\">\n<li>Ну и т. к. про инжиниринг — прогайте. Например автор доклада как раз описывает свой недавний опыт в качестве СТО, но который стал делать много PR из-за доступных технологий-ассистентов. <a href=\"https:\/\/lethain.com\/coding-at-work\/\">https:\/\/lethain.com\/coding-at-work\/<\/a><\/li>\n<\/ol>\n<blockquote>\n<p>The new wave of AI tooling like Claude Code or OpenAI Codex are extremely susceptive to creating low-quality commits, but my experience is that used effectively they also provide several opportunities for creating useful code contributions are well. > > They are effective at:<\/p>\n<ol start=\"1\">\n<li>answering questions into a codebase, e. g. “what are our most common patterns for working with authn and authz? what are good examples of each?”<\/li>\n<li>writing code that fits the existing codebase’s patterns and structure, particularly with a well-written AGENTS.md’s guidance<\/li>\n<li>taking general feedback to revise the approach, e. g. “look for existing utilities that solve date math within our codebase and reuse those”<br \/>\nMost importantly, you can do each of those in a few minutes at a time. Between meetings at work, I generally pop back into one of several Claude Code sessions to see where it got to on a given task, review the code, and suggest next steps.<\/li>\n<\/ol>\n<p>It’s worth acknowledging that there’s a significant learning curve to doing this well. I’ve spent a meaningful amount of time in the last year learning to write software this way, and each month there are new caveats that I’ve had to understand. Slowly but surely, I’ve built a mental model of both how writing software with AI works, and how Imprint’s codebases work.<\/p>\n<\/blockquote>\n<p>Ссылки<\/p>\n<ol start=\"1\">\n<li><a href=\"https:\/\/lethain.com\/good-eng-mgmt-is-a-fad\/\">Статья «Good engineering management» is a fad<\/a><\/li>\n<li><a href=\"https:\/\/docs.google.com\/presentation\/d\/17lTreuVdYMNOr7k2XLzrshEJnB-StaNUzAyh9tE0b5w\/edit?slide=id.g39f551c2725_0_391#slide=id.g39f551c2725_0_391\">Весь набор слайдов<\/a><\/li>\n<li><a href=\"https:\/\/youtu.be\/IJlrX4Z4QWs\">Презентация на YouTube<\/a><\/li>\n<\/ol>\n",
            "date_published": "2025-11-23T01:00:00+03:00",
            "date_modified": "2026-01-23T10:04:00+03:00",
            "tags": [
                "Карьера"
            ],
            "image": "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.13.jpeg",
            "_date_published_rfc2822": "Sun, 23 Nov 2025 01:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "56",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "jquery\/jquery.js",
                    "fotorama\/fotorama.css",
                    "fotorama\/fotorama.js"
                ],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.13.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.15.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.16.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.17.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.18.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.20.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.21.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.22.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.23.jpeg",
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-00.32.24.jpeg"
                ]
            }
        },
        {
            "id": "55",
            "url": "https:\/\/pxs.md\/all\/data-analytics-without-context\/",
            "title": "Анализ данных без контекста",
            "content_html": "<p>Недавно коллега из роботов-доставщиков рассказал историю про раскапывание причины падения метрики.<\/p>\n<p><b>Одна из ключевых метрик в логистике — скорость доставки<\/b>. Наблюдают ее на дашборде, где выведена средняя по всему флоту. <b>Как-то раз эта метрика упала<\/b>. Смежники уверяют, что никаких радикальных изменений не делали, которые бы могли повлиять на скорость.<\/p>\n<p>Снарядили отряд аналитиков для выявления причины. Первая гипотеза — проблема где-то в приборах измерения.  Проверили всё: поставку данных, ETL, формулы, код, дашборды.<\/p>\n<p class=\"loud\">Нареканий нет, всё корректно.<\/p>\n<p>Вторая гипотеза — видимо, что-то меняли, но что? Релизов софта не было в момент наблюдения спада метрики.<\/p>\n<p>Перешли от аналитики средней скорости доставки флотом к просмотру перформанса индивидуально по роверу. Вывели среднюю скорость по дням для доставщика и увидели четкую ступеньку вниз. Причем для каждого ровера день ступеньки разный, но видно, что падения у всех доставщиков прошли в один временной период.<\/p>\n<p>Оказалось, что в этот период была смена зимней резины на летнюю. <b>Зимняя резина чуть больше в диаметре, и поэтому при одинаковой скорости вращения колес ровер проезжал больше и быстрее.<\/b><\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/wheel-size.png\" width=\"2000\" height=\"1000\" alt=\"\" \/>\n<\/div>\n<h2>So What?<\/h2>\n<p>«Чистого» анализа данных без детального знания операционных процессов зачастую не хватает, чтобы быстро и правильно сделать вывод. Изучайте бизнес, в котором работайте.<\/p>\n",
            "date_published": "2025-10-26T12:00:00+03:00",
            "date_modified": "2026-01-20T12:48:17+03:00",
            "tags": [
                "Цепочка рассуждений"
            ],
            "image": "https:\/\/pxs.md\/pictures\/wheel-size.png",
            "_date_published_rfc2822": "Sun, 26 Oct 2025 12:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "55",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/wheel-size.png"
                ]
            }
        },
        {
            "id": "57",
            "url": "https:\/\/pxs.md\/all\/future-of-product-roles\/",
            "title": "Будущее продуктовых ролей",
            "content_html": "<p>Вот какие тренды намечаются... ИМХО, касается всех продуктовых ролей.<br \/>\nИсточник: <a href=\"https:\/\/www.suffsyed.com\/futurememo\/why-im-leaving-design\">Why I’m Giving Up My Design Title—And What That Says About The Future of Design<\/a><\/p>\n<p>—-<\/p>\n<p>Сафф Сайед решил отказаться от должности Head of Design и перейти к роли технического специалиста в области ИИ. .loud По его словам, дизайн давно не успевает за прогрессом и перестал быть движущей силой индустрии.<br \/>\nТем, кто хочет оставаться значимым, придётся менять профиль своей деятельности.<\/p>\n<p>Главное из статьи:<\/p>\n<ol start=\"1\">\n<li>С появлением агентных систем и стремительным развитием ИИ <b>акценты сместились в сторону инженерии<\/b>, организации работы моделей и построения инфраструктуры для них<\/li>\n<li><b>Эпоха агентных систем меняет парадигму самих продуктов.<\/b> Интерфейсы будут генерироваться динамически, что делает статичный UI и роль классического продуктового дизайна менее актуальными<\/li>\n<li><b>Новый подход потребует совершенно иных навыков и инструментов<\/b>, которые сильно отличаются от тех, что дизайнеры использовали раньше<\/li>\n<li>Дизайн почти никогда не определяет инновации. <b>Ключевые открытия происходят в инженерии и продукте<\/b>, а дизайн остаётся поддерживающей силой<\/li>\n<li>Лидеры в новой реальности — это не руководители больших команд, а <b>люди, способные самостоятельно и быстро запускать решения с помощью ИИ<\/b><\/li>\n<li>Современные инструменты и библиотеки сделали <b>качественные интерфейсы и UX<\/b> доступными для всех, а значит, они <b>больше не дают решающего преимущества<\/b><\/li>\n<li>Сегодня <b>инженеры-одиночки<\/b> в области ИИ получают сверхвысокие зарплаты, потому что <b>могут выполнять действительно важную и коммерчески ценную работу за целые отделы<\/b>. На этом фоне дизайн обесценивается<\/li>\n<li><b>Будущее за специалистами «на стыке»<\/b>, которые понимают и устройство ИИ-систем, и опыт пользователей и могут встроить ИИ в продукт без упрощения до чата<\/li>\n<\/ol>\n",
            "date_published": "2025-08-23T01:00:00+03:00",
            "date_modified": "2026-01-23T00:45:05+03:00",
            "tags": [
                "Карьера"
            ],
            "_date_published_rfc2822": "Sat, 23 Aug 2025 01:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "57",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "58",
            "url": "https:\/\/pxs.md\/all\/three-stages-of-truth\/",
            "title": "Три стадии истины",
            "content_html": "<p>Предлагать идеи и притворять их в жизнь — это основа практически любой деятельности.<\/p>\n<p>Сегодня я услышал любопытные слова:<\/p>\n<p class=\"loud\">Любая истина проходит через три этапа: сначала её высмеивают, затем яростно отрицают, а затем воспринимают как нечто очевидное.<\/p>\n<p>Очень сильно срезонировало с моим настроением. Но прежде чем поделиться с широкой аудиторией этой мудростью, я захотел узнать, кто её автор, как выглядит первоисточник.<\/p>\n<p>Пока искал, повстречал много ИИ-галлюцинаций, которые приписывали авторство то героям в романе Достоевского, то главе Microsoft, то философам из какого-то цитатника афоризмов СССР.<\/p>\n<p>Но, как нечасто бывает, искал медь, а нашел золото. Добрый человек из Department of (!) Computer Science at University of Waterloo проделал работу за меня, но тоже так и не понял конкретного автора: <a href=\"https:\/\/cs.uwaterloo.ca\/~shallit\/Papers\/stages.pdf\">https:\/\/cs.uwaterloo.ca\/~shallit\/Papers\/stages.pdf<\/a><\/p>\n<p>С удовольствием прочитал эту небольшую работу и узнал много интересного исторического контекста, в котором развивались «три стадии истины».<\/p>\n<p>Как оказалось, эту фразу использовали многие инноваторы, чтобы замотивировать себя и окружающих не сдаваться и продолжать работать. Так и всякие шарлатаны, чтобы продвигать свои нерабочие идеи, прикрывались красивыми словами.<\/p>\n",
            "date_published": "2025-08-17T01:00:00+03:00",
            "date_modified": "2026-01-23T00:48:29+03:00",
            "tags": [
                "Мировоззрение"
            ],
            "_date_published_rfc2822": "Sun, 17 Aug 2025 01:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "58",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "59",
            "url": "https:\/\/pxs.md\/all\/long-story-short\/",
            "title": "Коротко о главном",
            "content_html": "<p>Как <a href=\"https:\/\/www.oxfordreference.com\/display\/10.1093\/acref\/9780191866692.001.0001\/q-oro-ed6-00019739\">сказал Уильям Эдвардс Деминг<\/a>, американский учёный, статистик и консультант по менеджменту:<\/p>\n<p class=\"loud\">In God we trust; all others must bring data<\/p>\n",
            "date_published": "2025-07-05T10:00:00+03:00",
            "date_modified": "2026-01-23T09:57:07+03:00",
            "tags": [
                "Мировоззрение"
            ],
            "_date_published_rfc2822": "Sat, 05 Jul 2025 10:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "59",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "60",
            "url": "https:\/\/pxs.md\/all\/research-as-product\/",
            "title": "Исследование как продукт",
            "content_html": "<p>Продакт в команде тех-ресерчеров Спотифай размышляет как объединить понятийный аппарат продуктовых команд и хардкорных ученых. Оба в процессе формулируют гипотезы и проводят эксперименты, но фокусируются на разном.<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-23-10.17.01.jpeg\" width=\"1200\" height=\"630\" alt=\"\" \/>\n<\/div>\n<p>Предлагается построить мостик от тех.ресерча (research scientists) к продуктовым командам и обратно.<\/p>\n<p>В этой первой статье описана ментальная модель для ресерчеров: исследование — это продукт учёных, продуктовая команда — это клиенты.<\/p>\n<p>В такой картине мира:<\/p>\n<p class=\"loud\">research is a product with Product teams as customers and users.<\/p>\n<p>А отталкиваясь от этой идеи можно начать задавать правильные вопросы с точки зрения полезности проводимой работы (адаптированный список из книги Inspired)<\/p>\n<blockquote>\n<p>Looking through the lens of the Product team being the customer, we can reformulate the risks as follows:<br \/>\n<b>Value Risk<\/b>: Will customers Product teams find the product research valuable enough to buy or use?<br \/>\n<b>Usability Risk<\/b>: Can users Product teams easily understand and interact with the product research?<br \/>\n<b>Feasibility Risk<\/b>: Can the product research be done with available resources?<br \/>\n<b>Business Viability Risk<\/b>: Does the product research align with the company’s overall business strategy and goals?<\/p>\n<\/blockquote>\n<p>Источник: <a href=\"https:\/\/research.atspotify.com\/2025\/02\/bridging-the-product-research-gap-part-i-demystifying-product-for-researchers\/\">Bridging the Product & Research gap — Part I: Demystifying Product for Researchers<\/a><\/p>\n<p>P.S.<br \/>\nЖду вторую часть материала про то, на что продактам следует обращать внимание при работе с учеными.<\/p>\n",
            "date_published": "2025-03-19T11:00:00+03:00",
            "date_modified": "2026-01-23T10:17:25+03:00",
            "tags": [
                "Карьера",
                "Мировоззрение"
            ],
            "image": "https:\/\/pxs.md\/pictures\/photo_2026-01-23-10.17.01.jpeg",
            "_date_published_rfc2822": "Wed, 19 Mar 2025 11:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "60",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-23-10.17.01.jpeg"
                ]
            }
        },
        {
            "id": "16",
            "url": "https:\/\/pxs.md\/all\/chart-that-influenced-youtubes-strategy\/",
            "title": "График от QuantUX-ресерчера, который повлиял на стратегию YouTube",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/photo_2026-01-12-17.48.33.jpeg\" width=\"1148\" height=\"1280\" alt=\"\" \/>\n<\/div>\n<p><a href=\"https:\/\/elizlaraki.substack.com\/p\/how-one-ux-researcher-ignited-sweeping\">История из бородатого 2010 года<\/a>, в которой общими мазками описывают как взяли кучу данных поведения пользователей на сайте, систематизировали их и отобразили визуально. И этот визуал стал настолько виральным внутри компании, что с ним печатали футболки и никому в YouTube не удалось увернуться от выводов, которые прилагались к графику.<\/p>\n<p>Герой этой истории был первым квант-ресерчером, затем переквалифицировался в dataviz-инженера и вернулся обратно в ресерч. Попутно родился вот такой чудесный темплейт для рисования sunburst-диаграмм.<\/p>\n<p><a href=\"https:\/\/observablehq.com\/@kerryrodden\/sequences-sunburst\">https:\/\/observablehq.com\/@kerryrodden\/sequences-sunburst<\/a><\/p>\n<p>Я таких историй прочитал много, но что важно:<\/p>\n<ul>\n<li>персонализированные продукты генерируют большой объем разнообразных паттернов<\/li>\n<li>с каждый годом персонализации в продуктах все больше и больше<\/li>\n<li>чтобы емко и понятно отобразить результаты исследования их надо не только систематизировать и упростить, но и эффективно отобразить.<\/li>\n<\/ul>\n<p>Поэтому подчеркиваю важность dataviz-скиллов и в целом навыки презентации своей работы. Современные персонализированные продукты, которые оперируют в разных странах, на разных платформах и для разных сегментов аудитории почти невозможно объяснить «простыми, понятными» и неэффективными инструментыми коммуникации.<\/p>\n<p>Тренд на усложнение инструментов аналитики виден и в других частях продуктовой работы.<br \/>\nВспомним, как постепенно индустрия отходит от воронок и чаще начинает оперировать траекториями путей пользователя, а линейные деревья метрик уступают места каузальным графам со сложными неявными связями между метриками. А это требует новых методов обработки информации (напр. сетевой анализ) и их отображения (напр. знания по укладки графов или изучение\/создание новых моделей визуализаций).<\/p>\n",
            "date_published": "2024-06-09T14:00:00+03:00",
            "date_modified": "2026-01-12T17:52:17+03:00",
            "tags": [
                "dataviz",
                "Инструменты"
            ],
            "image": "https:\/\/pxs.md\/pictures\/photo_2026-01-12-17.48.33.jpeg",
            "_date_published_rfc2822": "Sun, 09 Jun 2024 14:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "16",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/photo_2026-01-12-17.48.33.jpeg"
                ]
            }
        },
        {
            "id": "62",
            "url": "https:\/\/pxs.md\/all\/podcast-eto-schitaetsya\/",
            "title": "Подкаст «Это считается»",
            "content_html": "<p>Этот выпуск будет полезен не только аналитикам, но и маркетологам, продактам и вообще всем, кто связан с исследованиями. Можно сказать, что наш новый эпизод — аудио-чек-лист по ресерчу.<br \/>\nМы расскажем, с чего начать исследование, как не зарыться в детали и вовремя обновить прошлые результаты.<\/p>\n<p><a href=\"https:\/\/podcast.ru\/e\/4dWETzJPtu5\">https:\/\/podcast.ru\/e\/4dWETzJPtu5<\/a><\/p>\n<p>И для разбора этой хардовой темы мы позвали в гости Антона Марцена, аналитика с 10-летним опытом работы. Сейчас он руководит аналитикой в Яндекс Музыке и ведет телеграм-канал Product Science — <a href=\"https:\/\/t.me\/product_science.\">https:\/\/t.me\/product_science.<\/a><\/p>\n<p>Тайм-коды:<\/p>\n<p>00:00 Начало подкаста<\/p>\n<p>01:04 Гость подкаста — Антон Марцен<\/p>\n<p>03:26 Классификация исследований<\/p>\n<p>05:46 Все о личном опыте CustDev<\/p>\n<p>07:19 CustDev — пацанское название или нет?<\/p>\n<p>08:19 Обсуждаем подходы к исследованиям<\/p>\n<p>09:53 С чего начать ресерч, если нет данных<\/p>\n<p>12:19 Антипаттерны в анализе спроса на продукт<\/p>\n<p>16:24 Теория красных и голубых океанов<\/p>\n<p>17:42 Вспомнить всех: кто занимается исследованиями?<\/p>\n<p>20:09 Должен ли аналитик разбираться в UX<\/p>\n<p>24:44 Работа с отзывами<\/p>\n<p>26:24 Особенности продуктовой аналитики<\/p>\n<p>28:32 Фил о сложностях при проведении исследований<\/p>\n<p>30:23 Как понять, что пора перепровести ресерч<\/p>\n<p>32:02 Тревожные руководители и как с ними работать<\/p>\n<p>34:23 Доменная экспертиза: опыт Антона в Flo<\/p>\n<p>36:30 Материалы для прокачки навыков ресерча<\/p>\n<p>41:23 Способы развить насмотренность<\/p>\n<p>43:20 Рубрика «Перефразируй профессионально»<\/p>\n<p>44:59 Как не зарыться в исследования<\/p>\n<p>47:50 Подводим итоги<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/g8ubfI3RC40?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2024-04-08T00:00:00+03:00",
            "date_modified": "2026-03-09T12:31:53+03:00",
            "tags": [
                "Публичные выступления"
            ],
            "image": "https:\/\/pxs.md\/pictures\/remote\/youtube-g8ubfI3RC40-cover.jpg",
            "_date_published_rfc2822": "Mon, 08 Apr 2024 00:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "62",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/remote\/youtube-g8ubfI3RC40-cover.jpg"
                ]
            }
        },
        {
            "id": "65",
            "url": "https:\/\/pxs.md\/all\/the-feature-is-born-how-products-are-made\/",
            "title": "Фича родилась: как создаются продукты",
            "content_html": "<p>Это PLUS CAMP 2023 — встреча для техлидов и тимлидов от Яндекса. Здесь спикеры и гости обсудили работу в командах, управление проектами, тонкости экосистем и эксперименты с нейросетями. Ну и факапы, конечно.<\/p>\n<p>Это Светлана Ивахненко и Антон Марцен. Ребята рассказали, как создаются фичи и какую роль в этом процессе занимают аналитики и исследователи.<\/p>\n<p>Запись с мероприятия от 23 января 2024:<\/p>\n<div class=\"e2-text-video\">\n<iframe src=\"https:\/\/www.youtube.com\/embed\/9CVYC5z2Ylo?enablejsapi=1\" allow=\"autoplay\" frameborder=\"0\" allowfullscreen><\/iframe>\n<\/div>\n",
            "date_published": "2024-01-23T13:00:00+03:00",
            "date_modified": "2026-03-09T12:39:54+03:00",
            "tags": [
                "Публичные выступления"
            ],
            "image": "https:\/\/pxs.md\/pictures\/remote\/youtube-9CVYC5z2Ylo-cover.jpg",
            "_date_published_rfc2822": "Tue, 23 Jan 2024 13:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "65",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/remote\/youtube-9CVYC5z2Ylo-cover.jpg"
                ]
            }
        },
        {
            "id": "13",
            "url": "https:\/\/pxs.md\/all\/ux-pomehi-kak-instrument-sbora-signala-dlya-algoritmov\/",
            "title": "UX-помехи как инструмент сбора сигнала для алгоритмов",
            "content_html": "<p>Ключевые идеи из статьи <a href=\"https:\/\/www.smashingmagazine.com\/2023\/08\/friction-feature-machine-learning-algorithms\/\">Using Friction As A Feature In Machine Learning Algorithms<\/a>, дополненные небольшими фатками автора из личного опыта.<\/p>\n<p><i>NB! Слово «friction» в переводе с английского означает «трение» или «разногласие», что не совсем подходит в контексте пользовательского опыта. Поэтому далее по тексту я буду переводить «friction» как «помеху», т. к. счел это более подходящим вариантом. Теперь про идеи из статьи...<\/i><\/p>\n<h2>1. Иногда нужно локально усложнять пользовательский опыт, чтобы упростить его в целом<\/h2>\n<p>Популярные цифровые продукты оттачивают ключевые сценарии до состояния «действий в один клик (или вообще без него)». Есть даже известная в дизайн-сообществе <a href=\"https:\/\/archive.org\/details\/dont-make-me-think-revisited\">книга на тему<\/a>. Но как и любая механика бездумно доведенная до крайности, она может привести к нежеланным для бизнеса и\/или пользователя последствиям.<\/p>\n<p>Поэтому иногда проектироващики осознанно вставляют юзерам палки в колеса:<\/p>\n<ol start=\"1\">\n<li>Заставлять настраивать и\/или собирать доп.инфу перед начало использования приложения (<i>ох уж эти любимые N экранов в первой сессии, которые большинство людей пролистывают не глядя...<\/i>)<\/li>\n<li>Подталкивать к определенным действиям при помощи механик из поведенческой экономики (интересующиеся могут <a href=\"https:\/\/yandex.ru\/search\/?text=Nudge+Theory\">поискать Nudge Theory<\/a>)<\/li>\n<li>«Защита от дурака» при критический действиях (<i>напр., удаление данных<\/i>)<\/li>\n<\/ol>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/2-friction-delete-modal.png\" width=\"1600\" height=\"1200\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Модальное окно, которое заставляет задуматься и напрячься, чтобы реально удалить учетную запись<\/div>\n<\/div>\n<h2>2. UX-помехи позволяют отделять «сигнал» от «шума» и повышать качество рекомендаций<\/h2>\n<p>Для работы рекомендательных алгоритмов, продукт должен собирать сигналы от пользователя, обрабатывать их, а результат обратно отображать у пользователя. Думаю, если вы пришли в этот блог, то знаете это и без меня. Но на всякий случай прикладываю схему, которую сделал автор оригинального поста:<\/p>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/7-friction-signals.jpeg\" width=\"1600\" height=\"1200\" alt=\"\" \/>\n<div class=\"e2-text-caption\">Цикл обратной связи типичного сервиса с движком рекомендаций<\/div>\n<\/div>\n<p>В свое время Tinder ввел дизайн карточек, который фокусирует человека на одном профиле за раз и механику свайпов, которая явным образом собирала оценку от пользователя.<\/p>\n<p>TikTok взял эту механику на вооружение и довел до совершенства для своих целей — быстрее подстроиться под вкусы пользователя и затянуть в продукт. Но как это сработало?<\/p>\n<p>TikTok не стал использовать «традиционный» дизайн в виде витрины контента, который:<\/p>\n<ul>\n<li>позволяет широким взглядом охватить имеющийся каталог, но...<\/li>\n<li>мешает алгоритму недвусмысленно понимать что захватывает внимание пользователя, а что нет<\/li>\n<\/ul>\n<p>Получается, что эта механика ухудшила один аспект опыта (человек видит меньше контента за раз), но позволила быстрее подстраивать ленту и улучшить опыт взаимодействия с сервисом в целом.<\/p>\n<p>А еще, у TikTok в первой сессии нет привычного онбординга из нескольких экранов, где можно настроить приложение. Настройка происходит по мере скролла ленты, что сокращает время до получения ценности от продукта.<\/p>\n<p>В марте 2023 музыкальный сервис Spotify выкатил редизайн своего продукта, в котором показал ленту <i>а-ля<\/i> TikTok. Верховный продуктолог и по совместительству глав.инженер сервиса, <a href=\"https:\/\/www.theverge.com\/23638082\/spotify-redesign-gustav-soderstrom-tiktok-stream-podcasts-music-discovery\">обстоятельно объяснил<\/a> в интервью почему они радикально меняют интерфейс.<\/p>\n<blockquote>\n<p>“Секрет того, почему некоторые из продуктов так хороши в рекомендациях, на самом деле заключается не в том, что у них лучшие алгоритмы. Это те же самые алгоритмы с более эффективным пользовательским интерфейсом”.<br \/>\n— Густав Седерстрем в <a href=\"https:\/\/www.theverge.com\/23638082\/spotify-redesign-gustav-soderstrom-tiktok-stream-podcasts-music-discovery\">статье The Verge “Почему Spotify хочет выглядеть как TikTok”<\/a><\/p>\n<\/blockquote>\n<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/9-friction-spotify.gif\" width=\"800\" height=\"600\" alt=\"\" \/>\n<\/div>\n<p>Интересно, что их редизайн собирает хейт по интернету. Например, Mashable назвал <a href=\"https:\/\/mashable.com\/article\/worst-app-updates-2023\">новый интерфейс Spotify одним из худших обновлений 2023 года<\/a>. Но руководство музыкального сервиса готово мириться с критикой, т. к. в долгосроке верит в правильность своего решения.<\/p>\n<h2>So What?<\/h2>\n<p>В статье есть еще несколько рассуждений про потенциальное использование этой механики в будущем и в других ML-продуктах. Не обошлось и без упоминания модных нынче языковых моделей. И есть несколько советов как искать «полезные помехи», но они как-будто слишком абстрактные.<\/p>\n<p>В целом, метериал годный и содержит ряд полезных релевантных ссылок. Не зря потратил 15 минут на чтение. Можно ссылаться на него при рабочей необходимости.<\/p>\n",
            "date_published": "2023-08-20T22:35:00+03:00",
            "date_modified": "2026-01-12T01:45:55+03:00",
            "tags": [
                "UX",
                "Персонализация"
            ],
            "image": "https:\/\/pxs.md\/pictures\/2-friction-delete-modal.png",
            "_date_published_rfc2822": "Sun, 20 Aug 2023 22:35:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "13",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/2-friction-delete-modal.png",
                    "https:\/\/pxs.md\/pictures\/7-friction-signals.jpeg",
                    "https:\/\/pxs.md\/pictures\/9-friction-spotify.gif"
                ]
            }
        },
        {
            "id": "20",
            "url": "https:\/\/pxs.md\/all\/research-news-filter-bubble\/",
            "title": "Пользователи чаще ищут немейнстримные новости, если видят «линию партии»",
            "content_html": "<p>Вот что нам говорит свежая <a href=\"https:\/\/www.nature.com\/articles\/s41586-023-06078-5)\">заметка из журнала Nature<\/a>:<\/p>\n<blockquote>\n<p>People, not search-engine algorithms, choose unreliable or partisan news. Analysis of people’s web searches & visited websites suggests that it is more likely that they are choosing to engage with partisan or unreliable news than that they are being unduly exposed to it by search-engine algorithms.<\/p>\n<\/blockquote>\n<p><b>So What?<\/b><br \/>\nСтоит задуматься: а так ли силен эффект «пузыря фильтров» в новостных рекомендациях?<\/p>\n<p><i>Полный текст научной работы: <a href=\"https:\/\/disk.yandex.ru\/i\/8TPqnw-qPPdiMA\">Users choose to engage with more partisan news than they are exposed to on Google Search<\/a>.<\/i><\/p>\n",
            "date_published": "2023-07-03T00:00:00+03:00",
            "date_modified": "2026-01-12T23:43:06+03:00",
            "tags": [
                "Исследования",
                "Персонализация"
            ],
            "_date_published_rfc2822": "Mon, 03 Jul 2023 00:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "20",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "19",
            "url": "https:\/\/pxs.md\/all\/sreepiness-ditch\/",
            "title": "«Долина ужаса» в рекомендательных системах",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/sreepiness-ditch.jpeg\" width=\"1280\" height=\"847\" alt=\"\" \/>\n<\/div>\n<p>Источник: <a href=\"https:\/\/thedecisionlab.com\/insights\/technology\/this-is-personal-the-dos-and-donts-of-personalization-in-tech\">This is Personal: The Do’s and Don’ts of Personalization in Tech<\/a><\/p>\n",
            "date_published": "2023-07-02T00:00:00+03:00",
            "date_modified": "2026-01-12T23:32:58+03:00",
            "tags": [
                "UX",
                "Персонализация"
            ],
            "image": "https:\/\/pxs.md\/pictures\/sreepiness-ditch.jpeg",
            "_date_published_rfc2822": "Sun, 02 Jul 2023 00:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "19",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/sreepiness-ditch.jpeg"
                ]
            }
        },
        {
            "id": "14",
            "url": "https:\/\/pxs.md\/all\/recsys-in-different-cultures\/",
            "title": "Рекомендации в разных странах и культурах",
            "content_html": "<p>Информация воспринимается и интерпретируется человекам исходя из убеждений, ценностей и поведения. Эти характеристики формируются в личности под влиянием культуры в которой она растет и развивается.<\/p>\n<blockquote>\n<p>Культура — это коллективное программирование сознания, которое отличает членов одной группы или типа людей от других<br \/>\n<i>Герт Хофстеде, нидерландский социолог<\/i><\/p>\n<\/blockquote>\n<p>Исследователи находят корреляции в восприятии информации в зависимости от страны и культуры. Вот несколько исследований в контексте рекомендаций:<\/p>\n<ul>\n<li><a href=\"https:\/\/disk.yandex.ru\/i\/bODu2E71IbqU5g\">Exploring Music Diversity Needs Across Countries<\/a><\/li>\n<li><a href=\"https:\/\/disk.yandex.ru\/i\/xUIkg6ZSvDrtcg\">Personalization to New Website Users: The Role of Trust and Culture<\/a><\/li>\n<li><a href=\"https:\/\/disk.yandex.ru\/i\/vi5PmAWsN0dFAQ\">The Personalization-Privacy Paradox Explored Through a Privacy Calculus Model and Hofstede’s Model of Cultural Dimensions<\/a><\/li>\n<\/ul>\n<p><b>So What?<\/b><br \/>\nИзучение культурных особенностей поможет выдвинуть гипотезы для проверок. Например, можно решить вопросы онбординга в приложении и проблему холодного старта в алгоритмах рекомендаций.<br \/>\nНе стоит пренебрегать индивидуальными характеристиками человека. Это более важный фактор, с который нужно брать с бОльшим весом.<\/p>\n",
            "date_published": "2023-06-03T11:58:00+03:00",
            "date_modified": "2026-01-12T10:08:18+03:00",
            "tags": [
                "Исследования",
                "Культура",
                "Персонализация"
            ],
            "_date_published_rfc2822": "Sat, 03 Jun 2023 11:58:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "14",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "43",
            "url": "https:\/\/pxs.md\/all\/how-to-choose-research-approach\/",
            "title": "Подход к исследованию в зависимости от ситуации",
            "content_html": "<div class=\"e2-text-picture\">\n<img src=\"https:\/\/pxs.md\/pictures\/user-research-prioritization-framework-2.png\" width=\"1440\" height=\"994\" alt=\"\" \/>\n<\/div>\n<p>Jeanette Fuccella составила фрейморк для приоритизация исследований. Схема на картинке довольно говорящая, но вот две статьи для погружения:<\/p>\n<ol start=\"1\">\n<li><a href=\"https:\/\/dovetail.com\/blog\/research-method-discovery-product-management\/\">How to choose the right research methods for your discovery process<\/a><\/li>\n<li><a href=\"https:\/\/www.pendo.io\/pendo-blog\/a-tried-and-true-framework-for-prioritizing-user-research\/\">A Tried and True Framework for Prioritizing User Research<\/a><\/li>\n<li><a href=\"https:\/\/uxdesign.cc\/building-a-framework-for-prioritizing-user-research-ed46622ead99\">Building a framework for prioritizing user research<\/a><\/li>\n<\/ol>\n",
            "date_published": "2023-04-25T00:00:00+03:00",
            "date_modified": "2026-01-17T23:49:46+03:00",
            "tags": [
                "UX"
            ],
            "image": "https:\/\/pxs.md\/pictures\/user-research-prioritization-framework-2.png",
            "_date_published_rfc2822": "Tue, 25 Apr 2023 00:00:00 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "43",
            "_rss_enclosures": [],
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": [
                    "https:\/\/pxs.md\/pictures\/user-research-prioritization-framework-2.png"
                ]
            }
        }
    ],
    "_e2_version": 4171,
    "_e2_ua_string": "Aegea 11.4 (v4171e)"
}