Sharovatov

Ищу команды для исследования влияния доверия на метрики продуктивности

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

Но нам с Виталием Шароватовым @vsharovatov захотелось копнуть в свое и нишевое: разобраться, как доверие между командами качества и разработчиками влияет на индекс продуктивности

Подробнее про наше исследование можно почитать тут: https://trust-research.org/

🔜 А вот какая нам нужна помощь:
Сейчас мы ищем QA и backend команды для того, чтобы собрать базу исследования. От вас — заполнить опросник доверия и собрать пару метрик из Джиры. От меня в благодарность — комментарии, на какие аспекты доверия стоит обратить внимание в вашей команде.

Буду благодарна любой помощи исследованию: и распространению информации, и вашей заявке на участие — заполнить тут

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

корреляцию найдём — и то хлеб
не найдём — тоже норм, будем менять методы поиска

вышел новый ISO 9001 (это про качество), пытаюсь купить пдфку на сайте
оплата не работает, просто показывает ошибку.
пробовал две карты, обе в порядке, проверил.

facepalm.

Если кто ещё не видел кайла и дээээээви, то советую:

https://youtu.be/8b-svBIDDD8

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

При этом человеческий “ресурс” внимания ограничен всё же.

Пока что FOMO “работает”, но продолжит ли?

https://arxiv.org/pdf/2603.14133

We find that both writing skill and CS achievement are significant predictors of vibe-coding performance, and that CS achievement remains a significant predictor after controlling for domain-general cognitive skills.

кто бы мог подумать — чем лучше коммуникационные скиллы и чем лучше понимаешь CS, тем лучше практикуешь разработку с LLM

*исследование корреляционное

как же красива французская деревня

товарищи, кто пользуется instagram/tiktok, скажите пожалуйста, кого-то крутого из технарей вы там знаете/смотрите регулярно?

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

В сентябре 2021 я пришёл в Qase

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

Спасибо тебе, @nik3r, за доверие, за изрядную автономность, крутую команду, и за возможность делать полезное для сообщества.

Эфир про доверие и метрики продуктивности с Виталием Шароватовым

Собрались мы тут с Виталием @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