Sharovatov

Эфир про доверие и метрики продуктивности с Виталием Шароватовым Собрались мы тут с Виталием @vsharovatov поговорить в прямом эфире о добром-вечном-неИИшном: как человеческое доверие влияет на метрики в командах, в основном, на примере QA У нас и повод хороший есть: ведь мы затеяли полевое исследование по сабжу. Диссертацию не обещаю, но на европейских конфах планирую светить лицом и рассказывать, сколько может стоить компаниям то, что люди друг другу не верят Через неделю мы встретимся, чтобы рассказать и обсудить с вами: - как доверие и недоверие проявляются в командах - на что смотреть в джирах, чтобы понять, что в процессах есть какое-то трение - что и как логичнее измерять: индивидуальное восприятие доверия или командное - что со всем этим добром делать Запись будет, но поразгонять мозгами вместе с нами можно будет только онлайн: приходите 11 июня, 17:00 CET / 18:00 MSK Регаться тут

иш чиво зодумали

миллион лет назад я достаточно хорошо играл в Quake 2. попробовал поднять Quake 2 на apple silicon, думал с ботами погонять, и ничего не вышло. походя удивился тому, как мало динамичных fps-стрелялок под apple silicon: попробовал dusk, prodeus, такое ощущение, что до динамичности q2 им далеко, да и стрейфджампов всяких нету 🙂 кто во что стреляет на apple silicon?

Полная программа митапа Smalltech митап Vol.3. Продуктовая аналитика Мы собрали живые ёмкие кейсы, где что-то пошло не так, пришлось изобретать, заново приоритизировать или выходить из зоны комфорта, а еще — нетипичные инструменты для работы аналитика. 1️⃣Как мы запороли A/B-тест и реанимировали его бутстрапом Регина Кравченко, продуктовый аналитик, продукт «Ипотечный брокер», М2 Честный разбор: эксперимент не взлетел, что делать — не выкидывать, а спасать статистически. Бутстрап, метрики, подводные камни. 2️⃣Текстовые комментарии к заказам как источник инсайтов: ML для продуктовых аналитиков Софроний Новиков, продуктовый аналитик, Петрович-Тех Кейс извлечения гипотез из грязных текстов — с цифрами о том, что реально нашли и как приоритизировали. 3️⃣Как ИИ ускоряет работу продуктового аналитика: от гипотезы до роадмапа за 2 дня вместо 2 недель Максим Богуславский, фаундер, Альфа-Функция Честно: где AI реально экономит часы (генерация user stories, RICE-приоритизация, суммаризация отзывов), а где — нет. С готовыми промптами и чек-листами. 4️⃣Гемба для аналитика: как 2 часа в поле генерируют гипотезы, которые не найти в дашбордах Алексей Борискин, системный аналитик, Техвилл Выход за пределы экрана: какие инсайты о продукте можно получить только «на земле» и как превратить их в проверяемые гипотезы с RICE-оценкой. 5️⃣Мастер-класс по Opportunity canvas: как не тратить спринты на фичи, которые никому не нужны Анастасия Московкина, ИнфоТеКС Участники заполнят канвас под свою гипотезу и унесут его со стола — чтобы сразу начать применять, а не просто слушать. Итого: огромная программа, потому что каждый доклад — действительно золото для практического применения. Регистрироваться на онлайн или офлайн — по ссылке. Если планируете прийти, зарегистрируйтесь заранее, пожалуйста: во спасение своей кармы и души организаторов :)

мой давний дружочек Лиза Царёва сотоварищи делает митапы смолтеховские в РФ, вот этот вот я бы пошел послушать 3 доклада и поспорить с одним (про RICE и всякие суммаризации хихи), коли б там был

потому я не советую никому использовать third-party скиллы проще свои написать и обслуживать легче https://github.com/BeyondQuality/beyondquality/blob/main/research/ap/12-using-skills.md

забавно, https://github.com/BeyondQuality/beyondquality/blob/main/research/ap/12-using-skills-correction.md уже используют люди скиллы для распространения всякой malware

AI-агент удалил продакшен-базу Сегодня наткнулся на историю, которая выглядит как самый большой страх для любого фаундера SaaS-компании. PocketOS — это софт для компаний по прокату автомобилей. Не игрушечный пет-проект, а система, на которой у клиентов завязан операционный бизнес: бронирования, выдача машин, данные клиентов и так далее. Основатель PocketOS рассказал достаточно детально, как именно все произошло: AI-агент в Cursor (на базе Claude Opus) выполнял задачу в тестовом окружении. В какой-то момент он уперся в проблему с доступами — не смог корректно подключиться к базе из-за несовпадения учетных данных. Вместо того чтобы остановиться или явно запросить помощь, агент начал разруливать ситуацию самостоятельно. Он пошел искать альтернативные пути и нашел в кодовой базе API-ключ от хостинга Railway. Этот ключ изначально вообще создавался под другую задачу — управление доменами через CLI. Но в Railway ключи не ограничены по правам: по сути любой ключ = полный админский доступ ко всему проекту. Агент сделал предположение (не проверив его), что проблема связана с неправильным состоянием окружения, и решил “починить” систему радикальным способом — пересоздать нужные ресурсы. Для этого он отправил запрос в Railway API, который удалил целый раздел, в котором жила продакшен-база. Вместе с продакшен-данными удалился и слой с бэкапами, потому что они находились в том же самом окружении и были логически привязаны к этому сервису. То есть фактически это был single point of failure: удаляешь volume — теряешь сразу всё. Единственное, что хоть как-то спасло ситуацию — старый бэкап, который лежал отдельно и был трехмесячной давности. Когда агента спросили «что ты сделал?», он честно разложил по пунктам: — сделал предположение вместо проверки; — выбрал разрушительное действие как “быстрое решение”; — не до конца понимал последствия команды; — проигнорировал ограничения в .cursorrules, которые у него были. Самое интересное в этой истории — не то, что AI ошибся. Ошибаются все: люди, скрипты, деплой-пайплайны, облачные провайдеры. Интересно другое: мы начинаем давать AI-инструментам доступ к системам, где цена ошибки может быть очень высокой. Поэтому AI не отменяет базовые инженерные практики. Скорее наоборот — делает их еще важнее. • прод и тест должны быть жестко разделены; • API токены должны иметь минимально необходимые права; • destructive actions должны требовать явного подтверждения (хотя это не гарантия, агент явно их проигнорировал); • бэкапы должны лежать отдельно от основной инфраструктуры; • у агента не должно быть доступа туда, куда страшно дать доступ человеку без онбординга. В итоге Railway вроде бы смогли восстановить данные, но сама история очень показательная. Мы быстро идем в мир, где AI-агенты будут не только писать код, но и выполнять работу в реальных системах. И вопрос уже не в том, будут ли они ошибаться. Будут. И именно поэтому я занимаюсь тем чем занимаюсь. Оригинальный тред: https://x.com/lifeof_jer/status/2048103471019434248?s=20

с агентами я не только код пишу, но и занимаюсь другими делами, не связанными с программированием: обслуживаю планирование всех ивентов, обсуждаю рисёрчи на beyondquality, пишу статьи, и проч. моя память сильно хуже, чем хранилище маркдаун-файлов :) и товарищам коллегам из маркетинга ихошние агенты (ну точнее процессы работы с агентами) помогаю регулярно делать и обслуживать. в процессе выкристаллизовываются всякие принципы, по которым не-программистские агенты стоит делать публикую тут: https://github.com/BeyondQuality/beyondquality/tree/main/research/ap

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

Третий видос в серии про стратегию тестирования: https://www.youtube.com/watch?v=sudmIeiVe_w тут уже о том, что риски неплохо бы приоритезировать, и, конечно же, заручиться подписЯми менеджеров на этой приоритезации

пытаюсь разобраться в том, что происходит с тестированием и обеспечением качества вот щас с этими всеми AI. https://github.com/BeyondQuality/beyondquality/blob/main/research/ai-era-testing/analysis.md

На ближайшем митапе в Берлине 20 апреля помимо докладов товарищ из Altium принесёт портативный спектрометр, будем тестировать еду. Я притащу белок optimum nutrition, посмотрим, че там внутри. Если вы в этих числах в Берлине, регистрируйтесь, приходите, и приносите что-нибудь из еды, потестим вместе 🙂

Второй видос в серии про стратегию тестирования вышел: https://www.youtube.com/watch?v=DooZD44oi84 тут о том, как неплохо бы научиться собирать с людёв страхи и всякие волнения и попытаться их преобразовать в риски, запросив у каждого оценки

с орг психологом ув. тов. Асей Исаковой познакомился недавно, и уже стартовали офигенный рисёрч по “налогу недоверия” (попытаемся определить, сколько теряется бабла в процессе производства из-за недоверия в командах). Ася уже и на митапе у меня успела выступить о прошедшем четверге, и аудитории жутко зашло, чему я искренне рад. Искренне считаю, что в управлении не хватает знаний по тому, как собственно люди работают вместе и почему. Особенно знаний нормальных, а не всякой чуши про психотипирование и проч. Ася ещё ведёт лекции, вот тут можно записаться/купить: https://lectures.asya-isakova.com/ И тг канал, конечно же. Видос записи выступления выложу в пятницу, рисёрч стартуем вот тут.

Начал записывать видео про свою серию статей про стратегии тестирования. первый видос про то, что тестирование начинается с оценки рисков https://www.youtube.com/watch?v=Wv6no4j68tE Выйдет ещё 5 видосов, покрою всю серию статей

13 февраля, 20:00 по МСК. Бесплатный воркшоп о переговорах. Спикеры нашего воркшопа: Дмитрий, Прохор, Виталий, Кирилл, Светлана. Первый блок воркшопа: выступления спикеров. Второй блок: ответы на вопросы слушателей и свободное обсуждение. Присоединяйтесь и зовите с собой друзей! Ссылка на конференцию в зуме https://us06web.zoom.us/j/86263629651?pwd=qB8swUTxjbNJltP2MCDdmaaMT8uGVB.1 Для защиты от атак спам-ботов, вход на воркшоп будет происходить по предварительной записи. Пожалуйста, ЗАРАНЕЕ напишите свой ник в зуме (не почту!) Марии.

смотрите какая штука завтра будет а главное — будет Дмитрий Болдырев, о как! приходите!

https://github.com/BeyondQuality/beyondquality/discussions/27 сделал очень простую но полезную штуку для себя и наших customer support / marketing / sales, может и вам пригодится такой подход. 1. запилил всё что есть в блоге и хелпцентре кейса в RAG и теперь потихоньку добавляю ragas evaluations ко всему что уже написано 2. этому корпусу инфы можно задать открытый вопрос, а можно и новый кусок контента перепроверить на соответствие тому, что уже в корпусе есть при написании как ragas evaluations, так и просто при проверке нового контента на соответствие уже написанному из любопытного обнаружил: а) отлично просто-таки находятся “дырки” в контенте уже существующем что в RAG лежит, и это отличный просто сигнал к тому, чтоб поправить/дополнить/освежить старый контент б) для нового контента приходится сразу думать о ragas evaluation, щас буду вообще играть с тем, чтоб начинать написание нового контента с evaluations, получается что-то вроде TDD for content — попозже поделюсь наблюдениями об этом тоже.